Re: ISSUE-385: hasProvenanceIn: finding a solution

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?
- Can you explain the  dcterms:identifier comment?

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?
- or have we got some form of ternary relation 
isContextualizationOf(e2,e1,bundle)?

Thanks,
Luc



>
> -Tim
>
>
>
>
>
>
>
>>
>> Luc
>>
>> On 31/05/2012 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
>