- From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
- Date: Thu, 08 Mar 2012 11:26:10 +0000
- To: public-prov-wg@w3.org
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.) 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. Similar for "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.? (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. #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 >>>> -- >>>> >>> >
Received on Thursday, 8 March 2012 13:19:17 UTC