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: Fri, 24 Feb 2012 15:22:55 +0000
Message-ID: <CAPRnXtm82m9i+Y6-0oHdv5X=r=oj_6MJe3ndWbjhD1Wj+GjObA@mail.gmail.com>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Cc: public-prov-wg@w3.org
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.

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
Received on Friday, 24 February 2012 15:23:47 GMT

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