Re: RDF named graph use case and requirement

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 UTC