W3C home > Mailing lists > Public > public-prov-wg@w3.org > September 2011

RDF named graph use case and requirement

From: Graham Klyne <GK@ninebynine.org>
Date: Wed, 21 Sep 2011 16:49:51 +0100
Message-ID: <4E7A079F.4060207@ninebynine.org>
To: W3C provenance WG <public-prov-wg@w3.org>
CC: Andy Seaborne <andy.seaborne@epimorphics.com>
(I've also posted this summary at 

In a meeting with Andy Seaborne this morning, we discussed provenance 
requirements and RDF named graphs, in light of some options that the RDF group 
might be considering.

The resulting requirement that we articulated was that for the purposes of 
provenance, we must be able to treat two "named" graphs with identical graph 
content as two distinct entities.


The use-case is this:

Suppose we have some resource R.

Observer A makes a provenance assertion about R on Monday 2011-09-19, which is 
expressed as an RDF graph Pra

Observer B makes a provenance assertion about R on Friday 2011-09-23, expressed 
as RDF graph Prb

To express provenance about the provenance assertions, we may wish to say:

Pra statedBy A; onDate "2011-09-19" .

Prb statedBy B; onDate "2011-09-23" .

It may be that the provenance assertions Pra and Prb have identical content; 
i.e. they are RDFG graphs containing identical triple sets.  For the purposes of 
provenance recording, it is important that even when they express the same 
graphs, Pra and Prb are distinct RDF nodes.  If Pra and Prb are treated as a 
common RDF node, one might then infer:

_:something statedBy A ; onDate "2011-09-23" .

which in this scenario would be false.


A particular consequence of this is that an RDF "named graph" specification 
based on graph literals (where RDF literals are self-denoting), somewhat like 
formulae in Notation 3, would have to be used with care.  That is, if Pra and 
Prb are graph literals, then Pra = Prb, and the given provenance-of-provenance 
statements could not be expressed as suggested above.

(This does not preclude a graph literal approach being used, but the above 
use-case might need to be constructed slightly differently.)

Received on Wednesday, 21 September 2011 15:51:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:08 UTC