- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Tue, 25 Oct 2011 16:42:44 +0100
- To: Paolo Missier <Paolo.Missier@ncl.ac.uk>
- Cc: public-prov-wg@w3.org
On Tue, Oct 25, 2011 at 11:41, Paolo Missier <Paolo.Missier@ncl.ac.uk> wrote: >> Such flat merging would also affect issues in PROV-DM - for instance >> the current Collection approach would not work in a merged account. > why not? Because it has unpacked the n-ary relationship of a "collection entry" into three different wasDerivedFrom subproperties. # Account 1 # c1 + (k1,e1) ==> c2 wasAddedTo_Coll(c2,c1) wasAddedTo_Key(c2,k1) wasAddedTo_Entity(c2,e1) # c2 + (k2,e2) ==> c3 wasAddedTo_Coll(c3,c2) wasAddedTo_Key(c3,k2) wasAddedTo_Entity(c3,e2) # Account 2 (sees addition of k2/e2 before k1/e1) # c1 + (k2,e2) ==> c2 wasAddedTo_Coll(c2,c1) wasAddedTo_Key(c2,k2) wasAddedTo_Entity(c2,e2) # c2 + (k1,e1) ==> c3 wasAddedTo_Coll(c3,c2) wasAddedTo_Key(c3,k1) wasAddedTo_Entity(c3,e1) What is the (asserted) content of c2 in a merging of these two accounts? What value is under k1 in c3? -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
Received on Tuesday, 25 October 2011 15:48:43 UTC