Difference between revisions of "ResponsesToPublicCommentsCR"

From Provenance WG Wiki
Jump to: navigation, search
(ISSUE-617)
(ISSUE-617)
Line 150: Line 150:
 
** This is a continuation of  https://www.w3.org/2011/prov/track/issues/612
 
** This is a continuation of  https://www.w3.org/2011/prov/track/issues/612
 
* Changes to the document:.
 
* Changes to the document:.
 +
** none.
 
* Original author's acknowledgement:
 
* Original author's acknowledgement:
  

Revision as of 18:08, 24 January 2013

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:

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)

  • Original email:
  • Tracker: http://www.w3.org/2011/prov/track/issues/611
  • Group Response
    • This response address the comment that test cases should be made available for all of PROV beyond prov-constraints.
    • The group assumes that this request applies to prov-o and prov-n as prov-dm is a conceptual data model
    • The groups believes test-cases are non-normative see prov-constraints test cases
    • The test suite in prov-constraints provide typical examples expressed in both prov-n, and prov-o - the two normative serializations. These should provide enough examples for implementations to exercise the syntax. Furthermore, the group provides a set of larger examples (PROV_examples) for implementations to use.
    • Providing typical examples was encouraged in discussions with the Semantic Web Coordination group.
  • References:
  • Changes to the document: none.
  • Original author's acknowledgement:

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

  • Original email: http://lists.w3.org/Archives/Public/public-prov-comments/2013Jan/0016.html
  • Tracker: https://www.w3.org/2011/prov/track/issues/617
  • Group Response
    • The lingering concern is: "Right now, it looks like some of the inferences from PROV Constraints document is included in PROV-O. Specifically, Inference 15 (influence-inference) [1] and Inference 20 (specialization-alternate-inference) [2] are included in PROV-O as subPropertyOf axioms. But other inferences defined in this document are not included in PROV-O which is a little confusing. For example, Inference 12 (revision-is-alternate-inference) [3] suggests another subPropertyOf relation (wasRevisionOf subPropertyOf alternateOf) but this is not in PROV-O. If the WG chooses to encode some of the inferences in PROV-O but not others, we would like to understand the rationale behind this decision."
    • The following is an exhaustive list of the inferences in http://www.w3.org/TR/prov-constraints/ The rationale for encoding a prov-constraints inference in prov-o follows these rules:
      • Rule 1: Do not encode a prov-constraints inference in prov-o, unless...
      • Rule 2: The inference is a single subproperty, BUT,
      • Rule 3: If a subproperty has multiple superproperties, choose the best ONE.
          • As you'll note, inferences 16-19 would have been trivially easy to include in prov-o, but that violated Rules 1 and 2.
          • Inference 20 passes all three Rules, and is thus encoded in prov-o.
          • Inference 15 and Inference 12 pass Rule 1 and Rule 2, but compete in Rule 3, and prov:wasInfluencedBy is the more natural place to place wasRevisionOf. The choice of "best" was editorial.
    • Inference 5 NOT included in prov-o.
    • Inference 6 NOT included in prov-o.
    • Inference 7 NOT included in prov-o.
    • Inference 8 NOT included in prov-o.
    • Inference 9 NOT included in prov-o.
    • Inference 10 NOT included in prov-o.
    • Inference 11 NOT included in prov-o.
    • Inference 12 NOT included in prov-o. (as commenter points out)
    • Inference 13 NOT included in prov-o.
    • Inference 14 NOT included in prov-o.
    • Inference 15 included in prov-o (?p subpropertyOf prov:wasInfluencedBy)
    • Inference 16 NOT included in prov-o. (alternateOf reflexivity)
    • Inference 17 NOT included in prov-o. (alternateOf transitive)
    • Inference 18 NOT included in prov-o. (alternateOf symmetric)
    • Inference 19 NOT included in prov-o. (specializationOf transitive)
    • Inference 20 included in prov-o (prov:specializationOf subproperty of prov:alternateOf)
    • Inference 21 NOT included in prov-o.
  • References:
  • Changes to the document:.
    • none.
  • Original author's acknowledgement:

ISSUE-XXX

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