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

Re: PROV-DICTIONARY internal review for first public working draft (ISSUE-614)

From: Tom De Nies <tom.denies@ugent.be>
Date: Thu, 24 Jan 2013 15:40:30 +0100
Message-ID: <CA+=hbbcGTomSsu0pLmm4mYDy3u618VuTgqNs_Ck_fumL-PY=sg@mail.gmail.com>
To: Paolo Missier <Paolo.Missier@ncl.ac.uk>
Cc: Provenance Working Group <public-prov-wg@w3.org>
Hello Paolo,

thanks for your very timely review! We have made changes in the document
according to your suggestions, and have responded below.

> specific comments:
> ----------
> sec. 2
> ----------
> ++ "A given dictionary forms a given structure for its members. A
> different structure (obtained either by insertion or removal of members)
> constitutes a different dictionary. "
> this sentence is not very clear to me. I think this is trying to say what
> the rest of the paragraph says, namely that
> "for the purpose of provenance, a dictionary entity is viewed as a
> snapshot of a structure . Insertion and removal operations result in new
> snapshots, each snapshot forming an identifiable dictionary entity"
> maybe rephrase this slightly?  suggestion:
> "for the purpose of provenance, a dictionary entity is viewed as a
> snapshot of a dictionary data structure, following a sequence of
> state-changing insertion and removal operations. These  operations result
> in new snapshots, each snapshot forming an identifiable dictionary entity"
> But this (that dictionaries, and in general collections, are snapshot of
> data structures with a state) is an important point which I can see that is
> gone missing from PROV-DM: http://www.w3.org/TR/prov-dm/#component6
> Thus, if it was not made there, maybe drop it from here, as well?

I like your rephrasing, and have incorporated in the document. I think the
snapshot concept was dropped from collections because the notion of
insertion/removal was removed as well. In dictionary, your description
seems very accurate to me, and I suggest we keep talking about snapshots.

> ++
> " i.e. an entity that can participate in relations amongst dictionaries;"
> suggest:  i.e. an entity that can participate in relations that involve
> dictionaries and their member entities;
>  Done.

> "The dictionary membership allows stating the members of a Dictionary, and
> has the purpose of providing more structure than the collection membership
> relation."
> suggest:
> Similar to the collection membership relation, the dictionary membership
> allows stating the members of a Dictionary. However, it provides additional
> structure."
> Done.

> ++
>  "Whereas the collection membership relation applies to entities having
> prov:type = 'prov:Collection' or prov:type = 'prov:Dictionary', the
> dictionary membership only applies to the latter."
> how can the collection membership in PROV-DM have a reference to prov:type
> = 'prov:Dictionary'?
> What we mean by this is that hadMember(c, e) can be used when c is a
Collection or a Dictionary, but that hadDictionaryMember(d,e,"k") can only
be used when d is a Dictionary. I have attempted to make this clearer in
the text, in a separate paragraph right above the example.

> "Note that dictionary membership implies collection membership,"
> this may be unclear because, formally, the former cannot be a sub-relation
> of the latter (they have different arguments).
> Suggestion: make a reference to top of sec. 6.1 (inferences) where this
> implication is formalized
> Done.

> sec 2.2
> ----------
> ++
>  "each key_i is expected to be unique for the key-entity-set;"
>   make a ref. to 6.1 inf 2?
> Done.

> ex. 3 and following:
>   "d0 is the set..."  would it be more appropriate to write "d0 was the
> set..."?
> Indeed, done. I've changed this throughout the rest of the document as well

> ----------
> sec 3.1
> ----------
> ++
> do we need an explicit (trivial) production for dIdentifier? i.e.
> dIdentifier ::= identifier
> Yes, and also for the other new non-terminals.
I've also corrected the links to prov-n non-terminals.
The new expressions are here:
Could you go over them quickly? Thanks!

> ----------
> sec 4
> ----------
>  Would it be useful to specify which of these specifications extend the
> PROV-O vocabulary for Collections?
> i.e.
>    prov:hadDictionaryMember replaces prov:hadMember
>    prov:KeyValuePair  is a new relation
>    etc
> I think this might be unnecessary. All the specifications mentioned in
this document are new, and for those that have a relation to PROV-DM, it is
mentioned at the level of each specification.
However, should there be more demand from other reviewers to include this
extra clarification, I'd be happy to do it by the next draft.

> ----------
> sec 6
> ----------
> should the rules be numbered for easy reference?

> IF derivedByRemovalFrom(d2, d1, {"k1"}) THEN hadDictionaryMember(d1, e1,
> "k1")
> I am in favour of removing this constraint.
> Dropped.

> --
> -----------  ~oo~  --------------
> Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org
> School of Computing Science, Newcastle University,  UKhttp://www.cs.ncl.ac.uk/people/Paolo.Missier
> PGP Public key: 0x45596549  - key servers: pool.sks-keyservers.net
Received on Thursday, 24 January 2013 14:41:07 UTC

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