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: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Thu, 24 Jan 2013 15:32:05 +0000
Message-ID: <CAPRnXt=g7j2A1vdqwiRHmwo1zVkGvSuCAsV+enN3zPzCEt3bYA@mail.gmail.com>
To: Tom De Nies <tom.denies@ugent.be>
Cc: Luc Moreau <l.moreau@ecs.soton.ac.uk>, public-prov-wg@w3.org
On Thu, Jan 24, 2013 at 12:47 PM, Tom De Nies <tom.denies@ugent.be> wrote:

> 1. In the notation hadDictionaryMember(d, e0, "k0"), key follows entity,
> whereas it precedes in derivedByInsertionFrom(d2, d1, {("k1", e3)}). Should
> this be made uniform? Is it worth the extra effort?

I think not, I am fine with the current order.

The hadDictionaryMember focuses on the dictionary having the entity as
a member.

If we swap arguments around here:
  hadDictionaryMember(d, "k0", e0)

..we might want to rename the relation to something key-centric like
"hadDictionaryEntry" - and then the link to hadMember is less obvious.
"hadDictionaryMemberAtKey"? That said - I could live with the above
order as well.


The order {("key", value), ("key2", value2)} is what is used in almost
all programming languages (with various syntax) when dealing with
dictionaries, including Python, Ruby, Lisp, Clojure, Javascript and
Java - and so I think we should keep that as well - and just live with
the inconsistency.


> 2. http://www.w3.org/TR/prov-n/#extensibility  states: the predicate MUST be
> a qualifiedName with a non-empty prefix. However, we will be using the prov
> namespace. How do we proceed?

See my suggestion - using prov:hadDictionaryMember(..) etc.

(it's also consistent with the type being 'prov:Dictionary' and not
'Dictionary' )


> 3. PROV-O: should qualifiedInsertion and qualifiedRemoval imply
> qualifiedDerivation? If yes, how do we specify this? Through a sub-property?
> Does that break anything?

No, they should not imply this.

In PROV-O we split out the qualified* and the prov:Influence
subclasses so that they are not in a nested hierarchy. So for instance
prov:qualifiedQuotation is just a subproperty of
prov:qualifiedInfluence - not of prov:qualifiedDerivation - even
though the corresponding prov:wasQuotedFrom is a subproperty of
prov:wasDerivedFrom.

However  - as I suggested in my review - we would want a
prov:DictionaryInfluence to be a domain for the prov:dictionary
property as it currently has the wrong intersection domain of
prov:Insertion and prov:Removal.



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
Received on Thursday, 24 January 2013 15:33:02 UTC

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