integration in ED
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Wed, 23 May 2012 13:07:35 +0100
changeset 2920 6ffa98377b37
parent 2919 b0c7d624f01b
child 2921 130178727363
integration in ED
model/extra-dm.css
model/prov-dm.html
--- a/model/extra-dm.css	Wed May 23 12:35:33 2012 +0100
+++ b/model/extra-dm.css	Wed May 23 13:07:35 2012 +0100
@@ -15,11 +15,11 @@
  background-color: rgba(204,255,0,0.2);
 }
 
-.component5-color {
+.component6-color {
  background-color: rgba(11,40,40,0.2);
 }
 
-.component6-color {
+.component5-color {
  background-color: rgba(244,105,14,0.2);
 }
 
--- a/model/prov-dm.html	Wed May 23 12:35:33 2012 +0100
+++ b/model/prov-dm.html	Wed May 23 13:07:35 2012 +0100
@@ -202,13 +202,15 @@
 PROV-DM, the PROV data model, is a data model for provenance that describes
 the entities, people and activities involved in
 producing a piece of data or thing. 
-PROV-DM is structured in six components, dealing with: 
+PROV-DM distinguishes core structures, forming the essence of provenance descriptions, from
+extended structures catering for more advanced uses of provenance. 
+PROV-DM is organized in six components, respectively dealing with: 
 (1) entities and activities, and the time at which they were created, used, or ended;
 (2) agents bearing responsibility for entities that were generated and activities that happened;
 (3) derivations of entities from entities;
 (4) properties to link entities that refer to the same thing;
-(5) collections forming a logical structure for its members;
-(6) a simple annotation mechanism.
+(5) notion of bundle, a mechanism to support provenance of provenance;
+(6) collections forming a logical structure for its members.
 </p>
 
 <p>This document introduces the provenance concepts found in
@@ -330,7 +332,7 @@
 
 <p>This specification presents the key concepts of the PROV Data Model, and
 provenance types and relations, without specific concern for how they are applied.
-With these, it becomes possible to write useful provenance descriptions, and publish or embed them along side the data they relate to. </p>
+With these, it becomes possible to write useful provenance descriptions, and publish or embed them alongside the data they relate to. </p>
 
 <p>However, if something about which provenance is expressed is subject to change, then it is challenging to express its provenance precisely (e.g. the data from which a daily weather report is derived  changes from day to day).
  To address this challenge, a <em>refinement</em> is proposed to enrich simple provenance, with extra descriptions that  help qualify the specific subject of provenance and provenance itself, with attributes and temporal information, intended to satisfy a comprehensive set of constraints.  These aspects are covered in the companion specification [[PROV-CONSTRAINTS]].
@@ -340,16 +342,22 @@
 <section id="structure-of-this-document"> 
 <h3>Structure of this Document</h3>
 
-<p><a href="#starting-points">Section 2</a> provides  starting points for the PROV Data Model, listing a set of types and  relations, which allows users to make initial provenance descriptions.</p>
-
-<p><a href="#prov-dm-example">Section 3</a> illustrates how the PROV data model can be used
+<p><a href="#section-prov-overview">Section 2</a> provides an overview of the PROV Data Model,  distinguishing a CORE set of types and  relations, commonly found in provenance descriptions, from extended structures catering for advanced uses.</p>
+
+<p><a href="#prov-notation">Section 3</a> overviews the Provenance Notation used to illustrate examples of provenance descriptions.</a>
+
+
+<p><a href="#prov-dm-example">Section 4</a> illustrates how the PROV data model can be used
 to express the provenance of a report published on the Web.</p>
 
-<p><a href="#data-model-components">Section 4</a> provides the definitions of PROV concepts, structured according to six components.</p>
-
-<p><a href="#extensibility-section">Section 5</a> summarizes PROV-DM extensibility points.</p>
-
-<p><a href="#valid-provenance">Section 6</a> introduces the idea that constraints can be applied to the PROV data model to refine provenance descriptions; these are covered in the companion specification [[PROV-CONSTRAINTS]].</p>
+
+<p><a href="#data-model-components">Section 5</a> provides the definitions of PROV concepts, structured according to six components.</p>
+
+
+
+<p><a href="#extensibility-section">Section 6</a> summarizes PROV-DM extensibility points.</p>
+
+<p><a href="#valid-provenance">Section 7</a> introduces the idea that constraints can be applied to the PROV data model to refine provenance descriptions; these are covered in the companion specification [[PROV-CONSTRAINTS]].</p>
 
 
 </section> 
@@ -379,25 +387,85 @@
 </table>
 </div>
 
+<p> 
+  Examples throughout this document use the PROV-N Provenance
+  Notation, briefly introduced in <a href="#prov-notation">Section 3</a> and specified fully in separate document [[PROV-N]].</p>
+
+
 </section> 
 
 </section> 
 
 
 
-<section id='starting-points'> 
-<h1>PROV Starting Points</h1>
-
-<p>
-This section introduces provenance concepts with informal descriptions and illustrative
-examples.  Since PROV-DM is a conceptual data
-model, Section 2.5 maps the concepts to various types and relations,
-which are illustrated graphically in
-a simplified UML diagram in <a href="#prov-dm-overview">Figure 1</a>.  Section 2.6
-then summarizes the PROV notation allowing instances of PROV-DM to be
-written down.
+<section id='section-prov-overview'> 
+<h1>PROV Overview</h1>
+
+<p>This section introduces provenance concepts with informal descriptions and illustrative
+examples. PROV distinguishes  <em>core structures</em>, forming the essence of  provenance descriptions, from <em>extended structures</em> catering for more advanced uses of provenance.  Core and extended structures are respectively presented in <a href="#core-structures">Section 2.1</a> and <a href="#section-extended-structures">Section 2.2</a>. Furthermore, the PROV data model is organized according to components, which are thematic groupings of concepts, overviewed in <a href="#section-overview-components">Section 2.3</a>.
 </p>
 
+
+<section id='core-structures'> 
+<h1>PROV Core Structures</h1>
+
+<p>The core of PROV consists of essential provenance structures commonly found in provenance descriptions.
+It is summarized graphically by
+the UML diagram of <a href="#prov-core-structures">Figure 1</a>,
+illustrating  three types (entity, activity, and agent) and how they relate to each other.  In the core of PROV, all relations are binary. </p>
+
+
+<div style="text-align: center; ">
+  <figure style="max-width: 70%; " >
+<!--     <img src="../images/OverviewDiagram.png" alt="PROV Core Structures" style="max-width: 70%; "  /> -->
+<img src="uml/essentials.svg" alt="PROV Core Structures" style="max-width: 70%; "  />
+<figcaption id="prov-core-structures">Figure 1: PROV Core Structures</figcaption>
+  </figure>
+</div>
+
+<p>The rest of this section introduces the concepts found in PROV Core structures.
+They are summarized in  <a href="#overview-types-and-relations">Table 2</a>, where they are grouped according to
+the types and relations the PROV conceptual data model. 
+ The first column lists concepts, the second column indicates whether a concept maps to a type or a relation, whereas the third column contains the corresponding name.    Names of relations have a verbal form in the past tense to express what happened in the past, as opposed to what may or will happen. 
+</p>
+</p>
+
+
+
+
+<div style="text-align: left;">
+<table border="1" style="margin-left: auto; margin-right: auto;">
+<caption id="overview-types-and-relations">Table 2: Mapping of PROV core concepts to  types and relations</caption>
+<tr><td><a><b>PROV Concepts</b></a></td><td><b>PROV-DM types or relations</b></td><td><b>Name</b></td><td><b>Overview</b></td></tr>
+<tr>
+<td><a>Entity</a></td><td rowspan="3" style="text-align: center;">PROV-DM Types</td><td><a title="dfn-Entity">entity</a></td><td style="text-align: center;"><a href="#section-entity-activity">2.1.1</a></td></tr>
+<tr><td><a>Activity</a></td><td><a title="dfn-Activity">activity</a></td><td style="text-align: center;"><a href="#section-entity-activity">2.1.1</a></td></tr>
+<tr><td><a>Agent</a></td><td><a title="dfn-agent">agent</a></td><td style="text-align: center;"><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td></tr>
+<tr>
+<td><a>Generation</a></td><td rowspan="6" style="text-align: center;">PROV-DM Relations</td><td><a title="wasGeneratedBy">wasGeneratedBy</a></td><td style="text-align: center;"><a href="#section-entity-activity">2.1.1</a></td></tr>
+<tr><td><a>Usage</a></td><td><a title="used">used</a></td><td style="text-align: center;"><a href="#section-entity-activity">2.1.1</a></td></tr>
+<tr><td><a>Attribution</a></td><td><a title="wasAttributedTo">wasAttributedTo</a></td><td style="text-align: center;"><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td></tr>
+<tr><td><a>Association</a></td><td><a title="wasAssociatedWith">wasAssociatedWith</a></td><td style="text-align: center;"><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td></tr>
+<tr><td><a>Responsibility</a></td><td><a title="actedOnBehalfOf">actedOnBehalfOf</a></td><td style="text-align: center;"><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td></tr>
+<tr><td><a>Derivation</a></td><td><a title="wasDerivedFrom">wasDerivedFrom</a></td><td style="text-align: center;"><a href="#section-derivation">2.1.3</a></td></tr>
+</table>
+</div>
+
+
+
+
+<!--
+<p><a href="#prov-core-structures">Figure 1</a> is not intended to be complete: it only illustrates  types and relations introduced in this section (<a href="#section-prov-overview">Section 2</a>), exploited in the example discussed in <a href="#prov-dm-example">Section 3</a>, and explained in detail in <a href="#data-model-components">Section 4</a>.
+Names of relations depicted in <a href="#prov-core-structures">Figure 1</a> 
+are listed in
+the third column of <a href="#overview-types-and-relations">Table 2</a>. These names are part of a textual notation to write instances of the PROV data model, which we introduce in the next section. </p>
+
+-->
+
+
+
+
+
 <form action="#"><p> 
 <input id="hide-examples" onclick="set_display_by_class('div','conceptexample','none'); set_display_by_id('hide-examples','none'); set_display_by_id('show-examples','');" type="button"
 value="Hide Concept Examples" /> 
@@ -440,11 +508,6 @@
 <p>An activity may be the publishing of a document on the Web, sending a twitter message, extracting metadata embedded in a file, 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, or editing a file.</p>
 </div>
 
-</section>
-
-    <section id="section-generation-usage-derivation"> 
-<h2>Generation, Usage, Derivation</h2>
-
 <p>Activities and entities are associated with each other in two different ways: activities utilize entities and activities  produce entities. The act of utilizing or producing an entity may have a duration.  
  The term 'generation' refers to the completion of the act of producing; likewise, the term 'usage' refers to the beginning of the act of utilizing entities. Thus, we define the following notions of generation and usage. </p>
 
@@ -475,22 +538,11 @@
 </div>
 
 
-<p>Activities utilize entities and producer entities. In some cases, utilizing an entity influences the creation of another in some way. This notion is captured by derivations, defined as follows.</p>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-derivation"  data-withspan="true"></span>
-
-
-
-<div class="conceptexample" id="derivation-example">
-<p>Examples of derivation include  the transformation of a relational table into a
-linked data set, the transformation of a canvas into a painting, the transportation of a work of art from London to New York, and a physical transformation such as the melting of ice into water.</p>
-</div>
-
 </section>
 
+
 <section id="section-agents-attribution-association-responsibility"> 
-<h2>Agents, Attribution, Association, and Responsibility</h2>
+<h2>Agents and Responsibility</h2>
 
 <p>The motivation for introducing  agents in the model is to express the agent's responsibility for activities that happened and entities that were generated. </p>
 
@@ -517,28 +569,6 @@
 </div>
 
 
-<p>Agents may adopt sets of actions or steps to achieve their goals. This is captured by the notion of plan. </p>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-plan"  data-withspan="true">
-</span>
-There exist no
-prescriptive requirement on the nature of plans, their representation, the
-actions or steps they consist of, or their intended goals.  Since plans may evolve over time,
-it may become necessary to track their provenance, so plans themselves are
-entities. Representing the plan explicitly in the provenance can be useful for various tasks: for example, to  
-validate the execution as represented in the provenance record, to  
-manage expectation failures, or to provide explanations.</p> 
-
-<div class="conceptexample" id="plan-example">
-<p>
-A plan can be a blog post tutorial for how to set up a web server, a list of instructions for a micro-processor execution, a cook's written recipe for a chocolate cake, or a workflow for a scientific experiment.
-</p>
-</div>
-
-
-
-
 
 
 <p>Agents can be related to entities, activities, and other agents.</p>  
@@ -550,16 +580,13 @@
 </div>
 
 <p>
-Agents are defined as having some kind of responsibility for activities. In some  
-cases, those activities reflect the execution of a plan that was  
-designed in advance to guide the execution.  Thus,
-a plan may also be linked to an activity.  </p>
+Agents are defined as having some kind of responsibility for activities. </p>
 
 <!-- <div class="note">Proposal: remove the above para as it repeats from 2.3. Proposed text: "the <em>activity association</em> relation provides a way to indicate that an agent is responsible for an activity, possibly with an associated plan."[PM]</div> -->
 
 
 <p>
-<span class="glossary-ref" data-ref="glossary-activityAssociation"  data-withspan="true"></span>
+<span class="glossary-ref" data-ref="glossary-core-association"  data-withspan="true"></span>
 </p>
 
 <div class="conceptexample" id="association-example">
@@ -568,7 +595,6 @@
 <li>creation of a web page under the guidance of a designer;</li>
 <li>various forms of participation in a panel discussion, including audience member, panelist, or panel chair;</li>
 <li>a public event, sponsored by a company, and hosted by a museum;</li>
-<li>an XSLT transform launched by a user based on an XSL style sheet (a plan).</li>
 </ul>
 </div>
 
@@ -589,13 +615,140 @@
 <div class="conceptexample" id="responsibility-example">
 <p>A student publishing a web page describing an academic
 department could result in both the student and the department being
-agents associated with the activity, and it may not matter which
-student published a web page but it matters a lot that the department
+agents associated with the activity.  It may not matter which actual
+student published a web page, but it may matter significantly that the department
 told the student to put up the web page.  
 </p>
 </div>
 </section>
 
+    <section id="section-derivation"> 
+<h2>Derivation</h2>
+
+
+
+<p>Activities utilize entities and produce entities. In some cases, utilizing an entity influences the creation of another in some way. This notion is captured by derivations, defined as follows.</p>
+
+<p>
+<span class="glossary-ref" data-ref="glossary-derivation"  data-withspan="true"></span>
+
+
+
+<div class="conceptexample" id="derivation-example">
+<p>Examples of derivation include  the transformation of a relational table into a
+linked data set, the transformation of a canvas into a painting, the transportation of a work of art from London to New York, and a physical transformation such as the melting of ice into water.</p>
+</div>
+
+</section>
+
+</section>
+
+<section id="section-extended-structures"> 
+<h2>PROV Extended Structures</h2>
+
+<p>While the core of PROV focuses on essential provenance structures commonly found in provenance descriptions, extended structures 
+are designed to support more advanced uses of provenance. 
+The purpose of this section is twofold. First, mechanisms to specify these extended structures are introduced.  Second,  two further categories of provenance structures are overviewed: they cater for provenance of provenance and collections,  respectively.</p>
+
+
+
+
+<section id="section-prov-extended-mechanisms"> 
+<h2>Mechanisms to Define Extended Structures</h2>
+
+<p>Extended structures are defined by a variety of mechanisms 
+outlined in this section: subtyping, expanded relations, optional
+identification, and new relations.</p>
+
+
+<section id="section-prov-extended-approach-subtyping"> 
+<h2>Subtyping</h2>
+
+<p>Subtyping can be applied to core types. For example, a software agent is special kind of agent, defined as follows.</p>
+
+<span class="glossary-ref" data-ref="glossary-software-agent"  data-withspan="true">
+</span>
+
+
+<p>Subtyping can also be applied to  core relations. For example, a revision is a special kind of derivation, defined as follows.</p>
+
+
+<p><span class="glossary-ref" data-ref="glossary-revision" data-withspan="true"></span></p>
+
+</section>
+
+<section id="section-prov-extended-approach-expanded-relation"> 
+<h2>Expanded Relations</h2>
+
+<p><a href="#core-structures">Section 2.1</a> shows that six concepts are mapped to binary relations in the core of PROV.  However, some advanced uses of these concepts cannot be captured by a binary relation, but require relations to be expanded to n-ary relations.</p>
+
+
+<p>To illustrate expanded relations, we consider the concept of
+association, described
+in <a href="#section-agents-attribution-association-responsibility">section
+2.1.2</a>.  Agents may adopt sets of actions or steps to achieve their
+goals in the context of an activity: this is captured by the notion of
+a plan.  Thus, an activity may reflect the execution of a plan that was
+designed in advance to guide the execution.  Hence, an expanded
+association relation allows a plan be linked to an
+activity. Plan is defined by subtyping and full association by an expanded relation, as follows. </p>
+
+<p>
+<span class="glossary-ref" data-ref="glossary-plan"  data-withspan="true">
+</span>
+There exist no
+prescriptive requirement on the nature of plans, their representation, the
+actions or steps they consist of, or their intended goals.  Since plans may evolve over time,
+it may become necessary to track their provenance, so plans themselves are
+entities. Representing the plan explicitly in the provenance can be useful for various tasks: for example, to  
+validate the execution as represented in the provenance record, to  
+manage expectation failures, or to provide explanations.</p> 
+
+
+<p>
+<span class="glossary-ref" data-ref="glossary-activityAssociation"  data-withspan="true"></span>
+</p>
+
+
+<div class="conceptexample" id="association-example2">
+<p>An example of association between an activity and an agent involving a plan is:
+an XSLT transform launched by a user based on an XSL style sheet (a plan).
+
+</div>
+</section>
+
+
+<section id="section-prov-extended-approach-optional-identification-new-relation"> 
+<h2>Optional Identification and New Relations</h2>
+
+<p>Some concepts exhibit both a core use, expressed as
+binary relation, and an extended use, expressed as n-ary relation.  In
+some cases, mapping the concept to a relation, whether binary or
+n-ary, is not sufficient: instead, it may be required to able to
+identify an instance of such concept.</p>
+
+<p>In such circumstances, PROV-DM allows an optional identifier to be
+expressed to identify an instance of an association between two or
+more elements.  This optional identifier can then be used to refer to
+an instance as part of other concepts.</p>
+
+<div class="conceptexample" id="identifier-example">
+<p>A service may read a same configuration file on two different occasions. Each  usage can be identifed by its own identifier, allowing them to be distinguished. 
+</div>
+
+<p>Finally, PROV-DM supports further relations that are not subtypes or expanded versions of existing relations.</p>
+
+
+
+
+</section>
+
+
+
+</section>
+
+
+
 <section id="section-provenance-of-provnance"> 
 <h2>Provenance of Provenance</h2>
 
@@ -623,7 +776,7 @@
 <h2>Collections</h2>
 
 <p>
-<span class="glossary-ref" data-ref="glossary-collection"  data-withspan="true"></span> This concept allows for the provenance of the collection itself to be expressed in addition to that of the members.  Many different types of collections exist, such as a <em>set</em>, <em>dictionaries</em>, or <em>lists</em>, all of which involve a membership relationship between the constituents and the collection. </p>
+<span class="glossary-ref" data-ref="glossary-collection"  data-withspan="true"></span> This concept allows for the provenance of the collection itself to be expressed in addition to that of the members.  Many different types of collections exist, such as a <em>sets</em>, <em>dictionaries</em>, or <em>lists</em>, all of which involve a membership relationship between the constituents and the collection. </p>
 
 <div class="conceptexample" id="collection-example">
 <p>
@@ -637,60 +790,40 @@
 
 
 
-
-    <section id="section-UML"> 
-<h2>Simplified Overview Diagram</h2>
-
-<p>So far, we have introduced a series of concepts underpinning provenance.   PROV-DM  is a conceptual data model consisting of types and relations between these.  <a href="#overview-types-and-relations">Table 2</a> shows how provenance concepts can be mapped to types and relations in PROV-DM: the first column lists concepts introduced in this section, the second column indicates whether a concept maps to a type or a relation, whereas the third column contains the corresponding name.    Names of relations have a verbal form in the past tense to express what happened in the past, as opposed to what may or will happen. 
-</p>
-
-
-<div style="text-align: left;">
+</section>
+
+<section id="section-overview-components"> 
+<h2>Modular Organization</h2>
+
+<p>Besides the separation between core and extended structures, PROV-DM
+is further organized according to components, grouping concepts in a
+thematic manner. </p>
+
+<p> <a href="#components-overview">Table 3</a> enumerates the six components, five of which have already been implicitly overviewed in this section. All components offer extended structures, whereas the first three only offer core structures.
+
+<div id="components-overview-div" style="text-align: center;">
 <table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="overview-types-and-relations">Table 2: Mapping of Provenance concepts to  types and relations</caption>
-<tr><td><a><b>PROV Concepts</b></a></td><td><b>PROV-DM types or relations</b></td><td><b>Name</b></td></tr>
-<tr>
-<td><a>Entity</a></td><td rowspan="3">PROV-DM Types</td><td><a title="dfn-Entity">entity</a></td></tr>
-<tr><td><a>Activity</a></td><td><a title="dfn-Activity">activity</a></td></tr>
-<tr><td><a>Agent</a></td><td><a title="dfn-agent">agent</a></td></tr>
-<tr>
-<td><a>Generation</a></td><td rowspan="6">PROV-DM Relations</td><td><a title="wasGeneratedBy">wasGeneratedBy</a></td></tr>
-<tr><td><a>Usage</a></td><td><a title="used">used</a></td></tr>
-<tr><td><a>Attribution</a></td><td><a title="wasAttributedTo">wasAttributedTo</a></td></tr>
-<tr><td><a>Association</a></td><td><a title="wasAssociatedWith">wasAssociatedWith</a></td></tr>
-<tr><td><a>Responsibility</a></td><td><a title="actedOnBehalfOf">actedOnBehalfOf</a></td></tr>
-<tr><td><a>Derivation</a></td><td><a title="wasDerivedFrom">wasDerivedFrom</a></td></tr>
+<caption id="components-overview">Table 3: Components Overview</caption>
+<tr><td></td><td>Component</td><td>Core <br>Structures</td><td>Overview</td><td>Specification</td><td>Description</td></tr> 
+<tr><td>1</td><td style="text-align: left;">Entities and Activities</td><td>&#10004;</td><td><a href="#section-entity-activity">2.1.1</a></td><td><a href="#component1">5.1</a></td><td  style="text-align: left;">about entities and activities, and their interrelations</td></tr> 
+<tr><td>2</td><td style="text-align: left;">Agent and Responsibility</td><td>&#10004;</td><td><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td><td><a href="#component2">5.2</a></td><td style="text-align: left;">about agents and concepts ascribing responsibility to them</td></tr> 
+<tr><td>3</td><td style="text-align: left;">Derivation</td><td>&#10004;</td><td><a href="#section-derivation">2.1.3</a></td><td><a href="#component3">5.3</a></td><td  style="text-align: left;">about derivations and its subtypes</td></tr> 
+<tr><td>4</td><td style="text-align: left;">Alternate</td><td></td><td>&mdash;</td><td><a href="#component4">5.4</a></td><td  style="text-align: left;">about relations linking entities referring the same thing</td></tr> 
+<tr><td>5</td><td style="text-align: left;">Bundles</td><td></td><td><a href="#section-provenance-of-provnance">2.2.2</a></td><td><a href="#component5">5.5</a></td><td style="text-align: left;">about bundles, a mechanism to support provenance of provenance</td></tr> 
+<tr><td>6</td><td style="text-align: left;">Collections</td><td></td><td><a href="#section-collections">2.2.3</a></td><td><a href="#component6">5.6</a></td><td style="text-align: left;">about collections and concepts capturing their transformation, such as insertion and removal</td></tr> 
 </table>
 </div>
 
-<p><a href="#prov-dm-overview">Figure 1</a> illustrates the three types (entity, activity, and agent) and how they relate to each other.  At this stage, all relations are shown to be binary.  Definitions of <a href="#data-model-components">Section 4</a> reveal that some relations, while  involving two primary elements, are n-ary. </p>
-
-
-<div style="text-align: center; ">
-  <figure style="max-width: 70%; " >
-  <img src="images/OverviewDiagram.png" alt="Simplified  Overview of PROV-DM" style="max-width: 70%; "  />
-<figcaption id="prov-dm-overview">Figure 1: Simplified  Overview of PROV-DM</figcaption>
-  </figure>
-</div>
-
-<p><a href="#prov-dm-overview">Figure 1</a> is not intended to be complete: it only illustrates  types and relations introduced in this section (<a href="#starting-points">Section 2</a>), exploited in the example discussed in <a href="#prov-dm-example">Section 3</a>, and explained in detail in <a href="#data-model-components">Section 4</a>.
-Names of relations depicted in <a href="#prov-dm-overview">Figure 1</a> 
-are listed in
-the third column of <a href="#overview-types-and-relations">Table 2</a>. These names are part of a textual notation to write instances of the PROV data model, which we introduce in the next section. </p>
-
-<!--
-<div class="note">
-   TODO: short text required to explain the overview diagram
-<p>I have the impression that the diagram presented in Section 2.5 would 
- > be more useful if placed at the beginning of Section 2 [KB]
-</div>
--->
 </section>
-<section id="prov-n"> 
-<h2>PROV-N: The Provenance Notation</h2>
-
-
-<p>To illustrate the application of PROV concepts to a concrete example (see <a href="#prov-dm-example">Section 3</a>) and to provide examples of concepts (see <a href="#data-model-components">Section 4</a>),
+
+</section>
+
+
+<section id="prov-notation"> 
+<h2>The Provenance Notation</h2>
+
+
+<p>To illustrate the application of PROV concepts to a concrete example (see <a href="#prov-dm-example">Section 4</a>) and to provide examples of concepts (see <a href="#data-model-components">Section 5</a>),
 we introduce PROV-N, a notation for writing instances of the PROV data model. For full details, the reader is referred to the companion specification [[PROV-N]].
 PROV-N is a notation  aimed at human consumption, with the following characteristics:</p>
 <ul>
@@ -701,12 +834,12 @@
 
 <li>
 PROV-N <em>optional arguments</em> need not be specified:
-the general rule for optional arguments is that, if none of them are used in the expression, then they are simply omitted, resulting in a simpler expression. However, it may be the case that only some of the optional arguments need to be specified. Because the position of the arguments in the expression matters, in this case an additional marker must be used to indicate that a particular term is not available. The syntactic marker  <span class="name">-</span> is used for this purpose.
+the general rule for optional arguments is that, if none of them are used in the expression, then they are simply omitted, resulting in a simpler expression. However, it may be the case that only some of the optional arguments need to be specified. Because the position of the arguments in the expression matters, in this case an additional marker must be used to indicate that a particular term is not available. The syntactic marker  '<span class="name">-</span>' is used for this purpose.
 </li>
 
 <li>Most expressions 
 include an identifier 
-and a set of attribute-value pairs; both are optional unless otherwise specified. By convention, the identifier occurs in the <em>first position</em>, and the the set of attribute-value pairs in the <em>last position</em>.
+and a set of attribute-value pairs; both are optional unless otherwise specified. By convention, the identifier occurs in the <em>first position</em>, and the set of attribute-value pairs in the <em>last position</em>.
 Consistent with the convention on arguments, the marker  <span class="name">-</span> can be used when the identifier is not available, or can be omitted altogether with no ambiguity arising.
 </li>
 </ul>
@@ -734,7 +867,7 @@
 </pre>
 </div>
 
-</section>
+
 
 </section>
 
@@ -742,7 +875,7 @@
 <section id="prov-dm-example"> 
 <h2>Illustration of PROV-DM by an Example</h2>
 
-<p><a href="#starting-points">Section 2</a> has introduced some provenance concepts, and how they are expressed as types or relations in the PROV data model. The purpose of this section is to put these concepts into practice in order to express the provenance of some document published on the Web.  
+<p><a href="#section-prov-overview">Section 2</a> has introduced some provenance concepts, and how they are expressed as types or relations in the PROV data model. The purpose of this section is to put these concepts into practice in order to express the provenance of some document published on the Web.  
 With this realistic example, PROV concepts are  composed together,  and a graphical illustration shows a provenance description forming a directed graph, rooted at the entity we want to explain the provenance of, and pointing to the entities, activities, and agents it depended on. This example also shows that, sometimes, multiple provenance descriptions about the same entity can co-exist, which then justifies the need for provenance of provenance.</p>
 
 
@@ -841,7 +974,7 @@
 </p>
 
 <p>
-We describe the kind of provenance record that the <a href="http://www.w3.org/Consortium">WWW Consortium</a> could keep for auditors to check that due processes are followed. All entities involved in this example are Web resources, with well defined URIs (some of which refer archived email messages, available to W3C Members).</p>
+We describe the kind of provenance record that the <a href="http://www.w3.org/Consortium">WWW Consortium</a> could keep for auditors to check that due processes are followed. All entities involved in this example are Web resources, with well-defined URIs (some of which refer archived email messages, available to W3C Members).</p>
 
 <ul>
 <li> Two versions of a document were involved: <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> (second working draft) and <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> (first working draft);</li>
@@ -974,7 +1107,7 @@
 <h2>PROV-DM Types and Relations</h2>
 
 <p>Provenance concepts, expressed as PROV-DM types and relations, are structured according to six components that are introduced in this section.
-Components and their dependencies are illustrated in <a href="#prov-dm-components">Figure 4</a>. A component that relies on concepts defined in another also sits above it in this figure.
+The components and their dependencies are illustrated in <a href="#prov-dm-components">Figure 4</a>. A component that relies on concepts defined in another also sits above it in this figure.
 PROV-DM consists of the following components.</p>
 
 <div id="prov-dm-components-ul">
@@ -992,7 +1125,7 @@
 
 <div style="text-align: center;">
 <figure style="max-width: 90%; ">
-<img  usemap="#componentMap" src="images/components-with-bundle.png" alt="PROV-DM Components"  style="max-width: 90%; " />
+<img  usemap="#componentMap" src="images/components-dependencies.png" alt="PROV-DM Components"  style="max-width: 90%; " />
 <map id="componentMap" name="componentMap">
 <area title="collections" href="#component5" coords="220,0,440,70"  alt="collections" shape="rect"/>
 <area title="alternate"   href="#component4" coords="450,0,510,140" alt="alternate"   shape="rect"/>
@@ -1008,7 +1141,8 @@
 <p>
 While  not all PROV-DM relations are binary, they all involve two primary elements. Hence, <a href="#relations-at-a-glance">Table 3</a> indexes all relations according to their two primary elements.  The table adopts the same color scheme as <a href="#prov-dm-components">Figure 4</a>, allowing components to be readily identified.
 Note that for simplicity, this table  does not include bundle-oriented and collection-oriented relations.
-Relation names appearing in bold correspond to the essential concepts introduced in the <a href="#starting-points">Starting Points Section</a>.</p>
+Relation names appearing in bold correspond to the core structures introduced
+in <a href="#core-structures">Section 2.1</a>.</p>
 </p>
 
 <div id="relations-at-a-glance-div" style="text-align: center;">
@@ -1023,7 +1157,7 @@
 </table>
 </div>
 
-<p><a href="#prov-dm-types-and-relations">Table 4</a> is a complete index of all the types and relations of PROV-DM, color-coded according to the component they belong to.  In the first column,  concept names  link to their informal definition, whereas, in the second column, representations link to the information used to represent the concept. Concept names appearing in bold are the essential concepts introduced in the <a href="#starting-points">Starting Points Section</a>.</p>
+<p><a href="#prov-dm-types-and-relations">Table 4</a> is a complete index of all the types and relations of PROV-DM, color-coded according to the component they belong to.  In the first column,  concept names  link to their informal definition, whereas, in the second column, representations link to the information used to represent the concept. Concept names appearing in bold are the core structures introduced in <a href="#core-structures">Section 2.1</a>.</p>
 
 
 <div id="prov-dm-types-and-relations-fig" style="text-align: left;">
@@ -1069,13 +1203,15 @@
 <section id="component1"> 
 <h3>Component 1: Entities and Activities</h3>
 
-<p>The first component of PROV-DM is concerned with <a title="entity">entities</a> and <a title="activity">activities</a>, and their interrelations: <a>Usage</a>, <a>Generation</a>, <a>Start</a>, <a>End</a>, <a>Invalidation</a>, and <a>Communication</a>.  <a href="#figure-component1">Figure 5</a> uses UML to depict the first component, with two classes and associations between them.  <a>Usage</a>, <a>Generation</a>, <a>Start</a>, <a>End</a>  include <em>time</em> attributes.
-UML association classes are used to express n-ary relations <a>Start</a> and <a>End</a>. 
+<p>The first component of PROV-DM is concerned with <a title="entity">entities</a> and <a title="activity">activities</a>, and their interrelations: <a>Usage</a>, <a>Generation</a>, <a>Start</a>, <a>End</a>, <a>Invalidation</a>, and <a>Communication</a>.  <a href="#figure-component1">Figure 5</a> uses UML to depict the first component.
+Core structures are displayed in the yellow area, consisting of two classes (<a>Entity</a>, <a>Activity</a>) and two binary associations between them (<a>Usage</a>, <a>Generation</a>). The rest of the figure displays extended structures, including UML associations classes (represented in gray) to express expanded n-ary relations (for <a>Usage</a>, <a>Generation</a>, <a>Invalidation</a>, <a>Start</a>, <a>End</a>,  <a>Communication</a>). The figure also makes explicit <em>time</em> attributes for these concepts (time being represented as a primitive).
 </p>
 
 <div style="text-align: center;">
 <figure>
-<img src="images/Entities-Activities.png" alt="entities and activities"/>
+<!--<img src="images/Entities-Activities.png" alt="entities and activities"/> -->
+
+<img src="uml/component1.svg" alt="entities and activities"/>
 <figcaption id="figure-component1">Figure 5: Entities and Activities Component Overview</figcaption>
 </figure>
 </div>
@@ -1292,8 +1428,8 @@
  <span class="name">ex:Bob</span>.
 <pre class="codeexample">
 activity(ex:foot_race)
+entity(ex:bang)
 wasStartedBy(ex:foot_race, ex:bang, -, 2012-03-09T08:05:08-05:00)
-entity(ex:bang)
 agent(ex:Bob)
 wasAttributedTo(ex:bang, ex:Bob)
 </pre>
@@ -1370,7 +1506,7 @@
 <li> an entity is time limited: e.g. the BBC news site on April 3rd, 2012;
 <li> an entity attribute is changing: e.g. the traffic light changed from green to red.
 </ul>
-<p>In the first two cases, the entity has physically disappeared after its termination: there is no more soup, or painting.  In the last two cases, there may be an "offer voucher" that still exists, but it is no longer valid; likewise, on April 4th, the BBC news site still exists but it is not the same entity as BBC news Web site on April 3rd; or the traffic light became red and therefore is regarded as a different entity to the green light.
+<p>In the first two cases, the entity has physically disappeared after its termination: there is no more soup, or painting.  In the last three cases, there may be an "offer voucher" that still exists, but it is no longer valid; likewise, on April 4th, the BBC news site still exists but it is not the same entity as BBC news Web site on April 3rd; or the traffic light became red and therefore is regarded as a different entity to the green light.
 </p>
 
 
@@ -1493,15 +1629,16 @@
 <section id="component2"> 
 <h3>Component 2: Agents and Responsibility</h3>
 
-<p>The second component of PROV-DM is concerned with <a title="agent">agents</a> and the notions of
+<p>The second component of PROV-DM, depicted in  <a href="#figure-component2">Figure 6</a>, is concerned with <a title="agent">agents</a> and the notions of
 <a>Attribution</a>, <a>Association</a>, <a>Responsibility</a>, relating agents to entities, activities, and agents, respectively.
-Figure <a href="#figure-component2">figure-component2</a> depicts the second component with four classes (Entity, Activity,  Agent, and Plan) and associations between them. UML association classes are used to express n-ary relations.
+ Core structures are displayed in the yellow area and include three classes and three binary associations. Outside the yellow area, extended structures comprise the subclass <a>Plan</a> and UML association classes to express expanded n-ary relations.
 </p>
 
 
 <div style="text-align: center;">
 <figure>
-<img src="images/Agents-Responsibility.png" alt="agents and responsibilities"/>
+<!-- <img src="images/Agents-Responsibility.png" alt="agents and responsibilities"/> -->
+<img src="uml/component2.svg" alt="agents and responsibilities"/>
 <figcaption id="figure-component2">Figure 6: Agents and Responsibilities Component Overview</figcaption>
 </figure>
 </div>
@@ -1523,7 +1660,7 @@
 <p>
 
 It is useful to define some basic categories of agents from an interoperability perspective.
-There are three types of agents that are common across most anticipated domains of use; It is acknowledged that these types do not cover all kinds of agent. </p>
+There are three types of agents that are common across most anticipated domains of use; it is acknowledged that these types do not cover all kinds of agent. </p>
 <ul>
 <li><span class="name">SoftwareAgent</span>
 <div class="glossary-ref" data-ref="glossary-software-agent"></div>
@@ -1606,7 +1743,7 @@
 </ul></div>
 
 <div class="anexample" id="anexample-wasAssociateWith">
-<p>In the following example, a designer and an operator agents are associated with an activity. The designer's goals are achieved by a workflow <span class="name">ex:wf</span>, described as an an entity of type <span class="name"><a>plan</a></span>.   </p>
+<p>In the following example, a designer agent and an operator agent are associated with an activity. The designer's goals are achieved by a workflow <span class="name">ex:wf</span>, described as an an entity of type <span class="name"><a>plan</a></span>.   </p>
 <pre class="codeexample">
 activity(ex:a, [prov:type="workflow execution"])
 agent(ex:ag1, [prov:type="operator"])
@@ -1706,13 +1843,14 @@
 
 
 <p>The third component of PROV-DM is concerned with <a title="derivation">derivations</a> of <a title="entity">entities</a> from others, and derivation subtypes <a>Revision</a>, <a>Quotation</a>, <a>Original Source</a>, and <a>Trace</a>.
-Figure <a href="#figure-component3">figure-component3</a> depicts the third component with three  classes (Entity, Activity, and Agent) and associations between them. UML association classes express n-ary relations.
+ <a href="#figure-component3">Figure 7</a> depicts the third component with three  classes (Entity, Activity, and Agent) and associations between them. As before, the yellow are includes PROV core structures, whereas extended structures are found outside this area. UML association classes express expanded n-ary relations.
 </p>
 
 
 <div style="text-align: center;">
 <figure>
-<img src="images/Derivation.png" alt="derivation"/>
+<!-- <img src="images/Derivation.png" alt="derivation"/> -->
+<img src="uml/component3.svg" alt="derivation"/>
 <figcaption id="figure-component3">Figure 7: Derivation Component Overview</figcaption>
 </figure>
 </div>
@@ -1729,7 +1867,7 @@
 
 
 
-<p>According to <a href="#starting-points">Section 2</a>, for an entity to be transformed from, created from, or resulting from an update to another, there must be some
+<p>According to <a href="#section-prov-overview">Section 2</a>, for an entity to be transformed from, created from, or resulting from an update to another, there must be some
 underpinning activities performing the necessary actions resulting in such a derivation.  
 A derivation can be described at various levels of precision. In its simplest form, derivation relates two entities. Optionally, attributes can be added to represent further information about the derivation.  If the derivation is the result of a single known activity, then this activity can also be optionally expressed. To provide a completely accurate description of the derivation, the generation and usage of the generated and used entities, respectively, can be provided.  Optional information such as activity, generation, and usage can be linked to derivations to aid analysis of provenance and to facilitate provenance-based reproducibility. </p>
 
@@ -1737,7 +1875,7 @@
 <p><div class="attributes" id="attributes-derivation">A <dfn title="wasDerivedFrom">derivation</dfn><span class="withPn">, written <span class="pnExpression" id="pn-wasDerivedFrom">wasDerivedFrom(id; e2, e1, a, g2, u1, attrs)</span> in PROV-N,</span> has:
 <ul>
 <li><span class='attribute' id="derivation.id">id</span>:  an OPTIONAL identifier  for a derivation;</li> 
-<li><span class='attribute' id="derivation.generatedEntity">generatedEntity</span>: the identifier (<span class="name">ee</span>) of the entity generated by the derivation;</li>
+<li><span class='attribute' id="derivation.generatedEntity">generatedEntity</span>: the identifier (<span class="name">e2</span>) of the entity generated by the derivation;</li>
 <li><span class='attribute' id="derivation.usedEntity">usedEntity</span>: the identifier (<span class="name">e1</span>) of the entity used by the derivation;</li>
 <li><span class='attribute' id="derivation.activity">activity</span>: an OPTIONAL identifier (<span class="name">a</span>) for the activity using and generating the above entities;</li>
 <li><span class='attribute' id="derivation.generation">generation</span>: an OPTIONAL identifier (<span class="name">g2</span>) for the generation involving the generated entity (<span class="name">e2</span>) and activity;</li> 
@@ -1906,7 +2044,7 @@
 some responsibility for  <span class="name">e2</span>'s existence.
 
 
-<p>A <dfn title="tracedTo">Trace</dfn> relation <span class="withPn">, written <span class="pnExpression">tracedTo(id;e2,e1,attrs)</span> in PROV-N,</span> has:</p>
+<p>A <dfn title="tracedTo">Trace</dfn> relation<span class="withPn">, written <span class="pnExpression">tracedTo(id;e2,e1,attrs)</span> in PROV-N,</span> has:</p>
 <ul>
 <li><span class='attribute' id="trace.id">id</span>:  an OPTIONAL identifier identifying the relation;</li> 
 <li><span class='attribute' id="trace.entity">entity</span>:  an identifier (<span class="name">e2</span>) for an entity;
@@ -1943,14 +2081,15 @@
 
 <p>The fourth component of PROV-DM is concerned with
 relations <a>specialization</a> and <a>alternate</a> between entities.
-Figure <a href="#figure-component4">figure-component4</a> depicts
+ <a href="#figure-component4">Figure 8</a> depicts
 the fourth component with a single class and two associations.
 </p>
 
 
 <div style="text-align: center;">
 <figure>
-<img src="images/Alternates.png" alt="alternates"/>
+<!-- <img src="images/Alternates.png" alt="alternates"/> -->
+<img src="uml/component4.svg" alt="alternates"/>
 <figcaption id="figure-component4">Figure 8: Alternates Component Overview</figcaption>
 </figure>
 </div>
@@ -1981,11 +2120,11 @@
 
 
 <p>
-<div class="attributes" id="attributes-specialization">A <dfn title="specializationOf">specialization</dfn>  relation<span class="withPn">, written <span class="pnExpression">specializationOf(sub, super)</span> in PROV-N,</span> has:
+<div class="attributes" id="attributes-specialization">A <dfn title="specializationOf">specialization</dfn>  relation<span class="withPn">, written <span class="pnExpression">specializationOf(infra, supra)</span> in PROV-N,</span> has:
 
 <ul>
-<li><span class='attribute' id="specialization.specializedEntity">specializedEntity</span>: an identifier (<span class="name">sub</span>) of the specialized entity;</li>
-<li><span class='attribute' id="specialization.generalEntity">generalEntity</span>: an identifier (<span class="name">super</span>) of the entity that is being specialized.</li>
+<li><span class='attribute' id="specialization.specialization">specialization</span>: an identifier (<span class="name">infra</span>) of the specialized entity;</li>
+<li><span class='attribute' id="specialization.generalEntity">generalEntity</span>: an identifier (<span class="name">supra</span>) of the entity that is being specialized.</li>
 </ul>
 </div>
 
@@ -2062,8 +2201,17 @@
 <h3>Component 5: Bundles</h3>
 
 
-<p>The fifth component of PROV-DM is concerned with bundles, a mechanism to support provenance of provenance. </p>
-
+<p>The fifth component of PROV-DM is concerned with bundles, a mechanism to support provenance of provenance. 
+<a href="#figure-component5">Figure 9</a>  depict a UML class diagram for the fifth component.  It comprises a <a>Bundle</a> class, a subclass of <a>Entity</a> and a novel n-ary relation, <a>Provenance Locator</a>.
+</p>
+
+<div style="text-align: center;">
+<figure>
+
+<img src="uml/component5.svg" alt="bundles"/>
+<figcaption id="figure-component5">Figure 9: Bundle Component Overview</figcaption>
+</figure>
+</div>
 
 
 
@@ -2343,15 +2491,17 @@
 <p>The fifth component of PROV-DM is concerned with the notion of collections. 
 A collection is an entity that has some members. The members are themselves entities, and therefore their provenance can be expressed. Some applications need to be able to express the provenance of the collection  itself: e.g. who maintains the collection, which members it contains as it evolves, and how it was assembled. The purpose of Component 5 is to define the types and relations that are useful to express the provenance of collections. In PROV, the concept of Collection is implemented by means of dictionaries, which we introduce in this section. </p>
 
-<p>Figure <a href="#figure-component5">figure-component5</a> depicts
-the fifth component with four new classes and three associations.
+<p><a href="#figure-component6">Figure 10</a> depicts
+the sixth component with three new classes (Collection, Dictionary, and Pair) and three associations (insertion, removal, and memberOf).
 </p>
 
 
 <div style="text-align: center;">
 <figure>
-<img src="images/Dictionaries.png" alt="dictionaries"/>
-<figcaption id="figure-component5">Figure 9: Collections Component Overview</figcaption>
+<!-- <img src="images/Dictionaries.png" alt="dictionaries"/> -->
+<img src="uml/component6.svg" alt="dictionaries"/>
+
+<figcaption id="figure-component6">Figure 10: Collections Component Overview</figcaption>
 </figure>
 </div>
 
@@ -2546,7 +2696,7 @@
 <span class="glossary-ref" data-ref="glossary-membership"></span>
 
 <p>
-The insertion and removal  relations make insertions and removals explicit as part of the history of a dictionary. This, however, requires explicit mention of the state of the dictionary prior to each operation. The membership relation removes this needs, allowing the state of a dictionary <span class="name">c</span> to be expressed without having to introduce a prior state.</p>
+The insertion and removal  relations make insertions and removals explicit as part of the history of a dictionary. This, however, requires explicit mention of the state of the dictionary prior to each operation. The membership relation removes this need, allowing the state of a dictionary <span class="name">c</span> to be expressed without having to introduce a prior state.</p>
 
 <p>
 <div class="attributes" id="attributes-memberOf">
@@ -2636,8 +2786,9 @@
 
 
 <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 un-prefixed qualified name in the scope of this default namespace declaration
+declaration refers to this namespace. </p>
+
+<p>A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every un-prefixed qualified name in the scope of this default namespace declaration
 refers to this namespace.</p>
 
 <p>The <dfn title="prov-namespace">PROV namespace</dfn> is identified by the URI <a href="http://www.w3.org/ns/prov#">http://www.w3.org/ns/prov#</a>.</p>
@@ -2904,7 +3055,7 @@
 <h2>PROV-DM Extensibility Points</h2>
 
 
-<p>The PROV data model provides extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
+<p>The PROV data model provides extensibility points that allow designers to specialize it for specific applications or domains. We summarize these extensibility points here:
 
 <ul>
 <li> Attribute-value lists occur in all types and relations of the data model.  Applications designers are free to introduce further application-specific attributes. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace