- From: Paul Groth <p.t.groth@vu.nl>
- Date: Tue, 31 Jul 2012 13:08:22 +0200
- To: James Cheney <jcheney@inf.ed.ac.uk>
- Cc: Provenance Working Group <public-prov-wg@w3.org>
Hi James, I'm fine with leaving it out because I agree with the "better to leave it out" reasoning. 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. 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> 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 >> >> Efficient Multi-Granularity Service Composition: >> http://eprints.dcs.kcl.ac.uk/1396/ >> ________________________________________ >> From: Luc Moreau [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 >> 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 >> > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > -- -- Dr. Paul Groth (p.t.groth@vu.nl) http://www.few.vu.nl/~pgroth/ Assistant Professor - Knowledge Representation & Reasoning Group | Artificial Intelligence Section | Department of Computer Science - The Network Institute VU University Amsterdam
Received on Tuesday, 31 July 2012 11:08:54 UTC