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

Hello Luc,

Thanks for your review. I've updated the document and responded below.
You raise some important questions that we have no straightforward answer
to. These are:

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

We would like to discuss these in the group after publishing the first
draft.

**
> 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.
>
Done.


>
> - derivedByInsertionFrom(id; d2, d1, {(key_1, e_1), ..., (key_n, e_n)},
> attrs),
> key_i <> key_j
>
What do you mean by this? Do we need to insert this here?
http://dvcs.w3.org/hg/prov/raw-file/default/dictionary/prov-dictionary.html#term-dictionary-insertion
In the list, it is already mentioned that "each key_i is expected to be
unique for the key-entity-set".

- key_i is a value,
>   link to the notion of value in prov-dm
>
Done.


> - 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?
>
I've clarified this in the text, and added it to the example as well.
I forgot to specify entity(d3, [prov:type="prov:Dictionary"]) indeed,
thanks.
Is the new explanation and example clear enough?


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


> - 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?
>
> This was done to preserve the correspondence of hadDictionaryMember with
hadMember. We could either change the order in hadDictionaryMember or in
insertion.
Either way, it means going through the entire document to change it
everywhere.
Is this a major concern or a "nice to have"?


> - 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.
>
> Neither do I, to be honest. Perhaps we could discuss this in the call or
make it an issue for the next draft?


> - "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.
>
> I've weakened this and said that if one wants to explicitly state that a
dictionary has no members, that dictionary  can be described as an instance
of the subclass EmptyDictionary

>
> - 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?
>
> Well spotted, we missed that one :)
They do imply qualifiedDerivation, but I'm not sure how to express this in
the ontology. Note that derivedByInsertiongFrom and derivedByRemovalFrom
are both sub-properties of wasDerivedFrom, but I'm not sure if the same
applies to the qualified properties.


> - prov:value is already defined in prov-o, it has Entity as a domain. This
> would make KeyValuePair an entity.
>   Is it the expectation?
>
> I think this explains why it was originally defined as prov:pairValue. We
named these properties prov:pairKey and prov:pairValue again. prov:value is
indeed meant as the value for entities, and does not seem to correspond to
what we mean to do with prov:pairValue (which should have KeyValuePair as
domain and Entity as range)


>
> - IF derivedByRemovalFrom(d2, d1, {_"k1"}) and derivedByInsertionFrom(d2,
> d1, {_("k2", e2)})THEN INVALID
> what is this notation _"k1"?
>
> Fixed in response to James's review.

>
> 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.
>
>
>
See response to  James's review.

>
>