--- a/model/blog/constraints-blog.html Mon Sep 10 14:05:54 2012 +0100
+++ b/model/blog/constraints-blog.html Mon Sep 10 14:11:21 2012 +0100
@@ -18,17 +18,17 @@
<p>Three types of <strong>constraints</strong> are defined.</p>
<ul>
-<li><strong>Uniqueness constraints</strong>. These include key constraints, stating for instance that identifier <code>e</code> is key for statement <code>entity(e,attrs)</code>, but also constraints that state the uniqueness of events such as the generation of an entity by an activity. <a href="http://www.w3.org/TR/prov-constraints#unique-generation">Constraint 25</a> for example states that only one generation event can be associated to a generated entity and a generating activity:</p>
+<li><strong>Uniqueness constraints</strong>. These include key constraints, stating for instance that identifier <code>e</code> is key for statement <code>entity(e,attrs)</code>, but also constraints that state the uniqueness of events such as the generation of an entity by an activity. <a href="http://www.w3.org/TR/2012/WD-prov-constraints-20120911/#unique-generation">Constraint 25</a> for example states that only one generation event can be associated to a generated entity and a generating activity:</p>
<code>IF wasGeneratedBy(gen1; e,a,_t1,_attrs1) and wasGeneratedBy(gen2; e,a,_t2,_attrs2), THEN gen1 = gen2.</code></p></li>
-<li><strong>Event ordering constraints</strong>. These specify the possible orderings of events (generation, usage, invalidation of entities, start and end of activities) that correspond to a sensible history. For example, an entity should not be used before it is generated (<a href="http://www.w3.org/TR/prov-constraints#generation-precedes-usage">Constraint 39</a>):</p>
+<li><strong>Event ordering constraints</strong>. These specify the possible orderings of events (generation, usage, invalidation of entities, start and end of activities) that correspond to a sensible history. For example, an entity should not be used before it is generated (<a href="http://www.w3.org/TR/2012/WD-prov-constraints-20120911/#generation-precedes-usage">Constraint 39</a>):</p>
<code>IF wasGeneratedBy(gen; e,_a1,_t1,_attrs1) and used(use; _a2,e,_t2,_attrs2) THEN gen precedes use.</code></p>
<li><strong>Impossibility constraints</strong>. These are used to state for example that the same identifier cannot be used in two different relation types (i.e. <code>entity(foo)</code> and <code>activity(foo)</code> is an illegal combination), but also to state property of relations, for example "specialization is irreflexive" (<a href="http://www.w3.org/TR/prov-constraints#impossible-specialization-reflexive">Constraint 54</a>): </p>
<code> IF specializationOf(e,e) THEN INVALID.</code></p>
-and "the set of entities and activities are disjoint" (<a href="http://www.w3.org/TR/prov-constraints#entity-activity-disjoint">Constraint 57</a>):</p>
+and "the set of entities and activities are disjoint" (<a href="http://www.w3.org/TR/2012/WD-prov-constraints-20120911/#entity-activity-disjoint">Constraint 57</a>):</p>
<code>IF 'entity' ∈ typeOf(id) AND 'activity' ∈ typeOf(id) THEN INVALID.</code></p>
</ul>
@@ -36,7 +36,7 @@
<h3>Example</h3>
-<p>We now show an inference process involving ordering constaints, which leads to concluding that <em>all the events involved in the provenance must all be simultaneous</em>. Although logically this is a possibility, this is most likely an indication of some of the statements disrupt the consistency of the entire history. The example involves a case of <em>mutual derivation</em> of an entity from another. Consider the following statements:</p>
+<p>We now show an inference process involving ordering constaints, which leads to concluding that <em>a set of provenance statements is invalid because it cannot satisfy ordering constraints</em>. The example involves a case of <em>mutual derivation</em> of an entity from another. Consider the following statements:</p>
<p>
<code>entity(e1)</code><br>
@@ -47,13 +47,13 @@
<code>wasGeneratedBy(gen1; e1,a1,t1)</code><br>
<code>wasDerivedFrom(d1; e2,e1,-,-,-)</code></p>
-<p>That is, <code>e2</code> was derived from <code>e1</code>, each of <code>e2</code>, <code>e1</code> being respectively generated by an activity <code>a2</code>, <code>a1</code>, at time <code>t2</code>, <code>t1</code>, as illustrated by the followign figure.</p>
+<p>That is, <code>e2</code> was derived from <code>e1</code>, each of <code>e2</code>, <code>e1</code> being respectively generated by an activity <code>a2</code>, <code>a1</code>, at time <code>t2</code>, <code>t1</code>. This set of statements is illustrated by the following figure, in which activities are rectangles and entities ellipses.</p>
<img src="blog1.svg">
-<p><a href="http://www.w3.org/TR/2012/WD-prov-constraints-20120911/#derivation-generation-generation-ordering">Constraint 44</a> defines the precedence of generation of the second entity over generation of the first entity in the context of derivation:</p>
+<p><a href="http://www.w3.org/TR/2012/WD-prov-constraints-20120911/#derivation-generation-generation-ordering">Constraint 44</a> defines the precedence of generation of the first entity over generation of the second entity in the context of derivation:</p>
<code>IF wasDerivedFrom(d; e2,e1,a,g,u,attrs) and wasGeneratedBy(gen1; e1,a1,t1,attrs1) and wasGeneratedBy(gen2; e2,a2,t2,attrs2) THEN gen1 strictly precedes gen2.</code>
@@ -78,7 +78,7 @@
<h2>Conclusion</h2>
-<p>This example was simple and may not have required an automated validator to detect invalidation. However, when graph patterns become more complex, an automated validator turns out to be an essential component for provenance user, whether they intend to publish provenance, or whether they intend to consume it. The prov-constraints document defines a set of constraints that validators are expected to implement.</p>
+<p>This example was simple and may not have required an automated validator to detect invalidation. However, when graph patterns become more complex, an automated validator turns out to be an essential component for provenance users, whether they intend to publish provenance, or whether they intend to consume it. The prov-constraints document defines a set of constraints that validators are expected to implement.</p>