- From: Stephan Zednik <zednis@rpi.edu>
- Date: Thu, 7 Jun 2012 17:26:15 -0400
- To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Cc: Timothy Lebo <lebot@rpi.edu>, "public-prov-wg@w3.org WG" <public-prov-wg@w3.org>
- Message-Id: <EE40B737-41AE-4030-B54A-CF193027D1E0@rpi.edu>
Luc, I think I focused too much on your last question without address the points you made before it. I think the membership of a collection is the membership over the values of a dictionary. It aligns dictionary with our definition of entity, allows us to treat a dictionary as if it were a generic collection, and means the extension to dictionary is a natural extension, rather than a change, to the definition of a generic collection. --Stephan On Jun 7, 2012, at 5:12 PM, Stephan Zednik wrote: > > On Jun 7, 2012, at 4:51 PM, Luc Moreau wrote: > >> Hi Stephan >> >> That's not I wanted to say. >> >> I can see how to define membership over the keys of a dictionary, >> and membership over the values of a dictionary, but what is membership >> for a dictionary? > > If a dictionary does not have membership, if it does not have constituents (which are said to be member of the collection), than how is it a concretization of the abstract collection class? > > from PROV-DM: (http://www.w3.org/TR/prov-dm/#concept-collection) > 4.5.1 > > Collection > A collection is an entity that provides a structure to some constituents, which are themselves entities. These constituents are said to be member of the collections. > In PROV, the concept of Collection is provided as an extensibility point for other kinds of collections. Collections are implemented by means of dictionaries, which are introduced next. > > 4.5.2 > > Dictionary > PROV-DM defines a specific type of collection: a dictionary, specified as follows. > > A dictionary is a collection whose members are indexed by keys. > > If we are hesitant to introduce a basic membership relation to go along with the abstract collection class, why define the collection class at all? Why mention member of and constituents in the definition of the the general collection term if there is no standard way in PROV to encode such information? > > As for answering the question of what is the membership of a dictionary, I think it is the set of values from all key-value pairs. I believe there may be not be full agreement in the group on this. To me, the key index is a means to specify a specific member of the collection. I don't think a key-value pair is a member of a dictionary, but a means to specify specific members by a unique index (key). > > This would mean Dictionaries are a natural extension of the simple collection, and not a change in modeling. We add key-value pairs as a way to index members, but do not replace the meaning of basic collection membership. > > --Stephan > >> >> Luc >> >> On 07/06/12 21:39, Stephan Zednik wrote: >>> >>> >>> On Jun 7, 2012, at 4:22 PM, Luc Moreau wrote: >>> >>>> Hi Tim, >>>> >>>> I don't think we have tried to define a membership relation over dictionary, >>>> which could work for any collection. >>>> >>>> I don't know how to make a relation such as the one you suggest work >>>> with the current dictionary definition. >>>> >>>> If you look at the specification of the Java Collection interface [1], it has a contains method >>>> (similar to your Collection.hadMember). >>> >>> I would not use the java Collection interface as a reference. >>> >>> Methods on inserting/removing/testing membership of a collection are different than a vocabulary which would be used to declaratively describe collection (container?) membership. >>> >>> For example, the Java collection's containsValue method has very different meaning than declaratively asserting membership. >>> >>> A more relevant reference would be the existing rdf container and collection properties: >>> >>> http://www.w3.org/TR/rdf-primer/#containers (rdf:Bag, rdf:Seq, rdf:Alt) >>> http://www.w3.org/TR/rdf-primer/#collections (rdf:List) >>> >>>> >>>> However, the Map interface [2] does not have this method, instead it has containsKey and >>>> containsValue. >>>> >>>> So, are you suggesting an equivalent to containsValue relation? >>> >>> No, because containsValue is not a relation, but a method that tests if a value is currently present in a given Map. This is not a declarative statement and would map to a query. >>> >>> --Stephan >>> >>>> >>>> Luc >>>> >>>> [1] http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Collection.html >>>> [2] http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Map.html >>>> >>>> >>>> On 07/06/2012 19:34, Timothy Lebo wrote: >>>>> >>>>> Luc, >>>>> >>>>> On the call today, we set aside concerns about CompleteDictionary, since there were not enough voiced objections. >>>>> >>>>> However, I still have concerns about DM's "too specific" restriction on hadMember, which is between a Dictionary and a KeyValuePair. >>>>> >>>>> I've copied the essence of the concern from a previous email, below. >>>>> >>>>> For a model with interoperability as it's primary objective, >>>>> I'm amazed that the DM precludes one from putting members into Collections, and only permits users to put members into its specialization(subclass), Dictionary. >>>>> >>>>> Why block this interoperability AND extensibility? >>>>> >>>>> I think the current modeling in PROV-O is a reasonable compromise to "leave the option open" to extend Collection, while "maintaining the scope" of this WG focusing on Dictionary. >>>>> >>>>> Thanks, >>>>> Tim >>>>> >>>>> >>>>> >>>>> On Jun 6, 2012, at 3:53 PM, Timothy Lebo wrote: >>>>> >>>>>> Luc, >>>>>> >>>>>> On Jun 6, 2012, at 3:37 PM, Luc Moreau wrote: >>>>>> >>>>>> >>>>>> I'm wondering what outstanding issue is in this thread. >>>>>> Is it that you do not want to have a >>>>>> >>>>>> prov:hadMember with domain Collection and range Entity, >>>>>> >>>>>> and instead restrain it to: >>>>>> >>>>>> prov:hadMember with domain Dictionary and range KeyValuePair >>>>>> >>>>>> ? >>>>>> >>>>>> I advocate the former, and think that you want the latter. >>>>>> >>>>>> Regards, >>>>>> Tim >>>>>> >>>>>> >>>>>> [1] http://www.w3.org/mid/CAPRnXtm52YzmjmpO4=Cx+q0um+UMpNdwMdjS68XjMhBmDi1pYQ@mail.gmail.com >>>>> >>> >
Received on Thursday, 7 June 2012 21:28:06 UTC