- From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
- Date: Tue, 29 May 2012 11:10:01 +0100
- 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 UTC