Re: PROV-ISSUE-458: wasInfluencedBy is not irreflexive [prov-dm-constraints]

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>

> 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>
> 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
> >
> >
>
>
>