- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Wed, 11 Jan 2012 23:17:51 +0000
- To: Satya Sahoo <satya.sahoo@case.edu>
- CC: public-prov-wg@w3.org
- Message-ID: <EMEW3|5f8c68f19d8dd96127595473750c5bc5o0ANJA08L.Moreau|ecs.soton.ac.uk|4F0E189F>
Thanks Satya. Luc On 11/01/12 23:06, Satya Sahoo wrote: > 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 > <mailto: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 > > 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 > <tel:%2B44%2023%208059%204487> > University of Southampton fax: +44 23 8059 2865 > <tel:%2B44%2023%208059%202865> > Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk > <mailto:l.moreau@ecs.soton.ac.uk> > United Kingdom http://www.ecs.soton.ac.uk/~lavm > <http://www.ecs.soton.ac.uk/%7Elavm> > > >
Received on Wednesday, 11 January 2012 23:22:03 UTC