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

Re: Collections in PROV-O

From: Paolo Missier <Paolo.Missier@ncl.ac.uk>
Date: Fri, 24 Feb 2012 17:52:27 +0000
Message-ID: <4F47CE5B.8080209@ncl.ac.uk>
To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
CC: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
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
Received on Friday, 24 February 2012 17:52:57 GMT

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