--- a/model/prov-constraints.html Fri Apr 27 12:54:00 2012 -0400
+++ b/model/prov-constraints.html Fri Apr 27 22:54:04 2012 +0200
@@ -81,7 +81,7 @@
specStatus: "ED",
// the specification's short name, as in http://www.w3.org/TR/short-name/
- shortName: "prov-dm-constraints",
+ shortName: "prov-constraints",
// if your specification has a subtitle that goes below the main
// formal title, define it here
@@ -171,8 +171,8 @@
<p> This document introduces a further set of concepts useful for
understanding the PROV data model and defines <i>inferences</i>
- that are allowed on provenance descriptions and <i>validity
- constraints</i> that well-structured provenance descriptions should
+ that are allowed on provenance statements and <i>validity
+ constraints</i> that PROV instances should
follow. These inferences and constraints are useful for readers who
develop applications that generate provenance or reason over
provenance.
@@ -246,20 +246,25 @@
<p> PROV-DM is a conceptual data model for provenance (realizable
using different serializations such as PROV-N, PROV-O, or PROV-XML).
-However, nothing in the PROV-DM specification [[PROV-DM]] forces PROV
-descriptions to be meaningful, that is, to correspond to a consistent
+However, nothing in the PROV-DM specification [[PROV-DM]] forces sets
+of PROV
+statements (or <a>instances</a>) to be meaningful, that is, to correspond to a consistent
history of objects and interactions. Furthermore, nothing in the
PROV-DM specification enables applications to perform inferences over
-provenance descriptions. </p>
-
-<p> This document specifies <em>inferences</em> over PROV descriptions that
+PROV <a>instances</a>. </p>
+
+<p> This document specifies <em>inferences</em> over PROV instances that
applications MAY employ, including definitions of some provenance
-descriptions in terms of others, and also defines a class of <em>valid</em>
-PROV descriptions by specifying <em>constraints</em> that valid PROV descriptions must
+statements in terms of others, and also defines a class of <em>valid</em>
+PROV instances by specifying <em>constraints</em> that valid PROV instances must
satisfy. Applications SHOULD produce valid provenance and
MAY reject provenance that is not valid in order to increase
the usefulness of provenance and reliability of applications that
-process it.</p>
+process it. <a href="#compliance"
+class="sectionRef"></a>
+summarizes the requirements for compliance with this document, which
+are specified in detail in the rest of the document.
+</p></p>
<p> This specification lists inferences and definitions together in one
section (<a href="#inferences" class="sectionRef"></a>), defines the
@@ -267,28 +272,17 @@
class="sectionRef"></a>), and then
considers two kinds of validity constraints (<a href="#constraints"
class="sectionRef"></a>): <em>structural constraints</em> that
-prescribe properties of PROV descriptions that can be checked directly
+prescribe properties of PROV instances that can be checked directly
by inspecting the syntax, and <em>event ordering</em> constraints that
-require that the records in a <a>PROV description</a> are consistent with a
+require that the records in a PROV <a>instance</a> are consistent with a
sensible ordering of events relating the activities, entities and
agents involved. In separate sections we consider additional
constraints specific to collections and accounts (<a
href="#collection-constraints" class="sectionRef"></a> and <a
href="#account-constraints" class="sectionRef"></a>). </p>
-<div class="note">Question to James: The term 'PROV Instance' seems to have a precise meaning. I read this as a PROV Description Set. Should we define it? Every where it occurs, there is a link to its first occurrence.</div>
-
-<p>
-The specification also describes how the inferences, definitions, and
-constraints should be used (<a href="#compliance"
-class="sectionRef"></a>). Briefly, a PROV compliant application is
-allowed (but not required) to treat two PROV descriptions the same
-if they are equal after applying the inference rules and possibly
-reordering expressions, and we can define a canonical form for <a title="PROV instance">PROV
-instances</a> obtained by applying all possible inference rules. In
-addition, a validating PROV application is required to check that
-the constraints are satisfied in (the normal form of) provenance data generated or consumed by the application.
-</p>
+
+
<p>
Finally, the specification includes a section (<a
@@ -319,6 +313,40 @@
</section>
+<section id="compliance">
+<h2>Compliance with this document</h2>
+
+<div class="note">
+TODO: Add collection and account constraint sections to the compliance
+ list as appropriate.
+ </div>
+ For the purpose of compliance, the normative sections of this document
+ are <a href="#compliance"
+class="sectionRef"></a>, <a href="#inferences"
+class="sectionRef"></a>, <a href="#equivalence"
+class="sectionRef"></a>, and <a href="#constraints"
+class="sectionRef"></a>.
+ To be compliant:
+ <ol><li>When processing provenance, an
+ application MAY apply the inferences and definitions in <a
+ href="#inferences" class='sectionRef'></a>.</li>
+ <li>When determining whether two PROV instances are
+ <a>equivalent</a>, an application MUST determine whether their
+ normal forms are equal, as specified in <a href="#equivalence" class="sectionRef"></a>.
+ <li>When determining whether a PROV instance is <a>valid</a>, an
+ application MUST check that all of the
+ constraints of <a href="#constraints" class="sectionRef"></a> are
+ satisfied on the <a>normal form</a> of the instance.</li>
+ <li> When producing provenance meant for other applications to
+ use, the application SHOULD produce <a>valid</a> provenance. </li>
+ </ol>
+ <div class="note">
+ Should we specify a way for PROV instances to say whether they
+ are meant to be validated or not? Seems outside the scope of this
+ document, may require changes to PROV-N.
+ </div>
+
+</section>
@@ -328,9 +356,9 @@
<p>
In this section, we describe <a title="inference">inferences</a> and <a title="definition">definitions</a> that MAY be used on
provenance data, and a notion of <a
-title="equivalence">equivalence</a> on PROV descriptions.
+title="equivalence">equivalence</a> on PROV instances.
An <dfn id="inference">inference</dfn> is a rule that can be applied
- to PROV descriptions to add new PROV expressions. A <dfn
+ to PROV instances to add new PROV statements. A <dfn
id="definition">definition</dfn> is a rule that states that a
provenance expression is equivalent to some other expressions; thus,
defined provenance expressions can be replaced by their definitions,
@@ -348,11 +376,11 @@
<p>
This means that if all of the provenance expressions matching <span class="name">hyp_1</span>... <span class="name">hyp_k</span>
- can be found in a PROV description, we can add all of the expressions
+ can be found in a PROV instance, we can add all of the expressions
<span class="name">concl_1</span> ... <span class="name">concl_n</span> to the instance, possibly after generating fresh
identifiers <span class="name">a_1</span>,...,<span class="name">a_m</span> for unknown objects. These fresh
identifiers might later be found to be equal to known identifiers;
- these fresh identifiers play a similar role in PROV descriptions to existential variables in logic.
+ these fresh identifiers play a similar role in PROV constraints to existential variables in logic.
</p>
<div class='note'>
TODO: Is this re-inventing blank nodes in PROV-DM, and do we want to
@@ -375,7 +403,7 @@
This means that a provenance expression defined_exp is defined in
terms of other expressions. This can be viewed as a two-way
inference: If <span class="name">defined_exp</span>
- can be found in a PROV description, we can add all of the expressions
+ can be found in a PROV instance, we can add all of the expressions
<span class="name">defining_exp_1</span> ... <span class="name">defining_exp_n</span> to the instance, possibly after generating fresh
identifiers <span class="name">a_1</span>,...,<span class="name">a_m</span> for unknown objects. Conversely, if there
exist identifiers <span class="name">a_1</span>...<span class="name">a_m</span> such that <span class="name">defining_exp_1</span>
@@ -403,7 +431,7 @@
</div>
<p>The relationship <span class="name">wasInformedBy</span> is not
-transitive. Indeed, consider the following descriptions.</p>
+transitive. Indeed, consider the following statements.</p>
<pre class="codeexample">
wasInformedBy(a2,a1)
wasInformedBy(a3,a2)
@@ -448,10 +476,10 @@
Attribution identifies an agent as responsible for an entity. An
agent can only be responsible for an entity if it was associated with
an activity that generated the entity. If the activity, generation
-and association events are not explicit in the description, they can
+and association events are not explicit in the instance, they can
be inferred.
<div class='inference' id='attribution-implication'>
-<span class='conditional'>If</span>
+<span class='conditional'>IF</span>
<span class="name">wasAttributedTo(e,ag)</span> holds for some identifiers
<span class="name">e</span> and <span class="name">ag</span>,
<span class='conditional'>THEN</span> there exists an activity with some identifier <span class="name">a</span> such that the following statements hold:
@@ -571,7 +599,7 @@
<p>Traceability allows an entity to be transitively linked to another entity it is derived from, to an agent it is attributed to, or another agent having some responsibility, or a trigger of an activity that generated it.</p>
-<p>Traceability can be inferred from existing descriptions, or can be asserted stating that a dependency path exists without its individual steps being expressed. This is captured
+<p>Traceability can be inferred from existing statements, or can be asserted stating that a dependency path exists without its individual steps being expressed. This is captured
by the following inferences:
<div class='inference' id='traceability-inference'>
@@ -639,11 +667,12 @@
For any entity <span class='name'>e1</span>, <span class='name'>e2</span>, <span class='conditional'>IF</span> <span class='name'>alternateOf(e1,e2)</span> <span class='conditional'>THEN</span> <span class='name'>alternateOf(e2,e1)</span>.
</div>
-<p>Similarly, specialization is a partial order: it is <a>reflexive</a>,
+<p>Similarly, specialization is a strict partial order: it is <a>irreflexive</a>,
<a>anti-symmetric</a> and
<a>transitive</a>.</p>
- <div class='inference' id="specialization-reflexive">
- For any entity <span class='name'>e</span>, we
+
+ <div class='inference' id="specialization-irreflexive">
+ For any entity <span class='name'>e</span>, it is not the case that
have <span class='name'>specializationOf(e,e)</span>.
</div>
@@ -651,12 +680,11 @@
For any
entities <span class='name'>e1</span>, <span
class='name'>e2</span>,
- <span class='conditional'>IF</span>
+it is not the case that
<span class='name'>specializationOf(e1,e2)</span>
and
- <span class='name'>specializationOf(e2,e1)</span> <span
- class='conditional'>THEN</span> <span class='name'>e1 = e2</span>.
- </div>
+ <span class='name'>specializationOf(e2,e1)</span>.
+</div>
<div class='inference' id="specialization-transitive">
For any
entities <span class='name'>e1</span>, <span class='name'>e2</span>, <span class='name'>e3</span>, <span class='conditional'>IF</span> <span class='name'>specializationOf(e1,e2)</span>
@@ -785,8 +813,7 @@
For the purpose of checking inferences and constraints, we define a
-notion of <a>equivalence</a> of PROV descriptions. Equivalence is
-has the following characteristics:
+notion of <a>equivalence</a> of PROV s. Equivalence has the following characteristics:
<ul>
@@ -797,8 +824,9 @@
<li> Redundant expressions are merged according to uniqueness
constraints. </li>
<li>
- The order of provenance expressions is irrelevant to the meaning of a PROV description. That is, a
- PROV description is equivalent to any other instance obtained by
+ The order of provenance expressions is irrelevant to the meaning of
+ a PROV instance. That is, a
+ PROV instance is equivalent to any other instance obtained by
permuting its expressions.
</li>
<li>
@@ -819,7 +847,7 @@
</div>
<div id="optional-attributes1">PROV-DM allows for some attributes to
be optionally expressed. Unless otherwise specified, when an
- optional attribute is not present in a description, some value
+ optional attribute is not present in a statement, some value
SHOULD be assumed to exist for this attribute, though it is not
known which.
@@ -857,10 +885,10 @@
<p>
-We define the <dfn>normal form</dfn> of a PROV description as the set
+We define the <dfn>normal form</dfn> of a PROV instance as the set
of provenance expressions resulting from merging all of the overlapping
expressions in the instance and applying all possible inference rules
-to this set. Formally, we say that two PROV descriptions are
+to this set. Formally, we say that two PROV instances are
<dfn>equivalent</dfn> if they have the same normal form (that is,
after applying all possible inference rules, the two instances produce
the same set of PROV-DM expressions.)
@@ -889,14 +917,11 @@
<p>
-This section defines a collection of constraints on PROV descriptions. An PROV description is <dfn id="dfn-valid">valid</dfn>
+This section defines a collection of constraints on PROV instances. A PROV instance is <dfn id="dfn-valid">valid</dfn>
if, after applying all possible inference and definition rules from
<a href="#inferences">Section 2</a>, the resulting instance
satisfies all of the constraints specified in this section.
- Applications that process PROV descriptions SHOULD check that the data
- they generate is <a title="valid">valid</a> and MAY reject input
- provenance data that is not <a title="valid">valid</a>.
- </p>
+ </p>
<p> There are two kinds of constraints:
<ul><li><em>uniqueness constraints</em> that say that a <a>PROV
@@ -908,7 +933,7 @@
<li> and <em>event ordering constraints</em> that say that it
should be possible to arrange the
events (generation, usage, invalidation, start, end) described in a
- PROV description into a partial order that corresponds to a sensible
+ PROV instance into a partial order that corresponds to a sensible
"history" (for example, an entity should not be generated after it
is used).
</li>
@@ -949,7 +974,7 @@
</div>
<p> We assume that the various identified objects of PROV-DM have
- unique expressions describing them within a PROV description.
+ unique statements describing them within a PROV instance.
</p>
<div class='constraint' id='entity-unique'>
<p>Given an entity identifier <span class="name">e</span>, there is at
@@ -976,7 +1001,7 @@
<em>simultaneously</em>.
This implies that the two generation events are actually the same and
caused by the same <em>activity</em>, though provenance may contain
-several descriptions for the same world activity.
+several statements for the same world activity.
</p>
@@ -1033,7 +1058,7 @@
<p>Given that provenance consists of a description of past entities
-and activities, <a>valid</a> provenance descriptions MUST
+and activities, <a>valid</a> provenance instances MUST
satisfy <em>ordering constraints</em> between instantaneous events, which we introduce in
this section. For instance, an entity can only be used after it was
generated; hence, we say that an entity's <a title="entity generation
@@ -1041,7 +1066,7 @@
entity's <a title="entity usage event">usage events</a>. Should this
ordering constraint be violated, the associated generation and
usage could not be credible. The rest of this section defines
-the <dfn>temporal interpretation</dfn> of provenance descriptions as a
+the <dfn>temporal interpretation</dfn> of provenance instances as a
set of instantaneous event ordering constraints. </p>
@@ -1064,9 +1089,8 @@
class="name">e2</span>. Both relations are partial orders, meaning
that they are reflexive, transitive, and antisymmetric.</p>
-<div class="note"> Define reflexivity, transitivity
-and antisymmetry in glossary. Also, do we want to allow an event to
- "precede" itself?
+<div class="note"> Do we want to allow an event to
+ "precede" itself? Perhaps precedes should be strict.
</div>
<div class="note">
@@ -1074,11 +1098,11 @@
</div>
<p>PROV-DM also allows for time observations to be inserted in
-specific provenance descriptions, for each of the five kinds
+specific provenance statements, for each of the five kinds
of <a title="instantaneous event">instantaneous events</a> introduced in this specification. The
presence of a time observation for a given <a>instantaneous event</a> fixes the
mapping of this <a>instantaneous event</a> to the timeline. The presence of time
-information in a provenance description instantiates the ordering constraint with
+information in a provenance statement instantiates the ordering constraint with
that time information. It is expected that such instantiated
constraints can help corroborate provenance information. We anticipate
that verification algorithms could be developed, though this
@@ -1575,7 +1599,7 @@
<p>A collection may be obtained by insertion or removal, or said to satisfy the membership relation.
To provide an interpretation of collections, PROV-DM
restricts one collection to be involved in a single derivation by insertion or removal, or to one membership relation.
-PROV-DM does not provide an interpretation for descriptions that consist of two (or more) insertion, removal, membership relations that result in the same collection.</p>
+PROV-DM does not provide an interpretation for statements that consist of two (or more) insertion, removal, membership relations that result in the same collection.</p>
@@ -1589,7 +1613,7 @@
</div>
<div class="anexample">
-Consider the following descriptions about three collections.
+Consider the following statements about three collections.
<pre class="codeexample">
entity(c1, [prov:type="prov:Collection" %% xsd:QName])
entity(c2, [prov:type="prov:Collection" %% xsd:QName])
@@ -1599,7 +1623,7 @@
derivedByInsertionFrom(c3, c1, {("k1", e1), ("k2", e2)})
derivedByInsertionFrom(c3, c2, {("k3", e3)})
</pre>
-<p>There is no interpretation for such descriptions since <span class="name">c3</span> is derived multiple times by insertion.</p>
+<p>There is no interpretation for such statements since <span class="name">c3</span> is derived multiple times by insertion.</p>
</div>
@@ -1609,7 +1633,7 @@
derivedByInsertionFrom(id1, c, c1, {("k1", e1), ("k2", e2)})
derivedByInsertionFrom(id2, c, c1, {("k3", e3), ("k4", e4)})
</pre>
-<p>The interpretation of such descriptions is also unspecified. </p>
+<p>The interpretation of such statements is also unspecified. </p>
<p>To describe the insertion of the 4 key-entity pairs, one would instead write:</p>
<pre class="codeexample">
derivedByInsertionFrom(id1, c, c1, {("k1", e1), ("k2", e2), ("k3", e3), ("k4", e4)})
@@ -1618,7 +1642,7 @@
The same is true for any combination of insertions, removals, and membership relations:
<div class="anexample">
-<p>The following descriptions</p>
+<p>The following statements</p>
<pre class="codeexample">
derivedByInsertionFrom(c, c1, {("k1", e1)})
derivedByRemovalFrom(c, c2, {"k2"})
@@ -1652,7 +1676,7 @@
derivedByInsertionFrom(c2, c0, {("k2", e2)})
derivedByInsertionFrom(c3, c1, {("k3", e3)})
</pre>
-From this set of descriptions, we conclude:
+From this set of statements, we conclude:
<pre class="codeexample">
c1 = { ("k1", e1) }
c2 = { ("k2", e2) }
@@ -1669,7 +1693,11 @@
<h4>Collections and Weaker Derivation Relation</h4>
-<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 descriptions regarding a collection's evolution may be incomplete, so is the reconstructed state obtained by querying those descriptions. In general, all descriptions reflect partial knowledge regarding 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 expressed as insertions or removals. The following example illustrates this.</p>
+<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 statements regarding a collection's evolution may be
+incomplete, so is the reconstructed state obtained by querying those
+statements. In general, all statements reflect partial knowledge regarding 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 expressed as insertions or removals. The following example illustrates this.</p>
@@ -1687,7 +1715,7 @@
wasDerivedFrom(c2, c1)
derivedByInsertionFrom(c3, c2, {("k2", e2)})
</pre>
-From this set of descriptions, we conclude:
+From this set of statements, we conclude:
<ul>
<li> <span class="name">c1 = { ("k1", e1) }</span>
<li> <span class="name">c2</span> is somehow derived from <span class="name">c1</span>, but the precise sequence of updates is unknown
@@ -1716,7 +1744,7 @@
<p>PROV-DM allows for multiple descriptions of entities (and in general any identifiable object) to be expressed. </p>
<div class="anexample" id="example-two-entities-one-id">
-<p>Let us consider two descriptions of a same entity, which we have taken from two different contexts. A working draft published by the <span class="name">w3:Consortium</span>:</p>
+<p>Let us consider two statements about the same entity, which we have taken from two different contexts. A working draft published by the <span class="name">w3:Consortium</span>:</p>
<pre class="codeexample">
entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
</pre>
@@ -1724,20 +1752,22 @@
<pre class="codeexample">
entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
</pre>
-<p>Both descriptions are about the same entity identified by
+<p>Both statements are about the same entity identified by
<span class="name">tr:WD-prov-dm-20111215</span>, but they contain different attributes, describing the situation or partial state of the these entities according to the context in which they occur.
</p>
</div>
-<p>Two different descriptions of a same entity cannot co-exist in a same account
- as formalized in <a href="#unique-description-in-account">unique-description-in-account</a>.</p>
+<p>Two different statements about the same entity cannot co-exist in a same account
+ as formalized in <a href="#unique-statement-in-account">unique-statement-in-account</a>.</p>
<!-- Moved to uniqueness constraints section
-<div class='constraint' id='unique-description-in-account'>
-<p>Given an entity identifier <span class="name">e</span>, there is at most one description
-<span class="name">entity(e,attrs)</span> occurring in a given account, where <span class="name">attrs</span> is some set of attribute-values. Other descriptions of the same entity can exist in different accounts.</p>
+<div class='constraint' id='unique-statement-in-account'>
+<p>Given an entity identifier <span class="name">e</span>, there is at most one statement
+<span class="name">entity(e,attrs)</span> occurring in a given
+ account, where <span class="name">attrs</span> is some set of
+ attribute-values. Other statements concerning the same entity can exist in different accounts.</p>
<p>This constraint similarly applies to all other types and relations,
with explicit identity.</p>
@@ -1747,10 +1777,10 @@
<p>In some cases, there may be a requirement for two different
- descriptions of the same entity to be included in the same account. To satisfy the constraint <a href="#unique-description-in-account">unique-description-in-account</a>, we can adopt a different identifier for one of them, and relate the two descriptions with the <span class="name">alternateOf</span> relation. </p>
+ statements concerning the same entity to be included in the same account. To satisfy the constraint <a href="#unique-statement-in-account">unique-statement-in-account</a>, we can adopt a different identifier for one of them, and relate the two statements with the <span class="name">alternateOf</span> relation. </p>
<div class="anexample" id="merge-with-rename">
-<p>We now reconsider the same two descriptions of a same entity, but we change the identifier for one of them:</p>
+<p>We now reconsider the same two statements of a same entity, but we change the identifier for one of them:</p>
<pre class="codeexample">
entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
entity(ex:alternate-20111215, [ prov:type="document", ex:version="2" ])
@@ -1764,9 +1794,9 @@
we may drop this discussion
</div>
<p> Taking the union of two accounts is another account,
-formed by the union of the descriptions they respectively contain. We note that the resulting union may or may not invalidate some constraints:
+formed by the union of the statements they respectively contain. We note that the resulting union may or may not invalidate some constraints:
<ul>
-<li> Two entity descriptions with a same identifier but different sets of attributes exist in each original account may invalidate <a href="#unique-description-in-account">unique-description-in-account</a> in the union, unless some form of description merging or renaming (as per <a href="#merge-with-rename">Example</a>) occurs.
+<li> Two entity statements with a same identifier but different sets of attributes exist in each original account may invalidate <a href="#unique-statement-in-account">unique-statement-in-account</a> in the union, unless some form of statement merging or renaming (as per <a href="#merge-with-rename">Example</a>) occurs.
<li> Structurally well-formed
accounts are not
closed under union because the
@@ -1785,7 +1815,7 @@
</div>
<div class="anexample">
<p>
-In the following descriptions, a workflow execution <span class="name">a0</span> consists of two sub-workflow executions <span class="name">a1</span> and <span class="name">a2</span>.
+In the following statements, a workflow execution <span class="name">a0</span> consists of two sub-workflow executions <span class="name">a1</span> and <span class="name">a2</span>.
Sub-workflow execution <span class="name">a2</span> generates entity <span class="name">e</span>, so does <span class="name">a0</span>.</p>
<pre class="codeexample">
activity(a0, [prov:type="workflow execution"])
@@ -1800,9 +1830,9 @@
but described from different perspectives.</p>
</div>
-<p>While this example is permitted in PROV-DM, it does not make the inter-relation between activities explicit, and it mixes descriptions expressed from different perspectives together.
+<p>While this example is permitted in PROV-DM, it does not make the inter-relation between activities explicit, and it mixes statements expressed from different perspectives together.
While this may acceptable in some specific applications, it becomes challenging for inter-operability. Indeed, PROV-DM does not offer any relation describing the structure of activities.
- Such descriptions are said not to be structurally well-formed.</p>
+ Such instances are said not to be structurally well-formed.</p>
<p>Structurally well-formed provenance can be obtained by partitioning the generations into different accounts. This makes it clear that these generations provide alternative
descriptions of the same real-world generation event, rather than describing two distinct generation events for the same entity. When accounts are used, the example can be encoded as follows.</p>
@@ -1810,7 +1840,7 @@
<div class="anexample">
<p>
-The same example is now revisited, with the following descriptions that are structurally well-formed. Two accounts are introduced, and there is a single generation for entity <span
+The same example is now revisited, with the following statements that are structurally well-formed. Two accounts are introduced, and there is a single generation for entity <span
class="name">e</span> per account.</p>
<p>In a first account, entitled "summary", we find:</p>
@@ -1829,8 +1859,8 @@
-<p>Structurally well-formed provenance satisfies 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 descriptions.
+<p>Structurally well-formed provenance satisfies some constraints, which force the structure of statements to be exposed by means of accounts. With these constraints satisfied, further
+inferences can be made about structurally well-formed statements.
The uniqueness of generations in accounts is formulated as follows.
</p>
@@ -1844,28 +1874,6 @@
-<section id="compliance">
-<h2>Compliance with this document</h2>
-
-For the purpose of compliance, the normative sections of this document
- are (TODO). To be compliant:
- <ul><li>When processing provenance obtained from another source, an
- application MAY apply the inferences and definitions in <a
- href="#inferences" class='sectionRef'></a>.</li>
- <li>An application SHOULD process <a>equivalent</a> PROV-DM instances in the same way, described in <a href="#equivalence" class="sectionRef"></a>
- <li>When determining whether a PROV description is <a>valid</a>, an
- application MUST check that all of the
- constraints of <a href="#constraints" class="sectionRef"></a> are
- satisfied on the <a>normal form</a> of the instance.</li>
- <li> When producing provenance meant for other applications to
- use, the application SHOULD produce <a>valid</a> provenance. </li>
- </ul>
- <div class="note">
- Should we specify a way for PROV descriptions to say whether they
- are meant to be validated or not? Seems outside the scope of this document.
- </div>
-
-</section>
<section id='rationale' class="informative">
@@ -1981,12 +1989,12 @@
An <dfn>entity</dfn> is a thing one wants to provide provenance for
and whose situation in the world is described by some attribute-value
pairs. An entity's attribute-value pairs are established as part of
-the entity description and their values remain unchanged for the
+the entity statement and their values remain unchanged for the
lifetime of the entity. An entity's attribute-value pairs are expected
to describe the entity's situation and (partial) state during an
entity's <a title="characterization interval">characterization interval</a>.</p>
-<p>If an entity's situation or state changes, this may result in its description being invalid, because one or more attribute-value pairs no longer hold. In that case, from the PROV viewpoint, there exists a new entity, which needs to be given a distinct identifier, and associated with the attribute-value pairs that reflect its new situation or state.</p>
+<p>If an entity's situation or state changes, this may result in its statement being invalid, because one or more attribute-value pairs no longer hold. In that case, from the PROV viewpoint, there exists a new entity, which needs to be given a distinct identifier, and associated with the attribute-value pairs that reflect its new situation or state.</p>
@@ -2149,7 +2157,7 @@
provenance descriptions. PROV-DM data MUST satisfy such constraints. </p>
<p>PROV-DM also allows for time observations to be inserted in
-specific descriptions, for each recognized <a
+specific statements, for each recognized <a
title="instantaneous event">instantaneous event</a> introduced in this
specification. The presence of a time observation for a given <a
title="instantaneous event">instantaneous event</a> fixes the mapping of this <a
@@ -2225,29 +2233,33 @@
to be able to express the provenance of provenance. </p>
<div class="note">
- See ISSUE-343. Also, what is an account's set of descriptions?
+ See ISSUE-343.
</div>
<p>
<span class="glossary" id="glossary-account">
-An <dfn>account</dfn> is an entity that contains a bundle of provenance descriptions.
+An <dfn>account</dfn> is an entity that contains an instance, or set
+ of PROV statements.
</span> PROV-DM does not provide an actual mechanism for creating accounts, i.e. for bundling up provenance descriptions and naming them. Accounts MUST satisfy some properties:
<ul>
<li>An account is a bundle of provenance descriptions whose content MAY change over time.</li>
-<li>If an account's set of descriptions changes over time, it SHOULD increase monotonically with time. </li>
+<li>If an account's set of statements changes over time, it SHOULD increase monotonically with time. </li>
<li>A given description of e.g. an entity in a given account, in terms of its identifier and attribute-value pairs, does not change over time. </li>
</ul>
<div class='note'>
The last point is important. It indicates that within an account:
<ul>
-<li>It is always possible to add new provenance descriptions, e.g. stating that a given entity was used by an activity, or derived from another. This is very much an open world assumption.
-<li>It is not permitted to add new attributes to a given entity (a form of closed world assumption from the attributes point of view), though it is always permitted to create a new description for an entity, which is a "copy" of the original description extended with novel attributes (cf Example <a href="#merge-with-rename">merge-with-rename</a>).
+<li>It is always possible to add new provenance statements, e.g. stating that a given entity was used by an activity, or derived from another. This is very much an open world assumption.
+<li>It is not permitted to add new attributes to a given entity (a
+ form of closed world assumption from the attributes point of view),
+ though it is always permitted to create a new statement describing
+ an entity, which is a "copy" of the original statement extended with novel attributes (cf Example <a href="#merge-with-rename">merge-with-rename</a>).
</ul>
</div>
<p>
There is no construct in PROV-DM to create such bundles of
-descriptions. Instead, it is assumed that some mechanism, outside
+statements. Instead, it is assumed that some mechanism, outside
PROV-DM can create them. However, from a provenance viewpoint, such
accounts are things whose provenance we may want to describe. In order to be able to do so, we need to see accounts as entities, whose origin can be described using PROV-DM vocabulary. Thus, PROV-DM introduces the reserved type <span class="name">Account</span>.
</p>
@@ -2271,7 +2283,11 @@
<h2>Glossary</h2>
<ul>
<li> <dfn>anti-symmetric</dfn>: A relation R over X is <a>anti-symmetric</a> if
- for any elements x, y of X, if x R y and y R x then x = y.</li>
+ for any elements x, y of X, if x R y and y R x then x = y.
+ Alternatively, for a strict partial order anti-symmetry usually
+ means that for any elements x, y of X, it is impossible that
+ both x R
+ y and y R x hold.</li>
<li> <dfn>reflexive</dfn>: A relation R over X is <a>reflexive</a> if
for any element x of X, we have x R x.</li>
<li> <dfn>symmetric</dfn>: A relation R over X is <a>symmetric</a> if
@@ -2310,7 +2326,7 @@
-->
<!-- LocalWords: continuant occurrent modalities toyota womanInRedDress
-->
-<!-- LocalWords: customerInChairAt manWithGlasses customerInChair
+<!-- LocalWords: customerInChairAt manWithGlasses customerInChair irreflexive
-->
<!-- LocalWords: wasStartedByActivity antisymmetric wasInvalidatedBy
-->