Re: Collections in PROV-O

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