--- a/model/prov-dm.html Tue Mar 27 17:06:33 2012 +0100
+++ b/model/prov-dm.html Tue Mar 27 17:07:12 2012 +0100
@@ -1985,16 +1985,20 @@
<section id="term-collection-insertion">
<h3>Insertion</h3>
-
+<span class="glossary" id="glossary-collection-insertion">
+ <dfn id="concept-insertion">Insertion</dfn> is a derivation denoting the transformation of a collection into another, by insertion of one or more key-value pairs.
+</span>
+
+<p>
<strong>Derivation-by-Insertion</strong> relation <span class="name">derivedByInsertionFrom(c2, c1, {(key_1, value_1), ..., (key_n, value_n)})</span> states that <span class="name">c2</span> is the state of the collection
-following the insertion of the set of pairs <span class="name"> {(key_1, value_1), ..., (key_n, value_n)}</span> into collection <span class="name">c1</span>.
+following the insertion of pairs <span class="name"> {(key_1, value_1), ..., (key_n, value_n)}</span> into collection <span class="name">c1</span>, with the provision that each <span class="name">key_i</span> is unique.
<p> A Derivation-by-Insertion relation<span class="withPn">, written <span class="pnExpression"> derivedByInsertionFrom(id, collAfter, collBefore, key-value-set, attrs)</span>,</span> contains:</p>
<ul>
<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
<li><span class='attribute'>after</span>: an identifier for the collection <em>after</em> insertion; </li>
<li><span class='attribute'>before</span>: an identifier for the collection <em>before</em> insertion;</li>
-<li><span class='attribute'>key-value-set</span>: a set of inserted key-value pairs, of the form {(key_1, value_1), ..., (key_n, value_n)} where each key_i is a value, and value_i is an identifier for the value that has been inserted with the key. This may be an entity identifier;</li>
+<li><span class='attribute'>key-value-set</span>: the inserted key-value pairs, of the form {(key_1, value_1), ..., (key_n, value_n)} where each key_i is a value, and value_i is an identifier for the value that has been inserted with the key. This may be an entity identifier;</li>
<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
</ul>
@@ -2024,7 +2028,12 @@
<section id="term-collection-removal">
<h3>Removal</h3>
-<strong>Derivation-by-Removal</strong> relation <span class="name">derivedByRemovalFrom(c2,c1, {key_1, ... key_n})</span> states that <span class="name">c2</span> is the state of the collection following the removal of the set of pairs corresponding to keys <span class="name">key_1...key_n</span> from <span class="name">c1</span>.
+<span class="glossary" id="glossary-collection-removal">
+ <dfn id="concept-removal">Removal</dfn> is a derivation denoting the transformation of a collection into another, obtained from the former by removing of one or more key-value pairs.
+</span>
+
+
+<p><strong>Derivation-by-Removal</strong> relation <span class="name">derivedByRemovalFrom(c2,c1, {key_1, ... key_n})</span> states that <span class="name">c2</span> is the state of the collection following the removal of the set of pairs corresponding to keys <span class="name">key_1...key_n</span> from <span class="name">c1</span>.
<p> A Derivation-by-Removal relation, written <span class="pnExpression"> derivedByRemovalFrom(id, collAfter, collBefore, key-set, attrs)</span>, contains:</p>
<ul>
@@ -2062,45 +2071,18 @@
</section> <!-- removal -->
-<!--
-<section id="term-collection-bulk">
-<h3>Bulk insertion and removal</h3>
-
-The following relations allow for insertion and removal assertions involving a set of key-value pairs.
-
-<p> A <strong>Derivation-by-Bulk-Insertion</strong> relation <span class="withPn">, written <span class="pnExpression"> derivedByBulkInsertionFrom(id, collAfter, collBefore, key-value-set, attrs)</span>,</span> contains:</p>
-<ul>
-<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
-<li><span class='attribute'>after</span>: an identifier for the collection <em>after</em> insertion; </li>
-<li><span class='attribute'>before</span>: an identifier for the collection <em>before</em> insertion;</li>
-<li><span class='attribute'>key-value-set</span>: a set of inserted key-value pairs, of the form {(key_1, value_1), ..., (key_n, value_n)}</li>
-<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
-</ul>
-
-<p> A <strong>Derivation-by-Bulk-Removal</strong> relation, written <span class="pnExpression"> derivedByBulkRemovalFrom(id, collAfter, collBefore, key-set, attrs)</span>, contains:</p>
-<ul>
-<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
-<li><span class='attribute'>after</span>: an identifier for the collection <em>after</em> the deletion; </li>
-<li><span class='attribute'>before</span>: an identifier for the collection <em>before</em> the deletion;</li>
-<li><span class='attribute'>key-set</span>: a set of deleted keys, of the form {key_1,..., key_n}</li>
-<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
-</ul>
-
-</section> <!-- bulk ops -->
-
-
-
-<section id="term-collection-containment">
+<section id="term-collection-membership">
<h3>Membership</h3>
+
+<span class="glossary" id="glossary-collection-membership">
+ <dfn id="concept-membership">Membership</dfn> denotes that a key-value pair is a member of a collection.
+</span>
+
+<p>
The insertion and removal relations make insertions and removals explicit as part of the history of a collection. This, however, requires explicit mention of the state of the collection prior to each insertion. The membership relation removes this needs, allowing the state of a collection <span class="name">c</span> to be asserted without having to introduce a prior state. This allows for the natural expression of a collection state, for instance in cases where a program or workflow block produces a new collection <span class="name">c</span> with known content. In such cases,
<span class="name">memberOf(c,{(key_1, value_1), ..., (key_n, value_n)})</span> asserts that <span class="name">c</span> is known to include <span class="name">{(key_1, value_1), ..., (key_n, value_n)}</span>, without having to introduce an initial state. <br/>
-<!--
-This relation is introduced as a convenience, as it can be rewritten as an insertion operation by introducing a prior state: <br/>
-<span class="name">contained(c,k, v)</span> iff there exists a collection <span class="name">c0</span> such that <span class="name">derivedByInsertionFrom(c, c0, k, v)</span>.
--->
-
<p> A <strong>Membership</strong> relation, written <span class="pnExpression"> memberOf(id, coll, key-value-set, attrs)</span>, contains:</p>
<ul>
<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
@@ -2136,84 +2118,9 @@
one would conclude that, based on these assertions, <span class="name">c1 = {("k1", v1) ("k2", v2), ("k3",v3)}</span>.
</div>
-<!--
-<p> A <strong>Bulk-Containment</strong> relation, written <span class="pnExpression"> containedBulk(id, coll, key-value-set, attrs)</span>, contains:</p>
-<ul>
-<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
-<li><span class='attribute'>after</span>: an identifier for the collection whose members are asserted; </li>
-<li><span class='attribute'>key-value-set</span>: a set of key-value pairs contained in the collection, of the form {(key_1, value_1), ..., (key_n, value_n)}</li>
-<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
-</ul>
-
-<div class="anexample">
-<pre class="codeexample">
- entity(c, [prov:type="EmptyCollection"]) // e is a collection, with unknown content
-
- entity(v1)
- entity(v2)
- derivedByBulkInsertionFrom(c1, c, {("k1", v1), ("k2", v2)})
- derivedByInsertionFrom(c2, c1, "k3", v3)
- derivedByBulkRemovalFrom(c3, c1, {"k1", "k3"})
-
- containedBulk(c3, {("k4", v4), ("k5", v5)})
-</pre>
- From this set of assertions, we conclude:
- <pre class="codeexample">
- c = { }
- c1 = { ("k1", v1) ("k2", v2)}
- c2 = { ("k1", v1) ("k2", v2), ("k3", v3)}
- c3 = { ("k2", v2), ("k4", v4), ("k5", v5)}
- </pre>
-</div>
--->
-</section> <!-- Containment -->
-
-
-
-<section id="term-collection-state">
-
-<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>
-
-<div class="anexample">
-<pre class="codeexample">
- entity(c, [prov:type="collection"]) // c is a collection, possibly not empty
- entity(v1)
- entity(v2, [prov:type="collection"]) // v2 is a collection
-
- derivedByInsertionFrom(c1, c, {(k1, v1)})
- derivedByInsertionFrom(c2, c1, {(k2, v2)})
- </pre>
- From this set of assertions, we conclude:
- <pre class="codeexample">
- c1 includes (k1,v1) but may contain additional unknown pairs
- c2 includes (k1,v1), (k2 v2) (and possibly more pairs), where v2 is a collection with unknown state
- </pre>
-
- </div>
- In the example, the state of <span class="name">c2</span> is only partially known because the collection is constructed from partially known other collections.
-
- <div class="anexample">
- <pre class="codeexample">
- entity(c, [prov:type="emptyCollection"]) // c is an empty collection
- entity(v1)
- entity(v2)
- entity(c1, [prov:type="collection"])
- entity(c2, [prov:type="collection"])
- entity(c3, [prov:type="collection"])
-
- derivedByInsertionFrom(c1, c, {(k1, v1)})
- wasDerivedFrom(c2, c1)
- derivedByInsertionFrom(c3, c2, {(k2, v2)})
- </pre>
- From this set of assertions, we conclude:
- <pre class="codeexample">
- c1 = { (k1,v1) }
- c2 is somehow derived from c1, but the precise sequence of updates is unknown
- 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> <!-- Membership -->
+
+
Further considerations: <p/>
@@ -2230,8 +2137,6 @@
<li>The representation of a collection through these relations, makes no assumption regarding the underlying data structure used to store and manage collections. In particular, no assumptions are needed regarding the mutability of a data structure that is subject to updates. Entities, however, are immutable and this applies to those entities that represent collections. This is reflected in the constraints listed in Part II. </li>
</ul>
-
- </section> <!-- term-collection-state -->
</section> <!-- end collections-->
--- a/model/working-copy/wd5-prov-dm-collections.html Tue Mar 27 17:06:33 2012 +0100
+++ b/model/working-copy/wd5-prov-dm-collections.html Tue Mar 27 17:07:12 2012 +0100
@@ -209,6 +209,51 @@
<section id="collection-constraints">
<h3>PROV-DM Collection Constraints [to go in part II]</h3>
+
+<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>
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="collection"]) // c is a collection, possibly not empty
+ entity(v1)
+ entity(v2, [prov:type="collection"]) // v2 is a collection
+
+ derivedByInsertionFrom(c1, c, {(k1, v1)})
+ derivedByInsertionFrom(c2, c1, {(k2, v2)})
+ </pre>
+ From this set of assertions, we conclude:
+ <pre class="codeexample">
+ c1 includes (k1,v1) but may contain additional unknown pairs
+ c2 includes (k1,v1), (k2 v2) (and possibly more pairs), where v2 is a collection with unknown state
+ </pre>
+
+ </div>
+ In the example, the state of <span class="name">c2</span> is only partially known because the collection is constructed from partially known other collections.
+
+ <div class="anexample">
+ <pre class="codeexample">
+ entity(c, [prov:type="emptyCollection"]) // c is an empty collection
+ entity(v1)
+ entity(v2)
+ entity(c1, [prov:type="collection"])
+ entity(c2, [prov:type="collection"])
+ entity(c3, [prov:type="collection"])
+
+ derivedByInsertionFrom(c1, c, {(k1, v1)})
+ wasDerivedFrom(c2, c1)
+ derivedByInsertionFrom(c3, c2, {(k2, v2)})
+ </pre>
+ From this set of assertions, we conclude:
+ <pre class="codeexample">
+ c1 = { (k1,v1) }
+ c2 is somehow derived from c1, but the precise sequence of updates is unknown
+ 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>
+
+
<div class='constraint' id='collection-unique-insertion'>
<p>One cannot have multiple assertions regarding the state of a collection. Thus:</p>
<pre class="codeexample">