W3C home > Mailing lists > Public > public-prov-wg@w3.org > February 2012

Re: Collections in PROV-O

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Sat, 25 Feb 2012 20:50:41 +0000
Message-ID: <CAPRnXtmOdeiQo3E_G5UEsQcfQxPohcyM1HW7tUUz-znBWqMiLg@mail.gmail.com>
To: Paolo Missier <Paolo.Missier@ncl.ac.uk>
Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
No, you've convinced me, let the keys stay as literals. :-)

My apologies for making another storm in a milk glass.

On Fri, Feb 24, 2012 at 17:52, Paolo Missier <Paolo.Missier@ncl.ac.uk> wrote:
> Stian
>
> we have to remember that this is not a programming language designed to
> manipulate data structures. It is designed to represent the effect of
> operations (in this case) on a data structure. In reality, what you observe
> going in and out of a collection are values. They are neither entities, nor
> literals. So in a sense this is a non-problem, but if you think that the use
> case of collections where a value has itself as key is important (as opposed
> to, er, another corner), I am happy to accommodate it by proposing to say
> nothing about the syntactic type of keys.
> Not a big deal, really.
>
> -Paolo
>
>
>
>
> On 2/24/12 3:22 PM, Stian Soiland-Reyes wrote:
>>
>> On Fri, Feb 24, 2012 at 15:10, Luc Moreau<L.Moreau@ecs.soton.ac.uk>
>>  wrote:
>>>
>>> ... and how would you represent this set without literal keys then?
>>> I don't understand what the issue is.
>>
>> Perhaps it's exotic, but to me it is a bit strange to say you can
>> represent any collection, but require the keys to be a literal.
>>
>> If keys can be entities, then you can do a set:
>>
>> entity (v1)
>> entity (v2)
>> entity(c1, prov:type=prov:EmptyCollection)
>> CollectionAfterInsertion(c2, c1, v1, v1)
>> CollectionAfterInsertion(c3, c2, v2, v2)
>> CollectionAfterRemoval(c4, c3, v1)
>>
>> Ie. the values are their own keys.
>>
>>
>>
>> or even with a fixed dummy value (This is how java.util.HashSet is
>> implemtented using a HashMap):
>>
>> entity(PRESENT) // dummy value
>> CollectionAfterInsertion(c2, c1, v1, PRESENT)
>> CollectionAfterInsertion(c3, c2, v2, PRESENT)
>> CollectionAfterRemoval(c4, c3, v1)
>>
>>
>> Both of which I think look elegant and easy enough for someone to
>> understand.
>>
>>
>> This I don't think look elegant:
>>
>> CollectionAfterInsertion(c2, c1, "value1", v1)
>> CollectionAfterInsertion(c3, c2, "value2", v2)
>> CollectionAfterRemoval(c4, c3, "value1")
>>
>> because one would have to keep track of these artificial keys when
>> there are removals - what is the value of saying that "value1" was
>> removed when the collection is reflecting a set of entities?
>>
>>
>> If CollectionAfterRemoval also have an optional value, then I don't
>> think my argumentation is very strong anymore. :-) I do of course see
>> the value of allowing the key to be a literal as well, as it can
>> handle indexes, string dictionaries, etc.
>>
>
>
> --
> -----------  ~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 Saturday, 25 February 2012 20:51:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:56 GMT