- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Wed, 03 Aug 2011 22:51:52 +0100
- To: public-prov-wg@w3.org
- Message-ID: <EMEW3|b6b62c2a7b6b84cad6dec1b359ec51f2n72Mpu08L.Moreau|ecs.soton.ac.uk|4E39C2F8>
Hi Jim, I don't want to introduce parts yet, since we have a concept of collection still to define, which will have a notion of containment I believe. I think inferring derivation from use-generate is orthogonal to the issue of transitivity, when taking attributes into account. In Paolo's example, some form of transitivity *does* hold: B / \ C --> B.1 B.2 --> A becomes C --> B --> A Indeed, A had to be available for B's attributes to be given a value (if A was not there, B wouldn't be the BOB we talk about), and B had to exist for C to be derived. We have to remember that the list of attributes is not necessarily complete, and there may be others not listed, which may show the kind of "influence" we are trying to capture with derivation. I suppose that you are looking at this picture, and replacing B by a process execution PE, and saying that C can be derived from A, since C was generated by PE, which used A. But there is something very different, here. PE makes no guarantee about use/generation, whereas BOB B only exists when B.1 and B.2 have been given a value! That's what allows us to have transitivity. Regards, Luc On 03/08/11 16:17, Myers, Jim wrote: > > I see parts as different from attributes, but -- as in my email that > crossed with yours responding to Luc, the 'loss of precision' you get > from ignoring attributes/parts seems to be the same as you'd get from > allowing inference of derivation from used-PE-generated by 'ignoring' > time stamps. Doing both or neither makes sense to me (different but > self-consistent definitions of derivation), allowing one and not the > other seems inconsistent. > > Jim > > *From:* public-prov-wg-request@w3.org > [mailto:public-prov-wg-request@w3.org] *On Behalf Of *Paolo Missier > *Sent:* Wednesday, August 03, 2011 11:03 AM > *To:* public-prov-wg@w3.org > *Subject:* Re: PROV-ISSUE-67 (single-execution): Why is there a > difference in what is represented by one vs multiple executions? > [Conceptual Model] > > yes, partial derivation, i.e., at the attribute level, gets in the way > of transitivity. Ignoring the attributes may be a way out. You lose > precision but save transitivity. > So you could have: > > B includes B.1, B.2 > B.1 derived from A => B derived from A (1) > C derived from B.2 => C derived from B (2) > => C derived from A (3) > > where inferences (1) and (2) are new, they "lift" derivation from > attribute to whole entity, and (3) is transitivity. > > "graphically": > > B > / \ > C --> B.1 B.2 --> A becomes C --> B --> A > > Graham's example is more involved but similar: > > C B A > / \ / \ / \ > c0 c1 --> b1 b0 --> a0 a1 becomes C --> B --> A > > what do you think? > > -Paolo > > > On 8/3/11 3:43 PM, Luc Moreau wrote: > > Jim, > > This counter example was already raised by Graham in PROV-ISSUE-56. > > My view on this is that for inference, we should ignore the attributes. > So, definitions should be tuned to accommodate this. > > I don't think generation can be inferred from use/generated. > > Luc > > On 08/03/2011 03:35 PM, Myers, Jim wrote: > > Paolo, Luc, > > Both clearly have to work the same way if we don't know about PE > internals. > > However, I still have some concern about the idea that B is partially > determined by A and transitivity don't mix. But it doesn't address > aggregate Bobs. If B has two parts, B.1, and B.2 and B.1 is derived > from A, so that B is derivedFrom A, we could also have C derived from > B.2 (therefore C derivedfrom B) and transitivity would break - C is > not derivedfrom A. (I see this as ~analogous to the issue of > derivation being inferable from used/generated: The doc does note that > if B was generated before A was used, derivation cannot be true, so > you can't infer derivation from used-PE-generated structures. This is > because PEs can have temporal parts- they could be an aggregate > process. There are analogous issues because Bobs can have spatial > parts/be aggregate objects. This means you can't infer across > generated-Bob-used structures either and transitivity allows this.) > > I think that boils down to there only being two self-consistent > definitions for derivation -- > > It is inferable from used/generated and is transitive > > It implies partial determination, is only assertable, and is not > transitive > > I think we can pick either or both, but right now it still looks like > we mix the idea that there's some real partial determination with > transitivity in ways that can break. > > Jim > > *From:* public-prov-wg-request@w3.org > <mailto:public-prov-wg-request@w3.org> > [mailto:public-prov-wg-request@w3.org] *On Behalf Of *Paolo Missier > *Sent:* Wednesday, August 03, 2011 8:36 AM > *To:* public-prov-wg@w3.org <mailto:public-prov-wg@w3.org> > *Subject:* Re: PROV-ISSUE-67 (single-execution): Why is there a > difference in what is represented by one vs multiple executions? > [Conceptual Model] > > JIm > > we have established that isDerivedFromInMultipleSteps is also > transitive. I hope this is fine. > > The point of having the relation is that, as Luc explained here below, > in this case the "pe introduction rule"(*) should not be used. > In other words, isDerivedFromInMultipleSteps simply means that, > according to the asserter, more than one pe is required to explain the > derivation (but we don't know how many). > > I can see that your objection is valid, however, in the sense that I > can make up one single pe that encompasses an arbitrary number of steps. > The problem is that we haven't said anything about the nature of the > activity represented by a pe. Unless we say something about their > granularity and composition, any pe can represent any aggregation of > "elementary" activities. > > -Paolo > > (*) if *isDerivedFrom(e1,e0)* holds, then there exists a process > execution *pe*, and roles *r0*,*r1*, such that: > *isGeneratedBy(e1,pe,r1)* and *uses(pe,e0,r0)*. > > > 8/2/11 3:08 AM, Myers, Jim wrote: > > > > It's not that pe is atomic or not. It's that there is a tight link between > > the derivation and the process execution. > > > isDerivedFromInMultipleSteps is silent about that link. > > > If B isDerivedInMultipleSteps from A, can't I (a second witness) always make up a single process that encompasses all steps? Would it then be OK (for me, the second witness making up this account) to claim a direct B isDerivedFrom A. Then I can do transitive closure over such relationships? And then recognize that there were multiple steps, thus making isDerivedInMultipleSteps transitive too? > > > I am not trying to infer derivation beyond transitive closures. > > > I don't see how the definitions given allow one to be transitive and one not to be. If the only difference between the two was an implication of how much the witness knew about what happened (one step or multiple), but both were transitive, I wouldn't be confused (I might still argue that we don't need the distinction). > > Cheers, > Jim > > > Regards, > Luc > > > > -- > 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 <mailto:l.moreau@ecs.soton.ac.uk> > United Kingdomhttp://www.ecs.soton.ac.uk/~lavm <http://www.ecs.soton.ac.uk/%7Elavm> > > > > > -- > ----------- ~oo~ -------------- > Paolo Missier -Paolo.Missier@newcastle.ac.uk <mailto:Paolo.Missier@newcastle.ac.uk>,pmissier@acm.org <mailto:pmissier@acm.org> > School of Computing Science, Newcastle University, UK > http://www.cs.ncl.ac.uk/people/Paolo.Missier
Received on Wednesday, 3 August 2011 21:52:25 UTC