--- a/model/ProvenanceModel.html Thu Jan 19 09:50:06 2012 +0000
+++ b/model/ProvenanceModel.html Thu Jan 19 09:53:35 2012 +0000
@@ -172,7 +172,9 @@
<section id="sotd">
<section id="prov-family">
<!-- <h3>Prov Family of Specifications</h3>-->
-This document is part of the PROV family of specifications, a set of specifications aiming to define the various aspects that are necessary to achieve the vision of inter-operable interchange of provenance information in heterogeneous environments such as the Web. This document defines the PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption.Four other documents are:
+This document is part of the PROV family of specifications, a set of specifications aiming to define the various aspects that are necessary to achieve the vision of inter-operable
+interchange of provenance information in heterogeneous environments such as the Web. This document defines the PROV-DM data model for provenance, accompanied with a notation to express
+instances of that data model for human consumption.Four other documents are:
<ul>
<li> PROV-O, the provenance ontology: by means of a mapping of PROV-DM to the OWL2 Web Ontology Language, this specification provides a normative serialization of PROV-DM in RDF</li>
<li> PROV-AQ, provenance access and query: the mechanisms for accessing and querying provenance; </li>
@@ -186,9 +188,12 @@
<div class="buttonpanel">
<form action="#"><p>
<input id="hide-bnf" onclick="set_display_by_class('div','grammar','none'); set_display_by_id('hide-bnf','none'); set_display_by_id('show-bnf','');" type="button" value="Hide Grammar" />
-<input id="show-bnf" onclick="set_display_by_class('div','grammar',''); set_display_by_id('hide-bnf',''); set_display_by_id('show-bnf','none');" style="display: none" type="button" value="Show Grammar" />
-<input id="hide-examples" onclick="set_display_by_class('div','anexample','none'); set_display_by_id('hide-examples','none'); set_display_by_id('show-examples','');" type="button" value="Hide Examples" />
-<input id="show-examples" onclick="set_display_by_class('div','anexample',''); set_display_by_id('hide-examples',''); set_display_by_id('show-examples','none');" style="display: none" type="button" value="Show Examples" />
+<input id="show-bnf" onclick="set_display_by_class('div','grammar',''); set_display_by_id('hide-bnf',''); set_display_by_id('show-bnf','none');" style="display: none" type="button"
+value="Show Grammar" />
+<input id="hide-examples" onclick="set_display_by_class('div','anexample','none'); set_display_by_id('hide-examples','none'); set_display_by_id('show-examples','');" type="button"
+value="Hide Examples" />
+<input id="show-examples" onclick="set_display_by_class('div','anexample',''); set_display_by_id('hide-examples',''); set_display_by_id('show-examples','none');" style="display: none"
+type="button" value="Show Examples" />
</p>
</form>
</div>
@@ -212,10 +217,13 @@
<p>
-The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
-Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it, process it, and reason over it.</p>
-
-<p>Thus, the vision is that different provenance-aware systems natively adopt their own model for representing their provenance, but a core provenance data model can be readily adopted as a provenance <em>interchange</em> model across such systems.</p>
+The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to
+consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
+Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it,
+process it, and reason over it.</p>
+
+<p>Thus, the vision is that different provenance-aware systems natively adopt their own model for representing their provenance, but a core provenance data model can be readily adopted as a
+provenance <em>interchange</em> model across such systems.</p>
<p>A set of specifications, referred to as the PROV family of specifications, define the various aspects
that are necessary to achieve this vision in an inter-operable
@@ -231,7 +239,8 @@
<p>
The PROV-DM data model for provenance consists of a set of core
-concepts, and a few common relations, based on these core concepts. PROV-DM is a domain-agnotisc model, but with clear extensibility points allowing further domain-specific and application-specific extensions to be defined.</p>
+concepts, and a few common relations, based on these core concepts. PROV-DM is a domain-agnotisc model, but with clear extensibility points allowing further domain-specific and
+application-specific extensions to be defined.</p>
<p>This specification also introduces
PROV-ASN, an abstract syntax that is primarily aimed at human consumption. PROV-ASN allows
@@ -256,7 +265,8 @@
<p><a href="#common-relations">Section 6</a> introduces further relations offered by PROV-DM, including relations for data collections and domain-independent common relations.</p>
-<p><a href="#interpretation">Section 7</a> provides an interpretation of PROV-DM in terms of ordering constraints between events, and also presents a set of structural constraints to be satisfied by PROV-DM.</p>
+<p><a href="#interpretation">Section 7</a> provides an interpretation of PROV-DM in terms of ordering constraints between events, and also presents a set of structural constraints to be
+satisfied by PROV-DM.</p>
<p><a href="#extensibility-section">Section 8</a> summarizes PROV-DM extensibility points.</p>
@@ -313,9 +323,14 @@
there are things, which can be physical, digital, conceptual, or
otherwise, and activities involving things. </p>
-<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.</p>
-
-<p>Hence, to accommodate different perspectives on things and their situation in the world as perceived by us, we introduce the idea of a characterized thing, which refers to a thing and its situation in the world, as characterized by someone. We then define an <dfn id="concept-entity">entity</dfn> as an identifiable characterized thing. An entity <em>fixes some aspects</em> of a thing and its situation in the world, so that it becomes possible to express its provenance, and what causes these specific aspects to be as such. An alternative entity may fix other aspects, and its provenance may be different.</p>
+<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.</p>
+
+<p>Hence, to accommodate different perspectives on things and their situation in the world as perceived by us, we introduce the idea of a characterized thing, which refers to a thing and its
+situation in the world, as characterized by someone. We then define an <dfn id="concept-entity">entity</dfn> as an identifiable characterized thing. An entity <em>fixes some aspects</em> of
+a thing and its situation in the world, so that it becomes possible to express its provenance, and what causes these specific aspects to be as such. An alternative entity may fix other
+aspects, and its provenance may be different.</p>
<div class="anexample" id="a-report-example">
Different users may take different perspectives on a resource with
@@ -330,15 +345,18 @@
<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>
+<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>
</div>
<!--
-<div class='paolo'>can we follow through from the example. thare three perspectives, possibly by just one observer or multiple ones. but <strong>why is it so important for reporting provenance</strong> that this distinction is made? I feel we need to connect this approach to provenance recording strongly and right away</div>
+<div class='paolo'>can we follow through from the example. thare three perspectives, possibly by just one observer or multiple ones. but <strong>why is it so important for reporting
+provenance</strong> that this distinction is made? I feel we need to connect this approach to provenance recording strongly and right away</div>
-->
-<p>We do not assume that any characterization is more important than any other, and 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 that characterizes the report appropriately.</p>
+<p>We do not assume that any characterization is more important than any other, and 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 that characterizes the report appropriately.</p>
<p>In the world, <dfn id="concept-activity">activities</dfn> involve
entities in multiple ways: consuming them, processing them,
@@ -347,10 +365,15 @@
etc.</p>
-<p>An <dfn id="concept-agent">agent</dfn> is a type of entity that takes an active role in an activity such that it can be assigned some degree of responsibility for the activity taking place.
-This definition intentionally stays away from using concepts such as enabling, causing, initiating, affecting, etc, because any entities also enable, cause, initiate, and affect in some way the activities. So the notion of having some degree of responsibility is really what makes an agent. </p>
-
-<p> Even software agents can be assigned some responsibility for the effects they have in the world, so for example if one is using a Text Editor and one's laptop crashes, then one would say that the Text Editor was responsible for crashing the laptop. If one invokes a service to buy a book, that service can be considered responsible for drawing funds from one's bank to make the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well). So when someone models software as an agent for an activity in our model, they mean the agent has some responsibility for that activity.
+<p>An <dfn id="concept-agent">agent</dfn> is a type of entity that takes an active role in an activity such that it can be assigned some degree of responsibility for the activity taking
+place.
+This definition intentionally stays away from using concepts such as enabling, causing, initiating, affecting, etc, because any entities also enable, cause, initiate, and affect in some way
+the activities. So the notion of having some degree of responsibility is really what makes an agent. </p>
+
+<p> Even software agents can be assigned some responsibility for the effects they have in the world, so for example if one is using a Text Editor and one's laptop crashes, then one would say
+that the Text Editor was responsible for crashing the laptop. If one invokes a service to buy a book, that service can be considered responsible for drawing funds from one's bank to make
+the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well). So when
+someone models software as an agent for an activity in our model, they mean the agent has some responsibility for that activity.
</p>
<p>PROV-DM considers agents as a type of entity so that the model can be
@@ -368,9 +391,11 @@
<section id='section-time-event'>
<h4>Time and Event</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: in a single system, across the Web, or in spatial data management, to name a few. Hence, it is a design objective of PROV-DM to minimize the assumptions about time, so that PROV-DM can be used in varied contexts. </p>
+<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: in a single system, across the Web, or in spatial data management, to name a
+few. Hence, it is a design objective of PROV-DM to minimize the assumptions about time, so that PROV-DM can be used in varied contexts. </p>
<p>Furthermore, consider two activities that started at the same time
@@ -382,8 +407,10 @@
relation with respect to other similar starts. </p>
-<p>Hence, in our conceptualization of the world, an <em>instantaneous event</em>, or <dfn id="dfn-event">event</dfn> for short, happens in the world and marks a change in the world, in its activities and in its 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>
+<p>Hence, in our conceptualization of the world, an <em>instantaneous event</em>, or <dfn id="dfn-event">event</dfn> for short, happens in the world and marks a change in the world, in its
+activities and in its 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>
@@ -391,11 +418,14 @@
<section id="types-of-events">
<h4>Types of Events</h4>
-<p>Four kinds of <a title="event">instantaneous events</a> underpin the PROV-DM data model. The <strong>activity start</strong> and <strong>activity end</strong> events demarcate the beginning and the end of activities, respectively. The <strong>entity generation</strong> and <strong>entity usage</strong> events demarcate the characterization interval for entities. More specifically:
+<p>Four kinds of <a title="event">instantaneous events</a> underpin the PROV-DM data model. The <strong>activity start</strong> and <strong>activity end</strong> events demarcate the
+beginning and the end of activities, respectively. The <strong>entity generation</strong> and <strong>entity usage</strong> events demarcate the characterization interval for entities. More
+specifically:
</p>
-<p>An <dfn id="dfn-generation-event">entity generation event</dfn> is the <a title="event">instantaneous event</a> that marks the final instant of an entity's creation timespan, after which it becomes available for use.</p>
+<p>An <dfn id="dfn-generation-event">entity generation event</dfn> is the <a title="event">instantaneous event</a> that marks the final instant of an entity's creation timespan, after which
+it becomes available for use.</p>
<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a title="event">instantaneous event</a> that marks the first instant of an entity's consumption timespan by an activity.</p>
@@ -507,7 +537,8 @@
<p>
-These records are relative to an asserter, and in that sense constitute assertions stating properties of the world, as represented by an asserter. Different asserters will normally contribute different records expressive different representations of the world.
+These records are relative to an asserter, and in that sense constitute assertions stating properties of the world, as represented by an asserter. Different asserters will normally
+contribute different records expressive different representations of the world.
This specification does not define a notion of consistency between different sets of records (whether by the same asserter or different asserters).
The data model provides the means to associate attribution to assertions.
</p>
@@ -590,7 +621,8 @@
</div>
<p>
-The following ER diagram provides a high level overview of the <strong>structure of PROV-DM records</strong>. Examples of provenance assertions that conform to this schema are provided in the next section.</p>
+The following ER diagram provides a high level overview of the <strong>structure of PROV-DM records</strong>. Examples of provenance assertions that conform to this schema are provided in
+the next section.</p>
<div style="text-align: center;">
<img src="overview.png" alt="PROV-DM overview"/>
@@ -604,12 +636,25 @@
<ul>
<li>An <a title="entity record">Entity Record</a> (noted <samp>entity</samp> in the diagram, to reflect the term used in the ASN) is a representation of an <em>entity</em>.
+<<<<<<< local
<li>An <a title="activity record">Activity Record</a>(noted <samp>activity</samp> in the diagram) represents an activity that has an effect on entities, namely it either <em>generates</em> or <em>uses</em> one or more entities.
Usage and generation are modelled by means of the <a title="usage record">used</a> and the <a title="generation record">wasGeneratedBy</a> relationships. Activities may include not only computations, but also any other type of activity that can be described in terms of their effect on <samp>entities</samp>.
Note that multiple <samp>activities</samp> may <em>use</em> the same <samp>entity</samp>, and each activity may use multiple <samp>entities</samp>. Finally, entities can be derived from other entities, and this is specified using the <a title="derivation record">wasDerivedFrom</a> relation.</li>
+=======
+ <li>An <a title="activity record">Activity Record</a>(noted <samp>activity</samp> in the diagram) represents an activity that has an effect on entities, namely it either <em>generates</em>
+or <em>uses</em> one or more entities. Usage and generation are modelled by means of the <a title="usage record">used</a> and the <a title="generation record">wasGeneratedBy</a>
+relationships. <samp>Activity</samp> denotes any type of activity that have an effect on <samp>entities</samp>.
+Note that multiple <samp>activities</samp> may <em>use</em> the same <samp>entity</samp>, and each activity may use multiple <samp>entities</samp>. Finally, entities can be derived from
+other entities, and this is specified using the <a title="derivation record">wasDerivedFrom</a> relation.</li>
+>>>>>>> other
- <li>An <a title="agent record">Agent Record</a> represents a particular <samp>entity</samp> that can be associated to activities, meaning that it can be assigned some degree of responsibility for an <samp>activity</samp> taking place.
- Agents have a rather generic connotation: their association with an activity is represented by the <a title="activity association record">wasAssociatedWith</a> relationship, which can take up various meanings (attribution, responsibility, supervision, management, etc.), which are not individually specified in the model. Relations <a title="start record">wasStartedBy</a> and <a title="end record">wasEndedBy</a> are specializations of <a title="activity association record">wasAssociatedWith</a> that can optionally be used to carry additional meaning. Furthermore, it is recognized that agents can act on behalf of others: hence, the relation <a title="responsibility record">actedOnBehalfOf</a> allows for chains of responsibility to be stated.
+ <li>An <a title="agent record">Agent Record</a> represents a particular <samp>entity</samp> that can be associated to activities, meaning that it can be assigned some degree of
+responsibility for an <samp>activity</samp> taking place.
+ Agents have a rather generic connotation: their association with an activity is represented by the <a title="activity association record">wasAssociatedWith</a> relationship, which can
+take up various meanings (attribution, responsibility, supervision, management, etc.), which are not individually specified in the model. Relations <a title="start record">wasStartedBy</a>
+and <a title="end record">wasEndedBy</a> are specializations of <a title="activity association record">wasAssociatedWith</a> that can optionally be used to carry additional meaning.
+Furthermore, it is recognized that agents can act on behalf of others: hence, the relation <a title="responsibility record">actedOnBehalfOf</a> allows for chains of responsibility to be
+stated.
</li>
@@ -618,12 +663,14 @@
<p> A set of attribute-value pairs can be associated to elements and relations of the PROV model in order to further characterize
their nature.
-The <a title="complementarity record">wasComplementOf</a> relationship is used to denote that two <samp>entities</samp> <em>complement</em> each other, in the sense that they each represent a partial, but mutually compatible characterization of the same thing.
+The <a title="complementarity record">wasComplementOf</a> relationship is used to denote that two <samp>entities</samp> <em>complement</em> each other, in the sense that they each
+represent a partial, but mutually compatible characterization of the same thing.
The attributes <a title="prov:role">role</a> and <a title="prov:type">type</a> are pre-defined.
</p>
<p>
-In addition to the kinds of record introduced in the overview figure, PROV-DM also features a notion of <a title="account record">Account Record</a> that allows attribution of provenance records to be expressed.
+In addition to the kinds of record introduced in the overview figure, PROV-DM also features a notion of <a title="account record">Account Record</a> that allows attribution of provenance
+records to be expressed.
</p>
@@ -631,11 +678,13 @@
<p>
-The model includes a further additional element: <a title="note record">notes</a>. These are also structured as sets of attribute-value pairs. Notes are used to provide additional, "free-form" information regarding <em>any</em> identifiable construct of the model, with no prescribed meaning. Notes are described in detail <a href="#record-note">here</a>.
+The model includes a further additional element: <a title="note record">notes</a>. These are also structured as sets of attribute-value pairs. Notes are used to provide additional,
+"free-form" information regarding <em>any</em> identifiable construct of the model, with no prescribed meaning. Notes are described in detail <a href="#record-note">here</a>.
</p>
<p>
-Attributes and notes are the main <em>extensibility points</em> in the model: individual interest groups are expected to extend PROV-DM by introducing new attributes and notes as needed to address applications-specific provenance modelling requirements. </p>
+Attributes and notes are the main <em>extensibility points</em> in the model: individual interest groups are expected to extend PROV-DM by introducing new attributes and notes as needed to
+address applications-specific provenance modelling requirements. </p>
</section>
@@ -643,11 +692,13 @@
<section class="informative" id="prov-dm-example">
<h2>Example</h2>
-<div class='issue'> There is a suggestion that a better example should be adopted for this document. Possibly, several shorter examples. This is <a href="http://www.w3.org/2011/prov/track/issues/132">ISSUE-132</a></div>
+<div class='issue'> There is a suggestion that a better example should be adopted for this document. Possibly, several shorter examples. This is <a
+href="http://www.w3.org/2011/prov/track/issues/132">ISSUE-132</a></div>
<p>
-To illustrate PROV-DM, this section presents an example encoded according to PROV-ASN. For more detailed explanations of how PROV-DM should be used, and for more examples, we refer the reader to the Provenance Primer [[!PROV-PRIMER]].</p>
+To illustrate PROV-DM, this section presents an example encoded according to PROV-ASN. For more detailed explanations of how PROV-DM should be used, and for more examples, we refer the
+reader to the Provenance Primer [[!PROV-PRIMER]].</p>
@@ -694,7 +745,8 @@
<p><a>Event</a> evt5: Edith emails (activity: a4) the contents of /share/crime.txt as an attachment, referred to as e5.
</p>
-<p><a>Event</a> evt6: between <a title="event">events</a> evt4 and evt5, someone (unspecified) runs a grammar checker (activity: a5) on the file /share/crime.txt, using a set of grammatical rules (referred to as gr1).
+<p><a>Event</a> evt6: between <a title="event">events</a> evt4 and evt5, someone (unspecified) runs a grammar checker (activity: a5) on the file /share/crime.txt, using a set of grammatical
+rules (referred to as gr1).
The file after grammatical checking is referred to as e6.
</p>
@@ -703,9 +755,11 @@
<section id="example-prov-asn-encoding">
<h3>Encoding using PROV-ASN</h3>
-In this section, the example is encoded according to the provenance data model (specified in section <a href="#data-model-concepts">PROV-DM: The Provenance Data Model</a>) and expressed in PROV-ASN.
+In this section, the example is encoded according to the provenance data model (specified in section <a href="#data-model-concepts">PROV-DM: The Provenance Data Model</a>) and expressed in
+PROV-ASN.
<p>
-Entity Records (described in <a href="#record-Entity">Section Entity</a>). The file in its various forms and its copies are modelled as entity records, corresponding to multiple characterizations, as per scenario. The entity records are identified by <span class="name">e0</span>, ..., <span class="name">e6</span>.</p>
+Entity Records (described in <a href="#record-Entity">Section Entity</a>). The file in its various forms and its copies are modelled as entity records, corresponding to multiple
+characterizations, as per scenario. The entity records are identified by <span class="name">e0</span>, ..., <span class="name">e6</span>.</p>
<pre>
entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice",
@@ -723,7 +777,9 @@
-<p>These entity records list attributes that have been given values during intervals delimited by <a title="event">events</a>; such intervals are referred to as <em>characterization intervals</em>. The following table lists all entity identifiers and their corresponding characterization intervals. When the end of the characterization interval is not delimited by an <a>event</a> described in this scenario, it is marked by "...".</p>
+<p>These entity records list attributes that have been given values during intervals delimited by <a title="event">events</a>; such intervals are referred to as <em>characterization
+intervals</em>. The following table lists all entity identifiers and their corresponding characterization intervals. When the end of the characterization interval is not delimited by an
+<a>event</a> described in this scenario, it is marked by "...".</p>
<blockquote>
<table>
<tr><td>Entity</td><td>Characterization Interval</td></tr>
@@ -740,7 +796,8 @@
<p>
-Activity Records (described in <a href="#record-Activity">Section Activity</a>) represent activities in the scenario. Each activity record contains the activity identifier, a start time and a type attribute characterizing the nature of the activity.</p>
+Activity Records (described in <a href="#record-Activity">Section Activity</a>) represent activities in the scenario. Each activity record contains the activity identifier, a start time and
+a type attribute characterizing the nature of the activity.</p>
<pre>
activity(a0, 2011-11-16T16:00:00,,[prov:type="createFile"])
activity(a1, 2011-11-16T16:05:00,,[prov:type="edit"])
@@ -752,10 +809,14 @@
<p>
-Generation Records (described in <a href="#record-Generation">Section Generation</a>) represent the <a>event</a> at which a file is created in a specific form. Attributes are used to describe the modalities according to which a given entity is generated by a given activity. The interpretation of attributes is application specific. Illustrations of such attributes for the scenario are: no attribute is provided for <span class="name">e0</span>;
-<span class="name">e2</span> was generated by the editor's save function; <span class="name">e4</span> can be found on the smtp port, in the attachment section of the mail message; <span class="name">e6</span> was produced on the standard output of <span class="name">a5</span>.
+Generation Records (described in <a href="#record-Generation">Section Generation</a>) represent the <a>event</a> at which a file is created in a specific form. Attributes are used to
+describe the modalities according to which a given entity is generated by a given activity. The interpretation of attributes is application specific. Illustrations of such attributes for
+the scenario are: no attribute is provided for <span class="name">e0</span>;
+<span class="name">e2</span> was generated by the editor's save function; <span class="name">e4</span> can be found on the smtp port, in the attachment section of the mail message; <span
+class="name">e6</span> was produced on the standard output of <span class="name">a5</span>.
Sometimes, it is necessary to refer to generation records in other records. For those cases, we introduce
- identifiers such as <span class="name">g1</span> and <span class="name">g2</span> to identify the generation records; these identifiers are used in derivations introduced below to reference those specific records.</p>
+ identifiers such as <span class="name">g1</span> and <span class="name">g2</span> to identify the generation records; these identifiers are used in derivations introduced below to
+reference those specific records.</p>
<pre>
wasGeneratedBy(e0, a0)
wasGeneratedBy(e1, a0, [ex:fct="create"])
@@ -772,8 +833,10 @@
Usage Records (described in <a href="#record-Usage">Section Usage</a>) represent the <a>event</a> by which a file is read by an activity.
Likewise, attributes describe the modalities according to which the various entities are used by activities. Illustrations of such attributes are:
-<span class="name">e1</span> is used in the context of <span class="name">a1</span>'s <span class="name">load</span> functionality; <span class="name">e2</span> is used by <span class="name">a2</span> in the context of its attach functionality; <span class="name">e3</span> is used on the standard input by <span class="name">a5</span>.
-Sometimes, it is also necessary to refer to usage records in other records. To this end, for these usage records, identifiers such as <span class="name">u1</span> and <span class="name">u2</span> are introduced to identify them; these identifiers are used later in derivations introduced below to refer to these specific Usage records.</p>
+<span class="name">e1</span> is used in the context of <span class="name">a1</span>'s <span class="name">load</span> functionality; <span class="name">e2</span> is used by <span
+class="name">a2</span> in the context of its attach functionality; <span class="name">e3</span> is used on the standard input by <span class="name">a5</span>.
+Sometimes, it is also necessary to refer to usage records in other records. To this end, for these usage records, identifiers such as <span class="name">u1</span> and <span
+class="name">u2</span> are introduced to identify them; these identifiers are used later in derivations introduced below to refer to these specific Usage records.</p>
<pre>
used(a1,e1,[ex:fct="load"])
used(a3,e2,[ex:fct="load"])
@@ -784,7 +847,9 @@
<p>
-Derivation Records (described in <a href="#Derivation-Relation">Section Derivation Relation</a>) express that an entity is derived from another. The first two are expressed in their compact version, whereas the following two are expressed in their full version, including the activity underpinning the derivation, and associated usage (<span class="name">u1</span>, <span class="name">u2</span>) and generation (<span class="name">g1</span>, <span class="name">g2</span>) records.</p>
+Derivation Records (described in <a href="#Derivation-Relation">Section Derivation Relation</a>) express that an entity is derived from another. The first two are expressed in their compact
+version, whereas the following two are expressed in their full version, including the activity underpinning the derivation, and associated usage (<span class="name">u1</span>, <span
+class="name">u2</span>) and generation (<span class="name">g1</span>, <span class="name">g2</span>) records.</p>
<pre>
wasDerivedFrom(e2,e1)
wasDerivedFrom(e3,e2)
@@ -798,7 +863,10 @@
</div>
<p>
-specializationOf: (this relation is described in <a href="#record-alternate-specialization">Section alternate and specialization records</a>). The crime statistics file (<span class="name">e0</span>) has various contents over its existence (<span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span>); the entity records identified by <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span> specialize <span class="name">e0</span> with an attribute <span class="name">content</span>. Likewise, the one denoted by <span class="name">e6</span> specializes the record denoted by <span class="name">e3</span> with an attribute <span class="name">grammarchecked</span>.</p>
+specializationOf: (this relation is described in <a href="#record-alternate-specialization">Section alternate and specialization records</a>). The crime statistics file (<span
+class="name">e0</span>) has various contents over its existence (<span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span>); the entity records identified by
+<span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span> specialize <span class="name">e0</span> with an attribute <span class="name">content</span>.
+Likewise, the one denoted by <span class="name">e6</span> specializes the record denoted by <span class="name">e3</span> with an attribute <span class="name">grammarchecked</span>.</p>
<pre>
specializationOf(e1,e0)
specializationOf(e2,e0)
@@ -809,7 +877,8 @@
<p>
-Agent Records (described at <a href="#record-Agent">Section Agent</a>): the various users are represented as agents, themselves being a type of entity. Furthermore, a sixth agent is defined to be a software agent (the grammar checker).</p>
+Agent Records (described at <a href="#record-Agent">Section Agent</a>): the various users are represented as agents, themselves being a type of entity. Furthermore, a sixth agent is defined
+to be a software agent (the grammar checker).</p>
<pre>
agent(ag1, [ prov:type="prov:Person" %% xsd:QName, ex:name="Alice" ])
@@ -827,7 +896,9 @@
<p>
-Activity Assocation Records (described in <a href="#record-ActivityAssociation">Section Activity Association</a>): the association of an agent with an activity is expressed with , and the nature of this association is described by attributes. Illustrations of such attributes include the role of the participating agent, as creator, author, communicator, and checker (role is a reserved attribute in PROV-DM).</p>
+Activity Assocation Records (described in <a href="#record-ActivityAssociation">Section Activity Association</a>): the association of an agent with an activity is expressed with , and the
+nature of this association is described by attributes. Illustrations of such attributes include the role of the participating agent, as creator, author, communicator, and checker (role is a
+reserved attribute in PROV-DM).</p>
<pre>
wasAssociatedWith(a0, ag1, [prov:role="creator"])
wasAssociatedWith(a1, ag2, [prov:role="author"])
@@ -835,14 +906,16 @@
wasAssociatedWith(a3, ag4, [prov:role="author"])
wasAssociatedWith(a4, ag5, [prov:role="communicator"])
</pre>
-<p>In addition, activity <span class="name">a5</span> is associated with the grammar checker, which relied on a set of grammatical rules to perform the grammar checking. Generally, rules like these are referred to as a <em>plan</em>, a specific type of entity.
+<p>In addition, activity <span class="name">a5</span> is associated with the grammar checker, which relied on a set of grammatical rules to perform the grammar checking. Generally, rules
+like these are referred to as a <em>plan</em>, a specific type of entity.
<pre>
entity(gr1,[prov:type="prov:Plan"%% xsd:QName,
ex:url="http://example.org/grammarRules.html" %% xsd:anyURI])
wasAssociatedWith(a5, ag6, gr1, [prov:role="checker"])
</pre>
-<p>Finally, the software agent <span class="name">ag6</span> did not act autonomously, but was operating on behalf of a user. This chain of responsibility is captured with the Responsibility Record (described in <a href="#record-responsibility">Section Responsibility Record</a>).</p>
+<p>Finally, the software agent <span class="name">ag6</span> did not act autonomously, but was operating on behalf of a user. This chain of responsibility is captured with the Responsibility
+Record (described in <a href="#record-responsibility">Section Responsibility Record</a>).</p>
<pre>
actedOnBehalfOf(ag6, ag4, a5, [prov:type="delegation"])
</pre>
@@ -854,15 +927,19 @@
<p>
-Provenance records can be <em>illustrated</em> graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of provenance records. Therefore, it should not be seen as an alternate notation for expressing provenance.</p>
-
-<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and pentagonal shapes, respectively. Usage, Generation, Derivation, Activity Association, and Specialization are represented as directed edges.</p>
-
-<p>Entities are layed out according to the ordering of their generation event. We endeavor to show time progressing from left to right. This means that edges for Usage, Generation and Derivation typically point from right to left.</p>
+Provenance records can be <em>illustrated</em> graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of
+provenance records. Therefore, it should not be seen as an alternate notation for expressing provenance.</p>
+
+<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and pentagonal shapes, respectively. Usage,
+Generation, Derivation, Activity Association, and Specialization are represented as directed edges.</p>
+
+<p>Entities are layed out according to the ordering of their generation event. We endeavor to show time progressing from left to right. This means that edges for Usage, Generation and
+Derivation typically point from right to left.</p>
<div class="note">
-Paolo, TODO: update the two figure. Replace wasComplementOf by alternateOf/specializationOf. Can we move key below figure to make better use of space? Can you remove the capture from the image, and add it in html using figcaption.
+Paolo, TODO: update the two figure. Replace wasComplementOf by alternateOf/specializationOf. Can we move key below figure to make better use of space? Can you remove the capture from the
+image, and add it in html using figcaption.
</div>
<div style="text-align: center; ">
@@ -896,7 +973,8 @@
<p>Concretely, PROV-DM consists of a set of constructs to formulate representations of the world and constraints that must be satisfied by them.
-A PROV-DN <dfn id="dfn-Record">record</dfn> is a body of information about something which is of interest from a provenance viewpoint. PROV-DM records may be asserted directly or may be inferred from others.
+A PROV-DN <dfn id="dfn-Record">record</dfn> is a body of information about something which is of interest from a provenance viewpoint. PROV-DM records may be asserted directly or may be
+inferred from others.
</p>
<p>
@@ -925,7 +1003,8 @@
Hence, by creating a set of PROV-DM records and packaging them into a record container,
one forms a provenance record. </p>
-<p>In PROV-ASN, such representations of the world MUST be conformant with the toplevel <a>production</a> <span class="nonterminal">record</span> of the grammar. These <span class="nonterminal">record</span>s are grouped in three categories:
+<p>In PROV-ASN, such representations of the world MUST be conformant with the toplevel <a>production</a> <span class="nonterminal">record</span> of the grammar. These <span
+class="nonterminal">record</span>s are grouped in three categories:
<span class="nonterminal">elementRecord</span> (see section <a href="#record-element">Element</a>),
<span class="nonterminal">relationRecord</span> (see section <a href="#record-relation">Relation</a>), and
<span class="nonterminal">accountRecord</span> (see section <a href="#record-Account">Account</a>).</p>
@@ -966,11 +1045,14 @@
<section id="record-element">
<h3>Element</h3>
-<p>This section describes all the PROV-DM records referred to as element records. (In PROV-ASN, such records are conformant to the <span class='nonterminal'>elementRecord</span> production of the grammar.)</p>
+<p>This section describes all the PROV-DM records referred to as element records. (In PROV-ASN, such records are conformant to the <span class='nonterminal'>elementRecord</span> production
+of the grammar.)</p>
<div class="issue">
-There is still some confusion about what the identifiers really denote. For instance, are they entity identifiers or entity record identifiers. This is <a href="http://www.w3.org/2011/prov/track/issues/183">ISSUE-183</a>.
-An example and questions appear in <a href="http://www.w3.org/2011/prov/track/issues/215">ISSUE-215</a>. A related issued is also raised in <a href="http://www.w3.org/2011/prov/track/issues/145">ISSUE-145</a>.
+There is still some confusion about what the identifiers really denote. For instance, are they entity identifiers or entity record identifiers. This is <a
+href="http://www.w3.org/2011/prov/track/issues/183">ISSUE-183</a>.
+An example and questions appear in <a href="http://www.w3.org/2011/prov/track/issues/215">ISSUE-215</a>. A related issued is also raised in <a
+href="http://www.w3.org/2011/prov/track/issues/145">ISSUE-145</a>.
</div>
<section id="record-Entity">
@@ -980,7 +1062,8 @@
<p>In PROV-DM, an <dfn id="dfn-entity">entity record</dfn> is a representation of an entity.</p>
-<p>Examples of entities include a car on a road, a linked data set, a sparse-matrix matrix of floating-point numbers, a document in a directory, the same document published on the Web, and meta-data embedded in a document.</p>
+<p>Examples of entities include a car on a road, a linked data set, a sparse-matrix matrix of floating-point numbers, a document in a directory, the same document published on the Web, and
+meta-data embedded in a document.</p>
<p>An entity record, noted <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
<ul>
@@ -990,7 +1073,8 @@
<p>
-The assertion of an entity record states, from a given asserter's viewpoint, the existence of an entity, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two <a title="event">instantaneous events</a> in the world.
+The assertion of an entity record states, from a given asserter's viewpoint, the existence of an entity, whose situation in the world is represented by the attribute-value pairs, which
+remain unchanged during a characterization interval, i.e. a continuous interval between two <a title="event">instantaneous events</a> in the world.
</p>
<p>
@@ -1028,15 +1112,20 @@
<pre class="codeexample">
entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
</pre>
-states the existence of an entity, denoted by identifier <span class="name">e0</span>, with type <span class="name">File</span> and path <span class="name">/shared/crime.txt</span> in the file system, and creator alice The attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span class="name">type</span> is reserved in the PROV-DM namespace.
+states the existence of an entity, denoted by identifier <span class="name">e0</span>, with type <span class="name">File</span> and path <span class="name">/shared/crime.txt</span> in the
+file system, and creator alice The attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span
+class="name">type</span> is reserved in the PROV-DM namespace.
</div>
Further considerations:
<ul>
<li>
The entity identifier <span class="name">id</span> contained in an entity record is expected to be unique among all the identifiers contained in the current account's records.
-This constraint is elaborated upon in <a href="#identifiable-record-in-account">identifiable-record-in-account</a>. It means that the current account does not contain any other record for this identifier. Effectively, <span class="name">id</span> acts as a <em>local</em> identifier for this record. In this specification, whenever we write "an entity record identified by ... ", this identification is to be understood in the context of the account that defines it. </li>
-<li>If an asserter wishes to characterize an entity with the same attribute-value pairs over several intervals, then they are required to create multiple entity records (either by direct assertion or by inference), each with its own identifier (so as to allow potential dependencies between the various entity records to be expressed). </li>
+This constraint is elaborated upon in <a href="#identifiable-record-in-account">identifiable-record-in-account</a>. It means that the current account does not contain any other record for
+this identifier. Effectively, <span class="name">id</span> acts as a <em>local</em> identifier for this record. In this specification, whenever we write "an entity record identified by ...
+", this identification is to be understood in the context of the account that defines it. </li>
+<li>If an asserter wishes to characterize an entity with the same attribute-value pairs over several intervals, then they are required to create multiple entity records (either by direct
+assertion or by inference), each with its own identifier (so as to allow potential dependencies between the various entity records to be expressed). </li>
<li>There is no assumption that the set of attributes is complete and that the attributes are independent or orthogonal of each other.</li>
@@ -1090,12 +1179,16 @@
<p>In PROV-DM, an <dfn id="dfn-activity">activity record</dfn> is a representation of an identifiable activity, which performs a piece of work.</p>
-<p>An activity, represented by an activity record, 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="event">instantaneous events</a>. However, an activity record need not mention time information, nor duration, because they may not be known.</p>
-
-<p>If start and end times are known, they are expressed as <em>attributes</em> of an activity, where the interpretation of attribute in the context of an activity record is the same as the interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the world can be represented by other attribute-value pairs, which MUST also remain unchanged during the activity duration.</p>
+<p>An activity, represented by an activity record, 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="event">instantaneous events</a>. However, an activity record need not mention time information, nor duration, because they may not be known.</p>
+
+<p>If start and end times are known, they are expressed as <em>attributes</em> of an activity, where the interpretation of attribute in the context of an activity record is the same as the
+interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the
+world can be represented by other attribute-value pairs, which MUST also remain unchanged during the activity duration.</p>
<p>
-Examples of activities include driving a car from Boston to Cambridge, assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a sparql query over a triple store, editing a file, and publishing a web page. </p>
+Examples of activities include driving a car from Boston to Cambridge, assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news
+items according to some criteria, running a sparql query over a triple store, editing a file, and publishing a web page. </p>
<p> An activity record, written <span class="name">activity(id, st, et, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
<ul>
@@ -1103,7 +1196,8 @@
<!--<li><em>recipeLink</em>: an OPTIONAL <a href="#record-RecipeLink">recipe link</a> <span class="name">rl</span>, which consists of a domain specific specification of the activity;</li>-->
<li><em>startTime</em>: an OPTIONAL time <span class="name">st</span> indicating the start of the activity;</li>
<li><em>endTime</em>: an OPTIONAL time <span class="name">et</span> indicating the end of the activity;</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole duration.</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole
+duration.</li>
</ul>
<p>In PROV-ASN, an activity record's text matches the <span class='nonterminal'>activityRecord</span> production of the grammar defined in this specification document.</p>
@@ -1130,7 +1224,10 @@
activity(a1,2011-11-16T16:05:00,2011-11-16T16:06:00,
[ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
</pre>
-<p>states the existence of an activity identified by <span class="name">a1</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix <span class="name">ex</span>). The attribute <span class="name">host</span> is application specific, but MUST hold for the duration of activity. The attribute <span class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
+<p>states the existence of an activity identified by <span class="name">a1</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span
+class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix
+<span class="name">ex</span>). The attribute <span class="name">host</span> is application specific, but MUST hold for the duration of activity. The attribute <span
+class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
</div>
<div class="interpretation-forward">
@@ -1138,7 +1235,8 @@
</div>
<!--
-<p>The mere existence of an activity assertion entails some <a>event</a> ordering in the world, since an <a>activity start event</a> always <a>precedes</a> the corresponding <a>activity end event</a>. This is expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
+<p>The mere existence of an activity assertion entails some <a>event</a> ordering in the world, since an <a>activity start event</a> always <a>precedes</a> the corresponding <a>activity end
+event</a>. This is expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
<div class='interpretation' id='start-precedes-end'> The following temporal constraint holds for any activity record: the
<a title="activity start event">start event</a> <a>precedes</a> the <a title="activity end event">end event</a>.</div>
@@ -1147,7 +1245,8 @@
<p>Further considerations:</p>
<ul>
<li>The activity identifier <span class="name">id</span> contained in an activity record is also expected to be unique among all the identifiers contained in the current account's records.
-This constraint is elaborated upon in <a href="#identifiable-record-in-account">identifiable-record-in-account</a>. It means that the current account does not contain any other record for this identifier, and that effectively <span class="name">id</span> acts as a <em>local</em> identifier for this record in the current account.</li>
+This constraint is elaborated upon in <a href="#identifiable-record-in-account">identifiable-record-in-account</a>. It means that the current account does not contain any other record for
+this identifier, and that effectively <span class="name">id</span> acts as a <em>local</em> identifier for this record in the current account.</li>
<li>An activity record is not an entity record.
Indeed, an entity record represents an entity that exists in full at
@@ -1170,7 +1269,8 @@
<p>An <dfn id="dfn-Agent">agent record</dfn> is a representation of an agent, which is an entity that can be assigned some degree of responsibility for an activity taking place.</p>
-<p>Many agents can have an association with a given activity. An agent may do the ordering of the activity, another agent may do its design, another agent may push the button to start it, another agent may run it, etc.
+<p>Many agents can have an association with a given activity. An agent may do the ordering of the activity, another agent may do its design, another agent may push the button to start it,
+another agent may run it, etc.
As many agents as one wishes to mention can occur in the provenance record, if it is important to indicate that they were associated with the activity. </p>
<p>
@@ -1180,7 +1280,8 @@
There are three types of agents in the model since they are common across most anticipated domain of use:
<ul>
<li><span class="name">Person</span>: agents of type Person are people. (This type is equivalent to a "foaf:person" [[FOAF]])</li>
-<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc. (This type is equivalent to a "foaf:organization" [[FOAF]])</li>
+<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc. (This type is equivalent to a "foaf:organization"
+[[FOAF]])</li>
<li><span class="name">SoftwareAgent</span>: a software agent is a piece of software. </li>
</ul>
<p>These types are mutually exclusive, though they do not cover all kinds of agent. </p>
@@ -1217,7 +1318,8 @@
entity(e3) and wasAssociatedWith(a1,e3,[prov:role="sponsor"])
</pre>
-<p>the agent record represents an explicit agent identified by <span class="name">e1</span> that holds irrespective of activities it may be associated with. On the other hand, from the entity records identified by <span class="name">e2</span> and <span class="name">e3</span>, one can infer agent records, as per the following inference.</p>
+<p>the agent record represents an explicit agent identified by <span class="name">e1</span> that holds irrespective of activities it may be associated with. On the other hand, from the
+entity records identified by <span class="name">e2</span> and <span class="name">e3</span>, one can infer agent records, as per the following inference.</p>
</div>
<p>One can assert an agent record or alternatively, one can infer an agent record
@@ -1231,7 +1333,8 @@
the record <span class="name">agent(e,attrs)</span> also holds.
</div>
-<div class='issue'> Shouldn't we allow for entities (not agent) to be associated with an activity? Should we drop the inference association-agent? <a href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
+<div class='issue'> Shouldn't we allow for entities (not agent) to be associated with an activity? Should we drop the inference association-agent? <a
+href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
</section>
@@ -1239,7 +1342,9 @@
<h4>Note Record</h4>
-<p>As provenance records are exchanged between systems, it may be useful to add extra-information about such records. For instance, a "trust service" may add value-judgements about the trustworthiness of some of the assertions made. Likewise, an interactive visualization component may want to enrich a set of provenance records with information helping reproduce their visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing any identifiable record to be associated with notes.</p>
+<p>As provenance records are exchanged between systems, it may be useful to add extra-information about such records. For instance, a "trust service" may add value-judgements about the
+trustworthiness of some of the assertions made. Likewise, an interactive visualization component may want to enrich a set of provenance records with information helping reproduce their
+visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing any identifiable record to be associated with notes.</p>
<p>A <dfn id="dfn-note">note record</dfn> is a set of attribute-value pairs, whose meaning is application specific. It may or may not be a representation of something in the world.</p>
@@ -1258,7 +1363,8 @@
<!-- -->
</div>
-<p>A separate PROV-DM record is used to associate a note with an identifiable record (see <a href="#record-annotation">Section on annotation</a>). A given note may be associated with multiple records.
+<p>A separate PROV-DM record is used to associate a note with an identifiable record (see <a href="#record-annotation">Section on annotation</a>). A given note may be associated with
+multiple records.
</p>
@@ -1279,7 +1385,8 @@
</div>
<p>
-Attribute-value pairs occurring in notes differ from attribute-value pairs occurring in entity records and activity records. In entity and activity records, attribute-value pairs MUST be a representation of something in the world, which remain constant for the duration of the characterization interval (for entity record) or the activity duration (for activity records).
+Attribute-value pairs occurring in notes differ from attribute-value pairs occurring in entity records and activity records. In entity and activity records, attribute-value pairs MUST be a
+representation of something in the world, which remain constant for the duration of the characterization interval (for entity record) or the activity duration (for activity records).
A note record linked with an entity record consists of
attribute-value pairs which may or may not represent the entity's
situation in the world.
@@ -1298,15 +1405,18 @@
<section id="record-relation">
<h3>Relation</h3>
-<p>This section describes all the PROV-DM records representing relations between the elements introduced in <a href="#record-element">Section Element</a>. While these relations are not binary, they all involve two primary elements. They can be summarized as follows. </p>
+<p>This section describes all the PROV-DM records representing relations between the elements introduced in <a href="#record-element">Section Element</a>. While these relations are not
+binary, they all involve two primary elements. They can be summarized as follows. </p>
<div style="text-align: center;">
<table border="1" style="margin-left: auto; margin-right: auto;">
<caption>PROV-DM Core Relation Summary</caption>
<tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Note</td></tr>
-<tr><td>Entity</td><td><a title="derivation record">wasDerivedFrom</a><br><a title="alternate record">alternateOf</a><br><a title="specialization record">specializationOf</a></td><td><a title="generation record">wasGeneratedBy</a></td><td>—</td><td><a title="annotation record">hasAnnotation</a></td></tr>
-<tr><td>Activity</td><td><a title="usage record">used</a></td><td>—</td><td><a title="start record">wasStartedBy</a><br><a title="end record">wasEndedBy</a><br><a title="activity association record">wasAssociatedWith</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
+<tr><td>Entity</td><td><a title="derivation record">wasDerivedFrom</a><br><a title="alternate record">alternateOf</a><br><a title="specialization record">specializationOf</a></td><td><a
+title="generation record">wasGeneratedBy</a></td><td>—</td><td><a title="annotation record">hasAnnotation</a></td></tr>
+<tr><td>Activity</td><td><a title="usage record">used</a></td><td>—</td><td><a title="start record">wasStartedBy</a><br><a title="end record">wasEndedBy</a><br><a title="activity
+association record">wasAssociatedWith</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
<tr><td>Agent</td><td>—</td><td>—</td><td><a title="responsibility record">actedOnBehalfOf</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
<tr><td>Note</td><td>—</td><td>—</td><td>—</td><td><a title="annotation record">hasAnnotation</a></td></tr>
</table>
@@ -1322,11 +1432,14 @@
<h4>Generation Record</h4>
-<p>In PROV-DM, a <dfn id="dfn-Generation">generation record</dfn> is a representation of an instantaneous world <a title="entity generation event">event</a>, the completed creation of a new entity by an activity. This entity become available for usage after this <a title="event">instantaneous
+<p>In PROV-DM, a <dfn id="dfn-Generation">generation record</dfn> is a representation of an instantaneous world <a title="entity generation event">event</a>, the completed creation of a new
+entity by an activity. This entity become available for usage after this <a title="event">instantaneous
event</a>. This entity did not exist before creation (though another with a different characterization may have existed before).
The representation of this <a title="event">instantaneous event</a> encompasses a description of the modalities of generation of this entity by this activity.</p>
-<p>A <a title="entity generation event">generation event</a> may be, for example, the completed creation of a file by a program, the completed creation of a linked data set, the completed publication of a new version of a document, and the complete sending of a value on a communication channel. The point at which creation is actually complete is application specific: generation of a file may complete when a lock is released by its creator, whereas actual publication of a document may be after the embargo period that was defined for it.</p>
+<p>A <a title="entity generation event">generation event</a> may be, for example, the completed creation of a file by a program, the completed creation of a linked data set, the completed
+publication of a new version of a document, and the complete sending of a value on a communication channel. The point at which creation is actually complete is application specific:
+generation of a file may complete when a lock is released by its creator, whereas actual publication of a document may be after the embargo period that was defined for it.</p>
<p>A generation record, written <span class="name">wasGeneratedBy(id,e,a,t,attrs)</span> in PROV-ASN, has the following components:</p>
<ul>
@@ -1359,7 +1472,8 @@
<p>
-A generation record's id is OPTIONAL. It MUST be used when annotating generation records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).
+A generation record's id is OPTIONAL. It MUST be used when annotating generation records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1
+derivations (see <a href="#Derivation-Relation">Derivation Record</a>).
</p>
@@ -1370,8 +1484,11 @@
wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1", ex:order=1])
wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p1", ex:order=2])
</pre>
-<p>state the existence of two <a title="event">events</a> in the world (with respective times <span class="name">2001-10-26T21:32:52</span> and <span class="name">2001-10-26T10:00:00</span>), at which new entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an activity, itself represented by an activity record identified by <span class="name">a1</span>.
-The first one is available as the first value on port p1, whereas the other is the second value on port p1. The semantics of <span class="name">port</span> and <span class="name">order</span> in these records are application specific.
+<p>state the existence of two <a title="event">events</a> in the world (with respective times <span class="name">2001-10-26T21:32:52</span> and <span
+class="name">2001-10-26T10:00:00</span>), at which new entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an
+activity, itself represented by an activity record identified by <span class="name">a1</span>.
+The first one is available as the first value on port p1, whereas the other is the second value on port p1. The semantics of <span class="name">port</span> and <span
+class="name">order</span> in these records are application specific.
</p>
</div>
@@ -1395,7 +1512,9 @@
<p>The assertion of a generation record implies ordering of <a title="event">events</a> in the world.</p>
-<div class='interpretation' id='generation-within-activity'><span class='conditional'>If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following temporal constraint also holds: the <a title="entity generation event">generation</a> of the entity denoted by <span class="name">x</span> <a>precedes</a> the <a title="activity end event">end</a>
+<div class='interpretation' id='generation-within-activity'><span class='conditional'>If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span
+class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following temporal constraint also holds: the <a title="entity generation
+event">generation</a> of the entity denoted by <span class="name">x</span> <a>precedes</a> the <a title="activity end event">end</a>
of <span class="name">a</span> and <a>follows</a> the <a title="activity start event">start</a> of <span class="name">a</span>.
</div>
-->
@@ -1409,10 +1528,14 @@
<!--
<p>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
The rationale for this constraint is as follows.
-If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct entities. Alternatively, for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This uniqueness constraint is formalized as follows.
-
-<div class='constraint' id='generation-uniqueness'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
-<span class='conditional'>if</span> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given account,
+If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct
+entities. Alternatively, for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this
+synchronization would constitute the actual generation of the entity, but is performed by a single activity. This uniqueness constraint is formalized as follows.
+
+<div class='constraint' id='generation-uniqueness'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span
+class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
+<span class='conditional'>if</span> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given
+account,
<span class='conditional'>then</span> <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
</div>
@@ -1420,7 +1543,12 @@
-->
+<<<<<<< local
<div class='pending'> We may want to assert the time at which an entity is created. The placeholder for such time information is a generation record. But a generation mandates the presence of an activity identifier. But it may not be known.
+=======
+<div class='issue'> We may want to assert the time at which an entity is created. The placeholder for such time information is a generation record. But a generation mandates the presence of
+an activity identifier. But it may not be known.
+>>>>>>> other
It would be nice if the activity identifier was made optional in the generation record.
This is <a href="http://www.w3.org/2011/prov/track/issues/205">ISSUE-205</a>.
<em>This is now implemented. See also <a href="http://www.w3.org/2011/prov/track/issues/43">ISSUE-43</a>.</em></div>
@@ -1432,11 +1560,14 @@
-<p>In PROV-DM, a <dfn id="dfn-Use">usage record</dfn> is a representation of an instantaneous world <a title="entity usage event">event</a>: an activity beginning to consume an entity. Before this event, the activity had not begun to consume or use to this entity.
+<p>In PROV-DM, a <dfn id="dfn-Use">usage record</dfn> is a representation of an instantaneous world <a title="entity usage event">event</a>: an activity beginning to consume an entity.
+Before this event, the activity had not begun to consume or use to this entity.
The representation includes a description of the modalities of usage of this entity by this activity.</p>
<p>
-A <a title="entity usage event">usage event</a> may be a procedure beginning to consume a parameter, a service starting to read a value on a port, a program beginning to read a configuration file, or the point at which an ingredient, such as eggs, is being added in a baking activity. Usage may entirely consume an entity (e.g. eggs are not longer available after being added to the mix), or leave it as such, ready for further uses (e.g. a file on a file system can be read indefinitely).</p>
+A <a title="entity usage event">usage event</a> may be a procedure beginning to consume a parameter, a service starting to read a value on a port, a program beginning to read a configuration
+file, or the point at which an ingredient, such as eggs, is being added in a baking activity. Usage may entirely consume an entity (e.g. eggs are not longer available after being added to
+the mix), or leave it as such, ready for further uses (e.g. a file on a file system can be read indefinitely).</p>
<p>A usage record, written <span class="name">used(id,a,e,t,attrs)</span> in PROV-ASN, has the following constituent:</p>
@@ -1481,7 +1612,10 @@
used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"])
used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])
</pre>
-<p>state that the activity, represented by the activity record identified by <span class="name">a1</span>, consumed two entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, at times <span class="name">2011-11-16T16:00:00</span> and <span class="name">2011-11-16T16:00:01</span>, respectively; the first one was found as the value of parameter <span class="name">p1</span>, whereas the second was found as value of parameter <span class="name">p2</span>. The semantics of <span class="name">parameter</span> in these records is application specific.</p>
+<p>state that the activity, represented by the activity record identified by <span class="name">a1</span>, consumed two entities, represented by entity records identified by <span
+class="name">e1</span> and <span class="name">e2</span>, at times <span class="name">2011-11-16T16:00:00</span> and <span class="name">2011-11-16T16:00:01</span>, respectively; the first
+one was found as the value of parameter <span class="name">p1</span>, whereas the second was found as value of parameter <span class="name">p2</span>. The semantics of <span
+class="name">parameter</span> in these records is application specific.</p>
</div>
@@ -1489,7 +1623,8 @@
<p>
-A usage record's id is OPTIONAL. It MUST be present when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).</p>
+A usage record's id is OPTIONAL. It MUST be present when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see
+<a href="#Derivation-Relation">Derivation Record</a>).</p>
<p>
A reference to a given entity record MAY appear in multiple usage records that share
@@ -1565,10 +1700,12 @@
between activities and plans.</p>
-<p>Thus, PROV-DM offers two kinds of records. The first, introduced in this section, represents an association between an agent, a plan, and an activity; the second, introduced in <a href="#record-responsibility">Section Responsibility record</a>, represents the fact that an agent was acting on behalf of another, in the context of an activity. </p>
-
-
-<p>An <dfn id="dfn-activity-association">activity association record</dfn>, written <span class="name">wasAssociatedWith(id,a,ag2,pl,attrs)</span> in PROV-ASN, has the following constituents:</p>
+<p>Thus, PROV-DM offers two kinds of records. The first, introduced in this section, represents an association between an agent, a plan, and an activity; the second, introduced in <a
+href="#record-responsibility">Section Responsibility record</a>, represents the fact that an agent was acting on behalf of another, in the context of an activity. </p>
+
+
+<p>An <dfn id="dfn-activity-association">activity association record</dfn>, written <span class="name">wasAssociatedWith(id,a,ag2,pl,attrs)</span> in PROV-ASN, has the following
+constituents:</p>
<ul>
<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the activity association record;</li>
<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record;</li>
@@ -1577,7 +1714,8 @@
<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of association of this activity with this agent.</li>
</ul>
-<p>In PROV-ASN, an activity association record's text matches the <span class="nonterminal">activityAssociationRecord</span> productions of the grammar defined in this specification document.</p>
+<p>In PROV-ASN, an activity association record's text matches the <span class="nonterminal">activityAssociationRecord</span> productions of the grammar defined in this specification
+document.</p>
<div class='grammar'>
<span class="nonterminal">activityAssociationRecord</span> ::=
@@ -1602,7 +1740,8 @@
entity(ex:wf,[prov:type="prov:Plan"%% xsd:QName, ex:label="Workflow 1",
ex:url="http://example.org/workflow1.bpel" %% xsd:anyURI])
</pre>
-Since the workflow <span class="name">ex:wf</span> is itself an entity, its provenance can also be expressed in PROV-DM: it can be generated by some activity and derived from other entities, for instance.
+Since the workflow <span class="name">ex:wf</span> is itself an entity, its provenance can also be expressed in PROV-DM: it can be generated by some activity and derived from other entities,
+for instance.
</div>
<div class='issue'> The activity association record does not allow for a plan to be asserted without an agent.
@@ -1619,7 +1758,8 @@
<h4>Start and End Records</h4>
<p> A <dfn id="dfn-Start">start record</dfn> is a representation of an agent starting an activity.
- An <dfn id="dfn-End">end record</dfn> is a representation of an agent ending an activity. Both relations are specialized forms of <span class="name">wasAssociatedWith</span>. They contain attributes describing the modalities of acting/ending activities.</p>
+ An <dfn id="dfn-End">end record</dfn> is a representation of an agent ending an activity. Both relations are specialized forms of <span class="name">wasAssociatedWith</span>. They contain
+attributes describing the modalities of acting/ending activities.</p>
@@ -1639,7 +1779,8 @@
<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent ended the activity.
</ul>
-<p>In PROV-ASN, start and end record's texts match the <span class="nonterminal">startRecord</span> and <span class="nonterminal">endRecord</span> productions of the grammar defined in this specification document.
+<p>In PROV-ASN, start and end record's texts match the <span class="nonterminal">startRecord</span> and <span class="nonterminal">endRecord</span> productions of the grammar defined in this
+specification document.
</p>
@@ -1722,8 +1863,10 @@
a <dfn id="dfn-responsibility">responsibility record</dfn>, written <span class="name">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-ASN, has the following constituents:</p>
<ul>
<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the responsibility record;</li>
-<li><em>subordinate</em>: an identifier <span class="name">ag2</span> for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible agent;</li>
-<li><em>responsible</em>: an identifier <span class="name">ag1</span> for an agent record, which represents the agent on behalf of which the subordinate agent <span class="name">ag2</span> acts;</li>
+<li><em>subordinate</em>: an identifier <span class="name">ag2</span> for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible
+agent;</li>
+<li><em>responsible</em>: an identifier <span class="name">ag1</span> for an agent record, which represents the agent on behalf of which the subordinate agent <span class="name">ag2</span>
+acts;</li>
<li><em>activity</em>: an OPTIONAL identifier <span class="name">a</span> of an activity record for which the responsibility record holds;</li>
<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this relation.</li>
</ul>
@@ -1744,7 +1887,9 @@
</div>
<div class="anexample">
-In the following example, a programmer, a researcher and a funder agents are asserted. The programmer and researcher are associated with a workflow activity. The programmer acts on behalf of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher. The terms 'delegation' and 'contact' used in this example are domain specific.
+In the following example, a programmer, a researcher and a funder agents are asserted. The programmer and researcher are associated with a workflow activity. The programmer acts on behalf
+of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher. The terms
+'delegation' and 'contact' used in this example are domain specific.
<pre class="codeexample">
activity(a,[prov:type="workflow"])
agent(ag1,[prov:type="programmer"])
@@ -1766,11 +1911,16 @@
<p>In PROV-DM, a <dfn id="dfn-Derivation">derivation record</dfn> is a representation that some entity is transformed from, created from, or affected by another entity in the world. </p>
-<p>Examples of derivation include the transformation of a canvas into a painting, the transportation of a person from London to New York, the transformation of a relational table into a linked data set, and the melting of ice into water.</p>
-
-
-<p>According to <a href="#conceptualization">Section Conceptualization</a>, for an entity to be transformed from, created from, or affected by another in some way, there must be some underpinning activities performing the necessary actions resulting in such a derivation.
-However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or less precise records of derivation to be asserted. Hence, PROV-DM uses the terms <em>precise</em> and <em>imprecise</em> to characterize the different kinds of derivation record. We note that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation record, that may be imprecise. </p>
+<p>Examples of derivation include the transformation of a canvas into a painting, the transportation of a person from London to New York, the transformation of a relational table into a
+linked data set, and the melting of ice into water.</p>
+
+
+<p>According to <a href="#conceptualization">Section Conceptualization</a>, for an entity to be transformed from, created from, or affected by another in some way, there must be some
+underpinning activities performing the necessary actions resulting in such a derivation.
+However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may
+not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or
+less precise records of derivation to be asserted. Hence, PROV-DM uses the terms <em>precise</em> and <em>imprecise</em> to characterize the different kinds of derivation record. We note
+that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation record, that may be imprecise. </p>
<p>The lack of precision may come from two sources:</p>
<ul>
@@ -1780,13 +1930,20 @@
<!--
-Furthermore, assuming that an asserter has full knowledge of an activity underpinning a derivation, the same activity can generally be modelled in terms of sub-activities, composed in a such a way as to deliver the same behavior. Hence, since activities can be modelled at arbitrary levels of granularity, there is a distinguished case in which a derivation between two entities <span class="name">e2</span> and <span class="name">e1</span> corresponds <em>exactly</em> to <em>one</em> activity that used <span class="name">e1</span> and generated <span class="name">e2</span>. This is to be contrasted to the case where one derivation corresponds to n activities, where n can be any number greater than 1.
+Furthermore, assuming that an asserter has full knowledge of an activity underpinning a derivation, the same activity can generally be modelled in terms of sub-activities, composed in a such
+a way as to deliver the same behavior. Hence, since activities can be modelled at arbitrary levels of granularity, there is a distinguished case in which a derivation between two entities
+<span class="name">e2</span> and <span class="name">e1</span> corresponds <em>exactly</em> to <em>one</em> activity that used <span class="name">e1</span> and generated <span
+class="name">e2</span>. This is to be contrasted to the case where one derivation corresponds to n activities, where n can be any number greater than 1.
Hence, PROV-DM uses the terms <em>one-activity</em> and <em>n-activities</em> to distinguish these two cases.</p>
-->
-<p>Hence, we can consider two axis. An activity number axis that has values <em>single</em>, <em>multiple</em>, and <em>unknown</em>, respectively representing the case where one activity is known to have occurred, more than one activities are known to have occurred, or an unknown number of activities have occurred. Likewise, we can consider another axis to cover other details (identities, generation and usage records, attributes), with values <em>asserted</em> and <em>not asserted</em>. We can then form a matrix of possible derivations. Out of the six possibilities,
-PROV-DM offers three forms of derivation derivation records to cater for five othem, while the remaining one is not meaningful. The following table summarises names for the three kinds of derivation, which we then explain.</p>
+<p>Hence, we can consider two axis. An activity number axis that has values <em>single</em>, <em>multiple</em>, and <em>unknown</em>, respectively representing the case where one activity
+is known to have occurred, more than one activities are known to have occurred, or an unknown number of activities have occurred. Likewise, we can consider another axis to cover other
+details (identities, generation and usage records, attributes), with values <em>asserted</em> and <em>not asserted</em>. We can then form a matrix of possible derivations. Out of the six
+possibilities,
+PROV-DM offers three forms of derivation derivation records to cater for five othem, while the remaining one is not meaningful. The following table summarises names for the three kinds of
+derivation, which we then explain.</p>
<div style="text-align: center;">
<table border="1" style="margin-left: auto; margin-right: auto;">
@@ -1805,7 +1962,9 @@
<li> The following cases are captured by an imprecise-n derivation record.
<ul>
<li> The asserter knows that multiple activities are involved or ignores the number of activities involved in the derivation, and other details are not asserted. </li>
-<li> The asserter knows that multiple activities are involved in the derivation, and all their details are asserted. In this case, these activities are connected by means of generated and used intermediary entities. Despite all activities and details being known, there is no guarantee that any of these activities plays an active role in the derivation; hence, this case is also regarded as imprecise. Instead, precise derivations need to be expressed between these intermediary entities. </li>
+<li> The asserter knows that multiple activities are involved in the derivation, and all their details are asserted. In this case, these activities are connected by means of generated and
+used intermediary entities. Despite all activities and details being known, there is no guarantee that any of these activities plays an active role in the derivation; hence, this case is
+also regarded as imprecise. Instead, precise derivations need to be expressed between these intermediary entities. </li>
</ul>
</ul>
@@ -1813,7 +1972,8 @@
asserting the details of an unknown number of activities is a contradiction.
</p>
-<p>In order to represent the number of activities in a derivation, we introduce a PROV-DM attribute <span class="name">steps</span>, which can take two possible values: <span class="name">single</span> and <span class="name">any</span>.
+<p>In order to represent the number of activities in a derivation, we introduce a PROV-DM attribute <span class="name">steps</span>, which can take two possible values: <span
+class="name">single</span> and <span class="name">any</span>.
When <span class="name">prov:steps="single"</span>, derivation is due to one activity; when <span class="name">prov:steps="any"</span>, the number of activities is multiple or not known.</p>
@@ -1827,34 +1987,50 @@
<li><em>activity</em>: an identifier <span class="name">a</span> of an activity record, which is a representation of the activity using and generating the above entities;</li>
<li><em>generation</em>: an identifier <span class="name">g2</span> of the generation record pertaining to <span class="name">e2</span> and <span class="name">a</span>;</li>
<li><em>usage</em>: an identifier <span class="name">u1</span> of the usage record pertaining to <span class="name">e1</span> and <span class="name">a</span>.</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation, optionally including the attribute-value pair <span class="name">prov:steps="single"</span>.</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation, optionally including the attribute-value
+pair <span class="name">prov:steps="single"</span>.</li>
</ul>
-<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in a precise-1 derivation since the record already refers to the one and only one activity underpinning the derivation.</p>
+<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in a precise-1 derivation since the record already refers to the one and only one activity underpinning the
+derivation.</p>
<p>An <dfn>imprecise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2,e1, t, attrs)</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
+<<<<<<< local
<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity;</li>
<li><em>time</em>: an OPTIONAL "generation time" <span class="name">t</span>, the time at which the entity denoted by <span class="name">e2</span> was created;</li>
<li><em>attributes</em>: a set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it MUST include the attribute-value pair <span class="name">prov:steps="single"</span>.</li>
+=======
+<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
+<li><em>attributes</em>: a set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it MUST include the attribute-value pair <span
+class="name">prov:steps="single"</span>.</li>
+>>>>>>> other
</ul>
-<p>An imprecise-1 derivation MUST include the attribute <span class="name">prov:steps</span>, since it is the only means to distinguish this record from an imprecise-n derivation record.</p>
+<p>An imprecise-1 derivation MUST include the attribute <span class="name">prov:steps</span>, since it is the only means to distinguish this record from an imprecise-n derivation
+record.</p>
<p>An <dfn>imprecise-n derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, t, attrs)</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
+<<<<<<< local
<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity;</li>
<li><em>time</em>: an OPTIONAL "generation time" <span class="name">t</span>, the time at which the entity denoted by <span class="name">e2</span> was created;</li>
<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it optionally includes the attribute-value pair <span class="name">prov:steps="any"</span>.</li>
+=======
+<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it optionally includes the attribute-value
+pair <span class="name">prov:steps="any"</span>.</li>
+>>>>>>> other
</ul>
<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in an imprecise-n derivation record. It defaults to <span class="name">prov:steps="any"</span>.</p>
-<p>None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property holds.</p>
+<p>None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property
+holds.</p>
<p>In PROV-ASN, a derivation record's text matches the <span class='nonterminal'>derivationRecord</span> production of the grammar defined in this specification document.</p>
@@ -1912,32 +2088,46 @@
entity denoted by <span class="name">e5</span> and generated it according to generation record
<span class="name">g2</span>.
+<<<<<<< local
The third record is an imprecise-1 derivation, which is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity record and associated attributes implicit. The fourth and fifth records are imprecise-n derivation records between <span class="name">e2</span> and <span class="name">e1</span>, but no information is provided as to the number and identity of activities underpinning the derivation. The six derivation records extends the fifth with the derivation time of <span class="name">e2</span>.
+=======
+The third record is an imprecise-1 derivation, which is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity record and associated attributes
+implicit. The fourth and fifth records are imprecise-n derivation records between <span class="name">e2</span> and <span class="name">e1</span>, but no information is provided as to the
+number and identity of activities underpinning the derivation.
+>>>>>>> other
</p>
</div>
-<p>An precise-1 derivation record is richer than an imprecise-1 derivation record, itself, being more informative that an imprecise-n derivation record. Hence, the following implications hold.</p>
+<p>An precise-1 derivation record is richer than an imprecise-1 derivation record, itself, being more informative that an imprecise-n derivation record. Hence, the following implications
+hold.</p>
<div class='inference' id='derivation-implications'>
-Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the assertion <span class="name">wasDerivedFrom(e2, e1, a, g2, u1, attrs)</span>
- holds for some generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, then <span class="name">wasDerivedFrom(e2,e1,[prov:steps="single"] ∪ attrs)</span> also holds.<br>
-
-Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the assertion <span class="name">wasDerivedFrom(e2, e1, [prov:steps="single"] ∪ attrs)</span>
+Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the assertion <span class="name">wasDerivedFrom(e2,
+e1, a, g2, u1, attrs)</span>
+ holds for some generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, then <span
+class="name">wasDerivedFrom(e2,e1,[prov:steps="single"] ∪ attrs)</span> also holds.<br>
+
+Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the assertion <span class="name">wasDerivedFrom(e2,
+e1, [prov:steps="single"] ∪ attrs)</span>
holds, then <span class="name">wasDerivedFrom(e2,e1,attrs)</span> also holds.<br>
</div>
<div class="interpretation-forward">
-For the interpretation of a derivation record, see <a href="#derivation-usage-generation-ordering">derivation-usage-generation-ordering</a> and <a href="#derivation-generation-generation-ordering">derivation-generation-generation-ordering</a>
+For the interpretation of a derivation record, see <a href="#derivation-usage-generation-ordering">derivation-usage-generation-ordering</a> and <a
+href="#derivation-generation-generation-ordering">derivation-generation-generation-ordering</a>
</div>
<!--
<p>
<p>If a derivation record holds for <span class="name">e2</span> and <span class="name">e1</span>, then
-this means that the entity represented by entity record identified by <span class="name">e1</span> has an influence on the entity represented entity record identified by <span class="name">e2</span>,
+this means that the entity represented by entity record identified by <span class="name">e1</span> has an influence on the entity represented entity record identified by <span
+class="name">e2</span>,
which at the minimum implies temporal ordering, specified as follows.
First, we consider one-activity derivations.</p>
-<div class='interpretation' id='derivation-usage-generation-ordering'>Given an activity record identified by <span class="name">a</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, <span class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
+<div class='interpretation' id='derivation-usage-generation-ordering'>Given an activity record identified by <span class="name">a</span>, entity records identified by <span
+class="name">e1</span> and <span class="name">e2</span>, generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, <span
+class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
or <span class="name">wasDerivedFrom(e2,e1,[prov:steps="single"] ∪ attrs)</span> holds, <span class='conditional'>then</span>
the following temporal constraint holds:
the <a title="entity usage event">usage</a>
@@ -1948,9 +2138,11 @@
<p>Then, imprecise-n derivations.</p>
<div class='interpretation' id='derivation-generation-generation-ordering'>
-Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,[prov:steps="n"] ∪ attrs)</span>
+Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the record <span
+class="name">wasDerivedFrom(e2,e1,[prov:steps="n"] ∪ attrs)</span>
holds, <span class='conditional'>then</span> the following temporal constraint holds:
-the <a title="entity generation event">generation event</a> of the entity denoted by <span class="name">e1</span> <a>precedes</a> the <a title="entity generation event">generation event</a> of
+the <a title="entity generation event">generation event</a> of the entity denoted by <span class="name">e1</span> <a>precedes</a> the <a title="entity generation event">generation event</a>
+of
the entity denoted by <span class="name">e2</span>.
</div>
@@ -1970,7 +2162,8 @@
asserted. This is formalized by the following inference rule,
referred to as <em>activity introduction</em>:</p>
<div class='inference' id="activity-introduction">
-<span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> there exist an activity record identified by <span class="name">a</span>, a usage record identified by <span class="name">u</span>, and a generation record identified by <span class="name">g</span>
+<span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> there exist an activity record identified by <span
+class="name">a</span>, a usage record identified by <span class="name">u</span>, and a generation record identified by <span class="name">g</span>
such that:
<pre class="codeexample">
activity(a,aAttrs)
@@ -2032,7 +2225,8 @@
<div class="note">This section is currently under revision and in flux</div>
-The purpose of the record types defined in this section is to establish a relationship between two entities, which asserts that they provide a different characterization of the same thing. Consider for example three entities:
+The purpose of the record types defined in this section is to establish a relationship between two entities, which asserts that they provide a different characterization of the same thing.
+Consider for example three entities:
<ul>
<li><span class="name">e1</span> denoting "Bob, the holder of facebook account ABC",
@@ -2062,9 +2256,11 @@
In order to further convey the intended meaning, the following properties are associated to these two relations.
<ul>
- <li><span class="name">specializationOf(e2,e1)</span> is <strong>transitive</strong>: <span class="name">specializationOf(e3,e2)</span> and <span class="name">specializationOf(e2,e1)</span> implies <span class="name">specializationOf(e3,e1)</span>.
-
- <li><span class="name">specializationOf(e2,e1)</span> is <strong>anti-symmetric</strong>: <span class="name">specializationOf(e2,e1)</span> implies that <span class="name">specializationOf(e1,e2)</span> does not hold.
+ <li><span class="name">specializationOf(e2,e1)</span> is <strong>transitive</strong>: <span class="name">specializationOf(e3,e2)</span> and <span
+class="name">specializationOf(e2,e1)</span> implies <span class="name">specializationOf(e3,e1)</span>.
+
+ <li><span class="name">specializationOf(e2,e1)</span> is <strong>anti-symmetric</strong>: <span class="name">specializationOf(e2,e1)</span> implies that <span
+class="name">specializationOf(e1,e2)</span> does not hold.
<li><span class="name">alternateOf(e2,e1)</span> is <strong>symmetric</strong>: <span class="name">alternateOf(e2,e1)</span> implies <span class="name">alternateOf(e1,e2)</span>.
</ul>
@@ -2088,7 +2284,9 @@
<p>
-An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to use the <span class="name">alternateOf</span> relation to link two entity record identifiers that are appear in different accounts. (In particular, the entity identifiers in two different account are allowed to be the same.). When account identifiers are not available, then the linking of entity records through <span class="name">alternateOf</span> can only take place within the scope of a single account.
+An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to use the <span class="name">alternateOf</span> relation to
+link two entity record identifiers that are appear in different accounts. (In particular, the entity identifiers in two different account are allowed to be the same.). When account
+identifiers are not available, then the linking of entity records through <span class="name">alternateOf</span> can only take place within the scope of a single account.
</p>
@@ -2149,7 +2347,8 @@
</div>
-<div class='issue'>A discussion on alternative definition of these relations has not reached a satisfactory conclusion yet. This is <a href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a>. Also <a href="http://www.w3.org/2011/prov/track/issues/96">ISSUE-96</a>.</div>
+<div class='issue'>A discussion on alternative definition of these relations has not reached a satisfactory conclusion yet. This is <a
+href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a>. Also <a href="http://www.w3.org/2011/prov/track/issues/96">ISSUE-96</a>.</div>
</section>
@@ -2157,76 +2356,24 @@
-<<<<<<< local
<!--
<section>
<h4>Transitive Derivation Record</h4>
-=======
-<!--
-
-<div style="text-align: center;">
-<img src="complement-of.png" alt="illustration complementOf"/>
-</div>
-
-
-
-
-<div class="anexample">
-<p>The following example illustrates the entity "Royal Society"and its perspectives at various points in time.</p>
-<pre class="codeexample">
-entity(rs,[ex:created=1870])
-
-entity(rs_l1,[prov:location="loc2"])
-entity(rs_l2,[prov:location="The Mall"])
-
-entity(rs_m1,[ex:membership=250, ex:year=1900])
-entity(rs_m2,[ex:membership=300, ex:year=1945])
-entity(rs_m3,[ex:membership=270, ex:year=2010])
-
-wasComplementOf(rs_m3, rs_l2)
-wasComplementOf(rs_m2, rs_l1)
-wasComplementOf(rs_m2, rs_l2)
-wasComplementOf(rs_m1, rs_l1)
-
-wasComplementOf(rs_m3, rs)
-wasComplementOf(rs_m2, rs)
-wasComplementOf(rs_m1, rs)
-wasComplementOf(rs_l1, rs)
-wasComplementOf(rs_l2, rs)
-</pre>
-</div>
-
-
-
-<div class='constraint' id='wasComplementOf-necessary-cond'>
-An assertion "wasComplementOf(B,A)" holds over the temporal intersection of A and B, <span class='conditional'>only if</span>:
-<ol>
-<li> if a mapping can be established from an attribute X of entity record identified by B to an attribute Y of entity record identified by A, then the values of A and B must be consistent with that mapping;</li>
-<li>entity record identified by B has some attribute that entity record identified by A does not have.</li>
-</ol>
- </div>
-
-<p>The complementarity relation is not transitive. Let us consider identifiers <span class="name">e1</span>, <span class="name">e2</span>, and <span class="name">e3</span> identifying three entity records such that
- <span class="name">wasComplementOf(e3,e2)</span> and <span class="name">wasComplementOf(e2,e1)</span> hold. The record <span class="name">wasComplementOf(e3,e1)</span> may not hold because the characterization intervals of the denoted entity records may not overlap.</p>
-
->>>>>>> other
<p>
-<<<<<<< local
-If <span class="name">wasDerivedFrom(e2,e1)</span> holds because attribute <span class="name">a2.1</span> of <span class="name">e2</span> is determined by attribute <span class="name">a1.1</span> of <span class="name">e1</span>,
-and if <span class="name">wasDerivedFrom(e3,e2)</span> holds because attribute <span class="name">a3.1</span>of <span class="name">e3</span> is determined by attribute <span class="name">a2.2</span> of <span class="name">e1</span>, it is not necessarily the case that an attribute of <span class="name">e3</span> is determined by an attribute of <span class="name">e1</span>; so, an asserter may not be able to assert <span class="name">wasDerivedFrom(e3,e1)</span>, since it would fail to satisfy constraint <a href="#derivation-attributes">derivation-attributes</a>. Hence, the constraint on attributes as expressed in <a href="#derivation-attributes">derivation-attributes</a> invalidates transitivity in the general case.
-=======
-An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to link two entity record identifiers that are appear in different accounts. (In particular, the entity record identifiers in two different account are allowed to be the same.). When account identifiers are not available, then the linking of entity records through complementarity can only take place within the scope of a single account.
->>>>>>> other
+If <span class="name">wasDerivedFrom(e2,e1)</span> holds because attribute <span class="name">a2.1</span> of <span class="name">e2</span> is determined by attribute <span
+class="name">a1.1</span> of <span class="name">e1</span>,
+and if <span class="name">wasDerivedFrom(e3,e2)</span> holds because attribute <span class="name">a3.1</span>of <span class="name">e3</span> is determined by attribute <span
+class="name">a2.2</span> of <span class="name">e1</span>, it is not necessarily the case that an attribute of <span class="name">e3</span> is determined by an attribute of <span
+class="name">e1</span>; so, an asserter may not be able to assert <span class="name">wasDerivedFrom(e3,e1)</span>, since it would fail to satisfy constraint <a
+href="#derivation-attributes">derivation-attributes</a>. Hence, the constraint on attributes as expressed in <a href="#derivation-attributes">derivation-attributes</a> invalidates
+transitivity in the general case.
</p>
-<<<<<<< local
-<p>However, there is sense that <span class="name">e3</span> still depends on <span class="name">e1</span>, since <span class="name">e3</span> could not be generated without <span class="name">e1</span> existing. Hence, we introduce a weaker notion of derivation record, which is transitive.</p>
-=======
->>>>>>> other
-
-<<<<<<< local
+<p>However, there is sense that <span class="name">e3</span> still depends on <span class="name">e1</span>, since <span class="name">e3</span> could not be generated without <span
+class="name">e1</span> existing. Hence, we introduce a weaker notion of derivation record, which is transitive.</p>
+
A transitive derivation record, written <span class="name">dependedOn(e2, e1)</span> in PROV-ASN:
<ul>
<li> contains an identifier <span class="name">e2</span>, denoting an entity record, which represents the entity that is the result of the derivation;
@@ -2235,53 +2382,20 @@
<p>The record <span class="name">dependedOn</span> can only be inferred; in other words, it cannot be asserted. It is
transitive by definition and relies on the previously defined derivation assertions for its
base case.</p>
-=======
-<div class="anexample">
-<p>In the following example, the same description of the Royal Society is structured according to two different accounts. In the second account, we find a complementarity record linking <span class="name">rs_m1</span> in account <span class="name">ex:acc2</span> to
-<span class="name">rs</span> in account <span class="name">ex:acc1</span>.
-<pre class="codeexample">
-account(ex:acc1,
- http://example.org/asserter1,
->>>>>>> other
-
-<<<<<<< local
+
<div class='constraint' id='transitive-derivation'>
<ul>
-<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> or <span class="name">wasDerivedFrom(e2,e1,pe,attrs2,attrs1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
-<li><span class='conditional'>If</span> <span class="name">wasEventuallyDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
-<li><span class='conditional'>If</span> <span class="name">dependedOn(e3,e2)</span> and <span class="name">dependedOn(e2,e1)</span> hold, <span class='conditional'>then</span> <span class="name">dependedOn(e3,e1)</span> holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> or <span class="name">wasDerivedFrom(e2,e1,pe,attrs2,attrs1)</span> holds, <span
+class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasEventuallyDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span>
+holds.</li>
+<li><span class='conditional'>If</span> <span class="name">dependedOn(e3,e2)</span> and <span class="name">dependedOn(e2,e1)</span> hold, <span class='conditional'>then</span> <span
+class="name">dependedOn(e3,e1)</span> holds.</li>
</ul>
-=======
- ...
- entity(rs,[ex:created=1870])
- ...
- )
-
-
-account(ex:acc2,
- http://example.org/asserter2,
-
- ...
- entity(rs_m1,[ex:membership=250, ex:year=1900])
- ...
- wasComplementOf(rs_m1, ex:acc2, rs, ex:acc1)
-
-)
-</pre>
->>>>>>> other
</div>
-<<<<<<< local
</section>
-=======
-
->>>>>>> other
-->
-<<<<<<< local
-=======
-
-
->>>>>>> other
@@ -2293,7 +2407,10 @@
<h4>Annotation Record</h4>
-<p>An <dfn id="dfn-annotation">annotation record</dfn> establishes a link between an identifiable PROV-DM record and a note record referred to by its identifier. Multiple note records can be associated with a given PROV-DM record; symmetrically, multiple PROV-DM records can be associated with a given note record. Since note records have identifiers, they can also be annotated. The annotation mechanism (with note record and the annotation record) forms a key aspect of the extensibility mechanism of PROV-DM (see <a href="#extensibility-section">extensibility section</a>).</p>
+<p>An <dfn id="dfn-annotation">annotation record</dfn> establishes a link between an identifiable PROV-DM record and a note record referred to by its identifier. Multiple note records can
+be associated with a given PROV-DM record; symmetrically, multiple PROV-DM records can be associated with a given note record. Since note records have identifiers, they can also be
+annotated. The annotation mechanism (with note record and the annotation record) forms a key aspect of the extensibility mechanism of PROV-DM (see <a
+href="#extensibility-section">extensibility section</a>).</p>
<p>An annotation record, written <span class="name">hasAnnotation(r,n,attrs)</span> in PROV-ASN, has the following constituents:</p>
<ul>
@@ -2317,7 +2434,8 @@
<span class="name">)</span>
</div>
-<p>The interpretation of notes is application-specific. See Section <a href="#record-note">Note</a> for a discussion of the difference between note attributes and other records attributes. We also note the present tense in this term to indicate that it may not denote something in the past.</p>
+<p>The interpretation of notes is application-specific. See Section <a href="#record-note">Note</a> for a discussion of the difference between note attributes and other records attributes.
+We also note the present tense in this term to indicate that it may not denote something in the past.</p>
<div class="anexample">
<p>
@@ -2336,7 +2454,11 @@
note(n2,[ex:style="dotted"])
hasAnnotation(u1,n2)
</pre>
-<p>assert the existence of two documents in the world (attribute-value pair: <span class="name">prov:type="document"</span>) identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these records with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also asserts an activity, its usage of the first entity, and its generation of the second entity. The <span class="name">usage</span> record is annotated with a style (an application specific way of rendering this edge graphically). To be able to express this annotation, the usage record was provided with an identifier <span class="name">u1</span>, which was then referred to in <span class="name">hasAnnotation(u1,n2)</span>.
+<p>assert the existence of two documents in the world (attribute-value pair: <span class="name">prov:type="document"</span>) identified by <span class="name">e1</span> and <span
+class="name">e2</span>, and annotate these records with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also
+asserts an activity, its usage of the first entity, and its generation of the second entity. The <span class="name">usage</span> record is annotated with a style (an application specific way
+of rendering this edge graphically). To be able to express this annotation, the usage record was provided with an identifier <span class="name">u1</span>, which was then referred to in <span
+class="name">hasAnnotation(u1,n2)</span>.
</p>
</div>
@@ -2360,14 +2482,18 @@
<p>It is common for multiple provenance records to co-exist. For instance, when emailing
a file, there could be a provenance record kept by the mail client,
- and another by the mail server. Such provenance records may provide different explanations about something happening in the world, because they are created by different parties or observed by different witnesses. A given party could also create multiple provenance records about an execution, to capture different levels of details, targeted at different end-users: the programmer of an experiment may be interested in a detailed log of execution, while the scientists may focus more on the scientific-level description. Given that multiple provenance records can co-exist, it is important to know who asserted these records. </p>
+ and another by the mail server. Such provenance records may provide different explanations about something happening in the world, because they are created by different parties or observed
+by different witnesses. A given party could also create multiple provenance records about an execution, to capture different levels of details, targeted at different end-users: the
+programmer of an experiment may be interested in a detailed log of execution, while the scientists may focus more on the scientific-level description. Given that multiple provenance
+records can co-exist, it is important to know who asserted these records. </p>
<p>In PROV-DM, an <dfn id="dfn-Account">account record</dfn> is a wrapper of records with the following purposes: </p>
<ul>
<li> It is the mechanism by which attribution of provenance can be assserted; it allows asserters to bundle up their assertions, and assert suitable attribution;</li>
<li> It provides a scoping mechanism for the uniqueness of identifiers (of elements and relations of PROV-DM);</li>
<li> It provides a scoping mechanism for structural contraints (such as
- <a href="#generation-uniqueness">generation-uniqueness</a> and <a href="#derivation-use">derivation-use</a> discussed in Section <a href="#structural-constraints">structural-constraints</a>).</li>
+ <a href="#generation-uniqueness">generation-uniqueness</a> and <a href="#derivation-use">derivation-use</a> discussed in Section <a
+href="#structural-constraints">structural-constraints</a>).</li>
</ul>
@@ -2397,7 +2523,8 @@
</div>
<div class='issue'>
-Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI and its interpretation is outside PROV-DM. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM assertions. The editors seek inputs on how to resolve this issue.
+Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI and its interpretation is outside PROV-DM. We may want the asserter to be an agent instead, and
+therefore use PROV-DM to express the provenance of PROV-DM assertions. The editors seek inputs on how to resolve this issue.
We seek inputs on how to resolve this issue. This is <a href="http://www.w3.org/2011/prov/track/issues/217">ISSUE-217</a>. </div>
<div class="anexample" id="account-example-1">
@@ -2416,20 +2543,32 @@
...
wasAssociatedWith(a4, ag5, [prov:role="communicator"]) )
</pre>
-<p>contains the set of provenance records of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span class="name">http://example.org/asserter</span>, and is identified by identifier <span class="name">ex:acc0</span>.
+<p>contains the set of provenance records of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span
+class="name">http://example.org/asserter</span>, and is identified by identifier <span class="name">ex:acc0</span>.
</p>
</div>
-<p> An identifier in a record within the scope of an account is intended to denote a single record. However, nothing prevents an asserter from asserting an account containing, for example, multiple entity records with a same identifier but different attribute-values. In that case, they should be understood as a single entity record with this identifier and the union of all attributes values, as formalized in <a href="#identifiable-record-in-account">identifiable-record-in-account</a>.</p>
+<p> An identifier in a record within the scope of an account is intended to denote a single record. However, nothing prevents an asserter from asserting an account containing, for example,
+multiple entity records with a same identifier but different attribute-values. In that case, they should be understood as a single entity record with this identifier and the union of all
+attributes values, as formalized in <a href="#identifiable-record-in-account">identifiable-record-in-account</a>.</p>
<div class='constraint' id='identifiable-record-in-account'>
<p>Given an entity record identifier <span class="name">e</span>, two sets of attribute-values denoted by <span class="name">av1</span> and <span class="name">av2</span>,
- two entity records <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account are equivalent to the entity record <span class="name">entity(e,av)</span> where <span class="name">av</span> is the set of attribute-value pairs formed by the union of <span class="name">av1</span> and <span class="name">av2</span>.</p>
-
-<p>This constraint similarly applies to all other types of records. As a result, the identifier that occurs in a record is unique and acts as a local identifier for that record in that account.</p>
+ two entity records <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account are equivalent to the entity record <span
+class="name">entity(e,av)</span> where <span class="name">av</span> is the set of attribute-value pairs formed by the union of <span class="name">av1</span> and <span
+class="name">av2</span>.</p>
+
+<p>This constraint similarly applies to all other types of records. As a result, the identifier that occurs in a record is unique and acts as a local identifier for that record in that
+account.</p>
</div>
+<<<<<<< local
<p>Whilst constraint <a href="#identifiable-record-in-account">identifiable-record-in-account</a> specifies how to understand multiple entity records with a same identifier within a given account, it does not guarantee that the entity record formed with the union of all attribute-value pairs satisfies the <a>attribute occurrence validity</a> property, as illustrated by the following example.</p>
+=======
+<p>Whilst constraint <a href="#identifiable-entity-in-account">identifiable-entity-in-account</a> specifies how to understand multiple entity records with a same identifier within a given
+account, it does not guarantee that the entity record formed with the union of all attribute-value pairs satisfies the <a>attribute occurrence validity</a> property, as illustrated by the
+following example.</p>
+>>>>>>> other
<div class="anexample">
<p>
@@ -2441,7 +2580,15 @@
entity(e,[prov:type="person", ex:weight=50, ex:age=30])
...)
</pre>
+<<<<<<< local
<p>Application of <a href="#identifiable-record-in-account">identifiable-record-in-account</a> results in an entity record containing the attribute-value pairs <span class="name">age=20</span>, <span class="name">weight=50</span>, and <span class="name">age=30</span>. The namespace referred to by prefix <span class="name">ex</span> declares the number of occurrences that are permitted for each attribute. The resulting entity record may or may not satisfy the <a>attribute occurrence validity</a>, depending on this namespace. For instance, if the namespace referred to by <span class="name">ex</span> declares that <span class="name">age</span> must have at most one occurrence, then the resulting entity record does not satisfy the <a>attribute occurrence validity</a> property. This document does not specify how to handle such an entity record.
+=======
+<p>Application of <a href="#identifiable-entity-in-account">identifiable-entity-in-account</a> results in an entity record containing the attribute-value pairs <span
+class="name">age=20</span>, <span class="name">weight=50</span>, and <span class="name">age=30</span>. The namespace referred to by prefix <span class="name">ex</span> declares the number of
+occurrences that are permitted for each attribute. The resulting entity record may or may not satisfy the <a>attribute occurrence validity</a>, depending on this namespace. For instance, if
+the namespace referred to by <span class="name">ex</span> declares that <span class="name">age</span> must have at most one occurrence, then the resulting entity record does not satisfy the
+<a>attribute occurrence validity</a> property. This document does not specify how to handle such an entity record.
+>>>>>>> other
</p></div>
<p>Account records can be nested since an account record can occur among the records being wrapped by another account. </p>
@@ -2474,16 +2621,24 @@
wasGeneratedBy(e0,a1,[ex:fct="create"])
... )
</pre>
-<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span class="name">a0</span> in the previous account <span class="name">ex:acc0</span>. If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together, the resulting set of records violates <a href="#generation-uniqueness">generation-uniqueness</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are distinct.</p>
+<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by
+entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span
+class="name">a0</span> in the previous account <span class="name">ex:acc0</span>. If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together,
+the resulting set of records violates <a href="#generation-uniqueness">generation-uniqueness</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are
+distinct.</p>
</div>
-->
-<p>Account records constitute a scope for identifier uniqueness. Since accounts can be nested, scopes can also be nested; thus, the requirement on uniqueness of identifiers should be understood in the context of such nested scopes. When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur. </p>
+<p>Account records constitute a scope for identifier uniqueness. Since accounts can be nested, scopes can also be nested; thus, the requirement on uniqueness of identifiers should be
+understood in the context of such nested scopes. When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account,
+except in sub-accounts where records with the same identifier occur. </p>
<div class="anexample">
<p>
-The following account record is inspired from section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>. This account, identified by <span class="name">ex:acc3</span>, declares entity record with identifier <span class="name">e0</span>, which is being referred to in the nested account <span class="name">ex:acc4</span>. Identifier <span class="name">e0</span> is uniquely identify a record in account <span class="name">ex:acc3</span>, including subaccount <span class="name">ex:acc4</span>.</p>
+The following account record is inspired from section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>. This account, identified by <span class="name">ex:acc3</span>,
+declares entity record with identifier <span class="name">e0</span>, which is being referred to in the nested account <span class="name">ex:acc4</span>. Identifier <span
+class="name">e0</span> is uniquely identify a record in account <span class="name">ex:acc3</span>, including subaccount <span class="name">ex:acc4</span>.</p>
<pre class="codeexample">
account(ex:acc3,
http://example.org/asserter1,
@@ -2497,14 +2652,17 @@
wasGeneratedBy(e1,a0,[ex:fct="create"])
wasComplementOf(e1,e0)))
</pre>
-<p>Alternatively, an activity record identified by <span class="name">a0</span> occurs in each of the two accounts. Therefore, each activity record is asserted in a separate scope, and therefore may represent different activities in the world.
+<p>Alternatively, an activity record identified by <span class="name">a0</span> occurs in each of the two accounts. Therefore, each activity record is asserted in a separate scope, and
+therefore may represent different activities in the world.
</p>
</div>
-<p>The identifier of an account record is expected to be globally unique, whereas identifiers for other records are expected to be unique within the scope of the account in which their record occurs. </p>
-
-
-<p>The account record is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. The annotation mechanism can be used for this purpose, but how general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>
+<p>The identifier of an account record is expected to be globally unique, whereas identifiers for other records are expected to be unique within the scope of the account in which their
+record occurs. </p>
+
+
+<p>The account record is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. The annotation mechanism can be used
+for this purpose, but how general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>
<div class="structural-forward">
See Section <a href="#structural-constraints">structural-constraints</a> for a structural constraint on account records.
@@ -2516,15 +2674,21 @@
<section id="RecordContainer">
<h4>Record Container</h4>
-<p>A <dfn id="dfn-RecordContainer">record container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM <a title="record">records</a>. A record container is the root of a provenance record and can be exploited to package up PROV-DM <a title="record">records</a> in response to a request for the provenance of something ([[!PROV-AQ]]). Given that a record container is the root of a provenance record, it is not defined as a PROV-DM record (production <span class="nonterminal">record</span>), since otherwise it could appear arbitrarily nested inside accounts.</p>
+<p>A <dfn id="dfn-RecordContainer">record container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM <a title="record">records</a>. A record container is the
+root of a provenance record and can be exploited to package up PROV-DM <a title="record">records</a> in response to a request for the provenance of something ([[!PROV-AQ]]). Given that a
+record container is the root of a provenance record, it is not defined as a PROV-DM record (production <span class="nonterminal">record</span>), since otherwise it could appear arbitrarily
+nested inside accounts.</p>
<p>A record container, written <span class="name">container decls recs endContainer</span> in PROV-ASN, contains:
<ul>
-<li><em>namespaceDeclarations</em>: a set <span class="name">decls</span> of namespace declarations, declaring namespaces and associated prefixes, which can be used in <a title="attribute">attributes</a> and <a title="identifier">identifiers</a> occurring inside <span class="name">recs</span>;</li>
+<li><em>namespaceDeclarations</em>: a set <span class="name">decls</span> of namespace declarations, declaring namespaces and associated prefixes, which can be used in <a
+title="attribute">attributes</a> and <a title="identifier">identifiers</a> occurring inside <span class="name">recs</span>;</li>
<li><em>records</em>: a non-empty set of records <span class="name">recs</span>.</li>
</ul>
-<p>All the records in <span class="name">recs</span> are implictly wrapped in a default account, scoping all the record identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts. Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a container's default account.</p>
+<p>All the records in <span class="name">recs</span> are implictly wrapped in a default account, scoping all the record identifiers they declare directly, and constituting a toplevel
+account, in the hierarchy of accounts. Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a
+container's default account.</p>
<p>In PROV-ASN, a record container's text matches the <span class="nonterminal">recordContainer</span> production of the grammar defined in this specification document.</p>
@@ -2554,7 +2718,8 @@
agent(ag2, [ prov:type="prov:Person" %% xsd:QName, ex:name="Bob" ])
endContainer
</pre>
-<p>This container could for instance be returned by querying a provenance store for the provenance of entity <span class="name">e2</span> [[!PROV-AQ]]. All these assertions are implicitly wrapped in a default account. In the absence of an explicit account, such provenance records remain unattributed.
+<p>This container could for instance be returned by querying a provenance store for the provenance of entity <span class="name">e2</span> [[!PROV-AQ]]. All these assertions are implicitly
+wrapped in a default account. In the absence of an explicit account, such provenance records remain unattributed.
</p>
</div>
@@ -2569,7 +2734,8 @@
account(ex:acc2,http://example.org/asserter1,...)
endContainer
</pre>
-<p> illustrates how two accounts with identifiers <span class="name">ex:acc1</span> and <span class="name">ex:acc2</span> can be returned in a PROV-ASN serialization of the provenance of something.
+<p> illustrates how two accounts with identifiers <span class="name">ex:acc1</span> and <span class="name">ex:acc2</span> can be returned in a PROV-ASN serialization of the provenance of
+something.
</p>
</div>
@@ -2591,11 +2757,13 @@
<h4>Attribute</h4>
<p>An <dfn id="dfn-attribute">attribute</dfn> is a <em>qualified name</em>.
-An <dfn id="dfn-qualified name">qualified name</dfn> is a name subject to namespace interpretation. It consists of namespace, denoted by an optional prefix, and a local name. The namespace is denoted by an IRI [[!IRI]].</p>
+An <dfn id="dfn-qualified name">qualified name</dfn> is a name subject to namespace interpretation. It consists of namespace, denoted by an optional prefix, and a local name. The namespace
+is denoted by an IRI [[!IRI]].</p>
<p>PROV-DM stipulates that a qualified name can be mapped into an IRI
- by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
+ by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a
+href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
<p>A qualified name's prefix is OPTIONAL. If a prefix occurs in a
qualified name, it refers to a <a>namespace</a> declared in the
@@ -2609,8 +2777,10 @@
<span class="nonterminal">qualifiedName</span> ::= <span class="nonterminal">prefixedName</span> | <span class="nonterminal">unprefixedName</span><br/>
<span class="nonterminal">prefixedName</span> ::= <span class="nonterminal">prefix</span> <span class="name">:</span> <span class="nonterminal">localPart</span><br/>
<span class="nonterminal">unprefixedName</span> ::= <span class="nonterminal">localPart</span><br/>
-<span class="nonterminal">prefix</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [[!XML-NAMES]]</em><br/>
-<span class="nonterminal">localPart</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [[!XML-NAMES]]</em>
+<span class="nonterminal">prefix</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production
+[[!XML-NAMES]]</em><br/>
+<span class="nonterminal">localPart</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production
+[[!XML-NAMES]]</em>
</div>
@@ -2632,7 +2802,9 @@
<p>The PROV data model introduces a fixed set of attributes in the <a href="#prov-dm-namespace">PROV-DM namespace</a>:</p>
<ul>
-<li> The attribute <dfn id="dfn-role"><span class="name">prov:role</span></dfn> denotes the function of an entity with respect to an activity, in the context of a usage, generation, activity association, start, end record. The attribute <span class="name">prov:role</span> is allowed to occur multiple times in such records. The value associated with a <span class="name">prov:role</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>. </li>
+<li> The attribute <dfn id="dfn-role"><span class="name">prov:role</span></dfn> denotes the function of an entity with respect to an activity, in the context of a usage, generation,
+activity association, start, end record. The attribute <span class="name">prov:role</span> is allowed to occur multiple times in such records. The value associated with a <span
+class="name">prov:role</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>. </li>
<div class="anexample">
<p>The following start record describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
@@ -2642,8 +2814,10 @@
</div>
</li>
-<li> The attribute <dfn id="dfn-type"><span class="name">prov:type</span></dfn> provides further typing information for the element or relation asserted in the record. PROV-DM liberally defines a type as a category of things having common characteristics. PROV-DM is agnostic about the representation of types, and only states that
-the value associated with a <span class="name">prov:type</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>. The attribute <span class="name">prov:type</span> is allowed to occur multiple times in a record.</li>
+<li> The attribute <dfn id="dfn-type"><span class="name">prov:type</span></dfn> provides further typing information for the element or relation asserted in the record. PROV-DM liberally
+defines a type as a category of things having common characteristics. PROV-DM is agnostic about the representation of types, and only states that
+the value associated with a <span class="name">prov:type</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>. The attribute <span class="name">prov:type</span>
+is allowed to occur multiple times in a record.</li>
<div class="anexample">
<p>The following record declares an agent of type software agent</p>
@@ -2653,10 +2827,14 @@
</div>
-<li> The attribute <dfn id="dfn-steps"><span class="name">prov:steps</span></dfn> defines the level of precision associated with a derivation record. The value associated with a <span class="name">prov:steps</span> attribute MUST be <span class="name">"single"</span> or <span class="name">"any"</span>. The attribute <span class="name">prov:step</span> occurs at most once in a derivation record. A derivation record without attribute <span class="name">prov:step</span> is considered to be equivalent to the same record extended with an extra attribute <span class="name">prov:step</span> and associated value <span class="name">"any"</span>. </li>
+<li> The attribute <dfn id="dfn-steps"><span class="name">prov:steps</span></dfn> defines the level of precision associated with a derivation record. The value associated with a <span
+class="name">prov:steps</span> attribute MUST be <span class="name">"single"</span> or <span class="name">"any"</span>. The attribute <span class="name">prov:step</span> occurs at most
+once in a derivation record. A derivation record without attribute <span class="name">prov:step</span> is considered to be equivalent to the same record extended with an extra attribute
+<span class="name">prov:step</span> and associated value <span class="name">"any"</span>. </li>
<div class="anexample">
-<p>The following record declares an imprecise-1 derivation, which is known to involve one activity, though its identity, usage details of <span class="name">ex:e1</span>, and generation details of <span class="name">ex:e2</span> are not asserted.</p>
+<p>The following record declares an imprecise-1 derivation, which is known to involve one activity, though its identity, usage details of <span class="name">ex:e1</span>, and generation
+details of <span class="name">ex:e2</span> are not asserted.</p>
<pre class="codeexample">
wasDerivedFrom(ex:e2, ex:e1, [prov:steps="single"])
</pre>
@@ -2678,7 +2856,8 @@
<p>An <dfn id="dfn-identifier">identifier</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
- by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
+ by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a
+href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
<div class='grammar'>
<span class="nonterminal">identifier</span> ::= <span class="nonterminal">qualifiedName</span><br/>
@@ -2710,7 +2889,8 @@
<span class="nonterminal">datatype</span> ::= <span class="nonterminal">qualifiedName</span><br/>
<span class="nonterminal">convenienceNotation</span> ::= <span class="nonterminal">stringLiteral</span> | <span class="nonterminal">intLiteral</span><br/>
<span class="nonterminal">stringLiteral</span> ::= <span class="nonterminal">quotedString</span><br/>
-<span class="nonterminal">quotedString</span> ::= <em>a finite sequence of characters in which " (U+22) and \ (U+5C) occur only in pairs of the form \" (U+5C, U+22) and \\ (U+5C, U+5C), enclosed in a pair of " (U+22) characters</em><br/>
+<span class="nonterminal">quotedString</span> ::= <em>a finite sequence of characters in which " (U+22) and \ (U+5C) occur only in pairs of the form \" (U+5C, U+22) and \\ (U+5C,
+U+5C), enclosed in a pair of " (U+22) characters</em><br/>
<span class="nonterminal">intLiteral</span> ::= <em>a finite-length sequence of decimal digits (#x30-#x39) with an optional leading negative sign (-)</em>
</div>
@@ -2724,7 +2904,8 @@
<div class="anexample">
<p>
-The following examples respectively are the string "abc" (expressed using the convenience notation), the string "abc", the integer number 1, the integer number 1 (expressed using the convenience notation) and the IRI "http://example.org/foo".
+The following examples respectively are the string "abc" (expressed using the convenience notation), the string "abc", the integer number 1, the integer number 1 (expressed using the
+convenience notation) and the IRI "http://example.org/foo".
<pre class="codeexample">
"abc"
"abc" %% xsd:string
@@ -2777,22 +2958,27 @@
</div>
<div class='issue'>
-Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM. We seek inputs on how to resolve this issue. This is <a href="http://www.w3.org/2011/prov/track/issues/217">ISSUE-217</a></div>
+Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance
+of PROV-DM. We seek inputs on how to resolve this issue. This is <a href="http://www.w3.org/2011/prov/track/issues/217">ISSUE-217</a></div>
</section>
<section id="record-NamespaceDeclaration">
<h3>Namespace Declaration</h3>
-<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [[!IRI]]. In PROV-DM, attributes, identifiers, and literals of with datatype <span class="name">xsd:QName</span> can be placed in a namespace using the mechanisms described in this specification. </p>
-
-
-<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this declaration refers to this namespace.
-A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration refers to this namespace.</p>
+<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [[!IRI]]. In PROV-DM, attributes, identifiers, and literals of with datatype <span
+class="name">xsd:QName</span> can be placed in a namespace using the mechanisms described in this specification. </p>
+
+
+<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this
+declaration refers to this namespace.
+A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration
+refers to this namespace.</p>
<div class='grammar'>
<span class="nonterminal">namespaceDeclarations</span> ::=
- | <span class="group"><span class="nonterminal">defaultNamespaceDeclaration</span> | <span class="nonterminal">namespaceDeclaration</span></span> <span class="star"> <span class="nonterminal">namespaceDeclaration</span></span><br>
+ | <span class="group"><span class="nonterminal">defaultNamespaceDeclaration</span> | <span class="nonterminal">namespaceDeclaration</span></span> <span class="star"> <span
+class="nonterminal">namespaceDeclaration</span></span><br>
<span class="nonterminal">namespaceDeclaration</span> ::=
<span class="name">prefix</span> <span class="nonterminal">prefix</span> <span class="nonterminal">IRI</span><br/>
<span class="nonterminal">defaultNamespaceDeclaration</span> ::=
@@ -2808,11 +2994,13 @@
<section id="record-Location">
<h3>Location</h3>
-<p><dfn id="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, row, column, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations in assertions. </p>
+<p><dfn id="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate,
+address, landmark, row, column, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations in assertions. </p>
<p>
-Location is an OPTIONAL attribute of entity records and activity records. The value associated with a attribute <span class="name">location</span> MUST be a <span class="nonterminal">Literal</span>, expected to denote a location.
+Location is an OPTIONAL attribute of entity records and activity records. The value associated with a attribute <span class="name">location</span> MUST be a <span
+class="nonterminal">Literal</span>, expected to denote a location.
</p>
@@ -2843,9 +3031,13 @@
<section id="record-traceability">
<h3>Traceability Record</h3>
-<p> It is common that we may want to know who or what may have some influence, whether direct or indirect, on a given entity, or who may, directly or not, have some responsibility for a given outcome. Hence, we may want to infer such a notion from an existing set of PROV-DM records. Vice-versa, we may have knowledge of this influence and responsibility, but without knowing its actual details. Thus, we may also want to assert such a notion. </p>
-
-<p> A <dfn id="dfn-Traceability">traceability record</dfn> states the existence of a "dependency path" between two entities, indicating that one entity can be shown to be in the lineage of another, and may have influenced it, or may bear some responsibility for it, in some way. The traceability relation subsumes derivation, activity association, and responsibility, and is defined to be transitive. </p>
+<p> It is common that we may want to know who or what may have some influence, whether direct or indirect, on a given entity, or who may, directly or not, have some responsibility for a
+given outcome. Hence, we may want to infer such a notion from an existing set of PROV-DM records. Vice-versa, we may have knowledge of this influence and responsibility, but without
+knowing its actual details. Thus, we may also want to assert such a notion. </p>
+
+<p> A <dfn id="dfn-Traceability">traceability record</dfn> states the existence of a "dependency path" between two entities, indicating that one entity can be shown to be in the lineage of
+another, and may have influenced it, or may bear some responsibility for it, in some way. The traceability relation subsumes derivation, activity association, and responsibility, and is
+defined to be transitive. </p>
<p> A traceability record, written <span class="name">tracedTo(id,e2,e1,attrs)</span> in PROV-ASN, contains the following components:</p>
<ul>
@@ -2871,40 +3063,56 @@
<span class="name">)</span>
</div>
-<p>A traceability record can be inferred from existing records, or can be asserted stating that such a dependency path exists without the asserter knowing its individual steps, as expressed by the following inference and constraint, respectively.
+<p>A traceability record can be inferred from existing records, or can be asserted stating that such a dependency path exists without the asserter knowing its individual steps, as expressed
+by the following inference and constraint, respectively.
<div class='inference' id='traceability-inference'>
Given two identifiers <span class="name">e2</span> and <span class="name">e1</span> identifying entity records,
the following statements hold:
<ol>
-<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span class="name">u1</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
-<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
-<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr) and wasAssociatedWith(a,e1)</span> hold, for some <span class="name">a</span> and <span class="name">gAttr</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
-<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span class="name">actedOnBehalfOf(e,e1)</span> hold, for some <span class="name">a</span>, <span class="name">e</span>, and <span class="name">gAttr</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
-<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr) and wasStartedBy(a,e1,sAttr)</span> hold, for some <span class="name">a</span>, <span class="name">e</span>, and <span class="name">gAttr</span>, and <span class="name">sAttr</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
-<li><span class='conditional'>If</span> <span class="name">tracedTo(e2,e)</span> and <span class="name">tracedTo(e,e1)</span> hold for some <span class="name">e</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span
+class="name">u1</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also
+holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr) and wasAssociatedWith(a,e1)</span> hold, for some <span class="name">a</span> and <span
+class="name">gAttr</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span
+class="name">actedOnBehalfOf(e,e1)</span> hold, for some <span class="name">a</span>, <span class="name">e</span>, and <span class="name">gAttr</span>, <span
+class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr) and wasStartedBy(a,e1,sAttr)</span> hold, for some <span class="name">a</span>, <span
+class="name">e</span>, and <span class="name">gAttr</span>, and <span class="name">sAttr</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also
+holds.</li>
+<li><span class='conditional'>If</span> <span class="name">tracedTo(e2,e)</span> and <span class="name">tracedTo(e,e1)</span> hold for some <span class="name">e</span>, <span
+class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
</ol>
</div>
<p>We note that the inference rule <a href="#traceability-inference">traceability-inference</a> does not allow us to infer attributes, which are record and application specific. </p>
<div class='constraint' id='traceability-assertion'>
-<span class='conditional'>If</span> the record <span class="name">tracedTo(r2,r1,attrs)</span> holds for two identifiers <span class="name">r2</span> and <span class="name">r1</span> identifying entity records, and attribute-value pairs <span class="name">attrs</span>,
+<span class='conditional'>If</span> the record <span class="name">tracedTo(r2,r1,attrs)</span> holds for two identifiers <span class="name">r2</span> and <span class="name">r1</span>
+identifying entity records, and attribute-value pairs <span class="name">attrs</span>,
<span class='conditional'>then</span> there exist
-<span class="name">e<sup>0</sup></span>, <span class="name">e<sup>1</sup></span>, ..., <span class="name">e<sup>n</sup></span> for <span class="name">n≥1</span>, with <span class="name">e<sup>0</sup></span>=<span class="name">r2</span> and <span class="name">e<sup>n</sup></span>=<span class="name">r1</span>, and
+<span class="name">e<sup>0</sup></span>, <span class="name">e<sup>1</sup></span>, ..., <span class="name">e<sup>n</sup></span> for <span class="name">n≥1</span>, with <span
+class="name">e<sup>0</sup></span>=<span class="name">r2</span> and <span class="name">e<sup>n</sup></span>=<span class="name">r1</span>, and
for any i such that <span class="name">0≤i≤n-1</span>, at least of the following statements holds:
<ul>
-<li> <span class="name">wasDerivedFrom(e<sup>i</sup>,e<sup>i+1</sup>,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span class="name">u1</span>, or</li>
+<li> <span class="name">wasDerivedFrom(e<sup>i</sup>,e<sup>i+1</sup>,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span class="name">u1</span>,
+or</li>
<li> <span class="name">wasDerivedFrom(e<sup>i</sup>,e<sup>i+1</sup>)</span> holds, or</li>
<li> <span class="name">wasBasedOn(e<sup>i</sup>,e<sup>i+1</sup>)</span> holds, or</li>
-<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasAssociatedWith(a,e<sup>i+1</sup>)</span> hold, for some <span class="name">a</span> and <span class="name">gAttr</span>, or</li>
-<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span class="name">actedOnBehalfOf(e,e<sup>i+1</sup>)</span> hold, for some <span class="name">a</span>, <span class="name">e</span> and <span class="name">gAttr</span>, or</li>
-<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasStartedBy(a,e<sup>i+1</sup>,sAttr)</span> hold, for some <span class="name">a</span>, <span class="name">e</span>, and <span class="name">gAttr</span>, and <span class="name">sAttr</span>.</li>
+<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasAssociatedWith(a,e<sup>i+1</sup>)</span> hold, for some <span class="name">a</span> and <span
+class="name">gAttr</span>, or</li>
+<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span class="name">actedOnBehalfOf(e,e<sup>i+1</sup>)</span> hold,
+for some <span class="name">a</span>, <span class="name">e</span> and <span class="name">gAttr</span>, or</li>
+<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasStartedBy(a,e<sup>i+1</sup>,sAttr)</span> hold, for some <span class="name">a</span>, <span class="name">e</span>, and
+<span class="name">gAttr</span>, and <span class="name">sAttr</span>.</li>
</ul>
</div>
-<p>We note that the previous constraint is not really an inference <em>rule</em>, since there is nothing that we can actually infer. Instead, this constraint should simply be seen as part of the definition of the traceability record. </p>
+<p>We note that the previous constraint is not really an inference <em>rule</em>, since there is nothing that we can actually infer. Instead, this constraint should simply be seen as part
+of the definition of the traceability record. </p>
</section>
@@ -2982,7 +3190,8 @@
<!--
<div class='interpretation' id='wasInformedBy-ordering'>
-Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span class="name">wasInformedBy(a2,a1)</span>
+Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span
+class="name">wasInformedBy(a2,a1)</span>
holds, <span class='conditional'>then</span> the following temporal constraint holds:
the <a title="activity start event">start event</a> of the activity record denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity end event">end event</a> of
the activity record denoted by <span class="name">a2</span>.
@@ -2996,7 +3205,12 @@
</pre>
<p> We cannot infer <span class="name">wasInformedBy(a3,a1)</span> from them. Indeed,
from
-<span class="name">wasInformedBy(a2,a1)</span>, we know that there exists <span class="name">e1</span> such that <span class="name">e1</span> was generated by <span class="name">a1</span> and used by <span class="name">a2</span>. Likewise, from <span class="name">wasInformedBy(a3,a2)</span>, we know that there exists <span class="name">e2</span> such that <span class="name">e2</span> was generated by <span class="name">a2</span> and used by <span class="name">a3</span>. The following illustration shows a case for which transitivity cannot hold. 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>
+<span class="name">wasInformedBy(a2,a1)</span>, we know that there exists <span class="name">e1</span> such that <span class="name">e1</span> was generated by <span class="name">a1</span>
+and used by <span class="name">a2</span>. Likewise, from <span class="name">wasInformedBy(a3,a2)</span>, we know that there exists <span class="name">e2</span> such that <span
+class="name">e2</span> was generated by <span class="name">a2</span> and used by <span class="name">a3</span>. The following illustration shows a case for which transitivity cannot hold. 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>
<div style="text-align: center;">
<img src="informedByNonTransitive.png" alt="non transitivity of wasInformedBy" />
@@ -3024,19 +3238,23 @@
and <span class="name">wasStartedBy(a2,e,sAttr)</span> hold.
</div>
-<p>We note that a <a>start record</a> associates an activity with an agent, and is denoted by the name <span class="name">wasStartedBy</span>. A <a>control ordering record</a> associates an activity with another activity, also denoted by the name <span class="name">wasStartedBy</span>. Effectively, by considering both record types, the relation <span class="name">wasStartedBy</span> has a range formed by the union of agents and activities.</p>
+<p>We note that a <a>start record</a> associates an activity with an agent, and is denoted by the name <span class="name">wasStartedBy</span>. A <a>control ordering record</a> associates an
+activity with another activity, also denoted by the name <span class="name">wasStartedBy</span>. Effectively, by considering both record types, the relation <span
+class="name">wasStartedBy</span> has a range formed by the union of agents and activities.</p>
<div class="anexample">
<p>
-In the following assertions, we find two activity records, identified by <span class="name">a1</span> and <span class="name">a2</span>, representing two activities, which took place on two separate hosts. The third record indicates that the latter activity was started by the former.</p>
+In the following assertions, we find two activity records, identified by <span class="name">a1</span> and <span class="name">a2</span>, representing two activities, which took place on two
+separate hosts. The third record indicates that the latter activity was started by the former.</p>
<pre class="codeexample">
activity(a1,t1,t2,[ex:host="server1.example.org",prov:type="workflow"])
activity(a2,t3,t4,[ex:host="server2.example.org",prov:type="subworkflow"])
wasStartedBy(a2,a1)
</pre>
-<p>Alternatively, we could have asserted the existence of an entity, representing a request to create a sub-workflow. This request, issued by <span class="name">a1</span>, triggered the start of <span class="name">a2</span>.
+<p>Alternatively, we could have asserted the existence of an entity, representing a request to create a sub-workflow. This request, issued by <span class="name">a1</span>, triggered the
+start of <span class="name">a2</span>.
</p>
<pre class="codeexample">
entity(e,[prov:type="creation-request"])
@@ -3056,7 +3274,8 @@
<section id="record-Revision">
<h3>Revision Record</h3>
-<p> A <dfn id="dfn-Revision">revision record</dfn> is a representation of the creation of an entity considered to be a variant of another. Deciding whether something is made available as a revision of something else usually involves an agent who represents someone in the world who takes responsibility for approving that the former is a due variant of the latter. </p>
+<p> A <dfn id="dfn-Revision">revision record</dfn> is a representation of the creation of an entity considered to be a variant of another. Deciding whether something is made available as a
+revision of something else usually involves an agent who represents someone in the world who takes responsibility for approving that the former is a due variant of the latter. </p>
<p> A revision record, written <span class="name">wasRevisionOf(e2,e1,ag,attrs)</span> in PROV-ASN, contains:</p>
<ul>
@@ -3092,7 +3311,8 @@
<div class='inference' id='wasRevision'>
Given two identifiers <span class="name">old</span> and <span class="name">new</span> identifying two entities, and an identifier <span class="name">ag</span> identifying an agent,
<span class='conditional'>if</span> a record <span class="name">wasRevisionOf(new,old,ag)</span> is asserted, <span class='conditional'>then</span>
-there exists an entity record identifier <span class="name">e</span> and attribute-values <span class="name">eAttrs</span>, <span class="name">dAttrs</span>, such that the following records hold:
+there exists an entity record identifier <span class="name">e</span> and attribute-values <span class="name">eAttrs</span>, <span class="name">dAttrs</span>, such that the following records
+hold:
<ul>
<li> <span class="name">wasDerivedFrom(new,old,dAttrs)</span>;
<li> <span class="name">entity(e,eAttrs)</span>;
@@ -3117,7 +3337,8 @@
entity(e2,[prov:type="document"])
wasRevisionOf(e2,e1,ag)
</pre>
-<p>states that the document represented by entity record identified by <span class="name">e2</span> is a revision of document represented by entity record identified by <span class="name">e1</span>; agent denoted by <span class="name">ag</span> is responsible for this new versioning of the document.
+<p>states that the document represented by entity record identified by <span class="name">e2</span> is a revision of document represented by entity record identified by <span
+class="name">e1</span>; agent denoted by <span class="name">ag</span> is responsible for this new versioning of the document.
</p>
</div>
@@ -3138,7 +3359,8 @@
<li><em>agent</em>: an identifier <span class="name">ag</span> of an agent whom the entity is attributed to;</li>
<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>
-<p>Attribution models the notion of an activity generating an entity identified by <span class="name">e</span> being associated with an agent <span class="name">ag</span>, which takes responsibility for generating <span class="name">e</span>. Formally, this is expressed as the following necessary condition.</p>
+<p>Attribution models the notion of an activity generating an entity identified by <span class="name">e</span> being associated with an agent <span class="name">ag</span>, which takes
+responsibility for generating <span class="name">e</span>. Formally, this is expressed as the following necessary condition.</p>
<div class='inference' id='attribution-implication'>
@@ -3304,19 +3526,30 @@
<a href="http://www.w3.org/2011/prov/track/issues/135">ISSUE-139</a>
</div>
-Activity-entity assertions account for the provenance of entities in terms of how they are produced and consumed. The <em>collection</em> assertions introduced in this section complement those by offering a family of entity-entity assertions that can be used to express structural relationships amongst entities. Specifically, their purpose is to enable modelling of part-of relationships amongst entities. In particular, a form of <strong>collection</strong> entity type is introduced, consisting of a <strong>set of key-value pairs</strong>. Key-value pairs provide a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more.<p/>
+Activity-entity assertions account for the provenance of entities in terms of how they are produced and consumed. The <em>collection</em> assertions introduced in this section complement
+those by offering a family of entity-entity assertions that can be used to express structural relationships amongst entities. Specifically, their purpose is to enable modelling of part-of
+relationships amongst entities. In particular, a form of <strong>collection</strong> entity type is introduced, consisting of a <strong>set of key-value pairs</strong>. Key-value pairs
+provide a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages),
+relational tables, ordered lists, and more.<p/>
Collections are entities that contain <strong>sets</strong> of key-value pairs. Both keys and values are also entities.
-The following record types are introduced to model (a) insertion of a new key-value pair into a collection and (c) removal of a key-value pair from a collection. Optionally, the time at which the insertion/deletion takes places can be specified.
-
-<p> Record: <span class="name">CollectionAfterInsertion(c2,c1, k, v, [t])</span> denotes that collection <span class="name">c2</span> is an updated version of collection <span class="name">c1</span>, following the insertion of pair <span class="name">(k,v)</span> into <span class="name">c1</span> (at time t).</p>
-
-<p> Record: <span class="name">CollectionAfterRemoval(c2,c1, k, [t])</span> denotes that collection <span class="name">c2</span> is an updated version of collection <span class="name">c1</span>, following the removal of pair <span class="name">(k,v)</span> from <span class="name">c1</span> (at time t), where <span class="name">v</span> is the value corresponding to key <span class="name">k</span> in <span class="name">c1</span>.</p>
-
-The intent of these records is to capture the history of changes to a collection, using <em>copy semantics</em>. This means that each insertion/removal operation generates a new collection, rather than updating the collection in place. Because these assertions state the derivation of a collection from another, formally they are specializations of the <a href="#record-Derivation"><strong>wasDerivedFrom</strong></a> relation, specifically precise-1 or imprecise-1.
-
-<div class="note">Given the specific nature of the derivation, the intervening activity that accounts for imprecise-1 derivation should have an equally specific type, such as" collection-insertion" and "collection-removal". This is left for a future version.</div>
+The following record types are introduced to model (a) insertion of a new key-value pair into a collection and (c) removal of a key-value pair from a collection. Optionally, the time at
+which the insertion/deletion takes places can be specified.
+
+<p> Record: <span class="name">CollectionAfterInsertion(c2,c1, k, v, [t])</span> denotes that collection <span class="name">c2</span> is an updated version of collection <span
+class="name">c1</span>, following the insertion of pair <span class="name">(k,v)</span> into <span class="name">c1</span> (at time t).</p>
+
+<p> Record: <span class="name">CollectionAfterRemoval(c2,c1, k, [t])</span> denotes that collection <span class="name">c2</span> is an updated version of collection <span
+class="name">c1</span>, following the removal of pair <span class="name">(k,v)</span> from <span class="name">c1</span> (at time t), where <span class="name">v</span> is the value
+corresponding to key <span class="name">k</span> in <span class="name">c1</span>.</p>
+
+The intent of these records is to capture the history of changes to a collection, using <em>copy semantics</em>. This means that each insertion/removal operation generates a new collection,
+rather than updating the collection in place. Because these assertions state the derivation of a collection from another, formally they are specializations of the <a
+href="#record-Derivation"><strong>wasDerivedFrom</strong></a> relation, specifically precise-1 or imprecise-1.
+
+<div class="note">Given the specific nature of the derivation, the intervening activity that accounts for imprecise-1 derivation should have an equally specific type, such as"
+collection-insertion" and "collection-removal". This is left for a future version.</div>
Because of the <strong>copy semantics</strong> interpretation of collection manipulation, one cannot have two assertions of the form:<br/>
<span class="name">CollectionAfterInsertion(c2,c1, k1, v1, t1)</span><br/>
@@ -3329,9 +3562,12 @@
<span class="name">CollectionAfterInsertion(c3,c2, k, v', t2)</span><br/>
are interpreted as follows:<br/>
<span class="name">c2</span> was derived from <span class="name">c1</span> by adding pair <span class="name">(k,v)</span> to it (at time <span class="name">t1</span>).
-Then <span class="name">c3</span> was derived from <span class="name">c2</span> by replacing value <span class="name">v</span> with value <span class="name">v'</span> for key <span class="name">k</span>. Notice that, as an additional requirement, if both <span class="name">t1, t2</span> are specified, then <span class="name">t2>t1</span> must hold.<p/>
-
-A set of assertions that involve these records makes it possible, potentially, to obtain the the state of a collection at a certain point <span class="name">t</span> in time, by retrieving all the assertions that account for a sequence of changes to an original collections. Thus, the state of a collection can be reconstructed by means of a query (the specification of such query, however, is out of the scope of the PROV language).</br>
+Then <span class="name">c3</span> was derived from <span class="name">c2</span> by replacing value <span class="name">v</span> with value <span class="name">v'</span> for key <span
+class="name">k</span>. Notice that, as an additional requirement, if both <span class="name">t1, t2</span> are specified, then <span class="name">t2>t1</span> must hold.<p/>
+
+A set of assertions that involve these records makes it possible, potentially, to obtain the the state of a collection at a certain point <span class="name">t</span> in time, by retrieving
+all the assertions that account for a sequence of changes to an original collections. Thus, the state of a collection can be reconstructed by means of a query (the specification of such
+query, however, is out of the scope of the PROV language).</br>
There are two caveats to the statement above.
<ul>
@@ -3339,9 +3575,11 @@
<li>Firstly, for the reconstruted state of a collection to be complete, it is necessary to assert a starting point in time, when the collection begins to exist.
This is done by introducing the built-in type <span class="name">collection</span> for entities. Specifically, the assertion:</br>
<span class="name">entity(e, [prov:type="collection"]</span>
-is interpreted to mean that <span class="name">e</span> is a collection. If nothing else is known about the contents of <span class="name">e</span>, then it is assumed to be an empty collection.<p/>
-
-<li>Secondly, the <em>complete</em> state of a collection at a certain time may not be known, because there is no guarantee that all real insertion/deletion events have been recorded using collection assertions (note that the problem of state completeness is common to other provenance assertions, and not specific to the case of collections or part-of relations).
+is interpreted to mean that <span class="name">e</span> is a collection. If nothing else is known about the contents of <span class="name">e</span>, then it is assumed to be an empty
+collection.<p/>
+
+<li>Secondly, the <em>complete</em> state of a collection at a certain time may not be known, because there is no guarantee that all real insertion/deletion events have been recorded using
+collection assertions (note that the problem of state completeness is common to other provenance assertions, and not specific to the case of collections or part-of relations).
</ul>
@@ -3361,7 +3599,9 @@
</pre>
</div>
-Note that <span class="name">c</span> is a collection by the initial entity record assertion, while <span class="name">c1, c2, c3</span> are known to be collections as a consequence of their involvement in collection derivation assertions. Note also that the state of <span class="name">c3</span> can be obtained by querying the chain of derivations assertions involving insertions and removals, up to the starting point, <span class="name">c</span>.<p/>
+Note that <span class="name">c</span> is a collection by the initial entity record assertion, while <span class="name">c1, c2, c3</span> are known to be collections as a consequence of their
+involvement in collection derivation assertions. Note also that the state of <span class="name">c3</span> can be obtained by querying the chain of derivations assertions involving insertions
+and removals, up to the starting point, <span class="name">c</span>.<p/>
The following example illustrates how copy semantics may lead to multiple derivations from a single root collection, possibly by different asserters:
@@ -3431,7 +3671,8 @@
<section id="constraints">
<h2>PROV-DM Constraints</h2>
-<p>The previous two sections have introduced a data model for provenance, without introducing any constraint that this data model has to satisfy. In this section, we explore the constraints that this data model has to satisfy. </p>
+<p>The previous two sections have introduced a data model for provenance, without introducing any constraint that this data model has to satisfy. In this section, we explore the constraints
+that this data model has to satisfy. </p>
<section id="interpretation">
<h3>PROV-DM Interpretation</h3>
@@ -3481,7 +3722,8 @@
activities. The four kind of <a title="event">instantaneous events</a> are represented by vertical
dotted lines (adjacent to the vertical sides of an activity's
rectangle, or intersecting usage and generation edges). The ordering
-constraints are represented by triangles: an occurrence of a triangle between two <a title="event">instantaneous event</a> vertical dotted lines represents that the event denoted by the left line precedes the event denoted by the right line.</p>
+constraints are represented by triangles: an occurrence of a triangle between two <a title="event">instantaneous event</a> vertical dotted lines represents that the event denoted by the left
+line precedes the event denoted by the right line.</p>
<div style="text-align: center;">
<img src="constraints.png" alt="constraints between events" />
@@ -3489,24 +3731,29 @@
</div>
-<p>The mere existence of an activity assertion entails some <a>event</a> ordering in the world, since an <a>activity start event</a> always <a>precedes</a> the corresponding <a>activity end event</a>. This is
+<p>The mere existence of an activity assertion entails some <a>event</a> ordering in the world, since an <a>activity start event</a> always <a>precedes</a> the corresponding <a>activity end
+event</a>. This is
illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (a) and expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
<div class='interpretation' id='start-precedes-end'> The following ordering constraint holds for any activity record: the
<a title="activity start event">start event</a> <a>precedes</a> the <a title="activity end event">end event</a>.</div>
-<p> Assertion of a usage record and a generation record for a given entity implies ordering of <a title="event">events</a> in the world, since the <a title="entity generation event">generation event</a> had to precede the <a title="entity usage event">usage event</a>. This is
+<p> Assertion of a usage record and a generation record for a given entity implies ordering of <a title="event">events</a> in the world, 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="#constraint-summary">constraint-summary</a> (b) and expressed by constraint <a href="#generation-precedes-usage">generation-precedes-usage</a>.</p>
-<div class='interpretation' id='generation-precedes-usage'>For any entity, the following ordering constraint holds: the <a title="entity generation event">generation</a> of an entity always <a>precedes</a> any of its <a title="entity usage event">usages</a>.
+<div class='interpretation' id='generation-precedes-usage'>For any entity, the following ordering constraint holds: the <a title="entity generation event">generation</a> of an entity always
+<a>precedes</a> any of its <a title="entity usage event">usages</a>.
</div>
<p>The assertion of a usage record implies ordering of <a title="event">events</a> in the world, since the corresponding event had to occur during the associated activity. This is
illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (c) and expressed by constraint <a href="#usage-within-activity">usage-within-activity</a>.</p>
-<div class='interpretation' id='usage-within-activity'>Given an activity record identified by <span class="name">a</span>, an entity record identified by <span class="name">e</span>, a set of attribute-value pairs <span class="name">attrs</span>, and optional time <span class="name">t</span>, <span class='conditional'>if</span>
+<div class='interpretation' id='usage-within-activity'>Given an activity record identified by <span class="name">a</span>, an entity record identified by <span class="name">e</span>, a set
+of attribute-value pairs <span class="name">attrs</span>, and optional time <span class="name">t</span>, <span class='conditional'>if</span>
assertion <span class="name">used(a,e,attrs)</span> or <span class="name">used(a,e,attrs,t)</span> holds, <span class='conditional'>then</span> the following ordering constraint holds:
- the <a title="entity usage event">usage</a> of the entity represented by entity record identified by <span class="name">e</span> <a>precedes</a> the <a title="activity end event">end</a> of activity represented by record identified by <span class="name">a</span> and <a>follows</a> its <a title="activity start event">start</a>.
+ the <a title="entity usage event">usage</a> of the entity represented by entity record identified by <span class="name">e</span> <a>precedes</a> the <a title="activity end event">end</a> of
+activity represented by record identified by <span class="name">a</span> and <a>follows</a> its <a title="activity start event">start</a>.
</div>
@@ -3514,7 +3761,9 @@
<p>The assertion of a generation record implies ordering of <a title="event">events</a> in the world, since the corresponding event had to occur during the associated activity. This is
illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (d) and expressed by constraint <a href="#generation-within-activity">generation-within-activity</a>.</p>
-<div class='interpretation' id='generation-within-activity'><span class='conditional'>If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following ordering constraint also holds: the <a title="entity generation event">generation</a> of the entity denoted by <span class="name">x</span> <a>precedes</a> the <a title="activity end event">end</a>
+<div class='interpretation' id='generation-within-activity'><span class='conditional'>If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span
+class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following ordering constraint also holds: the <a title="entity generation
+event">generation</a> of the entity denoted by <span class="name">x</span> <a>precedes</a> the <a title="activity end event">end</a>
of <span class="name">a</span> and <a>follows</a> the <a title="activity start event">start</a> of <span class="name">a</span>.
</div>
@@ -3523,12 +3772,16 @@
<p>If a derivation record holds for <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.
-First, we consider one-activity derivations. 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>.
+First, we consider one-activity derivations. 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="#constraint-summary">constraint-summary</a> (e) and expressed by constraint <a href="#derivation-usage-generation-ordering">derivation-usage-generation-ordering</a>.</p>
-
-
-<div class='interpretation' id='derivation-usage-generation-ordering'>Given an activity record identified by <span class="name">a</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, <span class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (e) and expressed by constraint <a
+href="#derivation-usage-generation-ordering">derivation-usage-generation-ordering</a>.</p>
+
+
+<div class='interpretation' id='derivation-usage-generation-ordering'>Given an activity record identified by <span class="name">a</span>, entity records identified by <span
+class="name">e1</span> and <span class="name">e2</span>, generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, <span
+class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
or <span class="name">wasDerivedFrom(e2,e1,[prov:steps="single"] ∪ attrs)</span> holds, <span class='conditional'>then</span>
the following ordering constraint holds:
the <a title="entity usage event">usage</a>
@@ -3536,13 +3789,17 @@
the entity denoted by <span class="name">e2</span>.
</div>
-<p>For imprecise-n derivations, a similar constraint exists, but in this case, no usage record can be inferred for <span class="name">e1</span>. Instead, the constraint refers to its generation event, as
-illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (f) and expressed by constraint <a href="#derivation-generation-generation-ordering">derivation-generation-generation-ordering</a>.</p>
+<p>For imprecise-n derivations, a similar constraint exists, but in this case, no usage record can be inferred for <span class="name">e1</span>. Instead, the constraint refers to its
+generation event, as
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (f) and expressed by constraint <a
+href="#derivation-generation-generation-ordering">derivation-generation-generation-ordering</a>.</p>
<div class='interpretation' id='derivation-generation-generation-ordering'>
-Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,[prov:steps="any"] ∪ attrs)</span>
+Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the record <span
+class="name">wasDerivedFrom(e2,e1,[prov:steps="any"] ∪ attrs)</span>
holds, <span class='conditional'>then</span> the following ordering constraint holds:
-the <a title="entity generation event">generation event</a> of the entity denoted by <span class="name">e1</span> <a>precedes</a> the <a title="entity generation event">generation event</a> of
+the <a title="entity generation event">generation event</a> of the entity denoted by <span class="name">e1</span> <a>precedes</a> the <a title="entity generation event">generation event</a>
+of
the entity denoted by <span class="name">e2</span>.
</div>
@@ -3553,22 +3810,27 @@
imprecise-n derivation, nothing is known about the usage of <span class="name">e1</span>,
since there is no associated activity.</p>
-<p>The assertion of an information flow ordering record between two activities of <span class="name">a1</span> and <span class="name">a2</span> also implies ordering of <a title="event">events</a> in the world, since some entity must have been generated by the former and used by the later, which implies that the start event of <span class="name">a1</span> cannot follow the end event of <span class="name">a2</span>. This is
+<p>The assertion of an information flow ordering record between two activities of <span class="name">a1</span> and <span class="name">a2</span> also implies ordering of <a
+title="event">events</a> in the world, since some entity must have been generated by the former and used by the later, which 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="#constraint-summary">constraint-summary</a> (g) and expressed by constraint <a href="#wasInformedBy-ordering">wasInformedBy-ordering</a>.</p>
<div class='interpretation' id='wasInformedBy-ordering'>
-Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span class="name">wasInformedBy(a2,a1)</span>
+Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span
+class="name">wasInformedBy(a2,a1)</span>
holds, <span class='conditional'>then</span> the following ordering constraint holds:
the <a title="activity start event">start event</a> of the activity record denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity end event">end event</a> of
the activity record denoted by <span class="name">a2</span>.
</div>
-<p>The assertion of a control flow ordering record between two activities of <span class="name">a1</span> and <span class="name">a2</span> also implies ordering of <a title="event">events</a> in the world, since <span class="name">a1</span> must have been active before <span class="name">a2</span> started. This is
+<p>The assertion of a control flow ordering record between two activities of <span class="name">a1</span> and <span class="name">a2</span> also implies ordering of <a
+title="event">events</a> in the world, since <span class="name">a1</span> must have been active before <span class="name">a2</span> started. This is
illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (h) and expressed by constraint <a href="#wasStartedBy-ordering">wasStartedBy-ordering</a>.</p>
<div class='interpretation' id='wasStartedBy-ordering'>
-Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span class="name">wasStartedBy(a2,a1)</span>
+Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span
+class="name">wasStartedBy(a2,a1)</span>
holds, <span class='conditional'>then</span> the following ordering constraint holds: the
<a title="activity start event">start</a> event of the activity record denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity start event">start event</a> of
the activity record denoted by <span class="name">a2</span>.
@@ -3593,20 +3855,28 @@
-<p>Sections 5 and 6 define a data model for provenance, which, for the most part, is unconstrained. Section 7.1 defines an interpretation of this data model, in terms of event ordering constraints. This section introduces further constraints on the structure of PROV-DM records. Records that satisfy these constraints are said to be <dfn>structurally well-formed</dfn>. A benefit of structurally well-formed provenance records is that further inferences can be made, because records are more precise, and therefore, richer. </p>
-
-<p>According to the definition of a <a>generation record</a>, an entity becomes available after this entity's generation event, and does not exist before this event. From this definition, we conclude that PROV-DM does not allow for an entity to have two generation records occurring at two different instants.
+<p>Sections 5 and 6 define a data model for provenance, which, for the most part, is unconstrained. Section 7.1 defines an interpretation of this data model, in terms of event ordering
+constraints. This section introduces further constraints on the structure of PROV-DM records. Records that satisfy these constraints are said to be <dfn>structurally well-formed</dfn>. A
+benefit of structurally well-formed provenance records is that further inferences can be made, because records are more precise, and therefore, richer. </p>
+
+<p>According to the definition of a <a>generation record</a>, an entity becomes available after this entity's generation event, and does not exist before this event. From this definition,
+we conclude that PROV-DM does not allow for an entity to have two generation records occurring at two different instants.
The rationale for this constraint is as follows.
- Two distinct <a title="entity generation event">generation events</a> (by a same activity or by two distinct activities), occurring one after the other, necessarily create two distinct entities; otherwise, the second <a title="entity generation event">generation event</a> would have resulted in an entity that existed before its creation, which contradicts the definition of <a>generation record</a>.</p>
-
-<p>So, PROV-DM allows for two distinct <a>generation records</a> <span class="name">g1</span> and <span class="name">g2</span> referencing a same entity record provided they occur <em>simultaneously</em>.
+ Two distinct <a title="entity generation event">generation events</a> (by a same activity or by two distinct activities), occurring one after the other, necessarily create two distinct
+entities; otherwise, the second <a title="entity generation event">generation event</a> would have resulted in an entity that existed before its creation, which contradicts the definition of
+<a>generation record</a>.</p>
+
+<p>So, PROV-DM allows for two distinct <a>generation records</a> <span class="name">g1</span> and <span class="name">g2</span> referencing a same entity record provided they occur
+<em>simultaneously</em>.
<!-- (This means that <span class="name">g1</span> <a>precedes</a> <span class="name">g2</span> and <span class="name">g2</span> <a>precedes</a> <span class="name">g1</span>.) -->
- In practice, for such a simultaneous generation to occur, the generation event has to be unique and caused by a <em>single world activity</em>, though the provenance records may contain different activity records providing alternative descriptions of that same world activity.
+ In practice, for such a simultaneous generation to occur, the generation event has to be unique and caused by a <em>single world activity</em>, though the provenance records may contain
+different activity records providing alternative descriptions of that same world activity.
</p>
<div class="anexample">
<p>
-In the following assertions, 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>
+In the following assertions, 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"])
@@ -3616,17 +3886,22 @@
wasGeneratedBy(e,a0)
wasGeneratedBy(e,a2)
</pre>
-This example is permitted in PROV-DM if the two activity records <span class="name">a0</span> and <span class="name">a2</span> provide alternate descriptions of what happens in the world with respect to this generation event.
+This example is permitted in PROV-DM if the two activity records <span class="name">a0</span> and <span class="name">a2</span> provide alternate descriptions of what happens in the world
+with respect to this generation event.
</div>
-<p>While this example is permitted in PROV-DM, it does not expose the hierarchical organization of executions and it mixes records providing two descriptions of a same execution. This issue is highlighted by two different <a title="generation record">generation records</a> for entity <span class="name">e</span>, which makes reasoning about this kind of provenance records unnecessarily difficult. Such assertions are said not be structurally well-formed.</p>
-
-<p>Structurally well-formed provenance records can be obtained by partitioning the generation records into different accounts. This makes it clear that these records provide alternative descriptions of the same real-world generation event, rather than describing two generation events for the same entity. When accounts are used, the example can be encoded as follows.</p>
+<p>While this example is permitted in PROV-DM, it does not expose the hierarchical organization of executions and it mixes records providing two descriptions of a same execution. This issue
+is highlighted by two different <a title="generation record">generation records</a> for entity <span class="name">e</span>, which makes reasoning about this kind of provenance records
+unnecessarily difficult. Such assertions are said not be structurally well-formed.</p>
+
+<p>Structurally well-formed provenance records can be obtained by partitioning the generation records into different accounts. This makes it clear that these records provide alternative
+descriptions of the same real-world generation event, rather than describing two generation events for the same entity. When accounts are used, the example can be encoded as follows.</p>
<div class="anexample">
<p>
-The same example is now revisited, with the following assertions that are structurally well-formed. Two accounts are introduced, and there is a single generation record for entity <span class="name">e</span> per account.</p>
+The same example is now revisited, with the following assertions that are structurally well-formed. Two accounts are introduced, and there is a single generation record for entity <span
+class="name">e</span> per account.</p>
<pre class="codeexample">
account(ex:summary,
http://example.org/asserter,
@@ -3647,16 +3922,21 @@
<!--
<p>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
The rationale for this constraint is as follows.
-If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct entities. Alternatively, for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This uniqueness constraint is formalized as follows.
+If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct
+entities. Alternatively, for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this
+synchronization would constitute the actual generation of the entity, but is performed by a single activity. This uniqueness constraint is formalized as follows.
-->
-<p>Structurally well-formed records satisfy some constraints, which force the structure of descriptions to be exposed by means of accounts. With these constraints satisfied, further inferences can be made about structurally well-formed records.
+<p>Structurally well-formed records satisfy some constraints, which force the structure of descriptions to be exposed by means of accounts. With these constraints satisfied, further
+inferences can be made about structurally well-formed records.
The uniqueness of generation records in accounts is formulated as follows.
</p>
-<div class='constraint' id='generation-uniqueness'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
-<span class='conditional'>if</span> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given account,
+<div class='constraint' id='generation-uniqueness'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span
+class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
+<span class='conditional'>if</span> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given
+account,
<span class='conditional'>then</span> <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
</div>
@@ -3664,11 +3944,14 @@
<p>A further inference is permitted from the imprecise-1 derivation record: </p>
<div class='inference' id='derivation-use'>
-<p>Given an activity record identified by <span class="name">a</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and set of attribute-value pairs <span class="name">attrs2</span>,
-<span class='conditional'>if</span> <span class="name">wasDerivedFrom(e2,e1, [prov:steps="single"])</span> and <span class="name">wasGeneratedBy(e2,a,attrs2)</span> hold, <span class='conditional'>then</span> <span class="name">used(a,e1,attrs1)</span> also holds
+<p>Given an activity record identified by <span class="name">a</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and set of attribute-value
+pairs <span class="name">attrs2</span>,
+<span class='conditional'>if</span> <span class="name">wasDerivedFrom(e2,e1, [prov:steps="single"])</span> and <span class="name">wasGeneratedBy(e2,a,attrs2)</span> hold, <span
+class='conditional'>then</span> <span class="name">used(a,e1,attrs1)</span> also holds
for some set of attribute-value pairs <span class="name">attrs1</span>.
</div>
-<p>This inference is justified by the fact that the entity represented by entity record identified by <span class="name">e2</span> is generated by at most one activity in a given account (see <a href="#generation-uniqueness">generation-uniqueness</a>). Hence, this activity record is also the one referred to in the usage record of <span class="name">e1</span>.
+<p>This inference is justified by the fact that the entity represented by entity record identified by <span class="name">e2</span> is generated by at most one activity in a given account
+(see <a href="#generation-uniqueness">generation-uniqueness</a>). Hence, this activity record is also the one referred to in the usage record of <span class="name">e1</span>.
</p>
@@ -3681,7 +3964,8 @@
<p>
An account is said to be structurally well-formed if
-it satisfies the constraint <a href="#generation-uniqueness">generation-uniqueness</a>. If an account is structurally well-formed, it support the inference <a href="#derivation-use">derivation-use</a>.</p>
+it satisfies the constraint <a href="#generation-uniqueness">generation-uniqueness</a>. If an account is structurally well-formed, it support the inference <a
+href="#derivation-use">derivation-use</a>.</p>
<p> The union of two accounts is another account,
containing the unions of their respective records, where
@@ -3705,7 +3989,11 @@
wasGeneratedBy(e0,a1,[ex:fct="create"])
... )
</pre>
-<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span class="name">a0</span> in the previous account <span class="name">ex:acc0</span>. If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together, the resulting set of records violates <a href="#generation-uniqueness">generation-uniqueness</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are distinct.</p>
+<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by
+entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span
+class="name">a0</span> in the previous account <span class="name">ex:acc0</span>. If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together,
+the resulting set of records violates <a href="#generation-uniqueness">generation-uniqueness</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are
+distinct.</p>
</div>
@@ -3715,14 +4003,16 @@
<div class="note" id="note-related-to-issue-105">
-Satya discussed the example of a sculpture, whose hand and leg are sculpted independently by two different sculptors. He suggested that the sculpture is generated by two distinct activities. This section explains that it is not the case. The example can be formulated as follows.
+Satya discussed the example of a sculpture, whose hand and leg are sculpted independently by two different sculptors. He suggested that the sculpture is generated by two distinct activities.
+This section explains that it is not the case. The example can be formulated as follows.
<p><a href="examples/sculpture.prov-asn">Sculpture example in ASN</a></p>
<p><a href="examples/sculpture.png">Sculpture example image</a></p>
<p>
-We see that ex:s_3 (the sculpture in its final state) was derived from ex:l_2 (containment) which was generated by ex:a2. However, ex:s_3 is not directly generated by ex:a2. We may want to consider an abbreviation for this: wasGeneratedBy*(ex:s_3,ex:a2).</p>
+We see that ex:s_3 (the sculpture in its final state) was derived from ex:l_2 (containment) which was generated by ex:a2. However, ex:s_3 is not directly generated by ex:a2. We may want to
+consider an abbreviation for this: wasGeneratedBy*(ex:s_3,ex:a2).</p>
</div>
@@ -3739,9 +4029,12 @@
<p>The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
<ul>
-<li> Attributes are constructs of the data model that allow representations of aspects of the world's entities and activities to be expressed. Applications are free to introduce application-specific attributes, according to their perspective on the world. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace declared in a namespace declaration.
-
-<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes catering for extensibility: <span class="name">type</span>, <span class="name">location</span>.</li>
+<li> Attributes are constructs of the data model that allow representations of aspects of the world's entities and activities to be expressed. Applications are free to introduce
+application-specific attributes, according to their perspective on the world. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace
+declared in a namespace declaration.
+
+<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes catering for extensibility: <span class="name">type</span>, <span
+class="name">location</span>.</li>
<li> Sets of Attribute-value pairs offer a mechanism to
@@ -3751,7 +4044,8 @@
<p>To this end, the <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
-<li>Note records allow arbitrary metadata to be associated with identifiable records of PROV-DM. Note records consist of name-value pairs. Like attributes, names are qualified by a namespace.</li>
+<li>Note records allow arbitrary metadata to be associated with identifiable records of PROV-DM. Note records consist of name-value pairs. Like attributes, names are qualified by a
+namespace.</li>
<li>Namespaces allow attributes and names to be qualified. </li>
@@ -3761,7 +4055,9 @@
<li>Domain specific values can be expressed by means of typed literals. </li>
</ul>
-<p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged. To ensure inter-operability, specializations of the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in this document. For instance, a qualified attribute on a domain specific entity record MUST represent an aspect of an entity and this aspect MUST remain unchanged during the characterization's interval of this entity record.</p>
+<p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged. To ensure inter-operability, specializations of
+the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in this document. For instance, a qualified attribute on a domain
+specific entity record MUST represent an aspect of an entity and this aspect MUST remain unchanged during the characterization's interval of this entity record.</p>
@@ -3772,7 +4068,8 @@
<section id="resource-section">
<h2>Resources, URIs, Entities, Identifiers, and Scope</h2>
-<p>This specification introduces the notion of an identifiable entity in the world. In PROV-DM, an entity record is a representation of such an identifiable entity. An entity record includes an identifier identifying this entity. Identifiers are qualified names, which can be mapped to IRIs. </p>
+<p>This specification introduces the notion of an identifiable entity in the world. In PROV-DM, an entity record is a representation of such an identifiable entity. An entity record
+includes an identifier identifying this entity. Identifiers are qualified names, which can be mapped to IRIs. </p>
<p>The term 'resource' is used in a general sense
for whatever might be identified by a URI [[!RFC3986]]. On the Web, a URI denotes a resource, without any expectation that the resource is accessed. </p>
@@ -3781,7 +4078,8 @@
<p>In the context of PROV-DM, a resource is just a thing in the world. One may take multiple perspectives on such a thing and its situation in the world, fixing some its aspects.</p>
-<p> We refer to the <a href="#a-report-example">example</a> of section <a href="#conceptualization">2.1</a> for a resource (at some URL) and three different perspectives, referred to as entities. Three different entity records can be expressed for this report, which in the PROV-ASN sample below, are expressed within a same account.
+<p> We refer to the <a href="#a-report-example">example</a> of section <a href="#conceptualization">2.1</a> for a resource (at some URL) and three different perspectives, referred to as
+entities. Three different entity records can be expressed for this report, which in the PROV-ASN sample below, are expressed within a same account.
</p>
<pre>
@@ -3804,7 +4102,10 @@
identifies the entity record it is contained in. In this example,
three identifiers were minted.</p>
-<p>Given that the report is a resource denoted by the URI <span class="name">http://example.org/crime.txt</span>, we could simply use this URI as the identifier of an entity. This would avoid us minting new URIs. Hence, the report URI would play a double role: as a URI it denotes a resource accessible at that URI, and as an identifier in a PROV-DM record, it helps identify a specific characterization of this report. A given identifier occurring in an entity record must be unique within the scope of an account. Hence, below, all entities records have been given the same identifier but appear in the scope of different accounts, so as to satisfy <a href="#identifiable-record-in-account">identifiable-record-in-account</a>.</p>
+<p>Given that the report is a resource denoted by the URI <span class="name">http://example.org/crime.txt</span>, we could simply use this URI as the identifier of an entity. This would
+avoid us minting new URIs. Hence, the report URI would play a double role: as a URI it denotes a resource accessible at that URI, and as an identifier in a PROV-DM record, it helps identify
+a specific characterization of this report. A given identifier occurring in an entity record must be unique within the scope of an account. Hence, below, all entities records have been given
+the same identifier but appear in the scope of different accounts, so as to satisfy <a href="#identifiable-record-in-account">identifiable-record-in-account</a>.</p>
<pre>
container
@@ -3830,9 +4131,11 @@
endContainer
</pre>
-<p>In this case, the qualified name <span class="name">app:crime.txt</span> maps to URI <span class="name">http://example.org/crime.txt</span> still denotes the same resource; however, the perspectives we take about that resource are expressed by multiple entity records, happening to all contain the same identifier but in different accounts. </p>
-
-<p> Alternatively, if we need to assert the existence of two different perspectives on the report within the same account, then alternate identifiers MUST be used, one of them being allowed to be the resource URI.</p>
+<p>In this case, the qualified name <span class="name">app:crime.txt</span> maps to URI <span class="name">http://example.org/crime.txt</span> still denotes the same resource; however, the
+perspectives we take about that resource are expressed by multiple entity records, happening to all contain the same identifier but in different accounts. </p>
+
+<p> Alternatively, if we need to assert the existence of two different perspectives on the report within the same account, then alternate identifiers MUST be used, one of them being allowed
+to be the resource URI.</p>
<pre>
container
@@ -3856,7 +4159,8 @@
<!--
-<li>For use, generation, and derivation event, the first argument is the 'effect' (i.e. most recent item) and the second argument is the 'cause' (i.e. least recent item). This order is compatible with the temporal layout of the graphical notation.
+<li>For use, generation, and derivation event, the first argument is the 'effect' (i.e. most recent item) and the second argument is the 'cause' (i.e. least recent item). This order is
+compatible with the temporal layout of the graphical notation.
-->