1.  Is the purpose of the document clear and consistent with the working group's consensus about the semantics?
 > 
 > Yes.
 > 
 > 
 > 2.  Are there minor issues that can be corrected easily prior to FPWD release?
 > 
 > You refer to "PROV instance" a few times. Should this be "PROV document"?
 > 

I meant instance, since that is the level of granularity that corresponds to a theory/model.  Documents can be handled by treating each instance separately.  I don't propose to try to model bundles or linking relations among them.

 > In the grammar at the start of Sec 2.4 (and at least once later), why have Collection and EmptyCollection got prov: prefixes unlike any other term?

Because these are the type names used in PROV-CONSTRAINTS.  As far as I am aware there is no reason for them to have prefixes there either but no one objected to it.  The type names don't actually matter very much.

 > 
 > Typo in Remark in Section 3.2.1: "forthe"

Fixed

 > 
 > Section 3.2.1: "An entity is a kind of object... the entity does not record a fixed value for a" - doesn't sound right. What does it mean for an object to record something?

Fixed (the entity now just "has" attributes /values)
 
 > 
 > Section 3.2.3: I notice that the description of agents does not refer to responsibility, which is the key concept in DM.

Copied over the current text - the existing text was way out of date.  This is probably also true elsewhere.

 > 
 > Typo in Section 3.2.4.1: In line 1 of the definition, "if and only of evt"

Fixed

 > 
 > The precedes relation does not appear correctly in my browser (other symbols render fine).
 > 

This can be fixed by improving Unicode support...

 > 
 > 3.  Are there blocking issues that must be addressed prior to release as a first public working draft?  
 > 
 > No.
 > 
 > 
 > 4.  Are there non-blocking, but important issues that should be discussed and resolved for future editions? (no need to list TODOs already reflected in the document itself, unless there is disagreement about how to resolve them).
 > 
 > Section 3.2.4: You say that Events and Associations may overlap, but the function type() seems to preclude that: if an interaction is in Associations, it has type association, but that is not an allowed type for a member of Events?

The suggestion that they may overlap was unintended (carried over from an earlier version); fixed.

 > 
 > Section 3.3.1: "linking each derivation to its path" - I'm not clear why a derivation maps to just one path.

See also response to Luc.  This is a modeling choice, not a derived property, but note that you can have multiple derivation relations (with different identifiers) linking two entities.  So there is no loss of generality in supposing that each has its own path. 

 > 
 > A lot of Section 4 seems to be making "obvious" connections between structures and the relations of Section 3. Might the amount of text obscure the parts that are most interesting and not necessarily intuitive, e.g. in the definitions of precise derivation (single step derivation path), specialization and alternate (common things between entities)? Could these special features of the semantics be highlighted in some way?
 > 

This is a good point; a lot of the semantics is just restating the constraints in a different notation, as can often be the case with semantics.  The derivation paths and Thing/Entity/thingOf structure is more interesting and should be highlighted.  I'd ideally like to avoid saying the same thing several different ways but not sure yet how best to do this.

I will do this in a future version.