--- a/model/comments/issue-459-simon.txt	Tue Aug 07 10:18:02 2012 +0100
+++ b/model/comments/issue-459-simon.txt	Tue Aug 07 11:10:14 2012 +0100
@@ -210,6 +210,18 @@
    > from whether a set of statements are valid. It seems fine for a user
    > to treat one bundle as one instance if they want to, but there's no
    > reason given why this is the general case. 
+
+I am not sure I understand this comment.  However, I have rewritten
+slightly the intro of section 6.1.
+
+"The definitions, inferences, and constraints, and the resulting notions of normalization, validity and equivalence, assume a PROV instance that consists of exactly one bundle, the toplevel bundle, containing all PROV statements in the top level of the bundle (that is, not enclosed in a named bundle). In this section, we describe how to deal with PROV instances consisting of multiple named bundles. Briefly, each bundle is handled independently; there is no interaction between bundles from the perspective of applying definitions, inferences, or constraints, computing normal forms, or checking validity or equivalence."
+
+I have also added: 
+
+"Names b1...bn are assumed to be distinct."
+
+@James: are you OK?
+
    > 
    > Misc
    > ------
@@ -218,15 +230,42 @@
    > PAQ etc? I thought we changed the definition because an entity is not
    > just something with provenance but also part of other things'
    > provenance, and that an activity can have provenance too? 
+
+I removed the "bold" font, since we are not defining the term here.
+
+ prov-dm says: "In PROV, things we want to describe the provenance of
+ are called entities and have some fixed aspects." So, I think the
+ text is ok.
+
    > 
    > H. Inference 11: Can we also infer that _t1 precedes _t2? I'm not sure
    > whether the event ordering constraints cover this, as they are
    > inferred times. 
+
+
+We don't infer time ordering, but event ordering, as discussed in
+section 2.2
+
+An application, with knowledge that both time t1 and t2 were measured
+with the same clock could reasonably infer what you suggest.
+
    > 
    > I. Inference 12: I agree this appears redundant
+
+Now that generation and usage are no longer expandable, inference 12
+is no longer redundant.
+
    > 
    > J. Inference 18: Shouldn't the antecedent be expressed in PROV-N,
    > "entity(e)", to be consistent with other rules? 
+
+Repharsed as follows:
+
+IF entity(e) THEN alternateOf(e,e).
+
+
+@James: are you ok?
+
    > 
    > K. Section 5.1, paragraph 1: In the example merge, I wasn't clear why
    > variables "t1" and "t2" disappeared in the merged version but "a" did

--- a/model/prov-constraints.html	Tue Aug 07 10:18:02 2012 +0100
+++ b/model/prov-constraints.html	Tue Aug 07 11:10:14 2012 +0100
@@ -619,7 +619,7 @@
 </p>
 
 <p>
-An <dfn>entity</dfn> is a thing one wants to provide provenance for
+An entity is a thing one wants to provide provenance for
 and whose situation in the world is described by some fixed
 attributes. An entity has a <dfn id="lifetime">lifetime</dfn>,
 defined as the period
@@ -1881,7 +1881,8 @@
  
 <div class='inference' id="alternate-reflexive">
 <p>
-    For any entity <span class='name'>e</span>, we have <span class='name'>alternateOf(e,e)</span>.
+<span class='conditional'>IF</span>  <span class='name'>entity(e)</span> <span class='conditional'>THEN</span>
+<span class='name'>alternateOf(e,e)</span>.
 </p>
     </div>
 
@@ -3472,10 +3473,10 @@
 
 <p>The definitions, inferences, and constraints, and
 the resulting notions of normalization, validity and equivalence,
-assume a PROV instance with exactly one <a>bundle</a>, the <a>toplevel
-bundle</a>, consisting of all PROV statements in the toplevel of the
-instance (that is, not enclosed in a named <a>bundle</a>).  In this section, we describe how to deal with PROV
-instances consisting of multiple bundles.  Briefly, each bundle is
+assume a PROV instance that consists of exactly one <a>bundle</a>, the <a>toplevel
+bundle</a>, containing all PROV statements in the top level of the
+bundle (that is, not enclosed in a named <a>bundle</a>).  In this section, we describe how to deal with PROV
+instances consisting of multiple named bundles.  Briefly, each bundle is
 handled independently; there is no interaction between bundles from
 the perspective of applying definitions, inferences, or constraints,
 computing normal forms, or checking validity or equivalence.</p>
@@ -3486,7 +3487,7 @@
 class="name">(B<sub>0</sub>,[b<sub>1</sub>=B<sub>1</sub>,...,b<sub>n</sub>=B<sub>n</sub>])</span>
 where <span class="name">B<sub>0</sub></span> is the set of
 statements of the <a>toplevel bundle</a>, and for each <span class="name">i</span>, <span class="name">B<sub>i</sub></span> is the set of
-statements of bundle <span class="name">b<sub>i</sub></span>.  This notation is shorthand for the
+statements of bundle <span class="name">b<sub>i</sub></span>.  Names <span class="name">b<sub>1</sub>...b<sub>n</sub></span> are assumed to be distinct.  This notation is shorthand for the
 following PROV-N syntax:</p>
 <pre>
 B<sub>0</sub>