--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/prov-constraints-dictionaries-old.html Thu Jun 28 23:39:19 2012 -0500
@@ -0,0 +1,185 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html> <head>
+<title></title>
+</head>
+
+<body>
+<h1></h1>
+
+
+<section id="dictionary-constraints">
+<h2>Dictionary Constraints</h2>
+
+
+ <div class="note">
+ As resolved at F2F3, the material in this section goes, if
+ anywhere, into the PROV-COLLECTIONS note.
+ </div>
+
+<hr>
+
+<p id='membership-as-insertion_text'>Membership is a convenience notation, since it can be expressed in terms of an insertion into some dictionary. The membership definition is formalized by <a class="rule-ref" href="#membership-as-insertion"><span/></a>.</p>
+
+<div class='definition' id='membership-as-insertion'>
+<p>
+ <span class="name">memberOf(d, {(k1, v1), ...})</span> holds
+<span class='conditional'>IF AND ONLY IF</span> there exists a dictionary <span class="name">d0</span>, such that
+<span class="name">derivedByInsertionFrom(d, d0, {(k1, v1), ...})</span>.</p>
+</div>
+
+<p>
+
+<hr>
+
+<p id='dictionary-unique-derivation_text'>A dictionary may be obtained by insertion or removal, or said to satisfy the membership relation.
+To provide an interpretation of dictionaries, PROV-DM
+ restricts one dictionary to be involved in a single derivation by insertion or removal, or to one membership relation.
+PROV-DM does not provide an interpretation for statements that consist of two (or more) insertion, removal, membership relations that result in the same dictionary.</p>
+
+
+
+<p>The following constraint ensures unique derivation.</p>
+
+
+<div class='note'> The following constraint is unclear.</div>
+<div class='constraint' id='dictionary-unique-derivation'>
+<p>A dictionary MUST NOT be derived through multiple insertions, removal,
+ or membership relations. </p>
+</div>
+
+<div class="anexample">
+Consider the following statements about three dictionaries.
+ <pre class="codeexample">
+entity(d1, [prov:type='prov:Dictionary'])
+entity(d2, [prov:type='prov:Dictionary'])
+entity(d3, [prov:type='prov:Dictionary'])
+
+
+derivedByInsertionFrom(d3, d1, {("k1", e1), ("k2", e2)})
+derivedByInsertionFrom(d3, d2, {("k3", e3)})
+</pre>
+<p>There is no interpretation for such statements since <span class="name">d3</span> is derived multiple times by insertion.</p>
+</div>
+
+
+<div class="anexample">
+<p>As a particular case, dictionary <span class="name">d</span> is derived multiple times from the same <span class="name">d1</span>. </p>
+<pre class="codeexample">
+derivedByInsertionFrom(id1, d, d1, {("k1", e1), ("k2", e2)})
+derivedByInsertionFrom(id2, d, d1, {("k3", e3), ("k4", e4)})
+</pre>
+<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, d, d1, {("k1", e1), ("k2", e2), ("k3", e3), ("k4", e4)})
+</pre>
+</div>
+
+The same is true for any combination of insertions, removals, and membership relations:
+<div class="anexample">
+<p>The following statements</p>
+<pre class="codeexample">
+derivedByInsertionFrom(d, d1, {("k1", e1)})
+derivedByRemovalFrom(d, d2, {"k2"})
+</pre>
+have no interpretation.
+Nor have the following:
+<pre class="codeexample">
+derivedByInsertionFrom(d, d1, {("k1", e1)})
+memberOf(d, {"k2",e2})
+</pre>
+</div>
+
+
+
+<section id="dictionary-branching">
+<h4>Dictionary branching</h4>
+
+It is allowed to have multiple derivations from a single root dictionary, as long as the resulting entities are distinct, as shown in the following example.
+
+<div class="anexample">
+<pre class="codeexample">
+entity(d0, [prov:type='prov:EmptyDictionary']) // d0 is an empty dictionary
+entity(d1, [prov:type='prov:Dictionary'])
+entity(d2, [prov:type='prov:Dictionary'])
+entity(d3, [prov:type='prov:Dictionary'])
+entity(e1)
+entity(e2)
+entity(e3)
+
+derivedByInsertionFrom(d1, d0, {("k1", e1)})
+derivedByInsertionFrom(d2, d0, {("k2", e2)})
+derivedByInsertionFrom(d3, d1, {("k3", e3)})
+</pre>
+From this set of statements, we conclude:
+<pre class="codeexample">
+ d1 = { ("k1", e1) }
+ d2 = { ("k2", e2) }
+ d3 = { ("k1", e1), ("k3", e3)}
+</pre>
+</div>
+
+</section>
+
+
+
+<section id="dictionaries-and-derivation">
+
+
+<h4>Dictionaries and Weaker Derivation Relation</h4>
+
+<p>Since a
+set of statements regarding a dictionary'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 dictionary evolution, in which some of the state changes may have been missed, the more generic derivation 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>
+
+
+
+ <div class="anexample">
+In the example, the state of <span class="name">d2</span> is only partially known because the dictionary is constructed from partially known other dictionaries.
+ <pre class="codeexample">
+entity(d0, [prov:type='prov:EmptyDictionary']) // d0 is an empty dictionary
+entity(d1, [prov:type='prov:Dictionary'])
+entity(d2, [prov:type='prov:Dictionary'])
+entity(d3, [prov:type='prov:Dictionary'])
+entity(e1)
+entity(e2)
+
+derivedByInsertionFrom(d1, d0, {("k1", e1)})
+wasDerivedFrom(d2, d1)
+derivedByInsertionFrom(d3, d2, {("k2", e2)})
+ </pre>
+From this set of statements, we conclude:
+<ul>
+<li> <span class="name">d1 = { ("k1", e1) }</span>
+<li> <span class="name">d2</span> is somehow derived from <span class="name">d1</span>, but the precise sequence of updates is unknown
+<li> <span class="name">d3</span> includes <span class="name">("k2", e2)</span> but the earlier "gap" leaves uncertainty regarding <span class="name">("k1", e1)</span> (it may have been removed) or any other pair that may have been added as part of the derivation activities.
+</ul>
+ </div>
+
+</section>
+
+
+<div class='note'>
+ Do the insertion/removal derivation steps imply wasDerivedFrom,
+ wasVersionOf, alternateOf?
+ </div>
+
+
+
+<section id="dictionaries-and-contents">
+
+
+<h4>Dictionaries and Contents</h4>
+
+<div class="note">
+Axiomatisation of dictionaries to be expressed here. See <a href="./working-copy/wd6-collections-constraints.html">here</a>.
+</div>
+</section>
+
+</section> <!-- dictionary-constraints -->
+
+<hr>
+<address></address>
+<!-- hhmts start --> Last modified: Thu Jun 28 23:35:34 CDT 2012 <!-- hhmts end -->
+</body> </html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/prov-constraints-rationale-old.html Thu Jun 28 23:39:19 2012 -0500
@@ -0,0 +1,349 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html> <head>
+<title></title>
+</head>
+
+<body>
+<h1>OLD rationale from PROV-CONSTRAINTS</h1>
+
+
+<section id='rationale' class="informative">
+<h2>Rationale for inferences and constraints</h2>
+
+<div class="note"> This section collects all of the explanatory
+ material that I was not certain how to interpret as an unambiguous
+ inference or constraint. Some of these observations may need to be folded
+ into the explanatory text in respective sections (for example for
+ events,
+ accounts or collections).
+
+ Editing is also needed to decrease redundancy.
+ </div>
+
+ <section id='section-attributes'>
+<h4>Entities and Attributes</h4>
+
+<p>When we talk about things in the world in natural language and even when we assign identifiers, we are often imprecise in ways that make it difficult to clearly and unambiguously report
+provenance: a resource with a URL may be understood as referring to a report available at that URL, the version of the report available there today, the report independent of where it is
+hosted over time, etc.
+However, to write precise descriptions of the provenance of things
+that change over time, we need ways of disambiguating which versions
+of things we are talking about.
+</p>
+
+<p>
+To describe the provenance of things that can change over
+time, PROV-DM uses the concept of <i>entities</i> with fixed
+attributes. From a provenance viewpoint, it is important to identify
+a partial state of something, i.e. something with some aspects that
+have been fixed, so that it becomes possible to express its provenance
+(i.e. what caused the thing with these specific aspects). An entity
+encompasses a part of a thing's history during which some of the
+attributes are fixed. An entity can thus be thought of as a part of a
+thing with some associated partial state.
+Attributes in PROV-DM are used to fix certain aspects of entities.</p>
+
+
+<p>
+An <dfn>entity</dfn> is a thing one wants to provide provenance for
+and whose situation in the world is described by some fixed
+attributes. An entity has a <dfn
+id="dfn-characterization-interval">characterization interval</dfn>,
+or <dfn id="lifetime">lifetime</dfn>,
+defined as the period
+between its <a title="entity generation event">generation event</a>
+and its <a title="entity invalidation event">invalidation event</a>.
+An entity's attributes are established when the entity is
+created and describe the entity's situation and (partial) state
+during an entity's lifetime.</p>
+
+<p>
+A different entity (perhaps representing a different user or
+system perspective) may fix other aspects of the same thing, and its provenance
+may be different. Different entities that are aspects of the same
+thing are called <em>alternate</em>, and the PROV-DM relations of
+specialization and alternate can be used to link such entities.</p>
+
+
+
+
+
+
+<div class="anexample" id="a-report-example">
+Different users may take different perspectives on a resource with
+a URL. A provenance record might use one (or more) different
+ entities to talk about different perspectives, such as:
+<ul>
+<li>a report available at a URL: fixes the nature of the thing, i.e. a document, and its location; </li>
+<li>the version of the report available there today: fixes its version number, contents, and its date;</li>
+<li>the report independent of where it is hosted and of its content over time: fixes the nature of the thing as a conceptual artifact.</li></ul>
+The provenance of these three entities may differ, and may be along the following lines:
+<ul>
+<li>the provenance of a report available at a URL may include: the act of publishing it and making it available at a given location, possibly under some license and access control;</li>
+<li>the provenance of the version of the report available there today may include: the authorship of the specific content, and reference to imported content;</li>
+<li>the provenance of the report independent of where it is hosted over time may include: the motivation for writing the report, the overall methodology for producing it, and the broad team
+involved in it.</li>
+</ul>
+<p>We do not assume that any entity is a better or worse description of
+reality than any other. That is, we do not assume an absolute ground truth with
+respect to which we can judge correctness or completeness of
+descriptions. In fact, it is possible to describe the processing that occurred for the report to be commissioned, for
+individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity with attribute-value pairs that fix some aspects of the report appropriately.</p>
+</div>
+
+
+<p>Besides entities, a variety of other PROV-DM objects have
+attributes, including activity, generation, usage, start, end,
+communication, attribution, association, responsibility, and
+derivation. Each object has an associated duration interval (which may
+be a single time point), and attribute-value pairs for a given object
+are expected to be descriptions that hold for the object's duration.
+</p>
+<p>
+However, the attributes of entities have special meaning because they
+are considered to be fixed aspects
+of underlying, changing things. This motivates constraints on
+<span class="name">alternateOf</span> and <span class="name">specializationOf</span> relating the attribute values of
+different entities.
+</p>
+<div class="note">
+ TODO:
+Constraints on alternateOf/specializationOf for this?
+ </div>
+
+ <div class="note">
+TODO: Further discussion of entities moved from the old "Definitional
+ constraints" section. Should merge with the surrounding
+ discussion to avoid repetition.
+ </div>
+<p>
+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 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 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>
+
+
+
+Further considerations:
+<ul>
+<li>In order to describe the provenance of something during an interval over which
+ relevant attributes of the thing are not fixed, it is required to
+ create multiple entities, each with its own identifier, <a
+ title="characterization interval">characterization interval</a>, and
+ fixed attributes, and express
+ dependencies between the various entities using events.
+ For example, if we want to describe the provenance of several
+ versions of a document, involving attributes such as authorship that
+ change over time, we need different entities for the versions linked
+ by appropriate generation, usage, revision, and invalidation events.
+</li>
+
+<li>There is no assumption that the set of attributes is complete, nor
+that the attributes are independent or orthogonal of each other.</li>
+<li>There is no assumption that the attributes of an entity uniquely
+identify it. Two different entities that are aspects of different
+things can have the same attributes.</li>
+<li>A <a title="characterization interval">characterization interval</a> may collapse into a single instant.</li>
+</ul>
+
+</section>
+
+<section>
+<h3>Activities</h3>
+
+<div class="note">
+ TODO: Further discussion of activities moved from old "Definitional
+ constraints and inferences" section. Edit to avoid repeating information.
+</div>
+
+
+<p>An activity is delimited by its <a title="activity start event">start</a> and its <a title="activity end event">end</a> events; hence, it occurs over
+an interval delimited by two <a title="instantaneous event">instantaneous
+events</a>. However, an activity record need not mention start or end time information, because they may not be known.
+An activity's attribute-value pairs are expected to describe the activity's situation during its interval, i.e. an interval between two instantaneous events, namely its <a title="activity start event">start</a> event and its <a title="activity end event">end</a> event.
+</p>
+
+
+<p>Further considerations:</p>
+<ul>
+<li>An activity is not an entity.
+Indeed, an entity exists in full at
+any point in its lifetime, persists during this
+interval, and preserves the characteristics that makes it
+identifiable. In contrast, an activity is something that occurs, happens,
+unfolds, or develops through time, but is typically not identifiable by
+the characteristics it exhibits at any point during its duration.
+This distinction is similar to the distinction between
+'continuant' and 'occurrent' in logic [[Logic]].</li>
+</ul>
+
+
+
+</section>
+
+
+ <section id="representation-term-assertion-inference">
+<h3>Description, Assertion, and Inference</h3>
+
+<p>
+PROV-DM is a provenance data model designed to express <em>descriptions</em> of the world.
+</p>
+
+<div class="anexample">
+A file at some point during its lifecycle, which includes multiple edits by multiple people, can be described by its type, its location in the file system, a creator, and content.
+</div>
+
+
+<p>The data model is designed to capture activities that happened in the past, as opposed to activities
+that may or will happen.
+However, this distinction is not formally enforced.
+Therefore, PROV-DM descriptions are intended to be interpreted as what
+has happened, as opposed to what may or will happen.</p>
+
+
+
+<p>
+This specification does not prescribe the means by which descriptions can be arrived at; for example, descriptions can be composed on the basis of observations, reasoning, or any other means.
+</p>
+
+
+<p>
+Sometimes, inferences about the world can be made from descriptions
+conformant to the PROV-DM data model. This
+specification defines some such inferences, allowing new descriptions
+to be inferred from existing ones. Hence, descriptions of the world
+can result either from direct assertion or from inference
+by application of inference rules defined by this specification.
+</p>
+
+
+</section>
+
+
+
+
+
+ <section id='section-event-time'>
+<h4>Events and Time</h4>
+
+
+
+
+<p>Time is critical in the context of provenance, since it can help corroborate provenance claims. For instance, if an entity is claimed to be obtained by transforming another, then the
+latter must have existed before the former. If it is not the case, then there is something wrong with such a provenance claim. </p>
+
+<p> Although time is critical, we should also recognize that
+provenance can be used in many different contexts within individual
+systems and across the Web. Different systems may use different clocks
+which may not be precisely synchronized, so when provenance records
+are combined by different systems, we may not be able to align the
+times involved to a single global timeline. Hence, PROV-DM is
+designed to minimize assumptions about time. </p>
+
+
+
+<p>Hence, to talk about the constraints on valid PROV-DM data, we
+refer to <a title="instantaneous event">instantaneous events</a> that correspond to interactions
+between activities and entities.
+The term "event" is commonly used in process algebra with a similar meaning. For instance, in CSP [[CSP]], events represent communications or interactions; they are assumed to be atomic and
+instantaneous.</p>
+
+
+
+
+
+<section id="event-ordering">
+<h4>Event Ordering</h4>
+
+
+
+<div class="note">
+ The following paragraphs are unclear and need to be revised, to
+ address review concerns: if
+ we aren't saying anything about how events and time relate, and time
+ is the only concrete information about event ordering in PROV-DM,
+ then how can implementations check that event ordering constraints
+ are satisfied?
+ </div>
+<p> How the <a>precedes</a> partial order is implemented in practice is beyond the scope
+of this specification. This specification only assumes that
+each <a title="instantaneous event">instantaneous event</a> can be mapped to an instant in some form of
+timeline. The actual mapping is not in scope of this
+specification. Likewise, whether this timeline is formed of a single
+global timeline or whether it consists of multiple Lamport-style
+clocks is also beyond this specification. The <a>follows</a> and
+<a>precedes</a> orderings of events should be consistent with the
+ordering of their associated times
+over these timelines.
+</p>
+
+
+<p>This specification defines <i>event ordering constraints</i>
+between <a title="instantaneous event">instantaneous events</a> associated with
+provenance descriptions. PROV-DM data MUST satisfy such constraints. </p>
+
+<p>PROV-DM also allows for time observations to be inserted in
+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
+ title="instantaneous event">instantaneous event</a> to the timeline. It can also
+help with the verification of associated ordering constraints (though,
+again, this verification is outside the scope of this specification).
+</p>
+
+
+
+</section>
+
+<section id="types-of-events">
+<h4>Types of Events</h4>
+<p>Five kinds of <a title="instantaneous event">instantaneous events</a> are used
+for the PROV-DM data model. The <strong>activity start</strong> and
+<strong>activity end</strong> events delimit the beginning and the end
+of activities, respectively. The <strong>entity usage</strong>,
+<strong>entity generation</strong>, and <strong>entity
+invalidation</strong> events apply to entities, and the generation and
+invalidation events delimit the <a title="characterization interval">characterization interval</a> of
+an entity. More specifically:
+
+</p>
+
+<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity starts.</p>
+
+<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity ends.</p>
+
+<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a
+title="instantaneous event">instantaneous event</a> that marks the first instant of
+an entity's consumption timespan by an activity. Before this instant
+the entity had not begun to be used by the activity.</p>
+
+<p>An <dfn id="dfn-generation-event">entity generation event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the final instant of an entity's creation timespan, after which
+it is available for use. The entity did not exist before this event.</p>
+
+<p>An <dfn id="dfn-invalidation-event">entity invalidation event</dfn>
+is the <a title="instantaneous event">instantaneous event</a> that
+marks the initial instant of the destruction, invalidation, or
+cessation of an entity, after which the entity is no longer available
+for use. The entity no longer exists after this event.</p>
+
+</section>
+
+
+</section>
+
+</section>
+
+
+
+
+
+<hr>
+<address></address>
+<!-- hhmts start --> Last modified: Thu Jun 28 23:29:44 CDT 2012 <!-- hhmts end -->
+</body> </html>
--- a/model/prov-constraints.html Thu Jun 28 23:53:15 2012 +0100
+++ b/model/prov-constraints.html Thu Jun 28 23:39:19 2012 -0500
@@ -388,12 +388,10 @@
<em>event ordering</em> constraints that 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. Next,
-notions of <a>equivalence</a> and <a>normalization</a> are defined (<a href="#equivalence"
+notions of <a>validity</a>, <a>equivalence</a> and <a>normalization</a> are defined (<a href="#equivalence"
class="sectionRef"></a>).
In <a
- href="#collection-constraints" class="sectionRef"></a> we consider
-additional constraints specific to collections and in <a
- href="#account-constraints" class="sectionRef"></a> we likewise
+ href="#bundle-constraints" class="sectionRef"></a> we
discuss how constraints interact with bundles. </p>
@@ -420,8 +418,140 @@
applications by ruling out nonsensical or inconsistent information.
</p>
-<p>This document assumes familiarity with [[PROV-DM]].
+<p>This document assumes familiarity with [[PROV-DM]].
</p>
+<section id='rationale' class="informative">
+<h3>Rationale</h3>
+<div class="note"> The following motivating discussion copied from
+ sec. 8 in a prior version; not sure where it fits best.</div>
+
+<p> In this section we give a high-level rationale that provides some
+ further background for the constraints. </p>
+
+<p>
+From a provenance viewpoint, it is important to identify
+a partial state of something, i.e. something with some aspects that
+have been fixed, so that it becomes possible to express its provenance
+(i.e. what caused the thing with these specific aspects).
+</p>
+
+<p>
+An <dfn>entity</dfn> is a thing one wants to provide provenance for
+and whose situation in the world is described by some fixed
+attributes. An entity has a <dfn
+id="dfn-characterization-interval">characterization interval</dfn>,
+or <dfn id="lifetime">lifetime</dfn>,
+defined as the period
+between its <a title="entity generation event">generation event</a>
+and its <a title="entity invalidation event">invalidation event</a>.
+An entity's attributes are established when the entity is
+created and describe the entity's situation and (partial) state
+during an entity's lifetime.</p>
+
+<p>
+A different entity (perhaps representing a different user or
+system perspective) may fix other aspects of the same thing, and its provenance
+may be different. Different entities that are aspects of the same
+thing are called <em>alternate</em>, and the PROV-DM relations of
+specialization and alternate can be used to link such entities.</p>
+
+<p>Besides entities, a variety of other PROV-DM objects have
+attributes, including activity, generation, usage, start, end,
+communication, attribution, association, responsibility, and
+derivation. Each object has an associated duration interval (which may
+be a single time point), and attribute-value pairs for a given object
+are expected to be descriptions that hold for the object's duration.
+</p>
+<p>
+However, the attributes of entities have special meaning because they
+are considered to be fixed aspects
+of underlying, changing things. This motivates constraints on
+<span class="name">alternateOf</span> and <span class="name">specializationOf</span> relating the attribute values of
+different entities.
+</p>
+
+Further considerations:
+<ul>
+<li>In order to describe the provenance of something during an interval over which
+ relevant attributes of the thing are not fixed, it is required to
+ create multiple entities, each with its own identifier, <a
+ title="characterization interval">characterization interval</a>, and
+ fixed attributes, and express
+ dependencies between the various entities using events.
+ For example, if we want to describe the provenance of several
+ versions of a document, involving attributes such as authorship that
+ change over time, we need different entities for the versions linked
+ by appropriate generation, usage, revision, and invalidation events.
+</li>
+
+<li>There is no assumption that the set of attributes is complete, nor
+that the attributes are independent or orthogonal of each other.</li>
+<li>There is no assumption that the attributes of an entity uniquely
+identify it. Two different entities that present the same aspects of
+possibly different things can have the same attributes; this leads to
+ambiguity, which is mitigated through the use of identifiers.</li> </ul>
+
+<p>An activity is delimited by its <a title="activity start event">start</a> and its <a title="activity end event">end</a> events; hence, it occurs over
+an interval delimited by two <a title="instantaneous event">instantaneous
+events</a>. However, an activity record need not mention start or end time information, because they may not be known.
+An activity's attribute-value pairs are expected to describe the activity's situation during its interval, i.e. an interval between two instantaneous events, namely its <a title="activity start event">start</a> event and its <a title="activity end event">end</a> event.
+</p>
+
+
+
+<p>Further considerations:</p>
+<ul>
+<li>An activity is not an entity.
+Indeed, an entity exists in full at
+any point in its lifetime, persists during this
+interval, and preserves the characteristics that makes it
+identifiable. In contrast, an activity is something that occurs, happens,
+unfolds, or develops through time, but is typically not identifiable by
+the characteristics it exhibits at any point during its duration.
+This distinction is similar to the distinction between
+'continuant' and 'occurrent' in logic [[Logic]].</li>
+</ul>
+
+<p> Although time is critical, we should also recognize that
+provenance can be used in many different contexts within individual
+systems and across the Web. Different systems may use different clocks
+which may not be precisely synchronized, so when provenance records
+are combined by different systems, we may not be able to align the
+times involved to a single global timeline. Hence, PROV-DM is
+designed to minimize assumptions about time. </p>
+
+
+<h4>Types of Events</h4>
+<p>Five kinds of <a title="instantaneous event">instantaneous events</a> are used
+for the PROV-DM data model. The <strong>activity start</strong> and
+<strong>activity end</strong> events delimit the beginning and the end
+of activities, respectively. The <strong>entity usage</strong>,
+<strong>entity generation</strong>, and <strong>entity
+invalidation</strong> events apply to entities, and the generation and
+invalidation events delimit the <a title="characterization interval">characterization interval</a> of
+an entity. More specifically:
+
+</p>
+
+<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity starts.</p>
+
+<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity ends.</p>
+
+<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a
+title="instantaneous event">instantaneous event</a> that marks the first instant of
+an entity's consumption timespan by an activity. Before this instant
+the entity had not begun to be used by the activity.</p>
+
+<p>An <dfn id="dfn-generation-event">entity generation event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the final instant of an entity's creation timespan, after which
+it is available for use. The entity did not exist before this event.</p>
+
+<p>An <dfn id="dfn-invalidation-event">entity invalidation event</dfn>
+is the <a title="instantaneous event">instantaneous event</a> that
+marks the initial instant of the destruction, invalidation, or
+cessation of an entity, after which the entity is no longer available
+for use. The entity no longer exists after this event.</p>
+
+</section>
</section>
</section>
@@ -605,7 +735,7 @@
</div>
<p>The relationship <span class="name">wasInformedBy</span> is not
-transitive. Indeed, consider the following statements.</p>
+<a>transitive</a>. Indeed, consider the following statements.</p>
<pre class="codeexample">
wasInformedBy(a2,a1)
wasInformedBy(a3,a2)
@@ -619,19 +749,35 @@
shows a counterexample to transitivity. The
horizontal axis represents the event line. We see that <span class="name">e1</span> was generated after <span class="name">e2</span> was used. Furthermore, the illustration also shows that
<span class="name">a3</span> completes before <span class="name">a1</span>. So it is impossible for <span class="name">a3</span> to have used an entity generated by <span
-class="name">a1</span>.</p>
+class="name">a1</span>. This is illustrated in <a
+href="#wasInformedBy-non-transitive">Figure 1</a>.</p>
<div style="text-align: center;">
<figure>
<img src="images/informedByNonTransitive.png" alt="non transitivity of wasInformedBy" />
-<figcaption id="counterexample-wasInformedBy">Figure 1: Counter-example for transitivity of wasInformedBy</figcaption>
+<figcaption id="counterexample-wasInformedBy"><b>Figure 1:</b> Counter-example for transitivity of wasInformedBy</figcaption>
</figure>
</div>
+<hr />
+<p id="activity-start-end-inference">
+From an activity statement we can infer that there must have existed
+start and end events having times matching the start and end times of
+the activity.
+</p>
+<div class='inference' id='inference'>
<p>
+<span class='conditional'>IF</span> <span
+ class="name">activity(a,t1,t2,attrs)</span> <span
+ class="conditional">THEN</span> <span
+ class="name">wasStartedBy(id;a,-,-,t1)</span> and <span class="name">wasEndedBy(id;a,-,-,t2)</span>.
+</div>
+
<hr>
-
+<div class="note"> The following definitions seem circular;
+ prune?</div>
+
<p id='wasStartedBy-definition_text'>Start of <span class="name">a2</span> by trigger <span class="name">e</span> and starter activity <span
class="name">a1</span> is <a title="definition">defined</a> as follows.</p>
@@ -776,7 +922,8 @@
a1 is associated with all activities a2 is associated with?
</div>
-<hr>
+<!-- DELETE
+ <hr>
<p id='inference-trace_text'>A trace 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>
@@ -818,17 +965,19 @@
allow us to infer anything about the attributes of the related
entities, agents or events.
</p>
+-->
</section>
<section>
-<h3>Component 4: Alternative and Specialized Entities</h3>
-
-<div class="note"> Merge in motivating discussion from sec. 8 here.</div>
+<h3>Component 4: Alternate and Specialized Entities</h3>
+
+
+<hr>
<p>The relation <span class='name'>alternateOf</span> is an equivalence relation: <a>reflexive</a>,
<a>transitive</a> and <a>symmetric</a>.</p>
@@ -853,8 +1002,8 @@
<hr>
-<p id="specialization-irreflexive_text">Similarly, specialization is a strict partial order: it is <a>irreflexive</a>,
- <a>anti-symmetric</a> and
+<p id="specialization-irreflexive_text">Similarly, specialization is a <a>strict</a> partial order: it is <a>irreflexive</a>,
+ <a>antisymmetric</a> and
<a>transitive</a>.</p>
<div class='inference' id="specialization-irreflexive">
@@ -952,7 +1101,7 @@
<section id="constraints">
-<h2>Validity Constraints</h2>
+<h2>Constraints</h2>
@@ -997,13 +1146,8 @@
event</a>, <a>entity usage event</a>, <a>entity invalidation event</a>, <a>activity start event</a>
and <a>activity end event</a>. PROV-DM adopts Lamport's clock
assumptions [[CLOCK]] in the form of a reflexive, transitive partial order <a>precedes</a>
-between <a title="instantaneous event">instantaneous events</a>. Furthermore,
-PROV-DM assumes the existence of a mapping from <a
-title="instantaneous event">instantaneous events</a> to time instants,
-though the actual mapping is not in scope of this specification.</p>
+between <a title="instantaneous event">instantaneous events</a>. </p>
-<div class="note"> Preceding sentence a bit vague</div>
-
<div class="note">
TODO: More about what it means for constraints to be satisfied;
constraint template(s)
@@ -1074,7 +1218,7 @@
<span class='conditional'>THEN</span> <span class="name">id1</span>=<span class="name">id2</span>, <span class="name">a1</span>=<span class="name">a2</span>, <span class="name">t1</span>=<span class="name">t2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.</p>
</div>
<div class="note">
-Fill in invalidation uniqueness.
+Should the id of a generation/invalidation be uniquely determined by entity?
</div>
<p> It follows from the above constraints that the generation and
@@ -1085,9 +1229,45 @@
<p>
-<hr>
-<div class="note">Refactor these as key constraints.</div>
-<p id='unique-startTime_text'>An <a>activity start event</a> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity starts. It allows for an optional time attribute. <span id="optional-start-time">Activities also allow for an optional start time attribute. If both are specified, they MUST be the same, as expressed by the following constraint.</span>
+
+<hr />
+<p id='unique-wasStartedBy_text'>
+The <span class="name">id</span> uniquely determines all of the other parameters to <span class="name">wasStartedBy</span>.
+</p>
+<div class='constraint' id='unique-wasStartedBy'>
+<p>
+<span class='conditional'>IF</span> <span
+ class="name">wasStartedBy(id;a1,e1,a2,t,attrs)</span> and <span
+ class="name">wasStartedBy(id;a1',e',a2',t',attrs')</span>, <span
+ class='conditional'>THEN</span> <span class="name">a1</span>=<span
+ class="name">a1'</span> and <span class="name">e</span>=<span
+ class="name">e'</span> and <span class="name">a2</span>=<span
+ class="name">a2'</span> and <span class="name">t</span>=<span class="name">t'</span>.</p>
+</div>
+
+
+
+
+
+<hr />
+<p id='unique-wasEndedBy_text'>
+The <span class="name">id</span> uniquely determines all of the other parameters to <span class="name">wasEndedBy</span>.
+</p>
+<div class='constraint' id='unique-wasEndedBy'>
+<p>
+<span class='conditional'>IF</span> <span
+ class="name">wasEndedBy(id;a1,e1,a2,t,attrs)</span> and <span
+ class="name">wasEndedBy(id;a1',e',a2',t',attrs')</span>, <span
+ class='conditional'>THEN</span> <span class="name">a1</span>=<span
+ class="name">a1'</span> and <span class="name">e</span>=<span
+ class="name">e'</span> and <span class="name">a2</span>=<span
+ class="name">a2'</span> and <span class="name">t</span>=<span class="name">t'</span>.</p>
+</div>
+
+<div class="note">The unique-startTime and unique-endTime constraints
+ are now redundant, by activity-start-end-inference and unique-wasStartedBy/unique-wasEndedBy.</div>
+
+ <p id='unique-startTime_text'>An <a>activity start event</a> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity starts. It allows for an optional time attribute. <span id="optional-start-time">Activities also allow for an optional start time attribute. If both are specified, they MUST be the same, as expressed by the following constraint.</span>
</p>
<div class='constraint' id='unique-startTime'>
@@ -1095,8 +1275,6 @@
<span class='conditional'>IF</span> <span class="name">activity(a,t1,t2)</span> and <span class="name">wasStartedBy(id;a,-,-,t)</span>, <span class='conditional'>THEN</span> <span class="name">t</span>=<span class="name">t1</span>.</p>
</div>
-<p>
-
<hr>
<p id='unique-endTime_text'>An <a>activity end event</a> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity ends. It allows for an optional time attribute. <span id="optional-end-time">Activities also allow for an optional end time attribute. If both are specified, they MUST be the same, as expressed by the following constraint.</span>
@@ -1110,7 +1288,6 @@
class='conditional'>THEN</span> <span class="name">t</span> = <span class="name">t2</span>.</p>
</div>
-
<p>
@@ -1147,33 +1324,25 @@
For symmetry, <dfn id="dfn-follows">follows</dfn> is defined as the
inverse of <a title="precedes">precedes</a>; that is, when we say
<span class="name">e1</span> follows <span class="name">e2</span>,
-this means that either the two events are equal or <span
+this means that <span
class="name">e1</span> happened after <span
-class="name">e2</span>. Both relations are strict partial orders, meaning
-that they are irreflexive, transitive, and antisymmetric.</p>
+class="name">e2</span>. Both relations are <a>strict</a> partial orders, meaning
+that they are <a>irreflexive</a>, <a>transitive</a>, and <a>antisymmetric</a>.</p>
-<div class="note"> Do we want to allow an event to
- "precede" itself? Perhaps precedes should be strict.
-</div>
-
-<div class="note">
- The following discussion is unclear: what is being said here, and
- why? Proposal: The times should ideally be consistent with event
- ordering, but doign so requires knowing how they map onto timelines,
- which we don't specify.
- </div>
<p>PROV-DM also allows for time observations to be inserted in
-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 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
-verification is outside the scope of this specification.
-</p>
+specific provenance statements, for each of the five kinds of <a
+ title="instantaneous event">instantaneous events</a> introduced in
+this specification. Times in provenance records arising from
+different sources might be with respect to different timelines
+(e.g. different time zones) leading to apparent inconsistencies. For
+the purpose of checking ordering constraints, the times associated
+with events is irrelevant; thus, there is no inference time ordering
+implies event ordering. However, an application MAY flag time values
+that appear inconsistent with the event ordering as possible
+inconsistencies. When generating provenance, an application SHOULD
+use a consistent timeline for related PROV statements within an
+instance.</p>
@@ -1204,7 +1373,7 @@
start and endpoints of its lifetime.
</p>
-<p><a href="#ordering-activity">Figure 2</a>> summarizes the ordering
+<p><a href="#ordering-activity">Figure 2</a> summarizes the ordering
constraints on activities in a
graphical manner. For this and subsequent figures, an event time line points to the
right. Activities are represented by rectangles, whereas entities are
@@ -1232,9 +1401,9 @@
<div style="text-align: center;">
-<figure>
+<figure id="ordering-activity">
<img src="images/ordering-activity.png" alt="constraints between events" />
-<figcaption id="ordering-activity-fig">Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints for activities</figcaption>
+<figcaption id="ordering-activity-fig"><b>Figure 2:</b> Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints for activities</figcaption>
</figure>
</div>
@@ -1245,7 +1414,7 @@
The existence of an activity implies that the <a>activity start
event</a> always <a>precedes</a> the corresponding <a>activity end
event</a>. This is illustrated by
-Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a>
+<a href="#ordering-activity">Figure 2</a>
(a) and expressed by <a class="rule-ref"
href="#start-precedes-end"><span>TBD</span></a>.</p>
@@ -1265,7 +1434,7 @@
<hr />
<p id='usage-within-activity_text'>A usage implies ordering of <a title="instantaneous event">events</a>, since the <a title="entity usage event">usage event</a> had to occur during the associated activity. This is
-illustrated by Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a> (b) and expressed by <a class="rule-ref" href="#usage-within-activity"><span>TBD</span></a>.</p>
+illustrated by <a href="#ordering-activity">Figure 2</a> (b) and expressed by <a class="rule-ref" href="#usage-within-activity"><span>TBD</span></a>.</p>
<div class='constraint' id='usage-within-activity'>
<ol>
@@ -1298,7 +1467,7 @@
<p id='generation-within-activity_text'>A generation implies ordering of <a title="instantaneous event">events</a>, since the <a title="entity generation event">generation event</a> had to occur during the associated activity. This is
-illustrated by Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a> (c) and expressed by <a class="rule-ref" href="#generation-within-activity"><span>TBD</span></a>.</p>
+illustrated by <a href="#ordering-activity">Figure 2</a> (c) and expressed by <a class="rule-ref" href="#generation-within-activity"><span>TBD</span></a>.</p>
<div class='constraint' id='generation-within-activity'>
<ol>
@@ -1337,17 +1506,20 @@
implies that the start event of <span class="name">a1</span> cannot
follow the end event of <span class="name">a2</span>. This is
illustrated by
-Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a>
+<a href="#ordering-activity">Figure 2</a>
(d) and expressed by <a class="rule-ref"
href="#wasInformedBy-ordering"><span>TBD</span></a>.</p>
+<div class="note">The following template illustrates the convention:
+ any variable that appears only once in a constraint should start
+ with _. TODO: Adopt this for other constraints.</div>
<div class='constraint' id='wasInformedBy-ordering'>
<span class="conditional">IF</span>
-<span class="name">wasInformedBy(-;a2,a1)</span>
+<span class="name">wasInformedBy(_id;a2,a1,_attrs)</span>
and
-<span class="name">wasStartedBy(start;a1,-,-,-)</span>
+<span class="name">wasStartedBy(start;a1,_e1,_a1',_attrs1)</span>
and
-<span class="name">wasEndedBy(end;a2,-,-,-)</span>
+<span class="name">wasEndedBy(end;a2,_e2,_a2',_attrs2)</span>
<span class="conditional">THEN</span>
<span class="name">start</span>
<a>precedes</a>
@@ -1356,6 +1528,7 @@
</div>
<p>
+<!-- OLD; delete
<hr />
<p id='wasStartedByActivity-ordering_text'>Start
@@ -1364,7 +1537,7 @@
of <a title="instantaneous event">events</a>,
since <span class="name">a1</span> must have been active
before <span class="name">a2</span> started. This is illustrated by
-Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a>
+<a href="#ordering-activity">Figure 2</a>
(e) and expressed by <a class="rule-ref"
href="#wasStartedByActivity-ordering"><span>TBD</span></a>.</p>
@@ -1379,25 +1552,30 @@
<a>precedes</a>
<span class="name">start2</span>.
</div>
+-->
</section>
<section>
<h3> Entity constraints</h3>
+
+<div class="note">The figure(s) in this section should have vertical lines with visual styles that match the diagonal arrow that they go with. </div>
+
<p>
As with activities, entities have lifetimes: they are generated, then
can be used, revised, or other entities can be derived from them, and
-finally are invalidated.
+finally they may be invalidated. The constraints on these events are
+illustrated graphically in <a href="#ordering-entity">Figure 3</a> and
+<a href="#ordering-trigger">Figure 4</a>.
</p>
<div style="text-align: center;">
-<figure>
-<figcaption id="ordering-entity-fig">Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints for entities</figcaption>
+<figure id="ordering-entity">
<img src="images/ordering-entity.png" alt="ordering constraints for entities" />
-</figure>
+<figcaption id="ordering-entity-fig"><b>Figure 3:</b> Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints for entities</figcaption></figure>
</div>
<p>
@@ -1430,10 +1608,10 @@
<p id='generation-precedes-usage_text'>
A usage and a generation for a given entity implies ordering of <a title="instantaneous event">events</a>, since the <a title="entity generation
event">generation event</a> had to precede the <a title="entity usage event">usage event</a>. This is
-illustrated by Subfigure <a href="#ordering-entity-fig">ordering-entity-fig</a> (a) and expressed by <a class="rule-ref" href="#generation-precedes-usage"><span>TBD</span></a>.</p>
+illustrated by <a href="#ordering-entity">Figure 3</a>(a) and expressed by <a class="rule-ref" href="#generation-precedes-usage"><span>TBD</span></a>.</p>
<div class='constraint' id='generation-precedes-usage'>
- <span class="conditional">IF</span>
+<p> <span class="conditional">IF</span>
<span class="name">wasGeneratedBy(gen;e,-,-)</span>
and
<span class="name">used(use;-,e,-)</span>
@@ -1441,6 +1619,7 @@
<span class="name">gen</span>
<a>precedes</a>
<span class="name">use</span>.
+</p>
</div>
<p>
@@ -1467,14 +1646,17 @@
-
+<div class="note">
+ Can ordering constraints be factored into "influence implies
+ precedes" and "everything implies influence"?
+ </div>
<p id='derivation-usage-generation-ordering_text'>If there is a derivation between <span class="name">e2</span> and <span class="name">e1</span>, then
-this means that the entity <span class="name">e1</span> had some form of influence on the entity <span class="name">e2</span>; for this to be possible, some event ordering must be satisfied.
+this means that the entity <span class="name">e1</span> had some influence on the entity <span class="name">e2</span>; for this to be possible, some event ordering must be satisfied.
First, we consider derivations, where the activity and usage are known. In that case, the <a title="entity usage event">usage</a> of <span class="name">e1</span> has to precede the <a title="entity generation
event">generation</a> of <span class="name">e2</span>.
This is
-illustrated by Subfigure <a href="#ordering-entity-fig">ordering-entity-fig</a> (b) and expressed by <a
+illustrated by <a href="#ordering-entity-fig">Figure 3</a> (b) and expressed by <a
class="rule-ref" href="#derivation-usage-generation-ordering"><span>TBD</span></a>.</p>
@@ -1494,7 +1676,7 @@
<p id='derivation-generation-generation-ordering_text'>
When the usage is unknown, a similar constraint exists, except that the constraint refers to its
generation event, as
-illustrated by Subfigure <a href="#ordering-entity-fig">ordering-entity-fig</a> (c) and expressed by <a
+illustrated by <a href="#ordering-entity-fig">Figure 3</a> (c) and expressed by <a
class="rule-ref" href="#derivation-generation-generation-ordering"><span>TBD</span></a>.</p>
<div class='constraint'
@@ -1523,7 +1705,7 @@
<p id='wasStartedBy-ordering_text'>
The entity that triggered the start of an activity must exist before the activity starts.
This is
-illustrated by Subfigure <a href="#ordering-entity-trigger-fig">ordering-entity-trigger-fig</a> (a) and expressed by <a class="rule-ref" href="#wasStartedBy-ordering"><span>TBD</span></a>.</p>
+illustrated by <a href="#ordering-entity-trigger">Figure 4</a>(a) and expressed by <a class="rule-ref" href="#wasStartedBy-ordering"><span>TBD</span></a>.</p>
<div class='constraint' id='wasStartedBy-ordering'>
@@ -1555,8 +1737,7 @@
<p id='wasEndedBy-ordering_text'> Similarly, the entity that triggered
the end of an activity must exist before the activity ends, as
illustrated by
-Subfigure <a href="#ordering-entity-trigger-fig">ordering-entity-trigger-fig</a>
-(b).</p>
+<a href="#ordering-entity-trigger">Figure 4</a>(b).</p>
<div class='constraint' id='wasEndedBy-ordering'>
@@ -1584,9 +1765,9 @@
</div>
<div style="text-align: center;">
-<figure>
-<figcaption id="ordering-entity-trigger-fig">Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints for trigger entities</figcaption>
+<figure id="#ordering-entity-trigger">
<img src="images/ordering-entity-trigger.png" alt="ordering constraints for trigger entities" />
+<figcaption id="ordering-entity-trigger-fig"><b>Figure 4:</b> Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints for trigger entities</figcaption>
</figure>
</div>
@@ -1602,12 +1783,14 @@
interactions such as starting, ending or association with an
activity, attribution, or delegation, and finally the agent is invalidated.
</p>
-<p>Further constraints associated with agents appear in Figure <a href="#ordering-agents">ordering-agents</a> and are discussed below.</p>
+<p>Further constraints associated with agents appear in <a href="#ordering-agents">Figure 5</a> and are discussed below.</p>
<div style="text-align: center;">
-<figure>
-<figcaption id="ordering-agents">Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints (continued)</figcaption>
+<figure id="ordering-agents">
<img src="images/ordering-agents.png" alt="ordering constraints for agents" />
+<figcaption><b>Figure 5:</b> Summary of <a
+ title="instantaneous event">instantaneous event</a> ordering
+ constraints for agents</figcaption>
</figure>
</div>
@@ -1616,7 +1799,7 @@
<p id='wasAssociatedWith-ordering_text'>An activity that was associated with an agent must have some overlap with the agent. The agent may be generated, or may only become associated with the activity, after the activity start: so, the agent is required to exist before the activity end. Likewise, the agent may be destructed, or may terminate its association with the activity, before the activity end: hence, the agent invalidation is required to happen after the activity start.
This is
-illustrated by Subfigure <a href="#ordering-agents">ordering-agents</a> (a) and expressed by <a class="rule-ref" href="#wasAssociatedWith-ordering"><span>TBD</span></a>.</p>
+illustrated by <a href="#ordering-agents">Figure 5</a> (a) and expressed by <a class="rule-ref" href="#wasAssociatedWith-ordering"><span>TBD</span></a>.</p>
<div class='constraint' id='wasAssociatedWith-ordering'>
@@ -1655,7 +1838,7 @@
with the agent. The agent is required to exist before the entity
invalidation. Likewise, the entity generation must precede the agent destruction.
This is
-illustrated by Subfigure <a href="#ordering-agents">ordering-agents</a> (b) and expressed by <a class="rule-ref" href="#wasAttributedTo-ordering"><span/></a>.</p>
+illustrated by <a href="#ordering-agents">Figure 5</a> (b) and expressed by <a class="rule-ref" href="#wasAttributedTo-ordering"><span/></a>.</p>
@@ -1834,649 +2017,25 @@
</section> <!-- equivalence -->
-<section id="dictionary-constraints">
-<h2>Dictionary Constraints</h2>
-<div class="note">
- Work on dictionaries and on these constraints is deferred until after
- the next working draft, so this section may not be stable.
- </div>
-
-<hr>
-
-<p id='membership-as-insertion_text'>Membership is a convenience notation, since it can be expressed in terms of an insertion into some dictionary. The membership definition is formalized by <a class="rule-ref" href="#membership-as-insertion"><span/></a>.</p>
-
-<div class='definition' id='membership-as-insertion'>
-<p>
- <span class="name">memberOf(d, {(k1, v1), ...})</span> holds
-<span class='conditional'>IF AND ONLY IF</span> there exists a dictionary <span class="name">d0</span>, such that
-<span class="name">derivedByInsertionFrom(d, d0, {(k1, v1), ...})</span>.</p>
-</div>
-
-<p>
-
-<hr>
-
-<p id='dictionary-unique-derivation_text'>A dictionary may be obtained by insertion or removal, or said to satisfy the membership relation.
-To provide an interpretation of dictionaries, PROV-DM
- restricts one dictionary to be involved in a single derivation by insertion or removal, or to one membership relation.
-PROV-DM does not provide an interpretation for statements that consist of two (or more) insertion, removal, membership relations that result in the same dictionary.</p>
-
-
-
-<p>The following constraint ensures unique derivation.</p>
-
-
-<div class='note'> The following constraint is unclear.</div>
-<div class='constraint' id='dictionary-unique-derivation'>
-<p>A dictionary MUST NOT be derived through multiple insertions, removal,
- or membership relations. </p>
-</div>
-<div class="anexample">
-Consider the following statements about three dictionaries.
- <pre class="codeexample">
-entity(d1, [prov:type='prov:Dictionary'])
-entity(d2, [prov:type='prov:Dictionary'])
-entity(d3, [prov:type='prov:Dictionary'])
-
-
-derivedByInsertionFrom(d3, d1, {("k1", e1), ("k2", e2)})
-derivedByInsertionFrom(d3, d2, {("k3", e3)})
-</pre>
-<p>There is no interpretation for such statements since <span class="name">d3</span> is derived multiple times by insertion.</p>
-</div>
-
+<section id="bundle-constraints">
+<h2>Bundles and Constraints</h2>
-<div class="anexample">
-<p>As a particular case, dictionary <span class="name">d</span> is derived multiple times from the same <span class="name">d1</span>. </p>
-<pre class="codeexample">
-derivedByInsertionFrom(id1, d, d1, {("k1", e1), ("k2", e2)})
-derivedByInsertionFrom(id2, d, d1, {("k3", e3), ("k4", e4)})
-</pre>
-<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, d, d1, {("k1", e1), ("k2", e2), ("k3", e3), ("k4", e4)})
-</pre>
-</div>
-
-The same is true for any combination of insertions, removals, and membership relations:
-<div class="anexample">
-<p>The following statements</p>
-<pre class="codeexample">
-derivedByInsertionFrom(d, d1, {("k1", e1)})
-derivedByRemovalFrom(d, d2, {"k2"})
-</pre>
-have no interpretation.
-Nor have the following:
-<pre class="codeexample">
-derivedByInsertionFrom(d, d1, {("k1", e1)})
-memberOf(d, {"k2",e2})
-</pre>
+<div class="note">
+TODO: Summarize how bundles interact with constraints.
+ Briefly, idea is: check each bundle independently, using the same
+ rules as for top-level statements. A whole PROV instance containing
+ several bundles is valid if each bundle is valid (including the "top
+ level").
</div>
-
-<section id="dictionary-branching">
-<h4>Dictionary branching</h4>
-
-It is allowed to have multiple derivations from a single root dictionary, as long as the resulting entities are distinct, as shown in the following example.
-
-<div class="anexample">
-<pre class="codeexample">
-entity(d0, [prov:type='prov:EmptyDictionary']) // d0 is an empty dictionary
-entity(d1, [prov:type='prov:Dictionary'])
-entity(d2, [prov:type='prov:Dictionary'])
-entity(d3, [prov:type='prov:Dictionary'])
-entity(e1)
-entity(e2)
-entity(e3)
-
-derivedByInsertionFrom(d1, d0, {("k1", e1)})
-derivedByInsertionFrom(d2, d0, {("k2", e2)})
-derivedByInsertionFrom(d3, d1, {("k3", e3)})
-</pre>
-From this set of statements, we conclude:
-<pre class="codeexample">
- d1 = { ("k1", e1) }
- d2 = { ("k2", e2) }
- d3 = { ("k1", e1), ("k3", e3)}
-</pre>
-</div>
-
-</section>
-
-
-
-<section id="dictionaries-and-derivation">
-
-
-<h4>Dictionaries and Weaker Derivation Relation</h4>
-
-<p>The state of a dictionary is only known to the extent that a chain
-of derivations starting from an empty dictionary can be found. Since a
-set of statements regarding a dictionary'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 dictionary evolution, in which some of the state changes may have been missed, the more generic derivation 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>
-
-
-
- <div class="anexample">
-In the example, the state of <span class="name">d2</span> is only partially known because the dictionary is constructed from partially known other dictionaries.
- <pre class="codeexample">
-entity(d0, [prov:type='prov:EmptyDictionary']) // d0 is an empty dictionary
-entity(d1, [prov:type='prov:Dictionary'])
-entity(d2, [prov:type='prov:Dictionary'])
-entity(d3, [prov:type='prov:Dictionary'])
-entity(e1)
-entity(e2)
-
-derivedByInsertionFrom(d1, d0, {("k1", e1)})
-wasDerivedFrom(d2, d1)
-derivedByInsertionFrom(d3, d2, {("k2", e2)})
- </pre>
-From this set of statements, we conclude:
-<ul>
-<li> <span class="name">d1 = { ("k1", e1) }</span>
-<li> <span class="name">d2</span> is somehow derived from <span class="name">d1</span>, but the precise sequence of updates is unknown
-<li> <span class="name">d3</span> includes <span class="name">("k2", e2)</span> but the earlier "gap" leaves uncertainty regarding <span class="name">("k1", e1)</span> (it may have been removed) or any other pair that may have been added as part of the derivation activities.
-</ul>
- </div>
-
-</section>
-
-
-<div class='note'>
- Do the insertion/removal derivation steps imply wasDerivedFrom,
- wasVersionOf, alternateOf?
- </div>
-
-
-<section id="dictionaries-and-contents">
-
-
-<h4>Dictionaries and Contents</h4>
-
-<div class="note">
-Axiomatisation of dictionaries to be expressed here. See <a href="./working-copy/wd6-collections-constraints.html">here</a>.
-</div>
-</section>
-
-</section> <!-- dictionary-constraints -->
-
-<section id="account-constraints">
-<h2>Account Constraints</h2>
-
-<div class="note">
-This section does not talk about accounts.
-</div>
-
-<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 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' ])
-</pre>
-The second version of a document edited by some authors:
-<pre class="codeexample">
-entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
-</pre>
-<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 statements about the same entity cannot co-exist in a PROV instance
- as formalized in <a class="rule-text" href="#unique-entity"><span>unique-entity</span></a>.</p>
-
-<!-- Moved to uniqueness constraints section
-<div class='constraint' id='unique-entity'>
-<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>
-</div>
--->
-
-
-
-<p>In some cases, there may be a requirement for two different
- statements concerning the same entity to be included in the same provenance instance. To satisfy the constraint <a class="rule-text" href="#unique-entity"><span>unique-entity</span></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 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' ])
-entity(ex:alternate-20111215, [ prov:type="document", ex:version="2" ])
-alternateOf(tr:WD-prov-dm-20111215,ex:alternate-20111215)
-</pre>
-</div>
-
-
-<div class='note'>
- Since we are not specifying ways to take the union of two accounts,
- we may drop this discussion
- </div>
-<p> Taking the union of two accounts is another account,
-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 statements with the same identifier but different sets of attributes exist in each original PROV instance may invalidate <a class="rule-text" href="#unique-entity"><span>unique-entity</span></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
-constraint <a class="rule-text" href="#unique-generation"><span>TBD</span></a> may no
-longer be satisfied in the resulting union. </li>
-</ul>
-<p>How to reconcile such accounts is beyond the scope of this specification.</p>
-
-
-<div class="note">
- Material transplanted from old structural well-formedness constraints section.
-
- This example isn't very clear, since the sub-workflow-ness isn't
- represented in the data. According to what was written above, we
- should conclude that a0 and a2 are equal!
- </div>
-<div class="anexample">
-<p>
-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"])
-activity(a1, [prov:type="workflow execution"])
-activity(a2, [prov:type="workflow execution"])
-wasInformedBy(a2,a1)
-
-wasGeneratedBy(e,a0)
-wasGeneratedBy(e,a2)
-</pre>
-<p>So, we have two different <a title="generation">generations</a> for entity <span class="name">e</span>. Such an example is permitted in PROV-DM if the two activities denoted by <span class="name">a0</span> and <span class="name">a2</span> are a single thing happening in the world
-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 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 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>
-
-
-<div class="anexample">
-<p>
-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>
-<pre class="codeexample">
-activity(a0,t1,t2,[prov:type="workflow execution"])
-wasGeneratedBy(e,a0,-)
-</pre>
-<p>In a second account, entitled "detail", we find:</p>
-<pre class="codeexample">
-activity(a1,t1,t3,[prov:type="workflow execution"])
-activity(a2,t3,t2,[prov:type="workflow execution"])
-wasInformedBy(a2,a1)
-wasGeneratedBy(e,a2,-)
-</pre>
-</div>
-
-
-
-<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>
-
-
-
-
-</section> <!-- account-constraints-->
-
-
-
+</section> <!-- bundle-constraints-->
- <section id='rationale' class="informative">
-<h2>Rationale for inferences and constraints</h2>
-
-<div class="note"> This section collects all of the explanatory
- material that I was not certain how to interpret as an unambiguous
- inference or constraint. Some of these observations may need to be folded
- into the explanatory text in respective sections (for example for
- events,
- accounts or collections).
-
- Editing is also needed to decrease redundancy.
- </div>
-
- <section id='section-attributes'>
-<h4>Entities and Attributes</h4>
-
-<p>When we talk about things in the world in natural language and even when we assign identifiers, we are often imprecise in ways that make it difficult to clearly and unambiguously report
-provenance: a resource with a URL may be understood as referring to a report available at that URL, the version of the report available there today, the report independent of where it is
-hosted over time, etc.
-However, to write precise descriptions of the provenance of things
-that change over time, we need ways of disambiguating which versions
-of things we are talking about.
-</p>
-
-<p>
-To describe the provenance of things that can change over
-time, PROV-DM uses the concept of <i>entities</i> with fixed
-attributes. From a provenance viewpoint, it is important to identify
-a partial state of something, i.e. something with some aspects that
-have been fixed, so that it becomes possible to express its provenance
-(i.e. what caused the thing with these specific aspects). An entity
-encompasses a part of a thing's history during which some of the
-attributes are fixed. An entity can thus be thought of as a part of a
-thing with some associated partial state.
-Attributes in PROV-DM are used to fix certain aspects of entities.</p>
-
-
-<p>
-An <dfn>entity</dfn> is a thing one wants to provide provenance for
-and whose situation in the world is described by some fixed
-attributes. An entity has a <dfn
-id="dfn-characterization-interval">characterization interval</dfn>,
-or <dfn id="lifetime">lifetime</dfn>,
-defined as the period
-between its <a title="entity generation event">generation event</a>
-and its <a title="entity invalidation event">invalidation event</a>.
-An entity's attributes are established when the entity is
-created and describe the entity's situation and (partial) state
-during an entity's lifetime.</p>
-
-<p>
-A different entity (perhaps representing a different user or
-system perspective) may fix other aspects of the same thing, and its provenance
-may be different. Different entities that are aspects of the same
-thing are called <em>alternate</em>, and the PROV-DM relations of
-specialization and alternate can be used to link such entities.</p>
-
-
-
-
-
-
-<div class="anexample" id="a-report-example">
-Different users may take different perspectives on a resource with
-a URL. A provenance record might use one (or more) different
- entities to talk about different perspectives, such as:
-<ul>
-<li>a report available at a URL: fixes the nature of the thing, i.e. a document, and its location; </li>
-<li>the version of the report available there today: fixes its version number, contents, and its date;</li>
-<li>the report independent of where it is hosted and of its content over time: fixes the nature of the thing as a conceptual artifact.</li></ul>
-The provenance of these three entities may differ, and may be along the following lines:
-<ul>
-<li>the provenance of a report available at a URL may include: the act of publishing it and making it available at a given location, possibly under some license and access control;</li>
-<li>the provenance of the version of the report available there today may include: the authorship of the specific content, and reference to imported content;</li>
-<li>the provenance of the report independent of where it is hosted over time may include: the motivation for writing the report, the overall methodology for producing it, and the broad team
-involved in it.</li>
-</ul>
-<p>We do not assume that any entity is a better or worse description of
-reality than any other. That is, we do not assume an absolute ground truth with
-respect to which we can judge correctness or completeness of
-descriptions. In fact, it is possible to describe the processing that occurred for the report to be commissioned, for
-individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity with attribute-value pairs that fix some aspects of the report appropriately.</p>
-</div>
-
-
-<p>Besides entities, a variety of other PROV-DM objects have
-attributes, including activity, generation, usage, start, end,
-communication, attribution, association, responsibility, and
-derivation. Each object has an associated duration interval (which may
-be a single time point), and attribute-value pairs for a given object
-are expected to be descriptions that hold for the object's duration.
-</p>
-<p>
-However, the attributes of entities have special meaning because they
-are considered to be fixed aspects
-of underlying, changing things. This motivates constraints on
-<span class="name">alternateOf</span> and <span class="name">specializationOf</span> relating the attribute values of
-different entities.
-</p>
-<div class="note">
- TODO:
-Constraints on alternateOf/specializationOf for this?
- </div>
-
- <div class="note">
-TODO: Further discussion of entities moved from the old "Definitional
- constraints" section. Should merge with the surrounding
- discussion to avoid repetition.
- </div>
-<p>
-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 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 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>
-
-
-
-Further considerations:
-<ul>
-<li>In order to describe the provenance of something during an interval over which
- relevant attributes of the thing are not fixed, it is required to
- create multiple entities, each with its own identifier, <a
- title="characterization interval">characterization interval</a>, and
- fixed attributes, and express
- dependencies between the various entities using events.
- For example, if we want to describe the provenance of several
- versions of a document, involving attributes such as authorship that
- change over time, we need different entities for the versions linked
- by appropriate generation, usage, revision, and invalidation events.
-</li>
-
-<li>There is no assumption that the set of attributes is complete, nor
-that the attributes are independent or orthogonal of each other.</li>
-<li>There is no assumption that the attributes of an entity uniquely
-identify it. Two different entities that are aspects of different
-things can have the same attributes.</li>
-<li>A <a title="characterization interval">characterization interval</a> may collapse into a single instant.</li>
-</ul>
-
-</section>
-
-<section>
-<h3>Activities</h3>
-
-<div class="note">
- TODO: Further discussion of activities moved from old "Definitional
- constraints and inferences" section. Edit to avoid repeating information.
-</div>
-
-
-<p>An activity is delimited by its <a title="activity start event">start</a> and its <a title="activity end event">end</a> events; hence, it occurs over
-an interval delimited by two <a title="instantaneous event">instantaneous
-events</a>. However, an activity record need not mention start or end time information, because they may not be known.
-An activity's attribute-value pairs are expected to describe the activity's situation during its interval, i.e. an interval between two instantaneous events, namely its <a title="activity start event">start</a> event and its <a title="activity end event">end</a> event.
-</p>
-
-
-<p>Further considerations:</p>
-<ul>
-<li>An activity is not an entity.
-Indeed, an entity exists in full at
-any point in its lifetime, persists during this
-interval, and preserves the characteristics that makes it
-identifiable. In contrast, an activity is something that occurs, happens,
-unfolds, or develops through time, but is typically not identifiable by
-the characteristics it exhibits at any point during its duration.
-This distinction is similar to the distinction between
-'continuant' and 'occurrent' in logic [[Logic]].</li>
-</ul>
-
-
-
-</section>
-
-
- <section id="representation-term-assertion-inference">
-<h3>Description, Assertion, and Inference</h3>
-
-<p>
-PROV-DM is a provenance data model designed to express <em>descriptions</em> of the world.
-</p>
-
-<div class="anexample">
-A file at some point during its lifecycle, which includes multiple edits by multiple people, can be described by its type, its location in the file system, a creator, and content.
-</div>
-
-
-<p>The data model is designed to capture activities that happened in the past, as opposed to activities
-that may or will happen.
-However, this distinction is not formally enforced.
-Therefore, PROV-DM descriptions are intended to be interpreted as what
-has happened, as opposed to what may or will happen.</p>
-
-
-
-<p>
-This specification does not prescribe the means by which descriptions can be arrived at; for example, descriptions can be composed on the basis of observations, reasoning, or any other means.
-</p>
-
-
-<p>
-Sometimes, inferences about the world can be made from descriptions
-conformant to the PROV-DM data model. This
-specification defines some such inferences, allowing new descriptions
-to be inferred from existing ones. Hence, descriptions of the world
-can result either from direct assertion or from inference
-by application of inference rules defined by this specification.
-</p>
-
-
-</section>
-
-
-
-
-
- <section id='section-event-time'>
-<h4>Events and Time</h4>
-
-
-
-
-<p>Time is critical in the context of provenance, since it can help corroborate provenance claims. For instance, if an entity is claimed to be obtained by transforming another, then the
-latter must have existed before the former. If it is not the case, then there is something wrong with such a provenance claim. </p>
-
-<p> Although time is critical, we should also recognize that
-provenance can be used in many different contexts within individual
-systems and across the Web. Different systems may use different clocks
-which may not be precisely synchronized, so when provenance records
-are combined by different systems, we may not be able to align the
-times involved to a single global timeline. Hence, PROV-DM is
-designed to minimize assumptions about time. </p>
-
-
-
-<p>Hence, to talk about the constraints on valid PROV-DM data, we
-refer to <a title="instantaneous event">instantaneous events</a> that correspond to interactions
-between activities and entities.
-The term "event" is commonly used in process algebra with a similar meaning. For instance, in CSP [[CSP]], events represent communications or interactions; they are assumed to be atomic and
-instantaneous.</p>
-
-
-
-
-
-<section id="event-ordering">
-<h4>Event Ordering</h4>
-
-
-
-<div class="note">
- The following paragraphs are unclear and need to be revised, to
- address review concerns: if
- we aren't saying anything about how events and time relate, and time
- is the only concrete information about event ordering in PROV-DM,
- then how can implementations check that event ordering constraints
- are satisfied?
- </div>
-<p> How the <a>precedes</a> partial order is implemented in practice is beyond the scope
-of this specification. This specification only assumes that
-each <a title="instantaneous event">instantaneous event</a> can be mapped to an instant in some form of
-timeline. The actual mapping is not in scope of this
-specification. Likewise, whether this timeline is formed of a single
-global timeline or whether it consists of multiple Lamport-style
-clocks is also beyond this specification. The <a>follows</a> and
-<a>precedes</a> orderings of events should be consistent with the
-ordering of their associated times
-over these timelines.
-</p>
-
-
-<p>This specification defines <i>event ordering constraints</i>
-between <a title="instantaneous event">instantaneous events</a> associated with
-provenance descriptions. PROV-DM data MUST satisfy such constraints. </p>
-
-<p>PROV-DM also allows for time observations to be inserted in
-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
- title="instantaneous event">instantaneous event</a> to the timeline. It can also
-help with the verification of associated ordering constraints (though,
-again, this verification is outside the scope of this specification).
-</p>
-
-
-
-</section>
-
-<section id="types-of-events">
-<h4>Types of Events</h4>
-<p>Five kinds of <a title="instantaneous event">instantaneous events</a> are used
-for the PROV-DM data model. The <strong>activity start</strong> and
-<strong>activity end</strong> events delimit the beginning and the end
-of activities, respectively. The <strong>entity usage</strong>,
-<strong>entity generation</strong>, and <strong>entity
-invalidation</strong> events apply to entities, and the generation and
-invalidation events delimit the <a title="characterization interval">characterization interval</a> of
-an entity. More specifically:
-
-</p>
-
-<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity starts.</p>
-
-<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity ends.</p>
-
-<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a
-title="instantaneous event">instantaneous event</a> that marks the first instant of
-an entity's consumption timespan by an activity. Before this instant
-the entity had not begun to be used by the activity.</p>
-
-<p>An <dfn id="dfn-generation-event">entity generation event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the final instant of an entity's creation timespan, after which
-it is available for use. The entity did not exist before this event.</p>
-
-<p>An <dfn id="dfn-invalidation-event">entity invalidation event</dfn>
-is the <a title="instantaneous event">instantaneous event</a> that
-marks the initial instant of the destruction, invalidation, or
-cessation of an entity, after which the entity is no longer available
-for use. The entity no longer exists after this event.</p>
-
-</section>
-
-
-</section>
-
-</section>
@@ -2494,14 +2053,18 @@
<section class="glossary">
<h2>Glossary</h2>
<ul>
- <li> <dfn>anti-symmetric</dfn>: A relation R over X is <a>anti-symmetric</a> if
+ <li> <dfn>antisymmetric</dfn>: A relation R over X is <a>antisymmetric</a> if
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
+ Alternatively, for a <a>strict</a> partial order anti-symmetry
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>strict</dfn>: Partial orders are often defined in one
+ of two standard forms: a weak form, like ≤, which is <a>reflexive</a>, and a <a>strict</a> form, like < that
+ is <a>irreflexive</a>. The meanings of certain terms, such as
+ <a>antisymmetric</a>, differe slightly depending on strictness.
<li> <dfn>symmetric</dfn>: A relation R over X is <a>symmetric</a> if
for any elements x, y of X, if x R y then y R x.</li>
<li> <dfn>transitive</dfn>: A relation R over X is <a>transitive</a> if