- From: Satya Sahoo <satya.sahoo@case.edu>
- Date: Wed, 11 Jan 2012 18:06:39 -0500
- To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Cc: public-prov-wg@w3.org
- Message-ID: <CAOMwk6zhLwWKGkdWdtug0qCb11c09Fcfw1t0BTLYgnUUL28U1A@mail.gmail.com>
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