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

I believe that now that we have a more clearly logical structure
called prov:Dictionary this issue can be closed.  (And I have done so)

Real-world collections are a different matter, which we can luckily
forget about for now/

On Wed, Apr 25, 2012 at 10:55 AM, Paolo Missier <Paolo.Missier@ncl.ac.uk> wrote:
> 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
>
>



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Thursday, 3 May 2012 13:51:39 UTC