- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Mon, 06 Aug 2012 09:48:04 +0100
- To: public-prov-wg@w3.org
- Message-ID: <EMEW3|55f28efebc6abb988a55b0cb5e94008co759m708l.moreau|ecs.soton.ac.uk|501F84C4>
Done. Luc On 02/08/12 16:38, James Cheney wrote: > Following resolution at today's teleconference, we will remove the > constraint and then close this issue. > > --James > > On Jul 31, 2012, at 5:55 PM, Daniel Garijo wrote: > >> Hi, >> sorry to jump in a bit late, but I would like to agree with Simon. >> We found that many of the entities defined in Dublin Core behave that >> way: if ex:myBook >> has a creation date and a modified date then both versions are >> conflated in 1 entity (ex:myBook), >> and it would be possible for the ex:myBook to have been derived from >> itself. >> >> Best, >> Daniel >> >> 2012/7/31 Timothy Lebo <lebot@rpi.edu <mailto:lebot@rpi.edu>> >> >> James, Luc, >> >> I think I'm in line with Paul: better to keep out the irreflexive >> constraint than to force it in, but it seems odd that it permits >> or encourages lack of details. >> >> Fortunately, we have the specialization dimension that allows us >> to frame the degree of details, so it can always be reconciled. >> >> Feel free to close this issue how you see fit. >> >> Regards, >> Tim >> >> >> On Jul 31, 2012, at 7:08 AM, Paul Groth wrote: >> >> > Hi James, >> > >> > I'm fine with leaving it out because I agree with the "better >> to leave >> > it out" reasoning. >> >> +1 >> >> > >> > However, I have to say that the argument from plausibility is >> not very >> > satisfying. There's lot's of things that may be plausible to >> say and >> > in some cases be important to say that are incompatible with the >> > constraints - but that's why we have scruffy provenance. The >> purpose >> > is to give guidance about what is good provenance - indeed we >> outside >> > comments looking for this sort of guidance. >> >> >> > I think one important >> > piece of that guidance is that you should be specific about the >> events >> > and states you are referring to. >> >> +1 >> >> >> > I believe the irreflexivity of these >> > relations encodes this guidance. >> > >> > If someone can tell me how the other constraints encode this >> guidance >> > then I'll be even more happy with my non-objection :-) >> > >> > thanks >> > Paul >> > >> > >> > On Tue, Jul 31, 2012 at 12:43 PM, James Cheney >> <jcheney@inf.ed.ac.uk <mailto:jcheney@inf.ed.ac.uk>> wrote: >> >> So far (synthesizing comments in this thread and reviews): >> >> >> >> Tim and Paul don't seem to object to the irreflexivity >> constraint, but don't seem to be making a strong case for its >> necessity. >> >> >> >> Paul says: >> >> >> >>> >> >>> I think this come downs what we think the role of the >> constraints are. >> >>> My impression is to encourage implementers to be both >> explicit and >> >>> correct in the provenance they create. In terms of the >> example given >> >>> in the issue, I would expect that if an activity called >> itself you >> >>> would want to identify that has two independent activities. >> Thus, I >> >>> think it's irreflexive. Actually, maybe this is suggesting >> the need >> >>> for a part of relation around activities. >> >> >> >> >> >> Tim says: >> >> >> >> >> >>> I think to be proper, an influence should be irreflexive. >> Otherwise, a critical distinction is being abstracted away (and >> that's what scruffy provenance is for). >> >> >> >> >> >> Luc has argued that there are plausible situations where it >> can be reflexive, and Simon's comments below (and in his review) >> also support this view. >> >> >> >> My proposal to close the issue is to remove the irreflexivity >> constraint on influence, as it is better to leave out a >> constraint (that we can introduce or refine later) than to add >> one that is not well-thought out. It was introduced to address >> potential examples of "strange" influence relations. To rule >> these out, we could introduce more specific irreflexivity >> constraints, for example on derivation - however, I believe these >> are already ensured by other ordering constraints. >> >> >> >> Are there any objections? Tim, you seem to be advocating most >> strongly for this constraint. If you object to its removal, >> please respond to Simon or Luc's points or suggest an alternative. >> >> >> >> --James >> >> >> >> On Jul 31, 2012, at 10:01 AM, Miles, Simon wrote: >> >> >> >>> Hello, >> >>> >> >>> I'm fairly new to the issue, but I would argue that >> >>> wasInfluenced(a, a) >> >>> and all its subproperties should be reflexive. >> >>> >> >>> My rationale: >> >>> - wasInfluenceBy(x, y) and its subproperties relate two >> occurrences that can exist over a period of time (activity, >> entity, agent) >> >>> - influence is actually between something at one instant and >> something else at a later instant, i.e. influence is between >> events, as illustrated by Luc's wasInformedBy example >> >>> - Something that exists over a period of time can have >> multiple events over its lifetime >> >>> - So its plausible for anything to influence itself, and it >> would be arbitrarily restrictive to prevent people saying it >> >>> >> >>> I think wasDerivedFrom(a, a) is plausible. For example, I >> define entity my:book for a book I'm writing. It changes content >> as I write it, but has a consistent identity. At some point, I >> finish a complete draft and it is only 5 pages long, so I entitle >> it "The short book". One mutable attribute (title) of the entity >> has influenced another mutable attribute (length) of the same >> entity, so the entity has influenced itself. It may not be >> particularly informative to say wasDerivedFrom(my:book, my:book), >> but it is still true. >> >>> >> >>> In general, I don't think wasInformedBy(a, a) will be used or >> useful in many settings, but allowing it seems to break nothing >> and does not add to the complexity of PROV, so why not allow it? >> There may be important application-specific examples that we >> haven't considered. >> >>> >> >>> thanks, >> >>> Simon >> >>> >> >>> Dr Simon Miles >> >>> Senior Lecturer, Department of Informatics >> >>> Kings College London, WC2R 2LS, UK >> >>> +44 (0)20 7848 1166 <tel:%2B44%20%280%2920%207848%201166> >> >>> >> >>> Efficient Multi-Granularity Service Composition: >> >>> http://eprints.dcs.kcl.ac.uk/1396/ >> >>> ________________________________________ >> >>> From: Luc Moreau [l.moreau@ecs.soton.ac.uk >> <mailto:l.moreau@ecs.soton.ac.uk>] >> >>> Sent: 31 July 2012 09:35 >> >>> To: Timothy Lebo >> >>> Cc: James Cheney; Provenance Working Group >> >>> Subject: Re: PROV-ISSUE-458: wasInfluencedBy is not >> irreflexive [prov-dm-constraints] >> >>> >> >>> Hi all, >> >>> >> >>> It would be good to try and reach consensus on this issue. >> >>> >> >>> My response to Tim: >> >>> >> >>> On 23/07/12 13:46, Timothy Lebo wrote: >> >>>> Luc, James, >> >>>> >> >>>> On Jul 20, 2012, at 6:55 AM, James Cheney wrote: >> >>>> >> >>>>> I added the irreflexivity constraint directly to address >> concerns raised in discussion by Tim and Tom on issue 454. I >> haven't heard whether this proposed fix, or Luc's example of a >> reflexive communication, addresses their concern. >> >>>>> >> >>>>> Briefly, I think wasInformedBy(a,a) is a bug, >> >>>> +1 >> >>> >> >>> I agree the wasDerivedFrom(e,e) where e is an entity is a bug. >> >>> >> >>> I think that >> >>> wasInfluencedBy(a,a) >> >>> wasInformedBy(a,a) >> >>> where a is an activity is plausible: >> >>> >> >>> In a producer/consumer pattern, with a scheduler allocating >> "tasks to >> >>> perform", one could imaging an activity >> >>> producing a task, and then being the one that consumes it, in >> the sense >> >>> that >> >>> >> >>> wasGeneratedBy(task,a) // a produces the task >> >>> used(a,task) // a consumes and executes the task, >> >>> >> >>> >> >>> >> >>> I think the case actedOnBehalfOf is not clear cut either. >> >>> >> >>> actedOnBehalfOf(slave1,uberMaster,a1) >> >>> ... >> >>> actedOnBehalfOf(slaven,uberMaster,an) >> >>> >> >>> where slave 1 . ... n are given responsibility for a1 ... an. >> >>> >> >>> We can imagine that, running out of slave, uberMaster takes >> direct >> >>> responsibility of activity a_x >> >>> >> >>> actedOnBehalfOf(uberMaster,uberMaster,a_x) >> >>> >> >>> This would imply wasInfluencedBy(uberMaster,uberMaster) >> >>> >> >>> >> >>> >> >>> >> >>>> >> >>>> >> >>>>> and we should fix it by dropping >> generation-use-communication, and keeping influence irreflexive. >> However, I'm not going to fight for irreflexive influence if >> Luc's example convinces everyone else that it may be reflexive. >> >>>> >> >>>> 1) >> >>>> >> >>>> prov-constraints is available to distinguish proper >> provenance from the scruffy provenance that prov-dm permits. >> >>>> A distinguishing characteristic between proper and scruffy >> is "precision"; The former has it, and the latter need not. >> >>>> >> >>>> The statement: >> >>>> >> >>>> wasInformedBy(a,a) >> >>>> >> >>>> is hardly precise, and without some precision it is not >> informative. >> >>>> Why would one inform oneself? Didn't the one already know it? >> >>>> You're implying two parts of oneself, and should thus >> distinguish them, describe them separately, and relate them >> appropriately. >> >>> >> >>> We could probably do that for the entity/agent examples above. >> >>> I don't think it works for activity. >> >>> >> >>> Luc >> >>> >> >>>> Meanwhile, it seems like a perfectly reasonable prov-dm >> statement. >> >>> >> >>>> The same argument applies to the general property >> wasInfluencedBy. >> >>>> >> >>>> >> >>>> 2) >> >>>> >> >>>> In a different topic but related to precision, does the >> latest prov-constraints prevent: >> >>>> >> >>>> :e prov:wasGeneratedBy :a_1, :a_2 . >> >>>> :a_1 owl:differentFrom :a_2 . >> >>>> >> >>>> >> >>>> Thanks, >> >>>> Tim >> >>>> >> >>>> >> >>>> >> >>>>> I am copying my comments from issue 454 for easy reference: >> >>>>>> The irreflexivity constraint was an attempt to address Tim >> and Tom's concerns, so they should comment on whether your >> example persuades them that it is not irreflexive. >> >>>>>> >> >>>>>> My inclination would be that influence and communication >> should be irreflexive, so this is no problem. >> >>>>>> >> >>>>>> But if we also allow the generation-use-communication >> inference, then from the totally reasonable: >> >>>>>> >> >>>>>> wasGeneratedBy(e,a) >> >>>>>> used(a,e) >> >>>>>> >> >>>>>> we could infer wasInformedBy(a,a) and then >> wasInfluencedBy(a,a), which would be invalid if influence has to >> be irreflexive. >> >>>>>> >> >>>>>> Overall, I think this makes a persuasive argument for >> dropping generation-use-communication and keeping irreflexivity >> of influence (and all this entails). >> >>>>> --James >> >>>>> >> >>>>> On Jul 20, 2012, at 9:07 AM, Provenance Working Group Issue >> Tracker wrote: >> >>>>> >> >>>>>> PROV-ISSUE-458: wasInfluencedBy is not irreflexive >> [prov-dm-constraints] >> >>>>>> >> >>>>>> http://www.w3.org/2011/prov/track/issues/458 >> >>>>>> >> >>>>>> Raised by: Luc Moreau >> >>>>>> On product: prov-dm-constraints >> >>>>>> >> >>>>>> Going back to the definition in prov-dm, >> >>>>>> >> >>>>>> Communication is the exchange of some unspecified entity >> by two activities, one activity using some entity generated by >> the other. >> >>>>>> >> >>>>>> I can imagine a service invoking itself (so effectively, >> exchanging an entity with itself). >> >>>>>> >> >>>>>> So, it would be fine to write: >> >>>>>> >> >>>>>> wasInformedBy(a,a) >> >>>>>> >> >>>>>> Therefore, >> >>>>>> >> >>>>>> wasInfluencedBy(a,a) >> >>>>>> >> >>>>>> which contradicts the constraints: >> >>>>>> >> >>>>>> >> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#impossible-influence-reflexive >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> -- >> >>>>> The University of Edinburgh is a charitable body, registered in >> >>>>> Scotland, with registration number SC005336. >> >>>>> >> >>>>> >> >>>>> >> >>> >> >>> -- >> >>> Professor Luc Moreau >> >>> Electronics and Computer Science tel: +44 23 8059 4487 >> <tel:%2B44%2023%208059%204487> >> >>> University of Southampton fax: +44 23 8059 2865 >> <tel:%2B44%2023%208059%202865> >> >>> Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk >> <mailto:l.moreau@ecs.soton.ac.uk> >> >>> United Kingdom http://www.ecs.soton.ac.uk/~lavm >> <http://www.ecs.soton.ac.uk/%7Elavm> >> >>> >> >> >> >> >> >> -- >> >> The University of Edinburgh is a charitable body, registered in >> >> Scotland, with registration number SC005336. >> >> >> >> >> > >> > >> > >> > -- >> > -- >> > Dr. Paul Groth (p.t.groth@vu.nl <mailto:p.t.groth@vu.nl>) >> > http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/> >> > Assistant Professor >> > - Knowledge Representation & Reasoning Group | >> > Artificial Intelligence Section | Department of Computer Science >> > - The Network Institute >> > VU University Amsterdam >> > >> > >> >> >> > > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. -- 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 Monday, 6 August 2012 08:48:39 UTC