--- a/model/prov-dm.html Wed Mar 28 15:16:00 2012 +0100
+++ b/model/prov-dm.html Wed Mar 28 15:30:13 2012 +0100
@@ -337,7 +337,7 @@
</ol>
-<p>This specification intentionally presents the key concepts of the PROV Data Model, without drilling down into all its subtleties. Using these key concepts, it becomes possible to write useful provenance assertions very quickly, and publish or embed them along side the data they relate to. </p>
+<p>This specification intentionally presents the key concepts of the PROV Data Model, without drilling down into all its subtleties. Using these key concepts, it becomes possible to write useful provenance descriptions very quickly, and publish or embed them along side the data they relate to. </p>
<p>However, if data changes, then it is challenging to express its provenance precisely, like it would be for any other form of metadata. To address this challenge, a <em>refinement</em> is proposed to enrich simple provenance, with extra-descriptions that help qualify the specific subject of provenance and provenance itself, with attributes and temporal interval, intended to satisfy a comprehensive set of constraints. These aspects are covered in the companion specification [[PROV-DM-CONSTRAINTS]].
</p>
@@ -871,7 +871,7 @@
<li> Several persons are associated with activity <span class="name">ex:edit1</span>, some in an editorial role, some in a contributor's role.</li>
</ul>
-<p>Again, we paraphrase some PROV-DM assertions, and illustrate them with the PROV-N notation.
+<p>Again, we paraphrase some PROV-DM descriptions, and illustrate them with the PROV-N notation.
Full details of the provenance record can be found <a href="examples/w3c-publication3.pn">here</a>.</p>
<ul>
@@ -1261,7 +1261,7 @@
</div>
-<p>The relations wasStartedBy and used are orthogonal, and thus need to be asserted independently, according to the situation being described.</p>
+<p>The relations wasStartedBy and used are orthogonal, and thus need to be expressed independently, according to the situation being described.</p>
</section>
@@ -1930,7 +1930,7 @@
<h3>Component 5: Collections</h3>
<p>The fifth component of PROV-DM is concerned with the notion of collections.
-A collection is an entity that has some parts. The parts are themselves entities, and therefore their provenance can be expressed. In many applications, it is also of interest to be able to express the provenance of the collection itself: e.g. who maintains the collection, which part it contains at which point in time, and how it was assembled. The purpose of Component 5 is to define the types and relations that are useful to express the provenance of collections. </p>
+A collection is an entity that has some members. The members are themselves entities, and therefore their provenance can be expressed. In many applications, it is also of interest to be able to express the provenance of the collection itself: e.g. who maintains the collection, which member it contains at which point in time, and how it was assembled. The purpose of Component 5 is to define the types and relations that are useful to express the provenance of collections. </p>
<p>Figure <a href="#figure-component5">figure-component5</a> overviews
the component, which consists of two "UML Class" and three associations.
@@ -1946,7 +1946,7 @@
<p>The intent of these relations and types is to express the <em>history of changes that occurred to a collection</em>.
-Changes to collections are about the insertion of parts to collections and the removal of parts from collections.
+Changes to collections are about the insertion of entities to collections and the removal of members from collections.
Indirectly, such history provides a way to reconstruct, the contents of a collection.</p>
<section id="term-collection">
@@ -1957,7 +1957,7 @@
<p>Conceptually, a collection has a logical structure consisting of key-entity pairs. This structure is often referred to as a <em>map</em>, and is a generic indexing mechanisms that can abstract commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more (the specification of such specialized structures in terms of key-value pairs is out of the scope of this document).</p>
-<p>A given collection forms a given structure for its parts. A different structure (obtained either by insertion or removal of parts) constitutes a different collection. Hence,
+<p>A given collection forms a given structure for its members. A different structure (obtained either by insertion or removal of members) constitutes a different collection. Hence,
for the purpose of provenance, a collection entity is viewed as a snapshot of a structure. Insertion and removal operations result in new snapshots, each snapshot forming an identifiable collection entity.</p>
@@ -2122,20 +2122,22 @@
<span class="glossary-ref" data-ref="glossary-membership"></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(id, c,{(key_1, e_1), ..., (key_n, e_n)})</span> asserts that <span class="name">c</span> is known to include <span class="name">{(key_1, e_1), ..., (key_n, e_n)}</span>, without having to introduce an initial state. <br/>
+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 operation. The membership relation removes this needs, allowing the state of a collection <span class="name">c</span> to be expressed without having to introduce a prior state.</p>
<p>
<div class="attributes" id="attributes-memberOf">
- A <dfn title="memberOf">membership</dfn> relation, written <span class="pnExpression"> memberOf(id, coll, key-value-set, attrs)</span>, contains:
+ A <dfn title="memberOf">membership</dfn> relation, written <span class="pnExpression">memberOf(id, c, {(key_1, e_1), ..., (key_n, e_n)}, attrs)</span>, contains:
<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 that are members of the collection, of the form {(key_1, e_1), ..., (key_n, e_n)}</li>
-<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+<li><span class='attribute'>after</span>: an identifier (<span class="name">c</span>) for the collection whose members are asserted; </li>
+<li><span class='attribute'>key-entity-set</span>: a set of key-entity pairs <span class="name">(key_1, e_1)</span>, ..., <span class="name">(key_n, e_n)</span> that are members of the collection;</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs to further describe the properties of the relation.</li>
</ul>
</div>
+<p>The description <span class="name">memberOf(c, {(key_1, e_1), ..., (key_n, e_n)})</span> states that <span class="name">c</span> is known to include <span class="name">(key_1, e_1)</span>, ..., <span class="name">(key_n, e_n)}</span>, without having to introduce an initial state. <br/>
+
+
<div class="anexample">
<pre class="codeexample">
@@ -2180,10 +2182,10 @@
<ul>
-<li>The state of a collection (i.e., the set of key-value pairs it contains) at a given point in a sequence of operations is never stated explicitly. Rather, it can be obtained by querying the chain of derivations involving insertions and removals. Entity type <span class="name">emptyCollection</span> can be used in this context as it marks the start of a sequence of collection operations.</li>
-
-
-<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>
+<li>The state of a collection (i.e., the set of key-entity pairs it contains) at a given point in a sequence of operations is never stated explicitly. Rather, it can be obtained by querying the chain of derivations involving insertions and removals. Entity type <span class="name">emptyCollection</span> can be used in this context as it marks the start of a sequence of collection operations.</li>
+
+
+<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>