Re: Prov-o call on Monday 12:00noon US ET

Stian
you seem to bring transactional issues into a provenance trace... this is not what the model is meant to do!!  the merged account is 
not always well-formed, but we knew that already.

-Paolo


  On 10/25/11 4:42 PM, Stian Soiland-Reyes wrote:
> 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?
>


-- 
-----------  ~oo~  --------------
Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org
School of Computing Science, Newcastle University,  UK
http://www.cs.ncl.ac.uk/people/Paolo.Missier

Received on Tuesday, 25 October 2011 16:12:07 UTC