RDF Context Associations

Living Document,

This version:
https://knowledgeonwebscale.github.io/rdf-context-associations/
Issue Tracking:
GitHub
Inline In Spec
Editors:
(IDLab - Ghent University)
Pieter Colpaert (IDLab - Ghent University)
Not Ready For Implementation

This spec is not yet ready for implementation. It exists in this repository to record the ideas and promote discussion.

Before attempting to implement this spec, please contact the editors.

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 20 March 2025, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

Abstract

This specification describes the definition of general context associations in RDF using RDF graphs

1. Introduction

Context Associations is a modeling approach for modeling and interpreting a target reference consisting of a closed set of statements in RDF. The approach provides guarantees of remaining unambiguous under storage, exchange and processing in the Semantic Web ecosystem. Current models for signatures, provenance and policy information often do not specify explicit boundaries of their target information in the RDF ecosystem, relying on external interpretation or non-rdf processing to define target boundaries. The ability to define the target of these context definitions as a closed set of statements within the local scope enables the combined processing of these context definitions using the RDF stack.
Defining a set of statements as the target Dataset with associated origin. 
> Content-Type: text/trig;profile=https://w3id.org/ca/graph_occurence

@prefix dcat: <http://www.w3.org/ns/dcat#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix sign: <https://example.org/signature#>.


_:graph {
    <http://people.org/ruben> foaf:name "Ruben";
        foaf:age 28.
}

_:graph a dcat:Resource;
    dcterms:creator <http://people.org/ruben>;
    dcterms:created "2021-01-01"^^xsd:date.

_:signature a sign:Signature;
    sign:target _:graph;
    sign:issuer <http://people.org/ruben>.
    ...

To model target sets of statements, we make use of Named Graphs in RDF. § 2 Named Graph references defines the modeling requirements for these Named Graphs that enables uniform interpretation throughout the ecosystem. § 3 Blank Node Graphs defines the requirements for ensuring target sets of statements are closed in the local scope, making them immutable from external sources.

2. Named Graph references

Defining contextual information that targets a set of statements encompassed in a Named graph, the ability to reference the RDF Graph contained in the name-graph pair using its name identifier is required.

To enforce this interpretation, the RDF profile https://w3id.org/ca/graph_occurence can be defined on the source using profile negotiation in HTTP in an approach that enforces the above interpretation over the full data source:

> Content-type text/turtle;profile=https://w3id.org/ca/graph_occurence

_:graphName { ... }

Any RDF datasource retrieved advertising the profile https://w3id.org/ca/graph_occurence MUST interpret name identifiers of named graphs in its content as referencing the associated RDF Graph of the named graph.

todo: incorporate other expressions of profile negotiation

Alternatively, the interpretation can be hinted in the RDF scope by defining the name identifier of a named graph as an rdf:type of ca:GraphIdentifier.

@prefix ca: <https://w3id.org/ca/> .

_:graphName a ca:GraphIdentifier.
_:graphName { ... }

Any identifier defined with an rdf:type of ca:GraphIdentifer MUST be interpreted as referencing the associated RDF Graph of the named graph.

3. Blank Node Graphs

The definition of target sets of statements an Named Graphs, in addition to requiring the name identifier to reference the contained RDF Graph also requires the set of statements contained by this RDF Graph to remain unambiguous throughout its lifespan.

To enforce the unique definition of Named Graph, its name identifier MUST be defined as EITHER a Blank Node identifier, or as a Skolemized identifier in cases where external references are required to ensure the unique generation of the name identifier.

An example association providing user-signed usage access to a medical instance of government-signed user medical data using skolemized name identifiers for named graphs. 
@prefix sign: <https://example.org/signature#>.
@prefix prov: <https://example.org/provenance#>.
@prefix pol: <https://example.org/policy#>.
@prefix reg: <https://example.org/government/registry#>.
@prefix med: <https://example.org/government/medical#>.
@prefix skolem: <https://example/org/.well-known/skolem/8b98b360-9a70-4845-b52c-c675af60ad01#>.


skolem:policySignatureGraph {
    _:s a sign:Signature;
        sign:value "...";
        sign:target skolem:dataGraph ;
        sign:issuer <http://people.org/Ruben>.
}

skolem:policyGraph {
    _:p a pol:Policy;
        pol:permission [
            pol:target skolem:dataGraph ;
            pol:action pol:Read;
            pol:assigner <http://people.org/Ruben>;
            pol:assignee med:MedicalService.
        ].
}

skolem:dataSignatureGraph {
    _:s a sign:Signature;
        sign:value "...";
        sign:target skolem:dataGraph ;
        sign:issuer reg:CitizenDatabase.
}

skolem:dataGraph {
    <http://people.org/Ruben> foaf:name "Ruben".    
        foaf:age 28.
    med:PatientRecord19237128149 :targetUser <http://people.org/Ruben>.
        med:date "2021-01-01"^^xsd:date.
        med:doctor ...;
}

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119

Issues Index

todo: incorporate other expressions of profile negotiation ↵