Re: PROV Dictionary

Reviewing 
http://dvcs.w3.org/hg/prov/raw-file/default/dictionary/prov-dictionary.html#dictionary-constraints-constraints 
retrieved on 2012-12-29.

...

Sect 1, para 2: "specify mor structure to a Collection"

Sect 2: is not explicit about whether keys can be repeated.  I assume not, but I 
think this should be stated explicitly.  (I think this may be implied indirectly 
by the first constraint.)  (I see it is stated by the first inference.)

For prov:Dictionary to be a subtype of prov:Collection, I think it must be 
possible to define (key, entity) to itself be an entity.

Sect 6.2:  What is the underscore denoting in the constraint descriptions?

On 18/12/2012 16:03, 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)

I haven't gone through the PROV-O details, but see above about key uniqueness.

Otherwise, it seems fine.

> 2. Are the constraints acceptable, or are they too loose/too strict?

I note you have described inferences and constraints separately.  Normally, 
inferences follow from constraints, so there's some redundancy here, and a 
possibility for inconsistency.  I think it would be better if all-constraints or 
all-inferences are used to define the formal properties (or if any inferences 
offered were provable from the constraints).

"Only keys that actually mapped to an entity in a dictionary can be removed from 
it" might prove to be difficult to guarantee for some applications.  If this is 
not needed, I'd be tempted to drop it.

> 3. Are you happy with the solution to the issue regarding completeness?
> (Tracing back to an EmptyDictionary)

Seems reasonable, but I have no strong opinion.

> 4. Is the note ready to be published as FPWD?

Yes, assuming this is for eventual publication as a NOTE.

(I have my doubts about how much this might be used, but have no problem with 
its description as a NOTE.  If it does find significant use, it can later be 
proposed for review as a REC track specification.)

#g
--

Received on Saturday, 29 December 2012 18:26:36 UTC