> 
   > 
   > Hi prov-constraints editors:
   > 
   > This is my review of the constraints draft for last call. Sorry for
   > the delay, I wanted to make sure that I could implement each type of
   > constraint. I'm reviewing
   > http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-constraints-20120723/prov-constraints.html
   > 
   > First, thanks for all your hard work. The document is precise and the
   > approach is systematic. I have more detailed comments below. Answering
   > the questions posed in
   > http://lists.w3.org/Archives/Public/public-prov-wg/2012Jul/0346.html -
   > 
   > 1.  Is PROV-CONSTRAINTS ready to be released as a last call working
   > draft (modulo editorial issues and resolution to the below issues)?
   > 
   > Yes, but there are some major editorial things that need to be done to
   > help implementors. Additionally, in section 6 you mention a proof in
   > an appendix. This is technical content so either needs to be or not
   > mentioned.

I made this appendix non-normative. This allows us to do it later.



   > 
   > 2.  Regarding ISSUE-346: Is the role, meaning, and intended use of
   > each type of inference or constraint clear?
   > (http://www.w3.org/2011/prov/track/issues/346)
   > 
   > I think each definition is now precise and clear but as I will mention
   > in my longer comments I think there is some additional intuition
   > necessary to help implementers.
   > 
   > 3.  Regarding ISSUE-451: Are there any objections to the
   > revision-is-alternate inference?
   > (http://www.w3.org/2011/prov/track/issues/451)
   > 
   > Nope
   > 
   > 4.  Regarding ISSUE-454: Are the rules for disjointness clear and
   > appropriate? (http://www.w3.org/2011/prov/track/issues/454)
   > 
   > Yes
   > 
   > 5.  Regarding ISSUE-458: Should influence (and therefore all
   > subrelations, including communication) be irreflexive, or can it be
   > reflexive (i.e., can wasInfluencedBy(x,x) be valid)?
   > (http://www.w3.org/2011/prov/track/issues/458)
   > 
   > I think this come downs what we think the role of the constraints are.
   > My impression is to encourage implementers to be both explicit and
   > correct in the provenance they create. In terms of the example given
   > in the issue, I would expect that if an activity called itself you
   > would want to identify that has two independent activities. Thus, I
   > think it's irreflexive. Actually, maybe this is suggesting the need
   > for a part of relation around activities.

no action.

   > 
   > 5.  Are there any objections to closing other open issues on
   > PROV-CONSTRAINTS?  They are:
   > 
   > - http://www.w3.org/2011/prov/track/issues/387
   > - http://www.w3.org/2011/prov/track/issues/394
   > - http://www.w3.org/2011/prov/track/issues/452
   > - http://www.w3.org/2011/prov/track/issues/453
   > 
   > I think all these issues are addressed.
   > 
   > 6.  Are there any new issues concerning definitions, constraints, or inferences?
   > No
   > 

no action.

   > 
   > ==Comments==
   > 
   > My approach to reviewing the constraints was to attempt to implement
   > the constraints and inferences using semantic web technologies.  You
   > can find the beginning of the implementation at
   > https://github.com/pgroth/prov-constraints-validator-spin . I have
   > satisfied myself that the specification can be implemented using SPIN
   > RDF. However, I'm not 100 % certain, which is a bit of concern.
   > Additionally, to get things to work I had to make sure the inferences
   > were done in one pass, which may go against what is specified in the
   > document.

It is fine to do it all in one pass.  The suggested
   approach in the spec is not required as long as the end results are
   the same.  This is now stated explicitly.

   > 
   > My major concern is the lack of intuition about what valid provenance
   > is. I would describe it as follows: valid provenance identifies
   > exactly partial states and those partial states are correctly ordered.
   > I'm trying to implement the spec but as an implementor I need to know
   > my broad goal when implementing these constraints.
   > 
   > A key thing that it took me a while to get is that I need to generate
   > all qualified relations before applying the constraints. This is an
   > important point because it's sometimes unclear what should be
   > considered an inference or constraints.
   > 
   > Concretely, in the Event Ordering Constraints, the constraints are
   > expressed stating that the head of the rule leads to an assertion of
   > precedence. But actually, the thing is that you have to assert all
   > these precedences relations first and then check for cycles. So I
   > guess, are these really constraints? At any rate, the notion of
   > checking for cycles needs to be brought out more.

@James: 
we define 'inference' and 'definition' but we don't seem to define constraint.

An inference is a rule that can be applied to PROV instances to add new PROV statements.
A definition is a rule that can be applied to PROV instances to replace defined expressions with definitions.

@James: Should we add a definition:

An ordering constraint (should we say rule?) is a rule that can be applied to PROV instances
to add new precedes/strictly precedes statements.

@James Should we add a constraint box, since this is the actual constraint to be satisfied.

Ordering constraints require that the directed graph from ordering statements contains no cycle containing a strictly precedes edge.


-- I think this can be clarified editorially without changing the
   technical content, by explaining the constraint generation/checking
   paradigm we're working in. --jrc

-- This is now done --jrc

   > 
   > Overall, I think an implementor could use some examples that show the
   > results of inference and the subsequent constraint checking and just
   > more intuition about what a valid and invalid provenance graphs look
   > like.

hhm, this would make the document very long.

   > 
   > ==Some comments per section==
   > 
   > Section 3
   > I'm worried about the MUST in the compliant list "When determining
   > whether two PROV instances are equivalent, an application must
   > determine whether their normal forms are equal, as specified in
   > section 6. Normalization, Validity, and Equivalence."
   > 
   > Does this imply that I have to implement this to be compatible with
   > PROV-DM? I would use SHOULD…


Note, text possibly being rephrased, following stian's input.

However, it's not problematic. If you determine wheher two prov instances are equivalence,
you must determine whehter the NF are equal.  Your application may not need to check equivalence.


   > 
   > Section 5.1
   > - From an RDF perspective, do I need to worry about merging? If the
   > assumption is that I'm provided an RDF serialization to check then no
   > merging is necessary. I guess the question is merging PROV-N specific?

Yes you do, because prov:qualifiedXXX and prov:influencer are not functional.
So, effectively, this constraint makes them functional.

   > 
   > Section 6.1
   > - Why do we need to talk about a hierarchy of bundles? Isn't just the
   > point that you want a set of provenance descriptions independent of
   > bundles?

It's a flat hierarchy: a toplevel, unamed bundle, possibly containing
named bundles. Named bundles dont contain bundles.

As per prov-dm/prov-n.


   > 
   > Minor Notes:
   > 
   > - PROV objects or prov constructs - check the consistency on this
   > - inconsistency with naming. Do you always want to end inference with
   > "-inference". See Inference 11 (derivation-generation-use) and
   > Inference 10 (wasEndedBy-inference)
   > 

The terminology 'prov construct'  is not present (anymore) in the document.

I updated some of the names, but still:
@TODO: make rule names more uniform.

-- This is editorial. see ISSUE-  --jrc

   > 
   > Thanks
   > Paul
   > 
   >