W3C home > Mailing lists > Public > public-prov-wg@w3.org > November 2011

Re: PROV-ISSUE-125: derivation-attributes constraint (PROV-DM and PROV-O) [Data Model]

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Wed, 30 Nov 2011 12:22:01 +0000
Message-ID: <EMEW3|0693dbd2008432022e6d660b7da27658nAYCM508L.Moreau|ecs.soton.ac.uk|4ED61FE9.7090709@ecs.soton.ac.uk>
To: public-prov-wg@w3.org
Hi Satya,
Can you please confirm we can close this issue? (at least, for the dm part)
Best regards,
Luc

On 11/07/2011 12:51 PM, Luc Moreau wrote:
> Hi Satya,
>
> Responses interleaved.
>
> On 10/15/2011 11:48 PM, Provenance Working Group Issue Tracker wrote:
>> PROV-ISSUE-125: derivation-attributes constraint (PROV-DM and PROV-O) 
>> [Data Model]
>>
>> http://www.w3.org/2011/prov/track/issues/125
>>
>> Raised by: Satya Sahoo
>> On product: Data Model
>>
>> The following constraint (id=derivation-attributes) is defined for 
>> wasDerivedFrom Relation (in mercurial fpwd head PROV-DM document on 
>> Oct 15, 2011):
>>
>> "Given a process execution expression denoted by pe, entity 
>> expressions denoted by e1 and e2, qualifiers q1 and q2, the assertion 
>> wasDerivedFrom(e2,e1,pe,q2,q1) or wasDerivedFrom(e2,e1) holds if and 
>> only if the values of some attributes of the entity expression 
>> identified by e2 are partly or fully determined by the values of some 
>> attributes of the entity expression identified by e1."
>>
>> Issue:
>> a) This attribute-based constraint for wasDerivedFrom property can 
>> lead to ambiguous assertions of wasDerivedFrom between Entity instances.
>>
>> Example scenario: The color attribute of an apple, kept in a 
>> refrigerator, "color = brown" is determined by the attribute of the 
>> refrigerator "temperature = -10C". Can we assert that "brown apple" 
>> wasDerivedFrom "refrigerator"?
>>
>> We can argue that the "brown apple" dependedOn "refrigerator" with 
>> temperature setting of -10C, but not wasDerivedFrom
>>
>> Suggestion: restate the above attribute-based constraint for 
>> "dependedOn" relation instead of "wasDerivedFrom"
>
> The WG agreed that this constraint should be dropped.
>
>> b) Since dependedOn is a weaker notion of wasDerivedFrom - we can 
>> assert in the PROV-O that dependedOn is a parent property (more 
>> generic version) of wasDerivedFrom
>
> That's a prov-o specific comment.
> You need to be careful about transitivity. One is, the other is not, i 
> believe.
>
>> c) Suggest renaming dependedOn to dependentOn
>>
>>
> It's nice to be able to keep the verbal form, similarly to the other 
> relations, with past explicit.
>
> I feel we can close this issue. Let me know if otherwise.
>
> Cheers,
> 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
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
Received on Wednesday, 30 November 2011 12:22:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:04 UTC