The semantics of Named Graphs

I have trouble understanding the semantics of Named Graphs. I've read the article, but I can't figure out how it works, except on the particular case when there is only one single named graph. I would like to know, for instance, what is an interpretation of this (in TriG syntax):

g1 { :me :worksfor :deri .
     :me a :Man }
g2 { :worksfor rdfs:domain :Person }
g3 { :Man rdfs:subClassOf :Person }

and, more importantly, what can I infer from it. To be more general and more formal, let's say I have a set of pairs (g_i, T_i) where g_i is the name of a graph and T_i the set of triples in that graph. What is an interpreation of this set? What does it mean that an interpretation satisfies the set of named graphs? In other words, can anybody give me a formal semantics for named graphs?

Please, give me a formal answer, I do not understand English, I only understand mathematics ;-)

Edit (26/08/2010): In relation to this question, some may be interested in the answers to Which OWL reasoners understand Named Graphs

This is what I understand from reading Secs. 2 and 4 of "Named Graphs, Provenance and Trust" [1]. I might well have missed something or got something wrong.

The paper extends the abstract syntax of RDF [2] and the model-theoretic semantics of RDF [3] to take the notion of Named Graphs into account. From now on, whenever I talk about RDF, I mean it in this extended form, not in the original form.

Semantically, a Named Graph g is some resource in the universe of discourse with two specific features: a name (URI) and an associated RDF graph (set of RDF triples). So you can, as always, use an interpretation function I to interpret a name in an RDF graph by such a Named Graph resource. It is then possible to define what it means that an RDF graph containing Named Graphs (now seen as syntactic parts of the original graph, of course) is /satisfied/ by an interpretation I and a universe U, using a vocabulary V. Let's take your example RDF graph and call it G. G consists of three (syntactic) Named Graphs g1, g2 and g3. An interpretation I satisfies G, if:

  • the vocabulary V of I contains the three names (URIs) "g1", "g2" and "g3";

  • the universe U of I contains three named graphs ng1, ng2 and ng3

    • having "g1", "g2" and "g3" as their names, respectively,
    • and having the content graphs of g1, g2 and g3 as their associated RDF graphs (!!! NOTE: this last point is NOT said in the paper, but it is my own assumption, because it looks to me that this condition is accidentally missing !!!);
  • I maps the name "g1" to ng1, and likewise for the other Named Graphs.

Of course, the interpretation I has also to satisfy all additional semantic conditions of the respective entailment regime (e.g. RDFS). The above is just meant as the "diff" to the original notion(s) of satisfaction, as defined in the RDF Semantics [3].

Once the notion of graph satisfaction is defined, the standard notions of /consistency/ of a graph G ("there exists some satisfying interpretation for G"), and that a graph G1 /entails/ another graph G2 ("G2 is satisfied whenever G1 is satisfied") can then be defined in the traditional way.

Up to now, all we can say for your example graph G is that is is clearly satisfiable, since it is obviously possible to construct a universe containing the three named graphs g1, g2 and g3 as resources, and there are no other statements in G which might become a "thread" to consistency. I don't see anything interesting being entailed that would be a conclusion mainly due to the contained named graphs, though.

What we certainly want is making non-trivial assertions about the RDF graphs associated with the three Named Graphs. However, in the current state, all we can do is treating Named Graphs as resources, i.e. having their names occur in property assertions (triples with custom predicates) or class assertions (triples with rdf:type as predicate). The situation here is similar as for classes in RDFS: classes are regular resources in the first place, and in order to refer to their associated sets (their "class extensions"), one needs specially interpreted vocabulary terms. For classes, there is "rdf:type" (relates a resource to the set of a class) and "rdfs:subClassOf" (relates the sets of two classes). In [1], there is "rdfg:subGraphOf" to relate the RDF graphs of two Named Graphs. So you could add the following triple to your graph G:

g1 rdfg:subGraphOf g2 .

This would make your graph G inconsistent, since the triples in g1 do not build a subset of the triples in g2, and so there cannot be any interpretation which would satisfy your graph.

"rdfg:subGraphOf" obviously makes assertions on a /syntactic/ level of Named Graphs: it is about the relationship of triple sets, not about the semantic meaning of these triple sets. I could imagine other syntactic relationships not mentioned in [1], such as one for telling that a graph is ground, i.e. does not contain blank nodes ("g rdf:type rdfg:GroundGraph"; this statement would be true for all of your three Named Graphs), or that one graph is the merge of two others ("g rdfg:mergeOf (g1 g2)"), etc.

I could even imagine terms for expressing /semantic/ relationships, such as consistency of the associated RDF graph of a Named Graph ("g rdf:type rdfg:ConsistentGraph"), or entailment between the associated RDF graphs of two Named Graphs ("g1 rdfg:entailsGraph g2"). In this case, one would have to distinguish between the different entailment regimes of the RDF Semantics (Simple, RDF, RDFS, D; and probably taking Named Graph semantics into account there as well). So it would actually be something like "g1 rdf:type rdfg:RDFSConsistentGraph" and "g1 rdfg:RDFSEntailsGraph g2", etc.

This can all be formally specified, I guess. However, at least for the semantic relationships, I would not propose to introduce them without an in-depth analysis of their ramifications.

[1] <>
[2] <>
[3] <>

As I understand it, named graphs are just a convenient mechanism of "partitioning" a triple store (storing many independent but possibly related graphs in it). The convenience comes from the fact that the names for the named graphs are URIs, so you can refer to them in RDF statements (using for example the owl:imports property mentioned by Toby).

One use case for named graphs is when importing graphs from external sources. That way you can record provenance and other metadata against a particular named graph by making statements about its URI. You can work with the imported statements in one named graph without them interfering with statements in your other named graphs.

In OWL terms, when reasoning over g1, then g2 and g3 are ignored unless explicitly imported. Something like...

g1 {
     :me :worksfor :deri .
     :me a :Man .
     :g1 owl:imports :g2 , :g3 .

In RDF terms, "it depends."

Reading it seems that semantics for graphs are not well defined at all, at least for OWL. I suspect the same for RDFS.