- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Sat, 25 Feb 2012 20:50:41 +0000
- 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 UTC