Re: prov-wg: Telecon Agenda March 8, 2012

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