--- a/model/ProvenanceModel.html Tue Jan 17 12:42:52 2012 +0000
+++ b/model/ProvenanceModel.html Tue Jan 17 12:59:08 2012 +0000
@@ -3542,11 +3542,11 @@
<p>According to the definition of a <a>generation record</a>, an entity becomes available after this entity's generation event, and does not exist before this event. From this definition, we conclude that PROV-DM does not allow for an entity to have two generation records occurring at two different instants.
The rationale for this constraint is as follows.
- Two distinct <a title="entity generation event">generation events</a> (by a same activity or by two distinct activities), occurring one after the other, necessarily create two distinct entities; otherwise, the second <a title="entity generation event">generation event</a> would have resulted in a entity that existed before its creation, which contradicts the definition of <a>generation record</a>.</p>
+ Two distinct <a title="entity generation event">generation events</a> (by a same activity or by two distinct activities), occurring one after the other, necessarily create two distinct entities; otherwise, the second <a title="entity generation event">generation event</a> would have resulted in an entity that existed before its creation, which contradicts the definition of <a>generation record</a>.</p>
<p>So, PROV-DM allows for two distinct <a>generation records</a> <span class="name">g1</span> and <span class="name">g2</span> referencing a same entity record provided they occur <em>simultaneously</em>.
<!-- (This means that <span class="name">g1</span> <a>precedes</a> <span class="name">g2</span> and <span class="name">g2</span> <a>precedes</a> <span class="name">g1</span>.) -->
- For such a simultaneous generation to occur, the generation event has to be unique and caused by a <em>single world activity</em>, though the provenance records may contain different activity records providing alternative descriptions of that same world activity.
+ In practice, for such a simultaneous generation to occur, the generation event has to be unique and caused by a <em>single world activity</em>, though the provenance records may contain different activity records providing alternative descriptions of that same world activity.
</p>
<div class="anexample">
@@ -3564,7 +3564,7 @@
This example is permitted in PROV-DM if the two activity records <span class="name">a0</span> and <span class="name">a2</span> provide alternate descriptions of what happens in the world with respect to this generation event.
</div>
-<p>While this example is permitted in PROV-DM, it does not expose the hierarchical organization of executions and it mixes records providing two descriptions of a same execution. This issue is highlighted by two different <a title="generation record">generation records</a> for entity <span class="name">e</span>, which make reasoning about this kind of provenance records unnecessarily difficult. Such assertions are said not be structurally well-formed.</p>
+<p>While this example is permitted in PROV-DM, it does not expose the hierarchical organization of executions and it mixes records providing two descriptions of a same execution. This issue is highlighted by two different <a title="generation record">generation records</a> for entity <span class="name">e</span>, which makes reasoning about this kind of provenance records unnecessarily difficult. Such assertions are said not be structurally well-formed.</p>
<p>Structurally well-formed provenance records can be obtained by partitioning the generation records into different accounts. This makes it clear that these records provide alternative descriptions of the same real-world generation event, rather than describing two generation events for the same entity. When accounts are used, the example can be encoded as follows.</p>
@@ -3686,14 +3686,14 @@
<ul>
<li> Attributes are constructs of the data model that allow representations of aspects of the world's entities and activities to be expressed. Applications are free to introduce application-specific attributes, according to their perspective on the world. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace declared in a namespace declaration.
-<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes: <span class="name">type</span>, <span class="name">location</span>.</li>
+<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes catering for extensibility: <span class="name">type</span>, <span class="name">location</span>.</li>
<li> Sets of Attribute-value pairs offer a mechanism to
describe modalities of use, generation, and control
Such attributes are also qualified by namespaces.
-<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
+<p>To this end, the <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
<li>Note records allow arbitrary metadata to be associated with identifiable records of PROV-DM. Note records consist of name-value pairs. Like attributes, names are qualified by a namespace.</li>
@@ -3701,7 +3701,7 @@
<li>Namespaces allow attributes and names to be qualified. </li>
-<li>Subtyping is allowed by means of the reserved attribute <span class="name">type</span>.</li>
+<li>Subtyping of elements and relations is allowed by means of the reserved attribute <span class="name">type</span>.</li>
<li>Domain specific values can be expressed by means of typed literals. </li>
</ul>