renamed unicity nto uniqueness
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Wed, 21 Dec 2011 16:05:42 +0000
changeset 1308 13ad76b544b5
parent 1307 667d7bed0dd7
child 1309 1f04f011ce46
renamed unicity nto uniqueness
model/ProvenanceModel.html
--- a/model/ProvenanceModel.html	Wed Dec 21 15:33:23 2011 +0000
+++ b/model/ProvenanceModel.html	Wed Dec 21 16:05:42 2011 +0000
@@ -1344,15 +1344,15 @@
 -->
 
 <div class="structural-forward">
-See <a href="#generation-unicity">generation-unicity</a> for a structural constraint on generation records.
+See <a href="#generation-uniqueness">generation-uniqueness</a> for a structural constraint on generation records.
 </div>
 
 <!--
 <p>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
 The rationale for this constraint is as follows.
-If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct entities. Alternatively,  for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This unicity constraint is formalized as follows.
-
-<div class='constraint' id='generation-unicity'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
+If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct entities. Alternatively,  for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This uniqueness constraint is formalized as follows.
+
+<div class='constraint' id='generation-uniqueness'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
 <span class='conditional'>if</span> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given account,
 <span class='conditional'>then</span> <span class="name">a1</span>=<span class="name">a2</span>  and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
 </div> 
@@ -2422,9 +2422,9 @@
 <p>In PROV-DM, an <dfn id="dfn-Account">account record</dfn> is a wrapper of records with the following purposes:  </p> 
 <ul>
 <li> It is the mechanism by which attribution of provenance can be assserted; it allows asserters to bundle up their assertions, and assert suitable attribution;</li>
-<li> It provides a scoping mechanism for identifier unicity since a record can be uniquely identified in an account by means of the identifier it contains;</li>
+<li> It provides a scoping mechanism for the uniqueness of identifiers (of elements and relations of PROV-DM);</li>
 <li> It provides a scoping mechanism for structural contraints (such as
-   <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a> discussed in Section <a href="#structural-constraints">structural-constraints</a>).</li>
+   <a href="#generation-uniqueness">generation-uniqueness</a> and <a href="#derivation-use">derivation-use</a> discussed in Section <a href="#structural-constraints">structural-constraints</a>).</li>
 </ul>
 
 
@@ -2507,14 +2507,14 @@
 <!--
 <p>
 An account is said to be well-formed if
-it satisfies the constraints  <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>.</p>
+it satisfies the constraints  <a href="#generation-uniqueness">generation-uniqueness</a> and <a href="#derivation-use">derivation-use</a>.</p>
 
 <p> The union of two accounts is another account, 
 containing the unions of their respective records, where
  records with a same identifier should be understood according to constraint <a href="#identifiable-record-in-account">identifiable-record-in-account</a>. Well-formed
 accounts are not
 closed under union because the
-constraint <a href="#generation-unicity">generation-unicity</a> may no
+constraint <a href="#generation-uniqueness">generation-uniqueness</a> may no
 longer be satisfied in the resulting union.  </p>
 
 <div class="anexample">
@@ -2530,12 +2530,12 @@
           wasGeneratedBy(e0,a1,[ex:fct="create"])     
           ... )
 </pre>
-<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span class="name">a0</span> in the previous account <span class="name">ex:acc0</span>.  If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together, the resulting set of records violates <a href="#generation-unicity">generation-unicity</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are distinct.</p>
+<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span class="name">a0</span> in the previous account <span class="name">ex:acc0</span>.  If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together, the resulting set of records violates <a href="#generation-uniqueness">generation-uniqueness</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are distinct.</p>
 </div>
 
 -->
 
-<p>Account records constitute a scope for identifier unicity. Since accounts can be nested,  scopes can also be nested; thus, the requirement on unicity of identifiers should be understood in the context of such nested scopes.  When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur. </p>
+<p>Account records constitute a scope for identifier uniqueness. Since accounts can be nested,  scopes can also be nested; thus, the requirement on uniqueness of identifiers should be understood in the context of such nested scopes.  When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur. </p>
 
 <div class="anexample">
 <p>
@@ -3664,15 +3664,15 @@
 <!--
 <p>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
 The rationale for this constraint is as follows.
-If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct entities. Alternatively,  for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This unicity constraint is formalized as follows.
+If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct entities. Alternatively,  for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This uniqueness constraint is formalized as follows.
 -->
 
 
 <p>Structurally well-formed records satisfy some constraints, which force the structure of descriptions to be exposed by means of accounts. With these constraints satisfied, further inferences can be made about structurally well-formed records.
-The unicity of generation records in accounts is formulated as follows.
+The uniqueness of generation records in accounts is formulated as follows.
 </p>
 
-<div class='constraint' id='generation-unicity'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
+<div class='constraint' id='generation-uniqueness'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
 <span class='conditional'>if</span> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given account,
 <span class='conditional'>then</span> <span class="name">a1</span>=<span class="name">a2</span>  and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
 </div> 
@@ -3685,7 +3685,7 @@
 <span class='conditional'>if</span> <span class="name">wasDerivedFrom(e2,e1, [prov:steps="1"])</span> and <span class="name">wasGeneratedBy(e2,a,attrs2)</span> hold, <span class='conditional'>then</span> <span class="name">used(a,e1,attrs1)</span> also holds
 for some set of attribute-value pairs <span class="name">attrs1</span>.
 </div>
-<p>This inference is justified by the fact that the entity represented by entity record identified by <span class="name">e2</span> is generated by at most one activity in a given account (see <a href="#generation-unicity">generation-unicity</a>). Hence,  this activity record is also the one referred to in the usage record of <span class="name">e1</span>. 
+<p>This inference is justified by the fact that the entity represented by entity record identified by <span class="name">e2</span> is generated by at most one activity in a given account (see <a href="#generation-uniqueness">generation-uniqueness</a>). Hence,  this activity record is also the one referred to in the usage record of <span class="name">e1</span>. 
 </p>
 
 
@@ -3698,14 +3698,14 @@
 
 <p>
 An account is said to be structurally well-formed if
-it satisfies the constraint  <a href="#generation-unicity">generation-unicity</a>. If an account is structurally well-formed, it support the inference <a href="#derivation-use">derivation-use</a>.</p>
+it satisfies the constraint  <a href="#generation-uniqueness">generation-uniqueness</a>. If an account is structurally well-formed, it support the inference <a href="#derivation-use">derivation-use</a>.</p>
 
 <p> The union of two accounts is another account, 
 containing the unions of their respective records, where
  records with a same identifier should be understood according to constraint <a href="#identifiable-record-in-account">identifiable-record-in-account</a>. Structurally well-formed
 accounts are not
 closed under union because the
-constraint <a href="#generation-unicity">generation-unicity</a> may no
+constraint <a href="#generation-uniqueness">generation-uniqueness</a> may no
 longer be satisfied in the resulting union.  </p>
 
 <p>
@@ -3722,7 +3722,7 @@
           wasGeneratedBy(e0,a1,[ex:fct="create"])     
           ... )
 </pre>
-<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span class="name">a0</span> in the previous account <span class="name">ex:acc0</span>.  If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together, the resulting set of records violates <a href="#generation-unicity">generation-unicity</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are distinct.</p>
+<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span class="name">a0</span> in the previous account <span class="name">ex:acc0</span>.  If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together, the resulting set of records violates <a href="#generation-uniqueness">generation-uniqueness</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are distinct.</p>
 </div>