- From: Tom De Nies <tom.denies@ugent.be>
- Date: Wed, 9 Jan 2013 15:20:46 +0100
- To: Stephan Zednik <zednis@rpi.edu>
- Cc: Graham Klyne <graham.klyne@zoo.ox.ac.uk>, Luc Moreau <l.moreau@ecs.soton.ac.uk>, Curt Tilmes <Curt.Tilmes@nasa.gov>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-ID: <CA+=hbbej9nxub8=SFWP+uXwCNeOBW6piToFbWBbeZqQythhbGg@mail.gmail.com>
We've made the changes using hadDictionaryMember. The conceptual definition, PROV-N, and constraints have been updated accordingly. What remains to do is the PROV-O and PROV-XML serializations. We expect to have these done by Thursday (or Friday at the last), after which we can release the document for internal review. Tom 2012/12/29 Stephan Zednik <zednis@rpi.edu> > Right now I am happy with either of the following, though I have a > preference for 2): > > 1) allow attributes on hadMember and require a prov:key in a dictionary > membership relation > > hadMember(d1, e1, [prov:key="k1"]) > > This allows re-use of the existing Membership relation but requires us to > modify it to support attributes and introduces a requirement on the use of > an attribute based on the type of the referenced collection. > > 2) mint a new dictionary specific membership relation which is ternary. > This relation could imply a simple (non-dictionary) membership of the > entity. > > hadDictionaryMember(d1, e1, "k1") > > Could imply > > HadMember(d1, e1) > > The benefit of 2) is that it would not require a change to the current > definition of Membership in the PROV-DM and the key requirement is easier > to enforce. > > --Stephan > > On Dec 29, 2012, at 5:03 AM, Graham Klyne <graham.klyne@zoo.ox.ac.uk> > wrote: > > On 20/12/2012 17:52, Stephan Zednik wrote: > > I believe Tim and myself had discussed a similar line of reasoning to what > Curt is suggesting when we were trying to see how Dictionary membership > could work in PROV-O (before Dictionary was split out into its own note). > > > We were at the time trying to use a unified non-qualified membership > relation that worked for dictionaries as well as general collections. In > PROV-O this lead to the question of where does the key information reside? > > > Right now I like the idea of > > > hadMember(d1, e1, "k1") > > > That alternative works for me, provided it also implies: > > hadMember(d1, e1) > > so that the dictionary still behaves as a subtype of a collection. > > #g > -- > > > The dictionary note can define the attribute prov:dictKey which is used in > a membership relation when the collection is a dictionary. We may want to > define a new relation such as hadDictionaryMember( ) so we are not > overloading the existing membership relation. > > > I am still not completely sure about what to do with unqualified > dictionary membership properties in PROV-O. Perhaps one is simply not > defined for dictionaries? > > > --Stephan > > > On Dec 20, 2012, at 8:24 AM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote: > > > > It would work, but feels heavy. > > > I personally prefer the original design. > > > Luc > > > On 12/20/2012 03:17 PM, Curt Tilmes wrote: > > > Specialization? > > > entity(d1, [prov:type='prov:Dictionary']) > > entity(d2, [prov:type='prov:Dictionary']) > > > entity(e1) > > > specializationOf(e1_1, e1) > > entity(e1_1, [prov:key='k1']) > > hadMember(d1, e1_1) > > > specializationOf(e1_2, e1) > > entity(e1_2, [prov:key='k2']) > > hadMember(d2, e1_2) > > > Gets kind of ugly though.. > > > Curt > > > On 12/20/2012 09:49 AM, Luc Moreau wrote: > > > Hi Curt, > > > What if e1 belongs to two dictionaries, with keys k1 and k2, respectively? > > > Luc > > > On 12/20/2012 02:44 PM, Curt Tilmes wrote: > > hadMember(c,e) can't have additional attributes or other arguments. > > > You could do something like: > > > entity(d, [prov:type='prov:Dictionary']) > > entity(e1, [prov:key='k1']) > > hadMember(d, e1) > > > This adds prov:key to the 'prov:' namespace, but that should be ok, > > since we've said Notes can do so. > > > We could make it a little more specific to Dictionaries with > > "prov:dictkey='k1'". > > > > I'm also not sure what to do with multiple membership like: > > > d = [(k1, e1), (k2, e1)] > > > (Just give it two "prov:key"s?) > > > Curt > > > On 12/20/2012 09:23 AM, Tom De Nies wrote: > > Hello Luc, > > > I understand your concern, and it's something we can address before > > proceeding. During the last telecon, we motivated our desire to redesign > > the original memberOf relation of Dictionary. Basically, we'd like > > consistency with Collection membership. > > > Would the notation hadMember(d1, e1, "k1") address you concern? (without > > the brackets) > > In essence, this adds one attribute to the Collection membership for > > Dictionary. It also would mean minimal changes througout the document. > > > Tom > > > On Dec 20, 2012 3:07 PM, "Luc Moreau" <l.moreau@ecs.soton.ac.uk > > <mailto:l.moreau@ecs.soton.ac.uk <l.moreau@ecs.soton.ac.uk>>> wrote: > > > Hi Tom and Sam, > > > Sorry for the delay. > > I have some concerns about the proposed membership relation. > > > PROV requires members of a collection to be entities. > > http://www.w3.org/TR/2012/CR-prov-dm-20121211/#concept-collection > > > Given this, your relation > > hadMember(d, ("k1", e1)) > > seems to indicate that ("k1",e1) is also an entity. > > > It's not how I had initially envisaged this to work. I see e1 as an > > entity > > belonging to the dictionary d, with "k1" it's key. > > So, in my view, we have: > > hadMember(d,e1) > > but not > > hadMember(d,("k1",e1)) > > > If ("k1",e1) is an entity, what is its identifier? > > > Grammatically, hadMember(d,("k1",e1)) is not compatible with the > > prov-n notation, since the second argument of hadMember has to > > be a qualified name (the identity of the member). > > > To me, it's important that we address this issue, before going into > > a review. > > > Luc > > > > On 12/18/2012 04:03 PM, Tom De Nies wrote: > > Specific questions we have for reviewers are: > > > 1. Is the notation of Dictionary concepts clear & acceptable for > > you? (in PROV-N and PROV-O) > > 2. Are the constraints acceptable, or are they too loose/too > > strict? > > 3. Are you happy with the solution to the issue regarding > > completeness? (Tracing back to an EmptyDictionary) > > 4. Is the note ready to be published as FPWD? > > > We would like to end the internal review after the first week of > > the new year. > > > Thanks everyone, and happy holidays! > > > Tom > > > 2012/12/18 Sam Coppens Ugent <sam.coppens@ugent.be > > <mailto:sam.coppens@ugent.be <sam.coppens@ugent.be>>> > > > Hello everybody, > > > The Dictionary Note > > ( > http://dvcs.w3.org/hg/prov/raw-file/default/dictionary/prov-dictionary.html > ) > > has been finalised for review. Feedback on the note is welcome. > > Could everybody also check the authors of the document? If > > someone is missing, let us know. > > > Thanks a lot! > > > Best Regards, > > > Sam & Tom > > > -- > > Professor Luc Moreau > > Electronics and Computer Science tel:+44 23 8059 4487 > > <tel:%2B44%2023%208059%204487> > > University of Southampton fax:+44 23 8059 2865 > > <tel:%2B44%2023%208059%202865> > > Southampton SO17 1BJ email:l.moreau@ecs.soton.ac.uk > > <mailto:l.moreau@ecs.soton.ac.uk <l.moreau@ecs.soton.ac.uk>> > > United Kingdomhttp://www.ecs.soton.ac.uk/~lavm > > > -- > > Professor Luc Moreau > > Electronics and Computer Science tel: +44 23 8059 4487 > > University of Southampton fax: +44 23 8059 2865 > > Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk > > United Kingdom http://www.ecs.soton.ac.uk/~lavm > > > > > > > >
Received on Wednesday, 9 January 2013 14:21:21 UTC