PROV-ISSUE-365 (membership-as-insertion-too-limitting): Collection constraint membership-as-insertion too limitting [prov-dm-constraints]

PROV-ISSUE-365 (membership-as-insertion-too-limitting): Collection constraint membership-as-insertion too limitting [prov-dm-constraints]

Raised by: Stian Soiland-Reyes
On product: prov-dm-constraints says:

memberOf(c, {(k1, v1), ...}) holds IF AND ONLY IF there exists a collection c0, such that derivedByInsertionFrom(c, c0, {(k1, v1), ...}).

This seems very limiting. (and is also contradicting constraint collection-unique-derivation - even if I don't like it also constraining memberOf)

Collections can be created by other means than insertion - removal is one of them, but it could also come out of an activity which does not have a 'before' collection.

For instance if I have:

wasAssociatedWith(shephard, buildingFenceAroundSheep)
entity(sheepWithinFence, [prov:type="prov:Collection"  %% xsd:QName])
wasGeneratedBy(sheepWithinFence, sheepWithinFence)

memberOf(sheepWithinFence, {(1, blackSheep), (2, whiteSheep)})
you are now saying that this implies:

derivedByInsertionFrom(X, sheepWithinFence, {(1, blackSheep), (2, whiteSheep)})

again implying 

used(buildingFenceAroundSheep, X)
entity(X, [prov:type="prov:Collection"  %% xsd:QName])

This does not make sense to me. What is this collection X, and where does it come from? Why are blackSheep and whiteSheep the newest additions? What if they were in X? In this example the shephard built a fence around the sheep, and so they were never inserted into a collection, even if you say that X is an empty collection - there never was a "0 sheep within the fence" collection.

>From computer science we can find examples of tuples, etc, which are never added to or removed, they either exist with both values, or they don't exist. They are not formed by inserting into some secret collection.

Received on Wednesday, 25 April 2012 08:44:21 UTC