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: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
Date: Tue, 29 May 2012 11:10:01 +0100
Message-ID: <4FC4A079.8050200@zoo.ox.ac.uk>
To: public-prov-wg@w3.org
Luc,

In your latest example here, it seems to me that ex:Bob1 and ex:Bob2 are both 
specializations of ex:Bob.

#g
--


On 29/05/2012 10:01, 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
>
Received on Tuesday, 29 May 2012 10:10:54 GMT

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