Re: PROV-ISSUE-67 (single-execution): Why is there a difference in what is represented by one vs multiple executions? [Conceptual Model]

Hi,
Sorry for joining this discussion late. I agree with many of Jim's proposal.
Responses are inline:

> The consequences of this definition are that, without additional information
(which we may want to add in the > model - see below), derivation cannot be
derived from a used-PE-generated structure in a given account, >and
derivation is not transitive.
Agree.

> Choosing the defaults to be fully connected would open the door for incorrect
assumptions given an open >world - if you're missing the 'composite' label
on a PE or Bob, you may infer derivation where there isn't any - >these
defaults would return the largest potential set of derivations given current
knowledge. I suspect that >this is actually the right way to 'err' - I'd
rather have false positives than to flip the situation and be unable to
>find everything that something truly was derived from.
I don't agree with this since this is likely to make the knowledge base
inconsistent (given that we are considering only monotonic assertions to
conform to the Semantic Web/RDF). Since, we agreed that PIL is an assertion
language it should require the provenance application/asserter/user to
explicitly assert isDerivedFrom to be transitive or non-transitive (if they
have enough information).

Further, if we consider isDerivedFrom to be transitive by default (and
encode it as such in our formal model), then provenance applications cannot
make it non-transitive subsequently. The solution is to not state
isDerivedFrom to be transitive (or non-transitive) - following the open
world assumption and leave it for application to create specializations of
the property that are transitive (or non-transitive). For example,
fully_connected_isDerivedFrom is a sub property of isDerivedFrom and is also
transitive (similarly for
less-than-fully-connected'/'composite'/'decomposable').

> If one inferred a derivation that looked odd, one would simply walk the
chain of Bobs and PEs to see if >there's evidence that one or more of them
might not be fully connected (i.e. one could look in other accounts) >along
with checking to see if one or more of the provenance statements is simply
wrong (A was not an >input!).
I am not sure how would we or an application "know" that the derivation
looks odd and we have to assume that the necessary "Bobs and PE" exist along
with a mechanism for the user or application to traverse that chain.


Going to back to some of Luc's earlier email regarding the assumption
that isGeneratedBy
links Bob to a single PE - I am not sure I understand why or how can we make
this assumption? Similar to our discussion on isDerivedFrom, we should not
make any assumption that PE in isGeneratedBy represents an atomic process.
There can be multiple PEs involved in generation of a single Bob (a
tropicalCyclone is generatedBy the processes of changeInAirPressure and
changeInTemperature and changeInMoisture and rotationofEarth).

A specific application may specialize isGeneratedBy property to define
isGeneratedBySingleProcessExecution or
isGeneratedByMultipleProcessExecution. Our provenance model should cater for
both these cases.


Thanks.

Best,
Satya



On Fri, Aug 5, 2011 at 10:29 AM, Myers, Jim <MYERSJ4@rpi.edu> wrote:

> An account -dependent definition of derivation would be much less
> useful. Let me try to restate what I've been saying as a proposal that I
> think will capture our collective sense of derivation and that will lead
> to some clear consequences for the model.
>
>
>
> Derivation means that, independent of the granularity of the description
> of provenance there exists (assuming the description is complete) a
> chain of used-PE-generated relationships between the two entities. That
> is B isDerivedFromA if there is a direct, directed, linear path between
> them (no breaks, no temporal zig-zags).
>
> A <---PE.1 <---X <---PE.2<---Y<---PE.3<----B - derivation
>
> A<--------PE.1
>             /
>          X
>        /
>      PE.2<---B - no derivation, though in some account A<---PE<---B
> (with used occurring after generation)
>
> A<---PE1<-----X.1
>                        \
>                         PE2
>                           \
>                            X.2<--PE3<---B - derivation
>
> A <----PE1 <--- X.1
>
>                        X.2<---PE2<----B - no derivation, though in some
> account A<---PE1<---X<---PE2<---B (with no processes internal to X such
> that one part influences the other)
>
>
> The idea of this is consistent with our discussions - if A was used
> after B was generated, there is no such path between them and an account
> with finer granularity of the PE could show it to be multiple
> subprocesses with A used by one that occurs after the one that generates
> B (there's no path, or the path has one or more links in the opposite
> temporal direction. The part/attribute cases also fit - going to finer
> granularity would show there's no such path.
>
> The consequences of this definition are that, without additional
> information (which we may want to add in the model - see below),
> derivation cannot be derived from a used-PE-generated structure in a
> given account, and derivation is not transitive.
>
> Since we have groups and use cases where either or both of these would
> be useful, we can ask what else is needed to allow them:
>
> To allow derivation to be inferable, we need to know the connectivity
> inside a PE. For a PE with m inputs and n outputs, this is an n x m
> matrix if we want full detail, but it may be sufficient for most cases
> to simply label the PE as fully connected or not. I would be inclined to
> make the default 'fully connected' and to allow a PE to be tagged as
> 'less-than-fully-connected'/'composite'/'decomposable' to stop
> inferencing about derivation. I think this default would be a good
> 80-90% solution while also allowing users/asserters to rigorously
> indicate when inference is not appropriate. Asserters would always be
> able to directly assert derivation and/or decompose partially connected
> PEs to allow the inferences that are valid while still indicating which
> ones are not.
>
> A similar mechanism would apply for Bobs and allow transitivity for
> derivation - A Bob that is fully connected - it is either one thing, or
> the parts of the thing interact (there are internal processes in B that
> if expanded would show that there is a path from C to A) - is sufficient
> to support transitivity. Again, I would argue that the default might be
> 'fully-connected' since that is likely to be the most popular case, and
> one could label a Bob as 'composite'/'not well mixed'/'not fully
> integrated'/'decomposable' to stop transitivity.
>
> The benefits of this proposal are that I think it really captures the
> essence of what we all think of as derivation in a rigorous way that is
> not asserter/account dependent. It also focuses directly on the
> provenance graph versus trying to relate attributes of Bobs or the
> nature (as described in a recipe) of a PE.
>
> Choosing the defaults to be fully connected would open the door for
> incorrect assumptions given an open world - if you're missing the
> 'composite' label on a PE or Bob, you may infer derivation where there
> isn't any - these defaults would return the largest potential set of
> derivations given current knowledge. I suspect that this is actually the
> right way to 'err' - I'd rather have false positives than to flip the
> situation and be unable to find everything that something truly was
> derived from. If one inferred a derivation that looked odd, one would
> simply walk the chain of Bobs and PEs to see if there's evidence that
> one or more of them might not be fully connected (i.e. one could look in
> other accounts) along with checking to see if one or more of the
> provenance statements is simply wrong (A was not an input!).
>
> I think one can define a useful equivalent for the distinction between
> isDerivedFrom and isDerivedFromMultipleSteps as we're talking about them
> today. I would suggest an account-dependent isDirectlyDerivedFrom(x,y,
> account z) relationship that would be limited to one hop in a specified
> account. This would really just be a convenience for scoping a query
> then and it would have a clear relationship to isDerivedFrom.
> isDirectlyDerivedFrom could be asserted and/or inferred  from a single
> used-PE-generated structure (same definition as above). isDerivedFrom is
> always inferable from isDirectlyDerivedFrom). (Both the assertion and
> inference of isDirectlyDerivedFrom are account dependent, but the
> dependency is just about the "Direct" part - it would always be true in
> any account that if you have an isDirectlyDerivedFrom relationship in
> one account, there is an isDerivedFrom relationship between the same
> entities that is account-independent). A consequence is that
> isDerivedFrom would just be the superset of  isDirectlyDerivedFrom and
> the additional relationships one gets from transitivity. If the
> asserters view of granularity fits yours, isDirectlyDerivedFrom would
> give you a useful subset of the overall derivation graph. If not, you
> just look directly at isDerivedFrom.
>
>
> Cheers,
>  Jim
>
> > -----Original Message-----
> > From: public-prov-wg-request@w3.org [mailto:public-prov-wg-
> > request@w3.org] On Behalf Of Luc Moreau
> > Sent: Friday, August 05, 2011 2:52 AM
> > To: public-prov-wg@w3.org
> > Subject: [Spam:****** SpamScore] Re: PROV-ISSUE-67 (single-execution):
> Why
> > is there a difference in what is represented by one vs multiple
> executions?
> > [Conceptual Model]
> >
> > Hi Simon,
> >
> > Your proposal is broadly inline with what I am currently drafting.
> >
> > Thanks for the name suggestion, which I will shamelessly borrow ;-)
> >
> > It is unclear to me at this stage, whether the first definition of
> derivation is
> > dependent on account or not, but I made an explicit note about it in
> the draft
> > document.  This will have to be discussed again in the next iteration.
> >
> > Luc
> >
> >
> > On 04/08/11 18:12, Simon Miles wrote:
> > > Hi Luc,
> > >
> > > OK. I believe that the current definitions do not fully capture what
> > > I've understood from your mails, so if I was clarifying the document
> > > based on my current understanding, I would start by refining the
> > > definitions (and rearranging the existing text to fit):
> > >
> > > "That characterized thing B _is derived from_ another characterized
> > > thing A means that B is transformed from, created from, or affected
> by
> > > A. In particular, this means that the values of some attributes of B
> > > are at least partially determined by the values of some attributes
> of
> > > A.
> > >
> > > xxx (B, A) represents that B is derived from A, and if P is the
> > > process execution generating B by the account in which the
> derivation
> > > is asserted, then P is the execution which used A and derived B from
> > > it.
> > >
> > > yyy (B, A) represents that B is derived from A, by any means whether
> > > direct or convoluted, and regardless of any other assertion made.
> > >
> > > For the account in which yyy (A, B) is asserted to be consistent
> then,
> > > within that account, it is implied that either xxx (A, B) also holds
> > > or there are multiple process executions ultimately using B and
> > > generating A through a chain of use and generation relations."
> > >
> > > xxx is currently called isDerivedFrom and yyy is called
> > > isDerivedFromInMultipleSteps.
> > >
> > > I fear that xxx is impossible to understand properly without
> including
> > > accounts, and consistency within accounts, in the model. Once we
> > > introduce accounts, it then makes sense.
> > >
> > > Assuming we don't want to introduce accounts into the current draft,
> I
> > > propose something like the following:
> > >
> > >   - isDerivedFromInMultipleSteps (yyy) is renamed
> isEventuallyDerivedFrom
> > >   - isEventuallyDerivedFrom is defined as for yyy above, removing
> the
> > > paragraph below mentioning accounts until accounts are introduced
> > >   - isDerivedFrom (xxx) is excluded from the model until accounts
> are
> > introduced
> > >   - isDerivedFrom+ is also excluded until accounts are introduced,
> as
> > > it depends on isDerivedFrom
> > >
> > > I don't like the proposal as it removes isDerivedFrom, but I can't
> see
> > > how we can define isDerivedFrom in a way which reflects your
> intention
> > > without introducing accounts. Otherwise, the implication that will
> be
> > > drawn (and has been by several people in discussing this issue) is
> > > that there is some implied notion of "atomic process executions".
> > >
> > > Thanks,
> > > Simon
> > >
> > > On 3 August 2011 22:56, Luc Moreau<L.Moreau@ecs.soton.ac.uk>  wrote:
> > >
> > >> Hi Simon,
> > >>
> > >> It's good to see that we understand each other's definition of
> derivation.
> > >>
> > >> Given what you say about your notion of derivation, isn't it
> similar
> > >> to isDerivedFromInMultipleSteps?
> > >>
> > >> I wonder whether we should find a better terminology for these
> relations.
> > >>
> > >> Luc
> > >>
> > >> On 03/08/11 16:59, Simon Miles wrote:
> > >>
> > >>> Hi Luc,
> > >>>
> > >>> Sorry, just catching up with these mails. Your explanation helps a
> > >>> lot. In particular, I think the critical point which clarifies my
> > >>> confusion is the following:
> > >>>
> > >>>
> > >>>
> > >>>> Asserting that
> > >>>>    isDerivedFrom(report2, data2)
> > >>>> would be very different. It would mean that the process execution
> > >>>> that generated report2 also used data2.
> > >>>>
> > >>>>
> > >>> I have always understood isDerivedFrom (A, B) as saying that "A
> was
> > >>> derived from B, regardless of any other assertion I make", which
> > >>> could be expressed as "there is a conceivably assertable process
> > >>> execution which used B and generated A".
> > >>>
> > >>> You are instead saying isDerivedFrom (A, B) means "A was derived
> > >>> from B, and if I assert A as being generated by a process
> execution,
> > >>> that was the execution which used B and led to A being derived
> from it".
> > >>>
> > >>> I agree these are semantically different. You are taking
> > >>> "use+generate" as fundamental, where "derived" implies a process
> > >>> which uses B and generates A takes place, so consistency within an
> > >>> account requires that the process which generates A is the same
> that
> > >>> is implied by derivation.
> > >>>
> > >>> I interpreted "derived" as fundamental itself and an independent
> > >>> assertion, so consistency in an account is given by this
> > >>> independence, i.e. by saying "derived" you are not implying a
> > >>> process in the same account anyway. And the independence of the
> > >>> assertion means that it does not even make sense to consider it in
> > >>> conjunction with the "generates" assertion (if it exists).
> > >>>
> > >>> thanks,
> > >>> Simon
> > >>>
> > >>> On 1 August 2011 23:59, Luc Moreau<L.Moreau@ecs.soton.ac.uk>
> wrote:
> > >>>
> > >>>
> > >>>> Hi Simon,
> > >>>>
> > >>>> That's a good example, thanks!
> > >>>>
> > >>>> Let me try and explain, how I see it:
> > >>>>
> > >>>> With
> > >>>>
> > >>>> isDerivedFrom (report1, data1)
> > >>>>
> > >>>> the asserter has a deep knowledge of the process execution that
> > >>>> underpins this derivation. In particular, it is PE workflow1 that
> > >>>> generates report1, and uses data1. Hence, both the generation
> event
> > >>>> for report1 and the use event for data1 occur during workflow1.
> > >>>>
> > >>>> In the provenance challenge, when you were using slicing
> techniques
> > >>>> to extract derivations from process definitions, I would argue
> you
> > >>>> were generating similar derivations.
> > >>>>
> > >>>> With
> > >>>>
> > >>>> isDerivedFromInMultipleSteps (report2, data2)
> > >>>>
> > >>>> the asserter is much less precise, and does not state whether a
> > >>>> single process is involved for generation/use, and which interval
> > >>>> they occur in.
> > >>>>
> > >>>> Furthermore, in this example, with the provenance given,  one
> > >>>> cannot ascertain whether 'unpublished2' is in the derivation path
> > >>>> between report2 and data2.
> > >>>>
> > >>>> A stronger provenance would have been
> > >>>>
> > >>>> isDerivedFrom (report2, unpublished2)
> > >>>>
> > >>>> isDerivedFrom(unpublished2, data2)
> > >>>>
> > >>>>
> > >>>> from which we can infer by transitive closure
> > >>>>
> > >>>> isDerivedFrom+ (report2, data2)
> > >>>>
> > >>>>
> > >>>> So, to me,
> > >>>> 1. isDerivedFrom is fundamental in the model, and requires
> deep/precise
> > >>>>       knowledge of process executions.
> > >>>> 2. isDerivedFrom+ is useful inference (transitive closure).
> > >>>> 3. isDerivedFromInMultipleSteps is convenience assertion, but not
> > >>>>        as precise as 1&2.
> > >>>>
> > >>>> We could drop 3, but then, you wouldn't be able to express your
> > >>>> second example.
> > >>>>
> > >>>> Asserting that
> > >>>>    isDerivedFrom(report2, data2)
> > >>>> would be very different. It would mean that the process execution
> > >>>> that generated
> > >>>> report2 also used data2.
> > >>>>
> > >>>> So,
> > >>>>
> > >>>> used (workflow1.2, data2, r) for some role r.
> > >>>>
> > >>>> But that's not the intent.
> > >>>>
> > >>>> What do you think?
> > >>>> Regards,
> > >>>> Luc
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 01/08/11 16:53, Simon Miles wrote:
> > >>>>
> > >>>>
> > >>>>> Hi Luc,
> > >>>>>
> > >>>>> OK. Here's my stab at an motivating example.
> > >>>>>
> > >>>>> An organisation, Org, wants to use the WG standard to record and
> > >>>>> provide access to provenance data on the documents it makes
> > >>>>> available online to its clients. It has storage limits on the
> > >>>>> provenance it can maintain.
> > >>>>>
> > >>>>> Alice regularly receives government data sets and for each,
> > >>>>> creates a report which is published online. Looking for a
> minimal
> > >>>>> way to express this using PIL, Org decides on one BOB for each
> > >>>>> data set, one for each report, one process representing the
> > >>>>> create-and-publish workflow, and a derivation link to show that
> > >>>>> the report is based on the data set. A given instance of this,
> for one data
> > set, is:
> > >>>>>
> > >>>>>      bob (data1, [ type: "File", location: "/shared/crime1.data"
> ])
> > >>>>>      bob (report1, [ type: "File", location:
> > >>>>> "http://example.com/report1.pdf", creator: "Alice" ])
> > >>>>>      processExecution (workflow1, create-and-publish, t)
> > >>>>>      isGeneratedBy (report1, workflow1, out)
> > >>>>>      used (workflow1, data1, in)
> > >>>>>      isDerivedFrom (report1, data1)
> > >>>>>
> > >>>>> A client, Clive, finds a mistake in report1, looks at the
> > >>>>> provenance and, being "creator", Alice gets the blame. However,
> > >>>>> the error is actually due to Bob, who published Alice's report,
> > >>>>> messing up the axes on a graph. To avoid Alice's anger, Org
> agrees
> > >>>>> to refine what is modelled to a finer granularity: create, then
> > >>>>> publish. As they have storage constraints, they will make
> > >>>>> available only one granularity of provenance information, and
> use
> > >>>>> this finer granularity only for subsequent reports. A given
> instance would
> > be:
> > >>>>>
> > >>>>>      bob (data2, [ type: "File", location: "/shared/crime2.data"
> ])
> > >>>>>      bob (unpublished2, [ type: "File", location:
> > >>>>> "/shared/report2.pdf",
> > >>>>> creator: "Alice" ])
> > >>>>>      bob (report2, [ type: "File", location:
> > >>>>> "http://example.com/report2.pdf", creator: "Alice", publisher:
> "Bob"
> > >>>>> ])
> > >>>>>      processExecution (workflow1.1, create, t)
> > >>>>>      processExecution (workflow1.2, publish, t+4)
> > >>>>>      isGeneratedBy (unpublished2, workflow1.1, out)
> > >>>>>      isGeneratedBy (report2, workflow1.2, out)
> > >>>>>      used (workflow1.1, data2, in)
> > >>>>>      used (workflow1.2, unpublished2, in)
> > >>>>>      isDerivedFromInMultipleSteps (report2, data2)
> > >>>>>
> > >>>>> Clive queries to find out what data sets the reports available
> are
> > >>>>> derived from. He finds that while report1 is derived from data1
> in
> > >>>>> one step (isDerivedFrom), report2 is derived from data2 in
> > >>>>> multiple steps (isDerivedFromInMultipleSteps). He (like me) does
> > >>>>> not understand how he should interpret the distinction between
> the
> > >>>>> two. There is apparently something different in the way that
> > >>>>> report2 is related to
> > >>>>> data2 compared to how report1 is derived from data1, and
> possibly
> > >>>>> he should trust report2 less because of this indirect link to
> its
> > >>>>> source data. But Org is adamant that nothing has changed in
> their
> > >>>>> procedures, and there is no distinction.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Simon
> > >>>>>
> > >>>>> On 1 August 2011 12:15, Luc Moreau<L.Moreau@ecs.soton.ac.uk>
> > wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Hi Simon,
> > >>>>>>
> > >>>>>> Sorry, but I don't understand.  Your initial example was not
> > >>>>>> valid because you had two PEs generating a single BOB.
> > >>>>>>
> > >>>>>> If they are different ways of describing something happening in
> > >>>>>> the world, I assume that you will identify different
> activities,
> > >>>>>> and hence multiple process executions will be asserted.
> > >>>>>>
> > >>>>>> Can you reformulate an example that illustrate your concern?
> > >>>>>>
> > >>>>>> Luc
> > >>>>>>
> > >>>>>> On 08/01/2011 12:02 PM, Simon Miles wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>> Hi Luc,
> > >>>>>>>
> > >>>>>>> I follow your argument, but it seems tangential to my point.
> The
> > >>>>>>> following argument still seems inevitably true to me:
> > >>>>>>>
> > >>>>>>> Activity in the world that uses one BOB and generates another
> > >>>>>>> *can* be described in PIL as multiple process executions or a
> > >>>>>>> single process execution (regardless of whether it actually is
> > >>>>>>> described in these different ways or not, or whether accounts
> are
> > required or not).
> > >>>>>>>
> > >>>>>>> Therefore, what one process execution denotes is not distinct
> > >>>>>>> from what multiple process executions denotes, we have just
> > >>>>>>> provided more detail in the latter description (and this
> detail
> > >>>>>>> is, in any case, removed when saying "is derived from").
> > >>>>>>>
> > >>>>>>> Therefore, isDerivedFrom and isDerivedFromInMultipleSteps as
> > >>>>>>> defined do not describe anything different in the world, so we
> > >>>>>>> have two terms for representing the same thing.
> > >>>>>>>
> > >>>>>>> I know that we've debated this or similar before, but it is
> > >>>>>>> still not clear to me where the fault lies in my argument, or
> > >>>>>>> what isDerivedFromInMultipleSteps really represents. If it's
> > >>>>>>> only me that's confused, I understand there are more urgent
> > >>>>>>> concerns (though I'd still like to understand).
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Simon
> > >>>>>>>
> > >>>>>>> On 1 August 2011 09:25, Luc Moreau<L.Moreau@ecs.soton.ac.uk>
> > wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> Hi Simon,
> > >>>>>>>>
> > >>>>>>>> If I understand you correctly, you are suggesting that the
> > >>>>>>>> following two assertions hold together.
> > >>>>>>>>
> > >>>>>>>> isGeneratedBy(e5,pe5,out)
> > >>>>>>>> isGeneratedBy(e5,pe4,out)
> > >>>>>>>>
> > >>>>>>>> But this is not legal, since it is stated that one BOB is
> > >>>>>>>> generated by at most one process execution.
> > >>>>>>>>
> > >>>>>>>> What you are suggesting should be encoded in a separate
> account
> > >>>>>>>> (though we have not defined this yet!).
> > >>>>>>>> A one-step derivation then expands to one process execution
> in
> > >>>>>>>> a given account.
> > >>>>>>>> In a separate account, there may be a multi-step derivation
> > >>>>>>>> between the same two BOBs and it would expand into multiple
> > >>>>>>>> process executions.
> > >>>>>>>>
> > >>>>>>>> Does it make sense?
> > >>>>>>>> Regards,
> > >>>>>>>>
> > >>>>>>>> Luc
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On 07/29/2011 05:52 PM, Provenance Working Group Issue
> Tracker
> > wrote:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> PROV-ISSUE-67 (single-execution): Why is there a difference
> in
> > >>>>>>>>> what is represented by one vs multiple executions?
> [Conceptual
> > >>>>>>>>> Model]
> > >>>>>>>>>
> > >>>>>>>>> http://www.w3.org/2011/prov/track/issues/67
> > >>>>>>>>>
> > >>>>>>>>> Raised by: Simon Miles
> > >>>>>>>>> On product: Conceptual Model
> > >>>>>>>>>
> > >>>>>>>>> By the definition, "a process execution represents an
> identifiable
> > activity". This does not seem to preclude one process execution
> assertion
> > denoting, at a coarse granularity, the same events in the world
> denoted by
> > multiple process executions in other assertions.
> > >>>>>>>>>
> > >>>>>>>>> If so, then in the File Scenario example, I could add a
> coarse-
> > grained process execution representing the whole e1-to-e5 activity:
> > >>>>>>>>>        processExecution(pe5,collaboratively-edit,t)
> > >>>>>>>>>        uses(pe5,e1,in)
> > >>>>>>>>>        isGeneratedBy(e5,pe5,out)
> > >>>>>>>>>
> > >>>>>>>>> But then Section 5.5.2 distinguishes between "a single
> process
> > execution" and "one or more process executions". Following the
> argument
> > above, these could represent exactly the same occurrences in the
> world.
> > >>>>>>>>>
> > >>>>>>>>> So there is no difference between what is denoted by one and
> > multiple process executions, and so no difference between
> isDerivedFrom and
> > isDerivedFromInMultipleSteps as described. Whether e5 was derived from
> e1
> > appears to me to be entirely independent of how many process
> executions
> > were involved.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> 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
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > _______________________________________________________________
> > >>>>>>>> _______ This email has been scanned by the MessageLabs Email
> > >>>>>>>> Security System.
> > >>>>>>>> For more information please visit
> > >>>>>>>> http://www.messagelabs.com/email
> > >>>>>>>>
> > _______________________________________________________________
> > >>>>>>>> _______
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>> --
> > >>>>>> 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
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > ________________________________________________________________
> > _
> > >>>>>> _____ This email has been scanned by the MessageLabs Email
> > >>>>>> Security System.
> > >>>>>> For more information please visit
> > >>>>>> http://www.messagelabs.com/email
> > >>>>>>
> > ________________________________________________________________
> > _
> > >>>>>> _____
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > ________________________________________________________________
> > ___
> > >>>> ___ This email has been scanned by the MessageLabs Email Security
> > >>>> System.
> > >>>> For more information please visit
> http://www.messagelabs.com/email
> > >>>>
> > ________________________________________________________________
> > ___
> > >>>> ___
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > ________________________________________________________________
> > _____
> > >> _ This email has been scanned by the MessageLabs Email Security
> > >> System.
> > >> For more information please visit http://www.messagelabs.com/email
> > >>
> > ________________________________________________________________
> > _____
> > >> _
> > >>
> > >>
> > >
> > >
> > >
>
>
>