Difference between revisions of "ResponsesToPublicCommentsCR"

From Provenance WG Wiki
Jump to: navigation, search
(ISSUE-612 (Test cases for other specifications))
Line 87: Line 87:
* Original author's acknowledgement:
* Original author's acknowledgement:
== ISSUE-612 (Test cases for other specifications) ==
== ISSUE-611 (Test cases for other specifications) ==
* Original email:  
* Original email:  

Revision as of 09:55, 21 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:


  • 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:


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