--- a/model/prov-dm-constraints.html	Mon Apr 02 09:09:31 2012 +0100
+++ b/model/prov-dm-constraints.html	Mon Apr 02 09:14:31 2012 +0100
@@ -1584,7 +1584,11 @@
 <div class="note"> unique key constraint removed as it follows from the "update semantics" which is explained in the DM</div>
 
 
-It is desirable to restrict the derivation of one collection from another to one single insertion or removal relation. The following examples illustrate what may happen when multiple derivation is allowed.
+It is desirable to restrict the derivation of one collection from another to one single insertion or removal relation, or to one membership relation.
+The interpretation of two (or more) insertion, removal, membership relations that result in the same collection is undefined.
+
+<!--
+The following examples illustrate what may happen when multiple derivations are allowed.
 
 <div class="anexample">
   <pre class="codeexample">
@@ -1611,19 +1615,23 @@
 </pre>
 Here the insertion and removal into, and removal from <span class="name">c1</span> and <span class="name">c2</span> "cancel" each other. This is allowed if no constraint is enforced, however it is not meaningful.
 </div>
+--> 
 <!--
 On the other hand, it is desirable to be able to express the fact that <span class="name">c</span> is obtained precisely as the result of <em>merging</em> <span class="name">c1</span> and <span class="name">c2</span>. <br/>
 -->
 <!--
 This is achieved by adding a constraint to ensure that each derivation is unique, and (ii) making use of the <span class="name">merge(c,c1,c2)</span> to define the state <span class="name">c</span>  precisely as the union of the states <span class="name">c1</span> and <span class="name">c2</span>. -->
-This justifies the introduction of the following constraint.
-
+The following constraint ensures unique derivation.
 
 
 <div class='constraint' id='collection-unique-derivation'/>
 
-  <p>One cannot have multiple assertions that define the state of a collection by means of insertions and removal relations. Thus:</p>
-<pre class="codeexample">
+  <p>The state of a collection that is derived through multiple insertions, removal, or membership relations is undefined.
+
+</div>
+
+<div class="anexample">
+  <pre class="codeexample">
 entity(c1, [prov:type="Collection"])
 entity(c2, [prov:type="Collection"])
 entity(c, [prov:type="Collection"])
@@ -1631,24 +1639,39 @@
 derivedByInsertionFrom(c, c1, {(k1, v1), (k2, v2)})
 derivedByInsertionFrom(c, c2, {(k3, v3)})
 </pre>
-is not allowed (unless the two sets were identical, in which case one of the two statements would be redundant)<p/>
-
- In particular, one cannot derive the state of a collection from another using multiple statements. Thus: <p/>
-<pre class="codeexample">
+is undefined (unless the two sets were identical, in which case one of the two statements would be redundant)<p/>
+</div>
+
+As a particular case, the state of <span class="name">c</span> as derived multiple times from the same <span class="name">c1</span> is undefined. <p/>
+<div class="anexample">
+  <pre class="codeexample">
 derivedByInsertionFrom(id1, c, c1, {(k1, v1), (k2, v2)})
 derivedByInsertionFrom(id2, c, c1, {(k3, v3), (k4, v4)})
 </pre>
-  is not allowed.<p/>
-
-The same applies to removal and combinations of insertions and removals, for example:
-
+  is undefined. <p/>
+   The expected way to accomplish the effect intended with these statements, is as follows:
+  <pre class="codeexample">
+derivedByInsertionFrom(id1, c, c1, {(k1, v1), (k2, v2), (k3, v3), (k4, v4)})
+</pre>  
+</div>
+
+The same is true for any combination of insertions, removals, and membership relations:
+<div class="anexample">
 <pre class="codeexample">
 derivedByInsertionFrom(c, c1, {(k1, v1)})
 derivedByRemovalFrom(c, c2, {k2})
 </pre>
-  is not allowed.
+  is undefined.
+<pre class="codeexample">
+derivedByInsertionFrom(c, c1, {(k1, v1)})
+memberOf(c, c2, {k2})
+</pre>
+  is undefined.
 </div>
 
+</div>
+
+
 
 <!--
 <section id="Collection-branching">