--- a/model/working-copy/prov-dm-constraints.html Thu Feb 16 11:08:41 2012 +0000
+++ b/model/working-copy/prov-dm-constraints.html Thu Feb 16 11:49:03 2012 +0000
@@ -1558,17 +1558,27 @@
<h3>PROV-DM Collection Constraints</h3>
<div class='note'>
-Raw material taken from prov-dm3, needs to be integrated.
+Raw material taken from prov-dm3. Some further text required.
</div>
-<ul>
- <li> One can have multiple assertions regarding the state of a collection following a <em>set</em> of insertions, for example:<br/>
-<span class="name">CollectionAfterInsertion(c2,c1, k1, v1)</span><br/>
-<span class="name">CollectionAfterInsertion(c2,c1, k2, v2)</span><br/>
- <span class="name">...</span><br/>
-This is interpreted as <em>" <span class="name">c2</span> is the state that results from inserting <span class="name">(k1, v1)</span>, <span class="name">(k2, v2)</span> etc. into <span class="name">c1</span>"</em></li></p>
-<li> It is possible to have multiple derivations from a single root collection, possibly by different asserters, as shown in the following example.
+<div class='constraint' id='collection-parallel-insertions'>
+<p>One can have multiple assertions regarding the state of a collection following a <em>set</em> of insertions, for example:</p>
+<pre class="codeexample">
+CollectionAfterInsertion(c2, c1, k1, v1)
+CollectionAfterInsertion(c2, c1, k2, v2)
+...
+</pre>
+<p>This is interpreted as <em>" <span class="name">c2</span> is the state that results from inserting <span class="name">(k1, v1)</span>, <span class="name">(k2, v2)</span> etc. into <span class="name">c1</span>"</em></p>
+</div>
+
+<div class='note'>
+Shouldn't we have the same for deletion, and combination of insertion and deletion?
+</div>
+
+
+<div class='constraint' id='collection-branching-derivations'>
+It is possible to have multiple derivations from a single root collection, as shown in the following example.
<div class="anexample">
<pre class="codeexample">
@@ -1585,28 +1595,45 @@
CollectionAfterInsertion(c3, c1, k3,v3) // c3 = { (k1,v1), (k3,v3) }
</pre>
</div>
-
-<div class='note'>Asserter not defined</div>
-</li></p>
+</div>
-<li>Given the pair of assertions:
-
-<span class="name">CollectionAfterInsertion(c, c1, k1, v1)</span><br/>
-<span class="name">CollectionAfterInsertion(c, c2, k2, v2)</span><br/>
-
-it follows that <span class="name">c1==c2, k1==k2, v1==v2</span>, because one cannot have two different derivations for the same final collection state.</li></p>
-<li>Given the following set of insertions:<br/>
-
-<span class="name">CollectionAfterInsertion(c1, c, k, v1)</span><br/>
-<span class="name">CollectionAfterInsertion(c1, c, k, v2)</span><br/>
-
-it follows that <span class="name">v1==v2</span>.</li></p>
-<li> The state of a collection is only known to the extent that a chain of derivations starting from an empty collection can be found. Since a set of assertions regarding a collection's evolution may be incomplete, so is the reconstructed state obtained by querying those assertions. In general, all assertions reflect the asserter's partial knowledge of a sequence of data transformation events. In the particular case of collection evolution, in which the asserter <em>knows</em> that some of the state changes may have been missed, then the more generic <a href="#Derivation-Relation">derivation</a> relation should be used to signal that some updates may have occurred, which cannot be precisely asserted as insertions or removals. The following two examples illustrate this.
+<div class='constraint' id='collection-unique-ancestor'>
+Given the pair of assertions:
+<pre class="codeexample">
+CollectionAfterInsertion(c, c1, k1, v1)
+CollectionAfterInsertion(c, c2, k2, v2)
+</pre>
+it follows that <span class="name">c1==c2</span>.
+</div>
+
+<div class='note'>
+Original text stated it follows that <span class="name">c1==c2, k1==k2, v1==v2</span>, because one cannot have two different derivations for the same final collection state. This is incompatible with parallel insertion constraint.
+</div>
+
+
+<div class='note'>
+Shouldn't we have the same for deletion, and combination of insertion and deletion?
+</div>
+
+
+
+
+<div class='constraint' id='collection-unique-value-for-key'>
+Given the following set of insertions:
+<pre class="codeexample">
+CollectionAfterInsertion(c1, c, k, v1)
+CollectionAfterInsertion(c1, c, k, v2)
+</pre>
+it follows that <span class="name">v1==v2</span>.
+</div>
+
+
+<p>The state of a collection is only known to the extent that a chain of derivations starting from an empty collection can be found. Since a set of assertions regarding a collection's evolution may be incomplete, so is the reconstructed state obtained by querying those assertions. In general, all assertions reflect the asserter's partial knowledge of a sequence of data transformation events. In the particular case of collection evolution, in which the asserter <em>knows</em> that some of the state changes may have been missed, then the more generic <a href="#Derivation-Relation">derivation</a> relation should be used to signal that some updates may have occurred, which cannot be precisely asserted as insertions or removals. The following two examples illustrate this.</p>
<div class="anexample">
<pre class="codeexample">
@@ -1630,9 +1657,10 @@
wasDerivedFrom(c2, c1) // the asserted knows that c2 is somehow derived from c1, but cannot assert the precise sequence of updates
CollectionAfterInsertion(c3, c2, k2, v2)
</pre>
+
+<p>Here <span class="name">c3</span> includes <span class="name">{ (k2 v2) }</span> but the earlier "gap" leaves uncertainty regarding <span class="name">(k1,v1)</span> (it may have been removed) or any other pair that may have been added as part of the derivation activities.</li></p>
</div>
-Here <span class="name">c3</span> includes <span class="name">{ (k2 v2) }</span> but the earlier "gap" leaves uncertainty regarding <span class="name">(k1,v1)</span> (it may have been removed) or any other pair that may have been added as part of the derivation activities.</li></p>
-</ul>
+
</section>