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

Re: RDF named graph use case and requirement

From: Graham Klyne <GK@ninebynine.org>
Date: Mon, 26 Sep 2011 14:49:12 +0100
Message-ID: <4E8082D8.8020500@ninebynine.org>
To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
CC: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, W3C provenance WG <public-prov-wg@w3.org>
On 26/09/2011 14:17, Stian Soiland-Reyes wrote:
> On Fri, Sep 23, 2011 at 07:26, Graham Klyne<GK@ninebynine.org>  wrote:
>
>
>> If one wants to be able to treat these as two different descriptions made by
>> different people, even if they have the same text, then one must choose a
>> different modeling approach in RDF, such as:
>
> So you are saying that if we are to use graph literals as a way to
> represent named graphs, but we want to somewhat describe that two
> different processes produced the same named graph *structure*, we need
> to introduce two prov:entities, as otherwise RDF semantics means they
> are the same node.

You'd need to introduce additional graph *nodes*, but don't think they would 
necessarily be prov:Entities.  I think they would be closer to Events denoting 
the act of recording the provenance.

e.g. instead of

   ex:someEntity --hasProvenance--> (provenancegraphliteral)

one might need to use something like this:

   ex:someEntity --hasProvenance--> _:bNode --hasValue--> (provenancegraph)

then, e.g., provenance author and date information could be attached to the 
bNode, as there may be two or more distinct provenance statements that refer to 
the same literal:

   ex:someEntity --hasProvenance--> _:bNode1 --hasValue--> (provenancegraph)
               \                                           /
                 --hasProvenance--> _:bNode2 --hasValue-->

> As you stated, the same argument can be used for other literals, which
> is why if in the workflow example two process executions both output
> the string value "Fred", those two Freds will have to be expressed as
> two entities with two different identities within the provenance
> assertions. (Both can have attribute value="Fred")

Yes, that makes sense.  The entities in this case would serve the role of the 
bNodes in my example, I think.

> This sounds all in line with how PROV is at the moment. So you could
> have two entities, which have the characterising attribute "graph"
> pointing to the very same graph literal.  Each of these entities can
> then have independent histories and wasGeneratedBy statements.

That may work fine until you want to record the provenance of the provenance 
itself.  I think the two entities would necessarily have different provenance 
records, even though the stated provenance itself may be the same - how are 
wasGeneratedBy statements attached to the provenance itself?

#g
--
Received on Monday, 26 September 2011 15:33:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:42 GMT