W3C home > Mailing lists > Public > public-prov-wg@w3.org > January 2013

Re: PROV Dictionary

From: Tom De Nies <tom.denies@ugent.be>
Date: Wed, 9 Jan 2013 15:20:46 +0100
Message-ID: <CA+=hbbej9nxub8=SFWP+uXwCNeOBW6piToFbWBbeZqQythhbGg@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:27 UTC