W3C home > Mailing lists > Public > public-prov-wg@w3.org > June 2012

Re: ISSUE-385: hasProvenanceIn: finding a solution

From: Timothy Lebo <lebot@rpi.edu>
Date: Mon, 4 Jun 2012 18:25:24 -0400
Cc: W3C provenance WG <public-prov-wg@w3.org>
Message-Id: <7316037A-AAA4-40E2-B0A3-90F0CC0AA175@rpi.edu>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>


On Jun 4, 2012, at 5:31 PM, Luc Moreau wrote:

> Hi Tim,
> Some comments/questions below.
> On 04/06/2012 13:46, Timothy Lebo wrote:
>> Luc,
>> On Jun 4, 2012, at 5:16 AM, Luc Moreau wrote:
>>> Hi all,
>>> During this diamond jubilee WE, I had the opportunity to think about Tim and Simon's long emails.
>>> I agree with them that we have concepts of alternate and specialisation, and we want to reuse them.
>>> I also came to the conclusion that behind the hasProvenanceIn relation, what I really wanted was a form of alternate. But not what Tim or Simon are suggesting.
>>> The PROV data model has a shortcoming: the inability to identify something in some context. That's what I am trying to address here.
>>> The interpretation of 
>>>        alternate(tool:Bob2, ex:Bob,ex:run2)
>>> is that tool:Bob2 is the entity that share aspects of ex:bob as described by ex:run2. Conceptually, this could be done by substituting ex:Bob for tool:Bob2 in ex:run2.
>>> I appreciate that what I am describing here is not too distant from http://www.w3.org/TR/2011/WD-prov-dm-20111215/#record-complement-of, which had optional account, and was not received with enthusiasm, to say the least.
>>> Coincidentally, Paul shared this paper 
>>> http://ceur-ws.org/Vol-614/owled2010_submission_29.pdf which introduces  rules of the kind
>>> X counts as Y in context C
>>> which bears some resemblance with what I am trying to argue for.
>>> So, my proposal is;
>>> - drop hasProvenanceIn
>>> - drop isTopicIn
>>> - allow for the ternary form of alternate
>>> Tim and Simon approach by using two binary relations do not offer the same level of expressivity.  
>>> The also have a technological bias, as well: they require querying/reasoning facility.  Therefore,
>>> their suggestion is not suitable for a data model supposed to be technology neutral.
>> A stab at:
>> bundle tool:analysis01
>>      alternate(tool:Bob2, ex:Bob,ex:run2)
>> endBundle
>> in PROV-O:
>> tool:analysis01 {
>>     tool:Bob2 
>>        prov:alternateOf [  ## The use here of bnode is, for once, actually appropriate :-)
>>            a prov:Entity;  prov:ContextualizedEntity;
>>            prov:identifier       ex:Bob;   ## The identifier that is used "over there"   Can't use dcterms:identifier b/c that is a rdfs:Literal.
>>            prov:inContext     ex:run2;   ## "over there"       Could prov:atLocation be reused?
>>        ];
>> }
> Thanks for this, Tim.
> First some questions:
> - why a bnode here?

bnodes are read "the thing that" and _can_ serve as an existential.

> - Can you explain the  dcterms:identifier comment?  

1) The value is the identifier used in the other bundle.
2) The rdfs:range of dcterms:identifier is a literal "http://foo.com", but it is more useful if it is a rdfs:Resource <http://foo.com>. With the former, we know that we can "try to go there" to dereference the URI.

> Now, assuming that this rdf encoding expresses what was originally suggested, some further questions:
> - have we got indeed a ternary alternateOf relation in prov-dm as I suggested?

Perhaps. The original binary that we now know and love, and a second ternary that "wraps" a URI and a Bundle (that mentions the URI).
The only new things would be:

1) The two new predicates prov:identifier and prov:inContext (perhaps that should just be called prov:inBundle -- I was swayed too far towards DCTerms when I chose that this morning).
2) The new rule to unwrap your ternary DM into this RDF structure.

> - or have we got some form of ternary relation isContextualizationOf(e2,e1,bundle)?

Or, just a binary isContextualized(e1,bundle)?

And we just stack on an existing alternateOf(e2,e1)...

BTW, not really sure where we're going with this.
It feels like we're close to wrapping this up, but worried that we're in some odd local minima.


> Thanks,
> Luc
Received on Monday, 4 June 2012 22:25:55 UTC

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