--- a/model/comments/issue-459-simon.txt	Tue Aug 07 09:32:44 2012 +0100
+++ b/model/comments/issue-459-simon.txt	Tue Aug 07 10:18:02 2012 +0100
@@ -136,12 +136,34 @@
    > ex:illustrate. While there is only one (implicit) generation event for
    > entity ex:chart1, both ex:compile and ex:illustrate can be asserted to
    > have generated the entity. 
+
+Constraint 27 indeed says that there is a single generation event 
+and constraint 26 says that the id is a key for a wasGeneratedBy
+which implies that there is a single activity.
+
+
+In the primer, you assert:
+  wasGeneratedBy(ex:chart1, ex:compile,  2012-03-02T10:30:00)
+  wasGeneratedBy(ex:chart1, ex:illustrate,  2012-03-02T10:30:00)
+
+This is invalid.
+
+One way to address this is to maintain two levels of abstraction for
+both activities and entities.
+
+ wasGeneratedBy(ex:chart1_abstract, ex:illustrate,  2012-03-02T10:30:00)
+ specializationOf(ex:chart1,ex:chart1_abstract)  // or similar.
+
+
    > 
    > Note I see nothing in the constraints (Inference 12, Constraints 27
    > and 28) that the primer example contradicts, and nothing intuitively
    > invalid about the primer example. The text referred to above, however,
    > states something more than the constraints do. 
    > 
+
+
+
    > Failed merges
    > ---------
    > D. Section 5.1: I did not find clear what the consequences of a failed
@@ -150,11 +172,31 @@
    > it mean that the output instance of the merge is the same as the input
    > instance? Or both? 
    > 
+
+Step 3 states:
+ - If merging fails, then the constraint is unsatisfiable, so application of the key constraint to I fails.
+
+Step 3 of normal form (section 6) states:
+- Apply all uniqueness constraints to I2 by merging terms or
+  statements and applying the resulting substitution to the instance,
+  yielding an instance I3. If some uniqueness constraint cannot be
+  applied, then normalization fails.
+
+Step 1 of validity (section 6) states:
+- Normalize the instance, obtaining normalized instance I'. If normalization fails, then I is not valid.
+
+
    > E. Section 6 says "A normal form of a PROV instance may not exist when
    > a uniqueness constraint fails due to merging failure." This doesn't
    > clarify things, as it says "may not" and I'm unclear under what
    > circumstances failed merge means a PROV instance does not exist and
    > when it does not. 
+
+Text was ambiguous, rephrased as:
+
+   A normal form of a PROV instance does not exist when a uniqueness
+  constraint fails due to merging failure. 
+
    > 
    > Bundles
    > -------

--- a/model/prov-constraints.html	Tue Aug 07 09:32:44 2012 +0100
+++ b/model/prov-constraints.html	Tue Aug 07 10:18:02 2012 +0100
@@ -3424,7 +3424,7 @@
   </li>
   </ol>
 
-<p>A normal form of a PROV instance may not exist when a uniqueness constraint fails due to merging failure. </p>
+<p>A normal form of a PROV instance does not exist when a uniqueness constraint fails due to merging failure. </p>
 
 
   <p>Two PROV instances are <dfn>equivalent</dfn> if they have the