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

Hi Sam and Tom,

Thanks for producing the document.

 >Questions for reviewers
 >- Is the notation of Dictionary concepts clear & acceptable for you? 
(in PROV-N, PROV-O and/or PROV-XML)
yes
 >- Are the constraints acceptable, or are they too loose/too strict?
 >-- In particular, can the constraint "IF derivedByRemovalFrom(d2, d1, 
{"k1"}) THEN hadDictionaryMember(d1, e1, "k1") " be >dropped, or do you 
strongly support it?
Constraints are fine, I would generalise some of them with sets of 
keys.  Otherwise, yes, we can drop this one.

 >- Is the name PROV-DICTIONARY appropriate for the document?

yes.
 >- Can this be released as a first public working draft?

yes
 >- If not, where are the blocking issues?
 >- If yes, are there other issues to work on?

Further comments.

- section 1:
" The Provenance Working Group is seeking feedback from the community on 
its usefulness in practical scenarios."
  should be placed in "status of this document" section rather than here.

- derivedByInsertionFrom(id; d2, d1, {(key_1, e_1), ..., (key_n, e_n)}, 
attrs),
key_i <> key_j
- key_i is a value,
   link to the notion of value in prov-dm

- 2.3 Dictionary Removal

derivedByRemovalFrom(d3, d2, {"k1"})
what's the meaning if a key "k1"  is not in the dictionary?
is d3 same as d2?


- "Entities, however, are immutable " ... we have to be careful, some 
aspects are fixed, but others can change.

- notation:
hadDictionaryMember(d, e0, "k0")
derivedByInsertionFrom(d2, d1, {("k1", e3)})

  In first notation, key follows entity, whereas it precedes in second. 
Can this be made uniform?

- prov-n defines extensibility of the grammar:
   http://www.w3.org/TR/prov-n/#extensibility

  The text states: the predicate MUST be a qualifiedName with a 
non-empty prefix.

   The reason for this requirement was that we anticipated new terms to 
be in non prov namespaces.
   I don't know what we should do here, given that we are defining these 
terms in the prov namespace.



- "A dictionary may be empty, in which case it SHOULD be described as an 
instance of the subclass prov:EmptyDictionary. "
  really? In fact, we may not know that
   entity(e, [prov:type='prov:Dictionary']) is empty, but it may well be.


- two kinds of INVOLVEMENTS ... it's legacy of a previous version, 
involvement is no longer defined in prov.
  I think we mean Influence?  Do qualifiedInsertion and qualifiedRemoval 
imply qualifiedDerivation?

- prov:value is already defined in prov-o, it has Entity as a domain. 
This would make KeyValuePair an entity.
   Is it the expectation?


- IF derivedByRemovalFrom(d2, d1, {_"k1"}) and 
derivedByInsertionFrom(d2, d1, {_("k2", e2)})THEN INVALID
what is this notation _"k1"?


And in next constraint: _("k1", e1)

- Should
  IF derivedByRemovalFrom(d2, d1, {_"k1"}) and derivedByRemovalFrom(d2, 
d1, {_"k2"})THEN INVALID
  become:
IF derivedByRemovalFrom(d2, d1, S1) and derivedByRemovalFrom(d2, d1, S2) 
and S1<>S2 THEN INVALID

- Should
   IF derivedByInsertionFrom(d2, d1, {_("k1", e1)}) and 
derivedByInsertionFrom(d2, d1, {_("k2", e2)})THEN INVALID
becoem
  IF derivedByInsertionFrom(d2, d1, S1) and derivedByInsertionFrom(d2, 
d1, S2) and S1<>S2 THEN INVALID

In general inference rules may have to be generalized similarly.



On 16/01/2013 09:17, Tom De Nies wrote:
> Hi everyone,
>
> Our apologies that this mail did not go out sooner. We had some 
> trouble with our university mailing server, and couldn't send any 
> mails anymore from our approved email addresses.
> I sent an email to the list from another address on Friday, but 
> apparently it didn't get through.
>
> PROV-DICTIONARY is now ready for internal review.
> This document is on the NOTE track, and we'd like to publish a working 
> draft by the time the RECs go to PR.
>
> The latest editor's draft is here: 
> https://dvcs.w3.org/hg/prov/raw-file/default/dictionary/prov-dictionary.html#dictionary-xml-schema
>
> The following people volunteered for reviewing the document: Paolo, 
> Stian, James (maybe), Luc, and Paul, but others are also welcome to 
> review of course.
> If you only have bandwidth to review part of the document (e.g. only 
> the ontology section), that could be useful as well.
>
> Questions for reviewers
> - Is the notation of Dictionary concepts clear & acceptable for you? 
> (in PROV-N, PROV-O and/or PROV-XML)
> - Are the constraints acceptable, or are they too loose/too strict?
> -- In particular, can the constraint "IF derivedByRemovalFrom(d2, d1, 
> {"k1"}) THEN hadDictionaryMember(d1, e1, "k1") " be dropped, or do you 
> strongly support it?
> - Is the name PROV-DICTIONARY appropriate for the document?
> - Can this be released as a first public working draft?
> - If not, where are the blocking issues?
> - If yes, are there other issues to work on?
>
> In your review please include ISSUE-614
>
> Due to the delay in sending this notification, I suggest we allow a 
> little more time to review the document.
> We propose the due date for review to be on Wednesday the 23rd, so 
> that we can vote on the revised document on the 24th.
>
> Thanks in advance to all the reviewers.
>
> Regards,
> Tom & Sam 

-- 
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