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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:12 UTC