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

Hi Luc,
Since the issues raised in this thread have been superseded with updates in
DM, I am comfortable with closing this issue.

Thanks.

Best,
Satya

On Wed, Nov 30, 2011 at 7:22 AM, Luc Moreau <L.Moreau@ecs.soton.ac.uk>wrote:

> 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<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<http://www.ecs.soton.ac.uk/~lavm>
>
>
>

Received on Wednesday, 11 January 2012 23:07:13 UTC