Graphs Design 6.1

This a proposed solution for the GRAPHS use cases. See List of Designs, Why Graphs, All Use Cases.

This is a refinement of Design 6 (Typed Labels).

It's applied to the Why Graphs uses cases here.

Syntax

The exchange syntax is trig. The data model is an RDF Dataset (as defined in the SPARQL specs and the current RDF WG drafts). Any trig document can be parsed to an RDF dataset; any RDF dataset can be serialized as a a trig document.

The default graph must be in braces. The trig syntax is essentially disjoint from the turtle syntax. (Only the empty document is both a valid turtle document and a valid trig document.)

ISSUE: maybe, for human readability, we can allow graphs to be spread throughout the document, so "<u1> { <a> <b> 1 } <u1> { <a> <b> 2 }" would parse to the same dataset as "<u1> { <a> <b> 1. <a> <b> 2 }"

Test (positive syntax)

{ <a> <b> <c> }
<u1>  { <a> <b> <c> }

Test (negative syntax)

<a> <b> <c>

Default Graph

The default graph is asserted. For a Trig document to be "true" the default graph must be "true".

Motivation: we need a way to carry metadata

Test

{ <a> <b> <c> }

ENTAILS

# ** TURTLE **
<a> <b> <c>

Test

# ** TURTLE **
<a> <b> <c>

ENTAILS

{ <a> <b> <c> }

Graph Labels

The graph label is an RDF subject identifier (an IRI term or a blank node label). That label can be used elsewhere in the same trig document to denote something, but in general we do not specify what that something is.

For the term <u1>, we can call that denoted thing: I(<u1>).

Test

@prefix owl: <http://www.w3.org/2007/owl#>.
{ <u1> owl:sameAs <u2> }
<u1> { <a> <b> <c> }

ENTAILS

<u2> { <a> <b> <c> }

Test

@prefix owl: <http://www.w3.org/2007/owl#>.
{ _:u1 owl:sameAs _:u2 }
_:u1 { <a> <b> <c> }

ENTAILS

_:u2 { <a> <b> <c> }

Blank Nodes

Blank node labels have file scope.

If you think blank nodes have to be scoped to some RDF graph, then imagine that every trig document has one big graph, in the background, and all the graphs serialized in braces-expressions in trig are subgraphs of that background graph.

Motivation:

• Sparql dump/restore
• Keeping inference results separate

Test

<u1> { _:a <b> 1 }
<u2> { _:a <b> 2 }

SPARQL Query:

ASK { GRAPH <u1> { ?s <b> 1 } 
      GRAPH <u2> { ?s <b> 2 } }

Returns

TRUE

Test

<u1> { _:a <b> 1 }
<u2> { _:b <b> 2 }

SPARQL Query:

ASK { GRAPH <u1> { ?s <b> 1 } 
      GRAPH <u2> { ?s <b> 2 } }

Returns

FALSE

Test

<u1> { _:a <b> 1 }
<u2> { _:a <b> 2 }

SPARQL Query:

ASK { GRAPH <u1> { ?s1 ?p1 ?o1 } 
      GRAPH <u2> { ?s2 ?p2 ?o2 } 
      FILTER ( ?s1 != ?s2 ) }

Returns

FALSE

The Labeling Relation

A trig document expresses an rdf:hasGraph relation between the graph label object and the RDF Graph. This relationship is functional; that is, for any one subject there is at most one value.

Test

<u1> { <a> <b> <c> }

ENTAILS

{ <u1> rdf:hasGraph _:x }

Test

INCONSISTENT:

@prefix owl: <http://www.w3.org/2007/owl#>.
{ _:a rdf:hasGraph 1. }
_:a { <a> <b> <c> }   #  could only be true if 1 == { <a> <b> <c> }

Test

INCONSISTENT (or could be syntax error):

<u1> { <a> <b> 1 }
<u1> { <a> <b> 2 }

Test

INCONSISTENT:

@prefix owl: <http://www.w3.org/2007/owl#>.
{ _:a owl:sameAs _:b }
_:a { <a> <b> 1 }
_:b { <a> <b> 2 }

rdf:Graph class

We define the class rdf:Graph such that for its instances, the rdf:hasGraph relation is the identity relation. That is, a Graph hasGraph itself.

Test

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
{ <u1> rdfs:comments "A good graph", a rdf:Graph. }
<u1> { <a> <b> <c> }   # u1 *is* this graph
<u2> { <a> <b> <c> }   # u2 merely *has* this graph

DOES NOT ENTAIL

{ <u2> rdfs:comments "A good graph" }

Test

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
{ <u1> rdfs:comments "A good graph", a rdf:Graph.
<u2> a rdf:Graph. }
<u1> { <a> <b> <c> }  # u1 is this graph
<u2> { <a> <b> <c> }  # u2 is the same graph, so u1=u2

ENTAILS

{ <u2> rdfs:comments "A good graph" }

Extensions

Additional modes of using trig can be handle by defining new classes for the labels. For example, future work might define a class rdf:GraphStateResource such that this trig document:

{ <http://example.org/a> a rdf:GraphStateResouce. }
<http://example.org/a> { <a> <b> <c> }

would mean that (at some unspecified point in time) the Web Resource with the address "http://example.org/a" is/was/will-be represented by the graph { <a> <b> <c>. }

Closing Issues

This proposal answers the open GRAPHS issues:

5 - Should we define Graph Literal datatypes?

No

14 - What is a named graph and what should we call it?

A "named graph" is an RDF Graph which happens to appear in one of the label+graph pairs in some RDF Dataset

15 - What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc

It is a functional relationship called rdf:hasGraph, which has no other semantics, in the general case

17 - How are RDF datasets to be merged?

Merge the default graphs. Any graphs with different labels remain distinct. It is a logical inconsistency to have the same label on different graphs.

21 - Can Node-IDs be shared between parts of a quad/multigraph format?

Yes

22 - Does multigraph syntax need to support empty graphs?

Yes.

23 - Does going from single-graph to multi-graph require new format and new media types?

Yes. Turtle and Trig will have different media types.

28 - Do we need syntactic nesting of graphs (g-texts) as in N3?

No. The use case ":alice :says { :bob :says { :s :p :o } }" can be handled as

{ :alice :says _:g1 }
_:g1 { :bob says _:g2 }
_:g2 { :s :p :o }
# the domain of :says is rdf:Graph, so we don't need to declare it

29 - Do we support SPARQL's notion of "default graph"?

Yes.

30 - How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?

They are the same notion. Inference concerning rdf:hasGraph and rdf:Graph may be supported by future versions of SPARQL Entailement Regimes.

31 - Do we produce a standard (REC) syntax for conveying multiple graphs?

Yes, trig.

32 - Can we identify both g-boxes and g-snaps?

Yes. In the example above, g-boxes are shown as GraphStateResources and g-snaps as rdf:Graph. (g-boxes will not be identifiable in a standard way unless we define a suitable class.)

33 - Do we provide a way to refer to sub-graphs and/or individual triples?

Yes, by copying the sub-graphs or triples into new labelled curly-brace expressions

35 - Should there be an rdf:Graph construct, or something like that?

Not really -- I think the sense of the issue is whether there will be a vocabulary for taking apart rdf:Graph instances, for talking about which rdf:Statements they contain, etc. That could be done, but isn't part of this proposal.

38 - What new vocabulary should be added to RDF to talk about graphs?

Just rdf:Graph and rdf:hasGraph, for now.