- From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
- Date: Fri, 15 Jun 2012 18:35:45 +0100
- To: Timothy Lebo <lebot@rpi.edu>
- CC: public-prov-wg@w3.org
Tim, all, On 14/06/2012 12:39, Timothy Lebo wrote: > 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. To be clear, I didn't claim it *will* violate RDF semantics, just that I can see a possibility that it might. > > 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). I've studied the example, and as it stands I don't believe it would break RDF semantics. But that's because the proposal appears to be rather vacuous, by which I mean that I can't see any significant respect in which the example as given (per link above) is semantically different from the following, which does not use the prov:ContextualizedEntity construct: [[ ex:run1 { ex:Bob a prov:Entity; foo:bar "yes" . } tool:analysis01 { ex:Bob a prov:Entity } tool:Bob_as_in_run1 prov:specializationOf ex:Bob . tool:Bob_as_in_run1 tool:awesomeness "BAD PERFORMER". ]] I fully expect that you *intend* that the proposal does say more than the above, but I'm not seeing how that would work formally. When these additional semantics are introduced/clarified, that's when I anticipate the possibility of violating RDF semantics may raise its head. #g -- > 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 Friday, 15 June 2012 17:37:45 UTC