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

Thanks James, fixed all of those.


2013/1/29 James Cheney <jcheney@inf.ed.ac.uk>

> Mostly looks OK.  A few minor things:
>
> - In this sentence:
>
> Thus, :d3 does not contain the members ("k1", :e1) and ("k2", :e2( from
> :d2.
>
>
> the "(" after :e2 should be a ")"
>
> - in constraint 12, part 4 and 5, the rules only say what to do in the
> case of a single insertion or deletion.  They could be generalized to
> handle sets of inserted KV pairs or sets of deleted keys.
>
> - maybe could you change the macro that assigns inference/constraint
> numbers so that they are numbered "D1", "D2", etc.?  Otherwise "inference
> 5" could mean "inference 5 of prov-constraints" or "inference 5 of
> prov-dictionary".  Not a big deal though.
>
> --James
>
>
>
> On Jan 29, 2013, at 12:21 PM, Tom De Nies <tom.denies@ugent.be> wrote:
>
> Thanks to all reviewers for your helpful comments!
>
> The revised document is available here:
> http://dvcs.w3.org/hg/prov/raw-file/default/dictionary/prov-dictionary.html
>
> Do note that the grammar, xsd and owl files are not finished yet, but will
> be somewhere this week.
> This is why we linked to the
> http://dvcs.w3.org/hg/prov/raw-file/default/dictionary/prov-dictionary.*versions in the draft.
>
> Could we get some sort of acknowledgement from the reviewers that your
> concerns were addressed? This way we could close this issue.
>
> Best regards,
> Tom and Sam
>
> 2013/1/29 Tom De Nies <tom.denies@ugent.be>
>
>> Hi Stian,
>>
>> thanks again for your extensive review. I responded to each issue below.
>> You'll see that many of the issues arose in other reviews as well, so
>> they were no trouble fixing.
>>
>> As I see it, only one real point of discussion remains after going
>> through your review: (item 3 in your review) whether or not we include the
>> constraint
>> IF hadMember(d, e) and 'Dictionary' \in typeOf(d) THEN
>> hadDictionaryMember(d, e, "k") with k and unknown key.
>> I suggest we leave this out for this draft, and make it a formal issue,
>> which we can discuss as a group before the next draft.
>>
>>
>>> Please find below detailed review:
>>>
>>> > 2.1 Dictionary  membership
>>> >     key: a key key_1 that is associated with the specified entity;
>>>
>>> 1) This should specify that the key is a *Value* as according to
>>> PROV-DM http://www.w3.org/TR/prov-dm/#term-value - as it is specified
>>> it could be interpreted as also an identifier - although the PROV-N
>>> example uses a "string value".   (I know it is confusing because DM
>>> for some reason chose to call this Value rather than the more
>>> appropriate term Literal - but here in a dictionary the actual 'value'
>>> is the Entity (identifier), and the key is a (literal) Value!
>>> Therefore this should be clarified with DM hyperlink.)
>>>
>> Indeed, Luc and Paolo's review also mentioned this. It's fixed.
>>
>>
>>>
>>> > Note that dictionary membership implies collection membership, but not
>>> vice versa.
>>>
>>> 2) This should link forward to inference 1
>>> (dictionary-membership-collection-membership)
>>>
>> Done.
>>
>>
>>>
>>> 3) Also I don't quite understand this.  So a prov:Dictionary kind of
>>> collection can have members that don't have keys?
>>>
>>> entity(d, [prov:type='prov:Dictionary' ])
>>> // implies:
>>> entity(d, [prov:type='prov:Collection ])
>>>
>>> hadDictionaryMember(d, e1, "k1")
>>> // implies:
>>> hadMember(d, e1)
>>>
>>> // But what if we also see?
>>> hadMember(d, e3)
>>> // are you saying this would NOT imply the below?
>>> hadDictionaryMember(d, e3, ?unknownKey)
>>>
>>> If so then I am a bit confused - a prov:Dictionary to be useful should
>>> be a constrained prov:Collection in which every member is associated
>>> with a key. This should be added to the Conceptual Definition of
>>> Dictionary above.
>>>
>>> If there is no such implication (of course the key is unknown until
>>> stated otherwise), I am not sure in which cases such a data type could
>>> be useful. It would be like describing an array type of collection,
>>> but where some items are allowed to not have a position.  (which is
>>> quite different from saying they have an unknown position!)
>>>
>>>
>> See explanation above, this remains an issue to be discussed.
>>
>>
>>>
>>> > > // d1 is a dictionary, with unknown content
>>>
>>> 4) Change to "with (so far) unknown content" ?   Both example 1 and 2
>>> and others - specially those that later actually do state the members.
>>>
>>>
>>> Done.
>>
>>
>>>
>>> > 2.2 Dictionary insertion
>>> >  d0 is the set { }
>>> > ...
>>>
>>> 5) I thought d0 was a Dictionary, not a set.   s/set/dictionary/g here
>>> and in other examples.
>>>
>>> It is not simply a set of pairs, because we don't allow multiple
>>> entries for same key.
>>>
>>> Fixed.
>>
>>
>>>
>>> > attributes: an optional set (attrs) of attribute-value pairs
>>> representing additional information about this relation.
>>>
>>> 6) Could one of the lines in example 3 perhaps include a
>>> dcterms:description or something? Just because it can get confusing
>>> with the new {("key", value)} syntax as opposed to the attribute
>>> syntax.
>>>
>>>
>>> derivedByInsertionFrom(d2, d1, {("k3", e3)}, [ dcterms:description =
>>> "An optional attribute" ] )
>>>
>>> Done.
>>
>>
>>>
>>> > 2.2 Dictionary Insertion
>>> > 2.3 Dictionary Removal
>>> > In particular, no assumptions are needed regarding the mutability of a
>>> data structure that is subject to updates
>>>
>>> 7) So from the examples given, it seems that both insertion and
>>> removal are "complete" statements - for instance after
>>>
>>>   derivedByRemovalFrom(d3, d2, {"k1", "k3"})
>>>
>>> we conclude that "k2" remains as a key in d3.
>>>
>>> I very much prefer this semantics, rather than a very earlier draft,
>>> where members could come and go out of the blue and you never really
>>> knew much. I think also this is OK as this is a specific
>>> prov:Dictionary thing rather than a general thing about
>>> prov:Collection's.
>>>
>>>
>>> Therefore 2.2 and 2.3 should clarify this and change
>>>
>>> > key-entity-set: the inserted key-entity pairs (
>>> to
>>> > key-entity-set: all inserted key-entity pairs (
>>>
>>> > key-set: a set of deleted keys (..)
>>> to
>>> > key-set: a set of all deleted keys (..)
>>>
>>> Inference 7 (insertion-removal-membership) makes this explicit (yay!)
>>> - so a forward reference would be good.
>>>
>>>
>>> Done.
>>
>>
>>>
>>>
>>> 3. PROV-N Notation of Dictionary Concepts
>>>
>>> 8a) This section should start with a paragraph explaining that
>>> PROV-DICTIONARY specifies an extension according to PROV-N Extension
>>> chapter - http://www.w3.org/TR/prov-n/#extensibility - but using the
>>> same namespace
>>>
>>> I have added the following text:
>>
>>> The notation used for dictionaries in this document extends the standard
>>> PROV-N according to the principles described in the PROV-N
>>> extensibility chapter <http://www.w3.org/TR/prov-n/#extensibility>.
>>> However, because dictionaries are defined in the same namespace as the rest
>>> of PROV-N, the terms in this document do not have a non-empty prefix. For
>>> the remainder of this document, we will assume that the default namespace
>>> http://www.w3.org/ns/prov# is used, and thus, no prefix is specified
>>> for the terms associated with dictionaries.
>>>
>> Is this acceptable to you?
>>
>>
>>> 8b) The extension grammar should be downloadable and linked to from
>>> introduction of PROV-N notation.
>>>
>>> We noticed that although there is a grammar folder on the mercurial
>> repository, PROV-N currently does not link to a downloadable grammar
>> either. (or we couldn't find the link).
>> We suggest that we wait until PROV-N does this in the final spec, and
>> then conform to that when we link to it in the next draft.
>>
>>
>>> 9) However, to be a valid extension, the terms must be given as a
>>>         QUALIFIED_NAME.  With the proposed syntax in this document - the
>>> QNAMEs are in the default name space, which can be customized in
>>> PROV-N - http://www.w3.org/TR/prov-n/#expression-NamespaceDeclaration
>>> - and therefore easily overlap with other extensions.
>>>
>>> It is not explicit in PROV-N (perhaps it should be!) - but a missing
>>> default namespace declaration would make the QNAMEs invalid.
>>>
>>> > A qualified name's prefix is optional. If a prefix occurs in a
>>> qualified name, the prefix must refer to a namespace declared in a
>>> namespace declaration. In the absence of prefix, the qualified name belongs
>>> to the default namespace.
>>>
>>> (Side note: PROV-N should require that PN_PREFIX is a declared prefix
>>> in the current scope - and that if it is empty, that the default
>>> namespace has been declared)
>>>
>>>
>>> The prefix prov: is reserved in PROV-N.
>>>
>>> I therefore suggest to rename all the Dictionary concepts to qualified
>>> names using prov:* - that is:
>>>
>>> prov:hadDictionaryMember
>>> prov:derivedByInsertionFrom
>>> prov:derivedByRemovalFrom
>>>
>>> Thus we would avoid the embarrassing situation of PROV-Dictionary-N
>>> documents not being valid PROV-N documents - while documents using
>>> other extensions would be.
>>>
>>>
>> See the text added to the beginning of the PROV-N section, and our
>> response to 8a. Does this remain a blocking issue for you now that this
>> text is included? I'd like to remark that PROV-LINKS does not declare this
>> namespace either, and is published as a working draft.
>> http://www.w3.org/TR/prov-links/
>>
>>
>>
>>>
>>> 10) This section paragraph should mention that prov:Dictionary and
>>> prov:EmptyDictionary is declared using regular entity statements (with
>>> example). This could be inserted before 3.1.
>>>
>>>
>>> Done.
>>
>>>
>>> 3.1 Membership  (PROV-N)
>>>
>>> > membershipExpression ::= 'hadDictionaryMember' '(' dIdentifier ','
>>> entity ',' key ')'
>>> > key   key (Non-Terminal)
>>>
>>> 11) "key" is not a defined Non-Terminal - neither here nor in PROV-N
>>> document or grammar.
>>>
>>> "dIdentifier" is similarly a new non-Terminal that must be defined
>>> here. (presumably it is an entity which is a prov:Dictionary type).
>>>
>>>
>>> Combined with issue #1 this is very confusing, and so I have made this
>>> and equivalent below a blocker.
>>>
>>>
>>> Use the style of the PROV-N document:
>>>
>>> http://www.w3.org/TR/prov-n/#expression-Entity
>>>
>>> .. here it also introduces optionalAttributeValuePairs, etc.
>>>
>>>
>>>
>> Fixed (after previous reviews). Could you check the expressions again? I
>> believe everything should be linked and defined correctly now.
>>
>>
>>>
>>> 12) This is not valid grammar according to the EBNF section of PROV-N
>>> as it uses 'single quotes' rather than "double"
>>>
>>> http://www.w3.org/TR/prov-n/#grammar-notation
>>>
>>> Change this and following declaration to style with double quotes:
>>>
>>> > membershipExpression ::= "hadDictionaryMember" "(" dIdentifier ","
>>> entity "," key ")"
>>>
>>> Now uses double quotes.
>>
>>
>>>
>>> 13) For some reason I was not able to copy-paste the ::== line  above
>>> correctly from neither Firefox nor Chrome - the 'single quotes'
>>> disappeared! Why? CSS? Ensure quotes are regular characters
>>
>>
>> This appears to be because the quotes are added through CSS. I noticed
>> that in PROV-N, this is done differently now, and the expressions are
>> pulled from the grammar by a javascript script that runs on the page. We
>> will fix this when we create the grammar document.
>>
>>
>>>
>>> > Example 6
>>> >
>>> >
>>> > In this example, d is a dictionary known to have e0, e1, and e2 as
>>> members, and may have other members.
>>> >  entity(e0)
>>> > ..
>>> > hadDictionaryMember(d, e0, "k0")
>>>
>>>
>>> 14) I think this and following examples can be shortened - you should
>>> not explain the PROV Dictionary semantics again in this section and
>>> don't need to repeat the full examples - only the syntax of the
>>> particular statement. So change style to only:
>>>
>>> > Example 6
>>> > // e0 is member in d under key "k0"
>>> > hadDictionaryMember(d, e0, "k0")
>>>
>>>
>>> Shortened.
>>
>>
>>> > 3.2 Insertion
>>> >  derivationByInsertionFromExpression ::= derivedByInsertionFrom (
>>> identifier , dIdentifier , dIdentifier , { keyValuePairs }
>>> optional-attribute-values )
>>>
>>> 15) Non-Terminals not matching table below: identifier,
>>> keyValuePairs, optional-attribute-values
>>> Change to match table.
>>>
>>>
>> Fixed (after previous reviews). Could you check the expressions again? I
>> believe everything should be linked and defined correctly now.
>>
>>
>>
>>> 16) Not defined: dIdentifier, keyEntitySet/keyValuePairs
>>>
>>> Remember that for keyValuePairs the first pair is not optional.
>>>
>>> Fixed (after previous reviews). Could you check the expressions again? I
>> believe everything should be linked and defined correctly now.
>>
>>
>>>
>>> 17) as the identifiers is optional, the separator should be ";" not
>>> ",". This also applies to  derivedByRemovalFrom
>>>
>>> Fixed.
>>
>>
>>>
>>> 18) Hyperlinks for prov-n terminals like 'identifier' are wrong - they
>>> go to non-existing local anchors rather than to PROV-N - like
>>> http://www.w3.org/TR/prov-n/#prod-identifier
>>>
>>>
>>> Fixed (after previous reviews). Could you check the expressions again? I
>> believe everything should be linked and defined correctly now.
>>
>>
>>> > 3.3 Removal
>>> > derivationByRemovalFromExpression ::= derivedByRemovalFrom (
>>> identifier , dIdentifier , dIdentifier , { keySet }
>>> optional-attribute-values )
>>>
>>> 19) optional-attribute-values -> optionalAttributeValuePairs
>>>
>>> Fixed.
>>
>>
>>>
>>> > key-set       keySet
>>>
>>> 20) Undefined terminal keySet
>>>
>>> Remember that the first key is not optional.
>>>
>>> Fixed.
>>
>>>
>>> > The following table summarizes how each constituent of a PROV-DM
>>> Membership maps to a non-terminal.
>>> > The following table summarizes how each constituent of a PROV-DM
>>> Insertion maps to a non-terminal.
>>> > The following table summarizes how each constituent of a PROV-DM
>>> Removal maps to a non-terminal.
>>>
>>> 21) PROV-DM -> PROV-DICTIONARY (or simply Dictionary)
>>>
>>>
>>>
>>>
>>> > 4. Ontological definition of dictionary
>>>
>>> Note that I have only checked the Turtle syntax here 'by hand' - they
>>> should be formally checked programmatically.
>>>
>>>
>> This remains a todo when we publish the owl file.
>>
>>>
>>> >     prov:hadDictionaryMember [
>>> >       a prov:KeyValuePair;
>>> >       prov:key   "k1"^^xsd:string
>>> >          prov:value :e1
>>>
>>> 22) Fix indentation of prov:value  (do NEVER use TAB character in such
>>> examples as it has inconsistent rendering)
>>>
>>> Fixed.
>>
>>
>>>
>>> 23) Missing ; after xsd:string (invalid Turtle syntax)
>>>
>>> Fixed.
>>
>>>
>>> > A dictionary may be empty, in which case it should be described as an
>>> instance of the subclass prov:EmptyDictionary.
>>>
>>> 24) This makes sense regardless of syntax - can a similar statement be
>>> made in section 2.?
>>>
>>> We revised this sentence after a previous review. I've added something
>> similar to the conceptual definition:
>>
>>> Note that the complete content of a dictionary is unknown unless it can
>>> be traced back to an empty dictionary through a series of insertions and
>>> removals. If an asserter wants to explicitly state that a dictionary is
>>> empty, it is recommended that the prov:type prov:EmptyCollection is
>>> used.
>>
>>
>> Is this ok for you?
>>
>>
>>>
>>> >  PROV-O provides two kinds of involvements
>>>
>>> 25) PROV-O --> PROV-DICTIONARY
>>>
>>> Done.
>>
>>
>>> >  prov:qualifiedInsertion is used to  (..)
>>> > prov:qualifiedRemoval is used to specify  (..)
>>>
>>
>> 26) Text should relate/hyperlink this to the insertion/removal sections
>>> earlier.
>>>
>>>
>>> > prov:Dictionary
>>>
>>> >  back to collections classes
>>>
>>> 27) hyperlink from headers - does not work. Remove or change to link
>>> to "These terms are used" section.
>>>
>>> Done, they point to the overview now.
>>
>>>
>>>
>>> >    :wasCreatedBy    :bob;
>>>
>>> 28) Remove this as it is potentially confusing with
>>> prov:wasAttributedTo  (or just change to prov:wAT)
>>>
>>> Done.
>>
>>>
>>> > described with properties
>>> >    prov:derivedByInsertionFromop prov:qualifiedRemovalop
>>> prov:qualifiedInsertionop prov:derivedByRemovalFromop
>>>
>>> 29) Somehow the most important property, prov:hadDictionaryMember
>>> seems to be missing here!
>>>
>>>
>>> Oops! fixed.
>>
>>
>>> >  prov:EmptyDictionary
>>> >
>>> > :d1 a prov:Dictionary;
>>> >   prov:derivedByInsertionFrom :d;
>>>
>>> 30) I find it confusing that this example uses most lines to talk
>>> about a non-empty dictionary.  Simplify to just show the boring:
>>>
>>> >  :d  a prov:EmptyDictionary .
>>>
>>> Done
>>
>>>
>>> > An empty dictionary.
>>>
>>> 31) Could you add the obvious "i.e. has no members"
>>>
>>>
>>> Done.
>>
>>
>>> >  prov:insertedKeyValuePair [
>>> >         a prov:KeyValuePair;
>>> >         prov:key   "k1"^^xsd:string;
>>> >         prov:value :e1;
>>> >     ]
>>>
>>>
>>> 32) I know we had discussions about this before (when this was in
>>> PROV-O) as one can consider either the value or the keyvaluepair to be
>>> what is inserted. But this is getting quite verbose..
>>> inserterkeyvaluepair keyvaluepair key and value! Puh!
>>>
>>> How about simplifying to:
>>>
>>>  prov:inserted [
>>>          a prov:KeyValuePair;
>>>          prov:key   "k1"^^xsd:string;
>>>          prov:value :e1;
>>>       ]
>>>
>>> .. or possibly prov:insertedPair  ?
>>>
>>> This is similar to how the insertion is a prov:Insertion and not a
>>> prov:DictionaryInsertion.
>>>
>>> I would keep prov:removedKey as it's important to know it's the *key*
>>> that was removed.
>>>
>>>
>> Sam and I discussed this, and came to the following conclusion. While it
>> is true that this syntax is quite verbose, it is also the only one that is
>> 100% clear and cannot induce confusion or discussion. This, and the fact
>> that the other reviewers did not see a problem with this property has made
>> us decide that this is the safest choice, and we will keep it. If you
>> consider it a serious problem, we can discuss it as an issue for the next
>> draft.
>>
>>
>>>
>>> > prov:Removal
>>> > removing one or more key-value pairs
>>>
>>> 33) Add ", specified by prov:removedKey"
>>>
>>> (as you don't specify the removed key/value pairs)
>>>
>>> done.
>>
>>
>>>
>>> > prov:dictionary
>>> > has domain
>>> >       prov:Insertion
>>> >       prov:Removal
>>>
>>> 34) This specifies that the domain is the intersection of Insertion
>>> and Removal  - thus any Insertion with a prov:dictionary becomes also
>>> a Removal etc. This is surely wrong.
>>>
>>>
>>> Formally you should specify this as the domain of the union of
>>> Insertion and Removal - alternatively as a common "abstract"
>>> superclass prov:DictionaryInfluence.
>>>
>>> See PROV-O http://www.w3.org/TR/prov-o/#owl-profile
>>>
>>> As the union would take the extension out of OWL-RL, and there already
>>> is precedence for other kind of influences, I would suggest making a
>>> new prov:DictionaryInfluence which can be superclass of Insertion and
>>> Removal, and in domain of prov:dictionary.
>>>
>>>
>>> Done.
>>
>>>
>>>
>>> 35)  Where can I find a download link for the OWL of this PROV
>>> Dictionary extension? I expected to find it in te beginning of section
>>> 4. I would also expect section 4 to have an explanation of the
>>> namespaces and how importing <http://www.w3.org/ns/prov#> one would
>>> get both PROV-O and extensions like PROV-Dictionary, while
>>> <http://www.w3.org/ns/prov-o> would give only PROV-O.  I would then
>>> also expect a separate versionIRI to import if I only wanted
>>> PROV-Dictionary - like <http://www.w3.org/ns/prov-dictionary#>
>>>
>>>
>>> As discussed on the call, we included a link to the owl file in the
>> document, but the file itself might still be updated. (we linked to the raw
>> "editor's draft" version, to allow ourselves some time to update and verify
>> the owl syntax.)
>> I''ve also included the text you asked for:
>>
>>> The classes and properties defined in this document will be included in
>>> the default namespace of PROV. Users of the ontology have the option of
>>> importing<http://www.w3.org/ns/prov#>, which includes all extensions,
>>> including PROV-Dictionary, or if they wish to have only [PROV-O] terms,
>>> they can import <http://www.w3.org/ns/prov-o#>. Similarly, <
>>> http://www.w3.org/ns/prov-dictionary#> holds only the PROV-Dictionary
>>> terms. The owl-file of PROV-Dictionary is available for download here<http://dvcs.w3.org/hg/prov/file/tip/dictionary/prov-dictionary.owl>.
>>> (Note that this file is unfinished at the time of this working draft, and
>>> may be subject to change.)
>>
>>
>> Is this text acceptable to you?
>>
>>
>>>
>>> > prov:qualifiedInsertion
>>> > If this Dictionary prov:derivedByInsertionFrom another Dictionary :e,
>>> then it can qualify how it did perform the Insertion using
>>> prov:qualifiedInsertion [ a prov:Insertion; prov:dictionary :e;
>>> prov:inserted [a prov:KeyValuePair; prov:key "k1"^^xsd:string; prov:value
>>> :foo] ].
>>>
>>> 36) I know I probably wrote this text - but without any indentation it
>>> is very difficult to read. Could this be simplified to some kind of
>>> mirror of prov:derivedByInsertionFrom? Same for prov:qualifiedRemoval.
>>>
>>>
>>> Done.
>>
>>
>>> 37) example for qualifiedInsertion should not detail the members of
>>> our-old-baseball-team-field-positions as that is confusing and makes
>>> example large.
>>>
>>> Done.
>>
>>>
>>> > 5. XML Schema Dictionary
>>> > In this section, we provide the XML Schema to use dictionaries with
>>> the [PROV-XML] serialization.
>>>
>>> Ironically, you don't (only fragments) - where can I find and download
>>> the XML Schema?
>>>
>>
>> We've included the link. XSD schema will actually be there today. Again,
>> we point to the editors space, to allow corrections after publication of
>> the document.
>>
>>>
>>> Note that I have not checked the syntax of XSD statements in this
>>> section - if I had the schema file I could have validated it.
>>>
>>>
>>> We will validate the schema
>>
>>
>>> 38) Modify to "This section details how to describe dictionaries with
>>> the [PROV-XML] serialization".
>>>
>>>
>>> Done.
>>
>>> 39) Provide download link for XML schema - also include usage
>>> instructions as per imports etc. (equivalent as for OWL imports above)
>>>
>>>
>>> Done.
>>
>>
>>> 40) Rename section to "PROV-XML representation of Dictionary" -
>>> similarly section 4 from "Ontological Definition of Dictionary" to
>>> "PROV-O representation of Dictionary"
>>>
>>>
>>> done.
>>
>>
>>> > 5.2 Key-Value Pair
>>> > <xs:element name="key" type="xs:String" />
>>>
>>> 41) The specification earlier specifies key as any value/literal - so
>>> xs:string (lowercase S!) is too specific - it would not allow
>>> integers, for instance. Change to xs:anySimpleType here and in 5.5
>>> Removal
>>> > <xs:element name="key" type="xs:String" maxOccurs="unbounded" />
>>>
>>> Done.
>>
>>>
>>>
>>> >  members of a dictionary are specified by listing all the key-value
>>> pairs inside a prov:DictionaryMembership element
>>>
>>> 42) Remove "all the" -- according to semantics of  hadDictionaryMember
>>>
>>>
>>> Done.
>>
>>
>>> > 6. Constraints Associated with Dictionary
>>>
>>> This section is very solid, good work!
>>>
>>>
>>> > These inferences and constraints need to be applied to obtain valid
>>> provenance when using dictionaries.
>>>
>>> 43) I don't think they *need to* be applied? Rephrase to "MAY be
>>> applied in order to ensure valid provenance".
>>>
>>> I think a similar kind of disclaimer as in
>>> http://www.w3.org/TR/prov-constraints/#purpose (or just linking to
>>> this) could be useful, so that it's clear that these constraints are
>>> not a MUST to use dictionaries.
>>>
>>> Changed, and added reference to purpose section of constraints.
>>
>>>
>>> >  Inference 1 (dictionary-membership-collection-membership)
>>> >  IF hadDictionaryMember(d, e1, "k1") THEN hadMember(d, e1)
>>>
>>>
>>> 44) I would also add the inverse inference
>>> dictionary-all-members-have-keys:
>>>
>>> > Inference X (dictionary-all-members-have-keys)
>>> >
>>> > Here k is a (potentially unknown) key
>>> >
>>> > IF hadMember(d, e1) AND 'prov:Dictionary' ∈ typeOf(d)
>>> > THEN hadDictionaryMember(d, e1, k)
>>>
>>>
>>>
>>> If we don't specify this, opens for a prov:Dictionary to also contain
>>> entities which don't have a key. This could be confusing. For instance
>>> this would be valid:
>>>
>>> entity(d0, [prov:type='prov:EmptyDictionary'])
>>> entity(d1, [prov:type='prov:Dictionary'])
>>> entity(d2, [prov:type='prov:Dictionary'])
>>>
>>> derivedByInsertionFrom(d1, d0, {("k1", e1)})
>>> // implied insertion-membership
>>> //hadDictionaryMember(d1, e1, "k1")
>>> // implied by dictionary-membership-collection-membership:
>>> //hadMember(d1, e1)
>>>
>>> derivedByRemovalFrom(d2, d1, {"k1"})
>>> // Invalid by impossible-removal-membership:
>>> //hadDictionaryMember(d2, e1, "k1")
>>>
>>> // however this is still valid ..
>>> hadMember(d2, e1)
>>>
>>> // Unless we add:
>>> entity(d2, [prov:type='prov:EmptyDictionary'])
>>> // which implies
>>> //entity(d2, [prov:type='prov:EmptyCollection'])
>>> //which is invalid by constraint membership-empty-collection in
>>> PROV-CONSTRAINTS
>>>
>>> // However, we might now still add this confusing statement:
>>> hadMember(d1, e2)
>>>
>>> // By the PROV-DICTIONARY constraints (including the completeness
>>> constraint impossible-insertion-insertion and
>>> membership-insertion-membership) we would not here expect any other
>>> keys than "k1" in d1 - so we SHOULD be able to conclude that e2==e1 -
>>> however we can't do that unless we introduce my inference
>>> dictionary-all-members-have-keys:
>>> // dictionary-all-members-have-keys implies
>>> //hadDictionaryMember(d1, e2, k)
>>> // and by key-single-entity and membership-insertion-membership and
>>> membership-empty-collection:
>>> //e2 == e1
>>>
>>>
>> You make a valid point, and I think it needs to be discussed before we
>> add it. See response at the beginning of this email.
>> Since this is not a blocker, we will discuss it for the next WD.
>>
>>
>>> >  IF hadDictionaryMember(d1, e, "k") and derivedByInsertionFrom(d2, d1,
>>> {("k1", e1),...,("kn", en)}) and k ∉ {k1,...,kn} THEN
>>> hadDictionaryMember(d2, e, "k")
>>>
>>> 45) Don't remove the quotes: "k" ∉ {"k1",...,"kn"}
>>>
>>> Done.
>>
>>>
>>> >  IF derivedByRemovalFrom(d2, d1, {"k1",...,"kn"}) and
>>> derivedByInsertionFrom(d2, d1, {("k1", e1),...,("km",em)})THEN INVALID
>>>
>>> 46) This implies that "k1", etc. needs to be on both sides (Implying
>>> an intersection/containment of keys). This constraint is true no
>>> matter the key/value pairs, so change to same style as below:
>>>
>>> > Here, KV1 and KV2 are sets of key-entity pairs.
>>> >  IF derivedByRemovalFrom(d2, d1, KV1) and derivedByInsertionFrom(d2,
>>> d1, KV2) THEN INVALID
>>>
>>> Done.
>>
>>>
>>>
>>> > 6.3 Typing
>>>
>>> > IF entity(d, [prov:type='prov:Dictionary']) THEN 'prov:Dictionary' ∈
>>> typeOf(d) and 'prov:Collection' ∈ typeOf(d)
>>> > IF entity(d, [prov:type='prov:EmptyDictionary']) THEN
>>> 'prov:EmptyDictionary' ∈ typeOf(d) and 'prov:Dictionary' ∈ typeOf(d)
>>>
>>> 47) The second rule would not cause firing of the first rule, so
>>> expand the second rule. Also include prov:EmptyCollection and entity.
>>>
>>> > IF entity(d, [prov:type='prov:EmptyDictionary']) THEN
>>> 'prov:EmptyDictionary' ∈ typeOf(d) and 'prov:Dictionary' ∈ typeOf(d) and
>>> 'prov:Collection' ∈ typeOf(d) and 'prov:EmptyCollection' ∈ typeOf(d)
>>>
>>> Done.
>>
>>>
>>> 48) Both lines must also include:
>>>  'entity' ∈ typeOf(c)
>>>
>>> ..as PROV-Constraint "typing" would not fire from a typeof
>>> prov:Collection.
>>>
>>>
>>> Done.
>>
>>
>>>
>>> > IF hadDictionaryMember(d, e, "k") THEN 'prov:Dictionary' ∈ typeOf(d)
>>> and 'entity' ∈ typeOf(e)
>>> > IF derivedByInsertionFrom(d2, d1, {("k1", e1)}) THEN 'prov:Dictionary'
>>> ∈ typeOf(d1) and 'prov:Dictionary' ∈ typeOf(d2) and 'entity' ∈ typeOf(e1)
>>> > IF derivedByRemovalFrom(d2, d1, {"k1"}) THEN 'prov:Dictionary' ∈
>>> typeOf(d1) and 'prov:Dictionary' ∈ typeOf(d2)
>>>
>>> 49) Similarly all of these should also include
>>> > AND prov:Collection' ∈ typeOf(c) AND 'entity' ∈ typeOf(c)
>>>
>>> Done.
>>
>>>
>>> ==== END OF REVIEW ===
>>>
>>> Now relax..! :)
>>>
>>>
>> I'll try. Is this a blocking issue? ;)
>>
>
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>