- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Mon, 01 Aug 2011 17:05:51 +0100
- To: Paul Groth <p.t.groth@vu.nl>
- CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Hi Paul, Is this related to the issue Simon raised? I am very confused, given that I didn't understand the issue. I think that what you raise here is not the same. It may be better to track as a separate issue. Let me try and answer below: On 01/08/11 16:44, Paul Groth wrote: > Hi Luc, > > The proposal says the following in the Generation: > > "A given BOB can be generated at most by one process execution." > > But it also says: > > "Given an assertion*isGeneratedBy(x,pe,r)*or*isGeneratedBy(x,pe,r,t)*, > the activity denoted by*pe*and the entities used by*pe*dermine values > of some of*x*'s attributes. " > > These two sentences are in conflict. Not sure they are in conflict. The latter is more experimental, since related to attributes, which are a novelty in this model. > Why can't there be another process execution (pe1) that determine's > x's values that were not determined by pe? Let's consider - bob b generated by pe1 setting attribute a1 - bob b generated by pe2 setting attribute a2 There are a number of cases: 1. b has attribute a1 only, and the bob set by pe2 is another bob b2, with attribute a2 maybe b2 could be an ivpOf b 2. vice versa, b has attribute a2 only ... symmetric case 3. b has both attributes a1 and a2 3.1: attributes are not set at the same time, so think we should model this as separate bobs again, one being derivation of the other 3.2: both are set at the same time by p1 and p2 It seems to me that's not really possible for two processes to create something in parallel without synchronisation. One would have to "control a transaction" and release the bob for use by others. That's the generation event. > > Additionally, the rational for the first constraint is not present. > Why can I not assert that x isGeneratedBy both pe and pe1? For > example, I want to state that the web page is generated by the apache > web server, and the apache web server thread #4. I think that your example could fall in any of those. > > It's not obvious why one cannot make this assertion in PIL. Luc > > Thanks, > Paul > > > Luc Moreau wrote: >> Hi Jim, >> >> The text does not mention atomic processes, and there was (in my mind) >> no intent >> of having them in the model. >> As I asked Simon, could you explain with an example in the context of >> the document >> what the problem is. >> >> Thanks, >> Luc >> >> >> >> On 01/08/11 15:31, Myers, Jim wrote: >>> +1 - there are very few 'atomic' processes that could not be >>> described as an aggregate graph of other processes. Given that we >>> don't know anything in PIL about the nature of processes, it seems >>> like distinguishing direct versus multiple will not be a clear binary >>> split and we'd essentially end up treating both the same way. >>> >>> Jim >>> >>> >>>> -----Original Message----- >>>> From: public-prov-wg-request@w3.org [mailto:public-prov-wg- >>>> request@w3.org] On Behalf Of Simon Miles >>>> Sent: Monday, August 01, 2011 7:03 AM >>>> To: Provenance Working Group WG >>>> Subject: 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 >>>> >>> >> > > -- 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 > VU University Amsterdam >
Received on Monday, 1 August 2011 16:06:27 UTC