Re: RDF named graph use case and requirement

On 21/09/2011 23:27, Sandro Hawke wrote:
> [cc'ing public-prov-wg, but reply-to set to public-rdf-prov, where as I
> understand it this discussion should proceed.]
>
> On Wed, 2011-09-21 at 16:49 +0100, Graham Klyne wrote:
>> (I've also posted this summary at
>> http://www.w3.org/2011/prov/wiki/ProvenanceRDFNamedGraph#Requirement_from_discussion_with_Andy_Seaborne)
>>
>> 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
>
> ( quiet grumble about the use of the undefinable term "named graph"... )

Agree the term is not always hepful.  Do we have a better commonly-known term 
for such discussions?

>> 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.
>
> Isn't this just some modeling confusion?  Pra and Prb are each an event
> of the authoring of a statement (ie they are "statings"), not
> statements, based on how you use them, giving them dates and such.
> Those two statings can then be connected to the same statement (graph,
> G1).
>
> Pra statement G1; dc:creator A; dc:date "2011-09-19".
> Prb statement G1; dc:creator B; dc:date "2011-09-23".
>
> Then G1 can just be a literal, or whatever we use to allow conversations
> about g-snaps.

Yes, this is indeed a modelling choice.  As I note later, I wasn't dismissing 
the graph literal approach, just trying be expose the need, which might be 
addressed in different ways.

>
>> .....
>>
>> 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.
>
> It seems to me Pra and Prb are not g-snaps (RDF graphs), so there's no
> problem here.

Again, an interaction of modelling and design choices.  There *could* be a 
problem, depending on what choices are made.

#g
--

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

Received on Thursday, 22 September 2011 06:12:49 UTC