- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Thu, 08 Mar 2012 13:53:14 +0000
- To: public-prov-wg@w3.org
Hi Graham, Responses interleaved. On 03/08/2012 11:26 AM, Graham Klyne wrote: > Luc, thanks ... comments below: > > Re: > http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd5-prov-dm-derivation.html > > > On 08/03/2012 09:04, Luc Moreau wrote: >> Hi Graham, >> yes, it's in the repo, at the URL you indicate. >> >> Luc >>>> >>>> Thanks for your input. I made a few changes >>>> - i fixed the asn > > In section 1, I'm still seeing a description that doesn't match the > sample ASN (e.g. which of the listed values does "e2" correspond to, > etc.) e2 is the identifier of the generated entity. which exact description do you refer to? > > Reading this in isolation, looking at "identifier for the generation > involving the generated entity and activity", I'm not sure what is > referred to by "generation". I might guess it's an event, but that's > not clear. These are terms defined in prov-dm: see http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-Generation > > Similar for "usage". http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-Usage > >>>> - i reordered the examples so that the simple one comes first > > The first two look reasonable to me, but I still don't see why > wasDerivedFrom(e2,e1,a,g2,u1) is needed. Once we have expressions > that expliciitly name activities, how much real value is there in > having the "short cut" form? Can't this be expressed by having an > explicit activity record, etc.? 'a' is not an activity but an activity identifier. Likewise for g2/u1, generation/usage identifiers. If you don't refer to them in a derivation, then you won't know, for instance, which usage refers to an entity, or which activity underpins the derivation. > > (I'm not suggesting the model should not be capable of expressing this > information, just arguing against this overloading of the > wasDerivedFrom record which AIUI is primarily an entity-entity relation.) > >>>> - i provided a brief explanation as to why it is useful to have >>>> activity, >>>> generation and usage mentioned. >>>> >>>> Regarding the statement about transitivity, i don't think it's >>>> unreasonable to >>>> have it here. It's inline with >>>> what we say for wasInformedBy, not transitive either. But, if >>>> people feel we >>>> shouldn't say anything >>>> about the characteristics of relations in part 1, I have got not >>>> objection >>>> moving this to part 2. >>>> Maybe we should only say when a relation *is* transitive. > > I thought the point of the simplified Part 1 was to concentrate on the > data model, and introduce all the constraint and inferential material > later in part 2. For someone who is reading *just* part 1, I don't > see any utility in being told that a property is or is not transitive, > unless it helps a reader to understand the intent of the record, which > in this case I don't think it does. > I am happy to follow suggestions from the WG. Ultimately, there is only one relation that is transitive (traceTo). Luc > #g > -- > >>>> It would be good to hear what people think. >>>> >>>> I hope it helps, >>>> >>>> Cheers, >>>> Luc >>>> >>>> On 06/03/2012 21:30, Graham Klyne wrote: >>>>> On 06/03/2012 13:41, Paul Groth wrote: >>>>>> 2) There is a proposal on derivation to resolve ISSUE-249. Please >>>>>> see >>>>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd5-prov-dm-derivation.html >>>>>> >>>>>> >>>>>> >>>>> In its present form, I can't be sure what it's trying to say, so >>>>> I'd have to >>>>> vote against. >>>>> >>>>> The ASN template and the description of terms do not match up. >>>>> >>>>> I don't understand "identifier for the generation involving the >>>>> generated >>>>> entity >>>>> and activity" >>>>> >>>>> I don't understand " identifier for the usage involving the used >>>>> entity and >>>>> activity" >>>>> >>>>> Assuming section 1 is intended to go in DM part 1, then I think >>>>> the paragraphj >>>>> about transitivity is out of place. >>>>> >>>>> Why do we need anything other than: >>>>> >>>>> wasDerivedFrom(e2, e1, [attr]) >>>>> >>>>> ? >>>>> >>>>> At heart, generation is about two entities and an activity, so the >>>>> full >>>>> gamut of >>>>> possibilities can be captured by >>>>> >>>>> wasGeneratedBy >>>>> used >>>>> >>>>> statements >>>>> >>>>> Thus the wasDerivedFrom is available as a convenience property to >>>>> describe the >>>>> derivation when further information about the activity is not >>>>> available. >>>>> >>>>> Note that I've deliberately ignored the multiple-stage derivation >>>>> case. When >>>>> the derivation passes through a chain of activities, one could, if >>>>> needed, >>>>> introduce a new activity that is the composition of the sequence >>>>> involved in >>>>> the >>>>> derivation. In practice, I don't see that this arises in the >>>>> simple cases. >>>>> >>>>> In summary, I propose: simplify! >>>>> >>>>> #g >>>>> -- >>>>> >>>> >> > -- 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
Received on Thursday, 8 March 2012 13:53:50 UTC