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

Hi Stian,

Response interleaved.

On 25/04/2012 10:44, Provenance Working Group Issue Tracker wrote:
> PROV-ISSUE-365 (membership-as-insertion-too-limitting): Collection constraint membership-as-insertion too limitting [prov-dm-constraints]
>
> http://www.w3.org/2011/prov/track/issues/365
>
> Raised by: Stian Soiland-Reyes
> On product: prov-dm-constraints
>
> https://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#collection-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:
>
> agent(shephard)
> entity(blackSheep)
> entity(whiteSheep)
> activity(buildingFenceAroundSheep)
> wasAssociatedWith(shephard, buildingFenceAroundSheep)
> entity(sheepWithinFence, [prov:type="prov:Collection"  %% xsd:QName])
> wasGeneratedBy(sheepWithinFence, sheepWithinFence)
>
>    
I assume you mean the following:

wasGeneratedBy(sheepWithinFence, buildingFenceAroundSheep)


> memberOf(sheepWithinFence, {(1, blackSheep), (2, whiteSheep)})
>
> you are now saying that this implies:
>
> derivedByInsertionFrom(X, sheepWithinFence, {(1, blackSheep), (2, whiteSheep)})
>
>    
Remember that the dictionary in prov-dm is a conceptual structure.

When we say:

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

We say there is a conceptual disctionary X to which blackSheep and whiteSheep were added.


> again implying
>
> used(buildingFenceAroundSheep, X)
>    

No, you can't infer this. You could only infer it if we had said that 
the derivation is underpinned by the activity

buildingFenceAroundSheep. But it's not the case. We don't say anything about the activity, because
we again, we are saying how conceptual structures evolve.


> 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.
>
>    


The point of this inference for me is to explain memberOf in terms of 
existing relations (in particular, this would allow us
to derive event ordering constraints ... ). I don't think you are able 
to relate X to any other entity/activity in the model.

Luc
> > 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 09:17:25 UTC