Re: PROV Dictionary

Hi Graham, thanks for your comments.

I responded to them inline below.
Tom

2012/12/29 Graham Klyne <graham.klyne@zoo.ox.ac.uk>

> Reviewing http://dvcs.w3.org/hg/prov/**raw-file/default/dictionary/**
> prov-dictionary.html#**dictionary-constraints-**constraints<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"
>
Fixed.


> 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.)
>
Stated explicitly now. No duplicate keys allowed.


> 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?
>
It has the same function as in PROV-Constraints.

>
> 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).
>
> They are separate in PROV-Constraints as well, which is why we did this
here. Checks for consistency remain to be done.


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

I understand your concern, and on second thought, it does seem a bit
overkill. I suppose writing derivedByRemovalFrom(d2, d1, "nonexistentkey")
shouldn't break your validity, as it changes nothing to the dictionary
itself. (basically you derive a duplicate dictionary)
If there is no strong opinion to keep this constraint in, we can 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
> --
>