more constraints sec 8
authorPaolo Missier <pmissier@acm.org>
Fri, 30 Mar 2012 17:20:00 +0100
changeset 2130 9de0045d5fe4
parent 2129 d31f335adead
child 2131 729472032d31
more constraints sec 8
model/prov-dm-constraints.html
--- a/model/prov-dm-constraints.html	Fri Mar 30 17:04:02 2012 +0100
+++ b/model/prov-dm-constraints.html	Fri Mar 30 17:20:00 2012 +0100
@@ -1592,8 +1592,12 @@
 </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  (i) 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.
+<!--
+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.
 
 
 
@@ -1627,7 +1631,9 @@
 </div>
 
 
+<!--
 <section id="Collection-branching">
+-->
 <h3>Collection branching.</h3>
 
 It is possible to have multiple derivations from a single root collection, as long as the resulting entities are distinct, as shown in the following example.
@@ -1652,11 +1658,15 @@
   c2 = { (k2 v2) }
   c3 = { (k1,v1),  (k3,v3) }
   </pre>
-
+</div>
+  <!--
 </section>
-
-<section id="collections-derivation">
-
+-->
+  
+<!--
+  <section id="collections-derivation">
+-->
+  
 <h3>State of collections and use of weaker <a href="#Derivation-Relation">derivation</a> relation</h3>
 
 <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 partial knowledge reagrding a sequence of data transformation events. In the particular case of collection evolution, in which some of the state changes may have been missed, 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>
@@ -1700,9 +1710,9 @@
     c3  includes  (k2 v2) but the earlier "gap" leaves uncertainty regarding  (k1,v1) <br/>  (it may have been removed) or any other pair that may have been added as part of the derivation activities.
    </pre>
  </div>
-
+<!--
 </section>
- 
+ -->
 
 </section>  <!-- end of collections -->