Re: RDF named graph use case and requirement

Luc,

I was talking narrowly in the context of the way that provenance requirements 
might impact RDF design choices.

#g
--


On 22/09/2011 07:25, Luc Moreau wrote:
> Hi Graham,
>
> Do you mean my language or the datamodel specification language?
>
> The email was to prov-wg and used terminology we use all the time.
>
> It is our responsibility as a prov wg to explain how provenance should be expressed. if our explanation does not involve entities, what is the point of standardising a prov data model?
>
>
>
> Professor Luc Moreau
> Electronics and Computer Science
> University of Southampton
> Southampton SO17 1BJ
> United Kingdom
>
>
> On 22 Sep 2011, at 06:22, "Graham Klyne"<GK@ninebynine.org>  wrote:
>
>> I think that's not necessarily the case, and in any case the language you use here would not be recognizable someone who works only with RDF.  In framing requirements on proposed RDF designs, I don't think this helps.
>>
>> #g
>> --
>>
>> On 21/09/2011 22:28, Luc Moreau wrote:
>>> Hi Graham,
>>>
>>> I suppose that the other point to make is that a named graph is just a thing in the world and we need to charscterize it and as part of the provenance represent it by an entity expression + other provenance assertions.
>>>
>>> If the named graph implementation is such that the graphs are the same node, aren't we allowed to have two separate entity expressions to represent them?
>>>
>>> The problem seems similar to stateful resource.
>>>
>>> So, it seems it's not a requirement on named graphs but on provenance.
>>>
>>> Professor Luc Moreau
>>> Electronics and Computer Science
>>> University of Southampton
>>> Southampton SO17 1BJ
>>> United Kingdom
>>>
>>>
>>> On 21 Sep 2011, at 16:51, "Graham Klyne"<GK@ninebynine.org>   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 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.)
>>>>
>>>> #g
>>>> --
>>>>
>>>
>>>
>
>

Received on Friday, 23 September 2011 07:13:44 UTC