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: Thu, 14 Jun 2012 07:39:08 -0400
Cc: public-prov-wg@w3.org
Message-Id: <B08D59EB-24DB-49CB-A602-1820B1FC16C5@rpi.edu>
To: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
Graham,

The PROV-O form of contextualization is at http://www.w3.org/2011/prov/wiki/Bundle_contextualization

I'm curious how you think this will break RDF.

In particular, tool:Bob_as_in_run1 is not ex:Bob; they are both just resources that happen to relate in some way (with a predicate that we've added for contextualization).

Thanks,
Tim



On Jun 14, 2012, at 6:09 AM, Graham Klyne wrote:

> On 14/06/2012 07:44, Luc Moreau wrote:
> > The latest version of prov-dm contains a simplified
> > version of contextualizationOf worked out with Tim and Simon.
> 
> Are we referring to http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-contextualization ?  (retrieved 2014-06-14T11:06 (UK time)).  Does this replace "hasProvenanceIn"?
> 
> If so, I vote -1, for reasons I've already stated.  I don't think this fixes any problem.  I think the whole issue of contextualization, as described, is fraught with potential problems.
> 
> At the very least, I'd need to see how this plays out in RDF before I could drop my opposition to this - I still think there's a possibility here of violating RDF semantics if the URIs are used unmodified.
> 
> I apologize that I shall have limited availility to discuss this further this week, but I feel compelled to oppose this as I think it *could* be a serious mistake.
> 
> #g
> --
> 
> On 14/06/2012 07:44, Luc Moreau wrote:
>> Dear all,
>> 
>> The latest version of prov-dm contains a simplified
>> version of contextualizationOf worked out with Tim and Simon.
>> 
>> The solution is very much in line with ISSUE-260 raised by Tim,
>> since contextualizationOf is a special case of specialization.
>> 
>> 
>> I am proposing to close this issue pending review by the working group.
>> 
>> Cheers,
>> Luc
>> 
>> 
>> On 31/05/12 22:54, Luc Moreau wrote:
>>> All,
>>> 
>>> To try and converge towards a solution, I am
>>> circulating an example using a ternary hasProvenanceIn.
>>> I would like to understand if and how we can make it work with
>>> a simpler relation.
>>> 
>>> 
>>> Two bundles ex:run1 and ex:run2 describe bob's role as a controller
>>> of two activities. Same bob, two different bundles.
>>> 
>>> bundle ex:run1
>>> activity(ex:a1, 2011-11-16T16:00:00,2011-11-16T17:0:00) //duration: 1hour
>>> wasAssociatedWith(ex:a1,ex:Bob,[prov:role="controller"])
>>> endBundle
>>> 
>>> bundle ex:run2
>>> activity(ex:a2, 2011-11-17T10:00:00,2011-11-17T17:0:00) //duration: 7hours
>>> wasAssociatedWith(ex:a2,ex:Bob,[prov:role="controller"])
>>> endBundle
>>> 
>>> 
>>> A performance analysis tool rates the performance of agents (this could be used
>>> to dispatch further work to performant agents, or congratulate them, etc).
>>> 
>>> 
>>> bundle tool:analysis01
>>> 
>>> agent(tool:Bob1, [perf:rating="good"])
>>> hasProvenanceIn(tool:Bob1, ex:run1, ex:Bob) // Bob performance in ex:run1 is good
>>> 
>>> agent(tool:Bob2, [perf:rating="bad"])
>>> hasProvenanceIn(tool:Bob2, ex:run2, ex:Bob) // Bob performance in ex:run2 is bad
>>> 
>>> endBundle
>>> 
>>> The performance analysis tool has to rate two involvements of ex:Bob in two
>>> separate activities.
>>> Two specialized version of ex:Bob are defined: tool:bob1 and tool:bob2, with
>>> rating good and
>>> bad respectively.
>>> 
>>> tool:Bob1 is linked to ex:Bob in run1, and tool:Bob2 is linked to ex:Bob in
>>> run2, with the following
>>> 
>>> hasProvenanceIn(tool:Bob1, ex:run1, ex:Bob)
>>> hasProvenanceIn(tool:Bob2, ex:run2, ex:Bob)
>>> 
>>> Nothing is expressed about ex:Bob in bundle tool:analysis01 (except that this
>>> is an alias
>>> for tool:Bob1 and tool:Bob2).
>>> 
>>> It is suggested that the ternary relation could be replaced by
>>> isTopicIn(tool:Bob1, ex:run1)
>>> and
>>> specialization(tool:Bob1, ex:Bob).
>>> 
>>> I don't understand the point of
>>> isTopicIn(tool:Bob1, ex:run1)
>>> since tool:Bob1 is not a topic in ex:run1.
>>> 
>>> Also, we now seem to have made ex:Bob a topic of tool:analysis01, because
>>> the following expression.
>>> specialization(tool:Bob1, ex:Bob).
>>> 
>>> From tool:analysis01, where do I find provenance about ex:Bob?
>>> It look like this has become a dead end in this graph.
>>> 
>>> Do I need to introduce:
>>> isTopicIn(ex:Bob, ex:run1)
>>> isTopicIn(ex:Bob, ex:run2)?
>>> 
>>> 
>>> So now we would have:
>>> isTopicIn(tool:Bob1, ex:run1)
>>> specialization(tool:Bob1, ex:Bob)
>>> isTopicIn(tool:Bob2, ex:run2)
>>> specialization(tool:Bob2, ex:Bob)
>>> isTopicIn(ex:Bob, ex:run1)
>>> isTopicIn(ex:Bob, ex:run2)
>>> 
>>> Which means that:
>>> 
>>> specialization(tool:Bob1, ex:Bob)
>>> isTopicIn(ex:Bob, ex:run2)
>>> 
>>> ... would lead us to believe that good rating is due to slow performance.
>>> 
>>> Can the proposer of the separate binary relations explain how this example can
>>> work?
>>> 
>>> Thanks,
>>> Luc
>> 
> 
> 
Received on Thursday, 14 June 2012 11:39:52 UTC

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