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

Many thanks Tom for tacking the time to address my comments.

I am happy with the way they are dealt, and agree that the one about
the new constraint, may need to be addressed later involving other
members of the WG.

Best,
khalid

On 5 February 2013 09:46, Tom De Nies <tom.denies@ugent.be> wrote:
> Hello Khalid,
>
> thanks for your review. I've responded inline below.
>
>
>
>> - I found the following sentence hard to follow "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."
>>
> Revised to: "In this document, a dictionary is viewed as a snapshot of a
> data structure with key-value pairs, following a sequence of state-changing
> insertion and removal operations."
>
>>
>> - Regarding prov:EmptyDictionary, I think there is anew constraint
>> that can be added to state that an entity that is both a doctionary
>> and an empty collection is an empty dictionary.
>>
> I would be cautious to adding new constraints, especially with PROV-DM
> constructs on the left-hand side.
> Note that we have the reverse, in constraint D12.2. Technically, your
> constraint is correct and doesn't break anything. I guess I just don't see a
> use case where one would want to write:
> entity(d, [prov:type="prov:Dictionary", prov:type="prov:EmptyCollection"])
> instead of
> entity(d, [prov:type="prov:EmptyDictionary")
> This is, in my view, a way of specifying EmptyDictionary we should not
> encourage.
> I suggest we make an issue out of it for the next draft, and talk about it
> on the call, together with Stian's suggested hadMember constraint.
>
>>
>> - In the definition of Dictionary Insertion in Section 2.2, it is
>> stated that "each key_i is expected to be unique for the
>> key-entity-set". I think that condition is necessary but not
>> sufficient. the key i should be unique considering the key-entity-set
>> specified in the insertion as well as the keys that are already used
>> within the dictionary D1.
>>
> I disagree. Right before example 4, we specify that Dictionary Insertion has
> an "update semantics", meaning that values for existing keys get replaced
> upon insertion. This is also formalized by Inference D4.
>
>>
>> - In section 2.2, you state that "Note that insertion is considered to
>> be complete. This means that we assume that no unknown keys were
>> inserted in or removed from a dictionary after an insertion." It is
>> not the insertion that is complete, but the key-entity-set specified
>> by the derivedByInsertion assertion. This same observation applies to
>> removal.
>
>
> Actually, they both are, because we don't want any keys to be removed upon
> insertion either. I've updated this in the text.
>
>>
>>
>> - I could not follow the following sentence: "In particular, no
>> assumptions are needed regarding the mutability of a data structure
>> that is subject to updates."
>>
> I agree. This was a legacy paragraph, and indeed, it was both unclear and
> unnecessary in my opinion. We already mentioned that we did not consider the
> underlying data structure in the introduction and definition of dictionary.
> I've removed the paragraph.
>
>>
>> - There a full stop that is missing after the first paragraph in Section
>> 4.
>>
> Well spotted, thanks!
>
>>
>> - Regarding Section 4, I found it a bit too long, and of different
>> style, compared with other sections, for example Section 5. This is a
>> minor comment that you may ignore, but if there is time, one would
>> have the details of all terms as an apendix, and focus on presenting
>> teh main constructs in Section 4.
>>
> This is a concern that we share, but we haven't had time to look into the
> layout much, and focused on the specification first. It is something we will
> consider for the next draft.
>
> - Tom
>

Received on Tuesday, 5 February 2013 10:17:27 UTC