ISSUE-137: Collection assertions does not guarantee isolation

collection-isolation

Collection assertions does not guarantee isolation

State:

CLOSED

Product:

prov-dm

Raised by:

Stian Soiland-Reyes

Opened on:

2011-10-29

Description:

http://www.w3.org/TR/prov-dm/#expression-Collection introduces relations for expressing collection modifications, including:

> Expression: wasAddedTo_Coll(c2,c1) (resp. wasRemovedFrom_Coll(c2,c1)) denotes that collection c2 is an updated version of collection c1, following an insertion (resp. deletion) operation.

a) Can other entities/keys be added or removed from c1 during its lifetime (on their own without wasAdded/Removed assertions), or is its whole content fixed for the duration of the entity c1?

b) in wasAddedTo_Coll(c2,c1) will c2 contain every key/value of c1, in addition to the added key/entity? (ignoring for now the separate issue collection-collision) - or could some c1 keys/elements be missing - or other keys/elements also have been added to c2?

c) (equivalent for wasRemovedFrom_Coll(c3, c2)

d) Is it possible to have both wasAddedTo_Coll(c2, c1) and wasRemovedFrom_Coll(c2,c1) at the same time, or are these functionally (issue collection-functional) exclusive? If it is possible - in which order should they be interpreted if they state the same key/value?


In short - I believe the collection assertions are useful - but they should also come with a strong promise that no other elements were added/removed between c2 and c1 - otherwise for all you know all of c1 has been removed "offline" from c2 (a hole in the bucket, so to speak), and you can then never look further back than the last added key/element.

Related Actions Items:

No related actions

Related emails:

1. Re: Collections: issue-136 and issue-137 (from soiland-reyes@cs.manchester.ac.uk on 2012-04-25)
2. Re: PROV-ISSUE-136 (collection-functional): Collection not stated as functional [Data Model] (from soiland-reyes@cs.manchester.ac.uk on 2012-04-25)
3. Re: PROV-ISSUE-137 (collection-isolation): Collection assertions does not guarantee isolation [Data Model] (from soiland-reyes@cs.manchester.ac.uk on 2012-04-25)
4. Collections: issue-136 and issue-137 (from L.Moreau@ecs.soton.ac.uk on 2012-04-18)
5. Re: closing old collection issues -> the question of monotonicity of provenance (from Paolo.Missier@ncl.ac.uk on 2012-03-29)
6. Re: closing old collection issues (from soiland-reyes@cs.manchester.ac.uk on 2012-03-29)
7. Re: closing old collection issues (from L.Moreau@ecs.soton.ac.uk on 2012-03-28)
8. Re: closing old collection issues (from satya.sahoo@case.edu on 2012-03-28)
9. Re: closing old collection issues (from L.Moreau@ecs.soton.ac.uk on 2012-03-28)
10. closing old collection issues (from Paolo.Missier@ncl.ac.uk on 2012-03-28)
11. Re: PROV-ISSUE-137 (collection-isolation): Collection assertions does not guarantee isolation [Data Model] (from Paolo.Missier@ncl.ac.uk on 2012-03-07)
12. Re: PROV-ISSUE-137 (collection-isolation): Collection assertions does not guarantee isolation [Data Model] (from soiland-reyes@cs.manchester.ac.uk on 2012-02-22)
13. Re: PROV-ISSUE-136 (collection-functional): Collection not stated as functional [Data Model] (from soiland-reyes@cs.manchester.ac.uk on 2012-02-22)
14. Re: PROV-ISSUE-135 (collection-names): Collection relations have confusing names [Data Model], ISSUE-137, (from soiland-reyes@cs.manchester.ac.uk on 2012-02-22)
15. PROV-ISSUE-137 (collection-isolation): Collection assertions does not guarantee isolation [Data Model] (from sysbot+tracker@w3.org on 2011-10-29)

Related notes:

Display change log