TF-Graphs/RDF-Quadless-Proposal

This proposal is entitled "quadless", as it aims to talk about graphs in RDF even in standard (i.e. triple based) syntaxes (even RDF/XML). More generally, it tries to be minimally invasive to RDF semantics.

update: it happens that Ivan already published a similar but cleaner proposal. It is cleaner because it uses datatypes rather than dedicated properties to convey the semantics of g-texts.

Rationale and Syntax

The idea is to represent graphs (g-snaps) as resources, and describe them with their serialization. What we need minimally is a property rdf:xml-serialization that would link a graph to its RDF/XML serialization. We could of course define, similarly rdf:turtle-serialization, rdf:ntriples-serialization... The domain of all those properties would be a new class rdf:Graph .

A turtle example would then be

 @prefix : <http://example.org/> .
 :pchampin :states [
   a rdf:Graph ;
   rdf:turtle-serialization """
     @prefix : <http://example.org/>
     @prefix owl: <...> .
     :pchampin owl:sameAs :patHayes .
   """ ].

Semantics

The RDF semantics document would need the following additions:

• every interpretation contains a mapping IG from IR to the set G of all RDF graphs
• every interpretation is constrained in such a way that
  • if (I(E),I(F)) ∈ IP(rdf:xml-serialization),
  • then IG(I(E)) is the graph that one gets from parsing I(F)
  • (to be specified: ensure that blank nodes in that graph are not shared with any other graph, what if F is not valid RDF/XML...)

Link with other syntaxes

It is fairly easy to map syntaxes that allow graph literals into that proposal. For example, curly brackets in N3 could be understood as a shortcut for '[ rdf:n3-serialization """' and '""" ]' respectively.

For Trig or NQuad, we do not have to commit to a very strong semantics for the link between the "graph URI" and the graph itself. We can for example specify that the following Trig

 @prefix : <http://example.org> .
 :G1 { :a :b :c }

actually means

 @prefix : <http://example.org> .
 [ a rdf:Graph ;
   rdf:turtle-serialization """
     @prefix : <http://example.org> .
     :a :b :c .
   """ ;
   trig:label :G1
 ]

Link with named graphs and datasets

Named graphs (as defined in Carroll et al 1995) or SPARQL Datasets can easily be represented withing this framework.

If I understand named graphs correctly, the URIs paired with the graph are the actual names of those graphs, so it amounts to using URIs instead of blank nodes to represent the graphs:

 :G1 a rdf:Graph; rdf:xml-serialization "..." .
 :G2 a rdf:Graph; rdf:xml-serialization "..." .

In SPARQL Datasets, the relation is looser, so as with the Trig example above, we add a level of indirection.

 <my-dataset> a sparql:Dataset ;
   sparql:has-default-graph [ a rdf:Graph; rdf:xml-serialization "..." ] ;
   sparql:has-named-graph [
     sparql:name :G1 ;
     :graph [ a rdf:Graph; rdf:xml-serialization "..." ]
   ],[
     sparql:name :G2 ;
     sparql:graph [ a rdf:Graph; rdf:xml-serialization "..." ]
   ].

Mutability

As graphs are still immutable objects (g-snaps), a level of indirection has to be added if one wants to represent a mutable object. A simple g-box could for example be represented as

 <my-box> a box:GBox ;
   box:hasState [
     a rdf:Graph ;
     rdf:xml-serialization "..."
   ].

A more complex structure, such as a SPARQL 1.1 Graph Store, can as well be represented:

 <my-graph-store> a sparql11:GraphStore ;
   sparql11:has-default-slot [
     sparql11:graph [ a rdf:Graph; rdf:xml-serialization "..." ] ;
   sparql11:has-named-slot [
     sparql11:name :G1 ;
     sparql11:graph [ a rdf:Graph; rdf:xml-serialization "..." ]
   ],[
     sparql11:name :G2 ;
     sparql11:graph [ a rdf:Graph; rdf:xml-serialization "..." ]
   ].

or alternatively:

 <my-graph-store> a sparql11:GraphStore ;
   sparql11:has-state <my-dataset> .
 # where <my-dataset> is described as above