- From: Stephan Zednik <zednis@rpi.edu>
- Date: Thu, 7 Jun 2012 16:39:36 -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: <036D523B-CE02-4A10-BD0F-D9BC53F76F7C@rpi.edu>
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 20:40:28 UTC