ResponsesToPublicCommentsCR

From Provenance WG Wiki
Revision as of 10:42, 21 February 2013 by Pgroth (Talk | contribs)

Jump to: navigation, search

Template for Issue Response

ISSUE-611 (comments on prov-o)

Please see ResponsesToPublicCommentsCR#ISSUE-612_.28Encoding_of_Constraints_in_OWL.29

ISSUE-611 (comments on prov-constraints)

  • Original email: http://lists.w3.org/Archives/Public/public-prov-comments/2013Jan/0000.html
  • Tracker: https://www.w3.org/2011/prov/track/issues/611
  • Group Response
    • The flow control arrows in Figure 1 seem to be backwards. This is because the arrows correspond to "derivation/generation/use" steps, which go backwards in time in PROV. We can reverse them if this proves confusing.
    • Definition 2.1 seems to be missing the id on the right-hand side. Actually, since this definition applies to entity, agent or activity statements, the "id" argument is just the first ordinary parameter, namely a1. Ids cannot be optional for these statements so they are treated uniformly with the other parameters. It would be equivalent to write out the three equivalences:
entity(id) IF AND ONLY IF entity(id,[])
activity(id,t1,t2)  IF AND ONLY IF activity(id,t1,t2,[])  
agent(id) IF AND ONLY IF agent(id,[]).

spelling out how to expand attribute lists for entity, activity and agent. We may change the document accordingly to avoid confusion.

    • Since uniqueness constraints are ‘applied’ and can derive new atoms, it is misleading to call them constraints. The same applies to typing constraints.

This is a reasonable view, but I'd prefer to stick with the existing terminology. The rationale for it is as follows:

      • uniqueness "constraints" do not infer new PROV statements, rather they result in either merging two statements that contain compatible information, or in failure.
      • typing "constraints" do not infer new PROV statements, rather they infer auxiliary non-PROV atomic formulas about typing of identifiers, which can in turn lead to detecting invalidity.
      • ordering "constraints" do not infer new PROV statements, rather they infer auxiliary ordering formulas that could in turn lead to invalidity.
      • only "inferences" result in new PROV statements being added to the instance, and only "constraints" can result in failure.

Of course, logically, distinguishing between PROV statements and auxiliary atoms is arbitrary, and there is no real reason to distinguish between inferences and constraints - we could simply call everything an inference. If there is a general consensus that the existing terminology is confusing to implementors we will revisit this.

    • The definition of enforcement of uniqueness constraints states one should apply the resulting substitution to the whole PROV instance. However, the scope of the variables is not sets of rules. This comment seems to mean that the explanation of what it means to apply a uniqueness constraint is unclear, because it has nonlocal effects on the whole instance that go beyond the statements mentioned in the constraint. We will try to explain this more clearly in future revisions.
    • Inferences 9, 10, 15.4, 15.7 have some singleton variables that should be written with underscores Yes; we will do this (it does not change the meaning of the inferences, though.)
    • Constraint 56 should be: IF hadMember(c,e) and 'prov:EmptyCollection' ∈ typeOf(c) THEN INVALID. Yes; we will fix this.
  • References:
  • Changes to the document:
    • Adding underscores to some variables in inferences 9, 10, 15
    • Changing hasMember to hadMember
    • Clarifying uniqueness constraint application
  • Original author's acknowledgement:

http://lists.w3.org/Archives/Public/public-prov-comments/2013Jan/0016.html

ISSUE-611 (PROV-CONSTRAINT Test Cases)

  • Original email: http://lists.w3.org/Archives/Public/public-prov-comments/2013Jan/0000.html
  • Tracker: ISSUE-611
  • Group Response
    • Normative test cases: There are a number of reasons why the PROV-CONSTRAINT test cases are non-normative.
      • Coverage: Despite our best efforts, we are not certain about the completeness of the current test suite, i.e. the full coverage of all cases that exercise all possible combinations of the constraints. If the test suite were normative, once it is released and approved, we would not be able to extend it later; or we would need to have two sets of tests, normative and non-normative, which would defeat the original purpose.
      • Compliance: If there were a normative test suite in addition to the normative document, the easier option to demonstrate compliance is to pass all the test cases. However, relating to the point above, an incomplete test suite would lead to a false sense of compliance.
      • Technical issue: We currently do not have formal mappings between different serializations. As it has been pointed out by the reviewer, some test cases work in PROV-N but not in RDF (and, potentially, vice versa). Therefore, passing the test suite in a particular serialization is not sufficient for checking compliance.
    • Feedback on individual test cases: Following the reviewer's identification of bugs in the test cases, we have corrected the following test cases:
      • ordering-association2-PASS-c47.ttl: entity(ex:ag) replaced by activity(ex:ag)
      • prov-o-class-Invalidation-PASS.ttl: the extra ; removed
      • prov-o-class-Collection-PASS.ttl and prov-o-property-hadMember-PASS.ttl: invalid xsd:timeDate literals corrected
      • prov-o-property-qualifiedCommunication-PASS: wasAttributedTo replaced by wasAssociatedWith
      • prov-o-property-qualifiedRevision-PASS: wasAssociatedWith replaced by wasAttributedTo
      • The PROV-N and PROV-XML representations of some test cases cannot be faithfully converted into the RDF representation since it collapse statements with the same identifier into one. We removed those from the list of RDF test files and provided explanatory notes in the test case table: unification-association-f4-FAIL-c23.ttl, unification-association-f5-FAIL-c23.ttl, unification-derivation-f1-FAIL-c23.ttl, unification-derivation-f2-FAIL-c23.ttl, unification-derivation-f3-FAIL-c23.ttl, unification-derivation-f4-FAIL-c23.ttl
  • References:
  • Changes to the document: Please see the list of changes listed under 'Feedback on individual test cases' above.
  • Original author's acknowledgement:

ISSUE-612 (Transitivity of Derivation)

ISSUE-612 (Encoding of Constraints in OWL)

ISSUE-611 (Test cases for other specifications)

ISSUE-616

  • Original email: http://lists.w3.org/Archives/Public/public-prov-comments/2013Jan/0006.html
  • Tracker: https://www.w3.org/2011/prov/track/issues/616
  • Group Response
    • The comment points out a confusing use of the wasQuotedFrom relation in the primer, suggesting that it implied the relation was the wrong way round (swapped subject and object), and that hadQuotationFrom may be a better name.
    • We think this is just the primer text being misleading rather than the relation name being incorrect. The wasQuotedFrom relation should link a quote to the document it was quoted from. The primer currently can be read as linking something *containing* a quote to the place it was quoted from, which is allowable under "scruffy" use of PROV, but not ideal for illustrating the concept as it doesn't match the relation name, as the reviewer indicates.
    • More generally, the working group extensively discussed the matter of the relation name, including considering hadQuotationFrom. While no relation name may be perfect, it was agreed wasQuotedFrom matches the intent of the relation and PROV-DM definition better than hadQuotationFrom or other relations.
  • References: The email discussion of wasQuotedFrom and hadQuotation can be found here: https://www.w3.org/2011/prov/track/issues/352
  • Changes to the document:
    • We will change "The blog entry had its own published provenance, stating that it quoted some text from the article." to "The blog entry had its own published provenance, stating that it is some text quoted from the article."
    • We will also change "Another specialized kind of derivation is to say that one entity, commonly a document, quotes from another." to "Another specialized kind of derivation is to say that one entity, commonly a part of a document, was a quote from another."
  • Original author's acknowledgement:


ISSUE-617

ISSUE-XXX

  • Original email:
  • Tracker:
  • Group Response
    • .....
    • ...
  • References:
  • Changes to the document:.
  • Original author's acknowledgement: