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

Stian,

again, my view, which is in line with Luc's in this instance. this is one of those "existential" inferences that stipulate the 
existence of an element in the model, which we know nothing else about. It just provides a uniform conceptual view of the act of 
creating a Collection with content.
With this, membership is no longer primitive but it is added to the model as a useful convenience, as agreed by the group.

-Paolo


On 4/25/12 11:15 AM, Luc Moreau wrote:
> 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.
>>
>>
>>
>>


-- 
-----------  ~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 Wednesday, 25 April 2012 09:56:17 UTC