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

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



-- 
Dr Simon Miles
Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166

Received on Monday, 1 August 2011 11:03:06 UTC