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: Tue, 29 May 2012 11:54:31 +0100
Message-ID: <EMEW3|a8a806b3fb9894981217fd255e8bf31co4SBsY08L.Moreau|ecs.soton.ac.uk|4FC4AAE7.2090604@ecs.soton.ac.uk>
To: "Miles, Simon" <simon.miles@kcl.ac.uk>
CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Hi Simon,
Response below.

On 05/29/2012 10:27 AM, Miles, Simon wrote:
> Hi Luc,
> If I'm interpreting the example correctly, I see the following:
>  - Bundles ex:run1 and ex:run2 refer to an entity (agent), ex:Bob, at 
> a coarse granularity that does not distinguish between that entity at 
> the times of the different activities. They use the same ID, so it is 
> exactly the same entity referred to.
>  - Bundle tool:analysis01 declares two entities, stating each has some 
> equivalence to ex:Bob (currently using hasProvenanceIn) but 
> have distinct attributes.
Yes, I have the same understanding
> Surely this seems exactly the case for using specializationOf, as if 
> tool:Bob1 and tool:Bob2 are equivalent to ex:Bob but have different 
> attributes, they must be constrained perspectives on the same thing?
> I don't see the problem in the example: ex:Bob is not itself rated 
> good or bad, but specializationOf would tell you that ex:Bob has been 
> rated good and bad in different constrained contexts. What would be 
> wrong with the below?
>   entity(tool:Bob1, [perf:rating="good"])
>   hasProvenanceIn(tool:Bob1, ex:run1)  // Bob performance in ex:run1 
> is good
>   specializationOf(tool:Bob1, ex:Bob)
>   entity(tool:Bob2, [perf:rating="bad"])
>   hasProvenanceIn(tool:Bob2, ex:run2)  // Bob performance in ex:run2 
> is bad
>   specializationOf(tool:Bob2, ex:Bob)


I am assuming you are familiar with component 5 section in
http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#component5


One of the reasons why hasProvenanceIn was introduced was to help with
incremental navigation.
tool:Bob1 and tool:Bob2 were both "end of graph" in bundle tool:analysis01.

With your suggestion, tool:Bob1 and tool:Bob2 are no longer "end of 
graph" but
ex:Bob is an "end of graph" in tool:analysis01.  So, I haven't solved 
the problem
of incremental navigation.

Luc


> 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:* Luc Moreau [L.Moreau@ecs.soton.ac.uk]
> *Sent:* 29 May 2012 10:01
> *To:* public-prov-wg@w3.org
> *Subject:* Re: PROV-ISSUE-385 (haProvenanceIn-complexity): The 
> hasProvenbanceIn relation is over-complicated [prov-dm]
>
> 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 Tuesday, 29 May 2012 10:55:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 May 2012 10:55:01 GMT