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

Re: PROV-ISSUE-385 (haProvenanceIn-complexity): The hasProvenbanceIn relation is over-complicated [prov-dm]

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Wed, 30 May 2012 08:08:17 +0100
Message-ID: <EMEW3|5650dbfa48caca9ea09c070f5f7dac50o4Y88L08L.Moreau|ecs.soton.ac.uk|4FC5C761.7090309@ecs.soton.ac.uk>
To: public-prov-wg@w3.org
Hi Simon

The second use case I have is the following.
Same bundles ex:run1 and ex:run2

     bundle ex:run1
      agent(ex:Bob)  //bob-in-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
      agent(ex:Bob)
      activity(ex:a2, 2011-11-17T10:00:00,2011-11-17T17:0:00)  
//duration: 7hours
      wasAssociatedWith(ex:a2,ex:Bob,[prov:role="controller"])
     endBundle


Now, a visualization tool renders each bundle separately.
For the first bundle, the agent Bob is displayed on the left, and  for 
the second
it is on the right.


     bundle viz:run1
       entity(ex:Bob, [screen:position="left"])            //bob-in-viz-run1
       hasProvenanceIn(ex:Bob, ex:run1, ex:Bob)     // equivalent to 
hasProvenanceIn(ex:Bob, ex:run1, -)
     endBundle


     bundle viz:run2
       entity(ex:Bob, [screen:position="right"])
       hasProvenanceIn(ex:Bob, ex:run2, ex:Bob)
     endBundle

Here the tool reused identifier ex:Bob (this is compatible with our 
approach of reusing existing identifiers).

What I am trying to say here is that
bob-in-viz-run1 is a specialization of bob-in-run1, seen as a entity 
with its own fixed facets.

But obviously
specializationOf (ex:Bob, ex:Bob) ... does not capture that.

Even If we had used a different identifier for Bob

     bundle viz:run1
       entity(viz:Bob, [screen:position="left"])            
//bob-in-viz-run1
       hasProvenanceIn(viz:Bob, ex:run1, ex:Bob)     // equivalent to 
hasProvenanceIn(ex:Bob, ex:run1, -)
     endBundle

I am not trying to say that viz:Bob specializes ex:Bob in all his 
occurrences, but only in the context of ex:run1.

Luc



On 05/29/2012 10:01 AM, Luc Moreau wrote:
> Hi Simon and Jim,
>
> Whether we have an id and/or attributes is a secondary question. What 
> we need
> to clarify is what the concept are involved in this relation.
>
> In principle, I am in agreement with you. In practice, I don't think 
> we can do
> it with the current alternate relation.
>
> Here is my use case:
>
>
>     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
>
>
>     bundle tool:analysis01
>
>       entity(tool:Bob1, [perf:rating="good"])
>       hasProvenanceIn(tool:Bob1, ex:run1, ex:Bob)  // Bob performance
>     in ex:run1 is good
>
>       entity(tool:Bob2, [perf:rating="bad"])
>       hasProvenanceIn(tool:Bob2, ex:run2, ex:Bob)  // Bob performance
>     in ex:run2 is bad
>
>     endBundle
>
>
>
> In the bundle tool:analysis01, a tool rates the performance of agents 
> in other bundles.
> ex:Bob performance in ex:run1 is good, and bad in ex:run2.
>
> If, as you suggest, I use
>  alternate(tool:Bob1,ex:Bob)
> instead of
>   hasProvenanceIn(tool:Bob1, ex:run1, ex:Bob)
> we do not make explicit the context in which ex:Bob is rated.
>
> Simon seems to suggest we could have a specializationOf over bundles.  
> I think it's too coarse granularity,
> and it wouldn't help in this case.
>
> Luc
>
> On 05/29/2012 09:40 AM, Miles, Simon wrote:
>> I tend to agree with Graham and Jim.
>> The hasProvenanceIn relation is not a description of provenance, it 
>> is about locations of provenance data. It seems unnecessary to apply 
>> the same rules as for relations describing the past.
>> In particular, I'm not clear how attributes should be interpreted for 
>> hasProvenanceIn: attributes of what? If we mean metadata about the 
>> bundle pointed to, e.g. its format, I think this goes beyond 
>> provenance and would ideally be left to serialisations to 
>> appropriately address.
>> Having an ID makes sense for entity(), activity(), agent() etc. 
>> because we are giving an identifier to something referred to in 
>> other PROV descriptions. I'd argue we don't need a general rule of 
>> identifying every description, because it's not obviously about 
>> provenance and any given serialisation could easily do that where 
>> required.
>> I agree with Jim that it seems important to use alternateOf here: 
>> this seems like the situation that specialisationOf/alternateOf were 
>> really designed for. Linked bundles with different IDs for the same 
>> entity seem most likely where different asserters provide provenance 
>> on the same entity or one asserter provides different accounts of the 
>> provenance of an entity. Each bundle then takes a particular 
>> perspective on the entity. Where we can be more precise and say one 
>> bundle's perspective is a specialisationOf the other, that is even 
>> better.
>> thanks,
>> Simon
>> Dr Simon Miles
>> Senior Lecturer, Department of Informatics
>> Kings College London, WC2R 2LS, UK
>> +44 (0)20 7848 1166
>> accounting for the reasons behind contractual violations:
>> http://eprints.dcs.kcl.ac.uk/1283/
>> ------------------------------------------------------------------------
>> *From:* Jim McCusker [mccusj@rpi.edu]
>> *Sent:* 28 May 2012 21:59
>> *To:* Luc Moreau
>> *Cc:* public-prov-wg@w3.org
>> *Subject:* Re: PROV-ISSUE-385 (haProvenanceIn-complexity): The 
>> hasProvenbanceIn relation is over-complicated [prov-dm]
>>
>> Can't that be decomposed into:
>>
>> hasProvenanceIn(ex:report1,bob:bundle4)
>> alternateOf(alice:report1, ex:report1)
>>
>> ?
>>
>> We should focus on re-using constructs rather than implicitly 
>> re-introducing them into relations like this. Especially since the 
>> idea of a target is entirely optional, as bob and alice may already 
>> be using the same URIs.
>>
>> Jim
>>
>> On Mon, May 28, 2012 at 4:26 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk 
>> <mailto:L.Moreau@ecs.soton.ac.uk>> wrote:
>>
>>     Hi Graham,
>>
>>     Like PROV-AQ, we need a target.
>>     Example 47 illustrates the need for it:
>>
>>      hasProvenanceIn(alice:report1, bob:bundle4, ex:report1)
>>
>>     In the current bundle, there is a description for alice:report1.
>>     More provenance can be found for it in bundle bob:bundle4, under
>>     the name ex:report1.
>>
>>
>>     The presence of attributes and id follow the pattern of other
>>     qualified relations.
>>
>>     Luc
>>
>>
>>     On 28/05/12 20:01, Provenance Working Group Issue Tracker wrote:
>>
>>         PROV-ISSUE-385 (haProvenanceIn-complexity): The
>>         hasProvenbanceIn relation is over-complicated [prov-dm]
>>
>>         http://www.w3.org/2011/prov/track/issues/385
>>
>>         Raised by: Graham Klyne
>>         On product: prov-dm
>>
>>         I'm raising this issue as a placeholder and for discussion.
>>          I didn't notice the arrival of prov:hasProvenanceIn, but
>>         based on its appearance in
>>         http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120525/prov-dm.html
>>         (which AFAIK is not a currently active draft, but a proposal)
>>         is rather over-complicated and a bit obscure.
>>
>>         My sense is that, especially as this is motivated by PROV-AQ,
>>         there are just too many identifiers floating around.
>>
>>         Instead of:
>>
>>           hasProvenanceIn(id, subject, bundle, target, attrs)
>>
>>         Why not just:
>>
>>           hasProvenanceIn(subject, bundle)
>>
>>         Where subject is based on the URI of an entity, and bundle is
>>         based on the URI of a provenance bundle with information
>>         about that entity.
>>
>>         I would like to understand what  real scenario justifies all
>>         the added machinery that has been included with this relation.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> Jim McCusker
>> Programmer Analyst
>> Krauthammer Lab, Pathology Informatics
>> Yale School of Medicine
>> james.mccusker@yale.edu <mailto:james.mccusker@yale.edu> | (203) 785-6330
>> http://krauthammerlab.med.yale.edu
>>
>> PhD Student
>> Tetherless World Constellation
>> Rensselaer Polytechnic Institute
>> mccusj@cs.rpi.edu <mailto:mccusj@cs.rpi.edu>
>> http://tw.rpi.edu
>
> -- 
> Professor Luc Moreau
> Electronics and Computer Science   tel:   +44 23 8059 4487
> University of Southampton          fax:   +44 23 8059 2865
> Southampton SO17 1BJ               email:l.moreau@ecs.soton.ac.uk
> United Kingdomhttp://www.ecs.soton.ac.uk/~lavm
>    

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
Received on Wednesday, 30 May 2012 07:10:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 May 2012 07:10:16 GMT