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

I'm not fully up to speed on this discussion, but there's a consideration I 
wanted to suggest.  The distinction between single- and multiple process 
execution steps seems to assume that at some level there are distinct atomic 
operations.

But consider a dataset stored on a medium that is subject to degradation over 
time.  What is the atomic item of "process execution" in this degradation 
process? Individual state changes at the atomic/molecular level?  (I think not.)

SO: do we need a model that allows a mereological interpretation of process 
execution?

(I think this also overlaps the discussion of ISSUE 66)

#g
-- 



Luc Moreau 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.
>>
>>
>>
>>
>>    
>

Received on Thursday, 4 August 2011 08:41:54 UTC