Difference between revisions of "ResponsesToPublicCommentsCR"

From Provenance WG Wiki
Jump to: navigation, search
(ISSUE-612 (Test cases for other specifications))
(ISSUE-611 (comments on prov-constraints))
Line 7: Line 7:
 
== ISSUE-611 (comments on prov-constraints) ==
 
== ISSUE-611 (comments on prov-constraints) ==
  
JAMES TODO
+
* 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:<br />
 +
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 (normative test cases) ==
 
== ISSUE-611 (normative test cases) ==

Revision as of 17:18, 10 January 2013

Template for Issue Response

ISSUE-611 (comments on prov-o)

PAUL TODO (refer to 612)

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 (normative test cases)

DONG TODO

ISSUE-611 (feedback on individual test cases)

  • Original email: http://lists.w3.org/Archives/Public/public-prov-comments/2013Jan/0000.html
  • Tracker: ISSUE-611
  • Group Response
    • 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:.
  • Original author's acknowledgement:

ISSUE-612 (Transitivity of Derivation)

LUC TODO

ISSUE-612 (Encoding of Constraints in OWL)

PAUL TODO

ISSUE-612 (Test cases for other specifications)

PAUL TODO

ISSUE-XXX

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