minor edits
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Mon, 16 Jan 2012 23:15:32 +0000
changeset 1369 5f6924634a7d
parent 1367 2185359b6fa2
child 1370 d052c50db1e4
minor edits
model/ProvenanceModel.html
--- a/model/ProvenanceModel.html	Mon Jan 16 20:52:36 2012 +0000
+++ b/model/ProvenanceModel.html	Mon Jan 16 23:15:32 2012 +0000
@@ -38,7 +38,7 @@
           "<a href=\"http://www.ditext.com/johnson/intro-3.html\"><cite>Logic: Part III</cite></a>."+
           "1924. "+
           "URL: <a href=\"http://www.ditext.com/johnson/intro-3.html\">http://www.ditext.com/johnson/intro-3.html</a>",
-        "PROV-SEMANTICS":
+        "PROV-SEM":
           "James Cheney "+
           "<a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\"><cite>Formal Semantics Strawman</cite></a>. "+
           "2011, Work in progress. "+
@@ -56,7 +56,7 @@
           "2011, Working Draft. "+
           "URL: <a href=\"http://www.w3.org/TR/prov-o/\">http://www.w3.org/TR/prov-o/</a>",
 
-        "PROV-PAQ":
+        "PROV-AQ":
           "Graham Klyne and Paul Groth (eds.) Luc Moreau, Olaf Hartig, Yogesh Simmhan, James Meyers, Timothy Lebo, Khalid Belhajjame, and Simon Miles "+
           "<a href=\"http://www.w3.org/TR/prov-aq/\"><cite>Provenance Access and Query</cite></a>. "+
           "2011, Working Draft. "+
@@ -172,7 +172,7 @@
 <section id="sotd">
 <section id="prov-family">
 <!-- <h3>Prov Family of Specifications</h3>-->
-This document is part of 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>
@@ -194,7 +194,7 @@
 </div>     
 
 
-    <section> 
+    <section id="introduction"> 
       <h2>Introduction<br>
 </h2> 
 
@@ -217,20 +217,21 @@
 
 <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 define the various aspects
+<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
-way, the first of which is contained in this document:</p>
+way, the first of which is this document:</p>
 <ul>
-<li>  The PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption; </li>
-<li> A normative serialization of PROV-DM in RDF [[!PROV-O]], specified by means of a mapping to the OWL2 Web Ontology Language [[!OWL2-SYNTAX]];</li>
-<li> The mechanisms for accessing and querying provenance [[!PROV-PAQ]];</li>
-<li> A Primer for the PROV approach [[!PROV-PRIMER]].</li>
+<li>PROV-DM: a data model for provenance, accompanied with a notation to express instances of that data model for human consumption (this document); </li>
+<li>PROV-O: a normative serialization of PROV-DM in RDF [[!PROV-O]], specified by means of a mapping to the OWL2 Web Ontology Language [[!OWL2-SYNTAX]];</li>
+<li>PROV-AQ: the mechanisms for accessing and querying provenance [[!PROV-AQ]];</li>
+<li>PROV-PRIMER: a primer for the PROV approach [[!PROV-PRIMER]];</li>
+<li>PROV-SEM: semantics of the PROV-DM data model [[PROV-SEM]];</li>
 </ul>
 
 
 <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 well-defined 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
@@ -240,7 +241,7 @@
 to illustrate the data model. 
 </p>
 
-    <section> 
+    <section id="structure-of-this-document"> 
 <h3>Structure of this Document</h3>
 
 <p>In <a href="#preliminaries">section 2</a>, a set of preliminaries are introduced, including concepts that underpin PROV-DM and motivations for the PROV-ASN notation.</p>
@@ -253,9 +254,9 @@
 
 <p><a href="#data-model-concepts">Section 5</a> provides the normative definition of PROV-DM and the notation PROV-ASN.</p>
 
-<p><a href="#common-relations">Section 6</a> introduces common relations used in PROV-DM, including relations for data collections and common 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.</p>
+<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="#extensibility-section">Section 8</a> summarizes PROV-DM extensibility points.</p>
 
@@ -273,13 +274,13 @@
 <p> All the elements, relations, reserved names and attributes introduced in this specification belong to the PROV-DM namespace.</p>
 
 <div class="note">
-There is a desire to use a single namespace that all specs can share to refer to common provenance terms.
+There is a desire to use a single namespace that all specifications of the PROV family can share to refer to common provenance terms.
 </div>
 
 </section>
 
 
-    <section> 
+    <section id="conventions"> 
 <h3>Conventions</h3>
 
 
@@ -322,12 +323,12 @@
 referred to as entities. Three such entities may be
 expressed:
 <ul>
-<li>a report available at  URL: fixes the nature of the thing, i.e. a document, and its location; </li>
+<li>a report available at a URL: fixes the nature of the thing, i.e. a document, and its location; </li>
 <li>the version of the report available there today: fixes its version number, contents, and its date;</li>
 <li>the report independent of where it is hosted and of its content over time: fixes the nature of the thing as a conceptual artifact.</li></ul>
 The provenance of these three entities may differ, and may be along the following lines: 
 <ul>
-<li>the provenance of a report available at  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 a report available at a URL may include: the act of publishing it and making it available at a given location, possibly under some license and access control;</li>
 <li>the provenance of the version of the report available there today may include: the authorship of the specific content, and reference to imported content;</li>
 <li>the provenance of the report independent of where it is hosted over time may include: the motivation for writing the report, the overall methodology for producing it, and the broad team involved in it.</li>
 </ul>
@@ -342,7 +343,7 @@
 <p>In the world, <dfn id="concept-activity">activities</dfn> involve
 entities in multiple ways:  consuming them,  processing them, 
 transforming them,  modifying them,  changing them,  relocating
-them,  using them,  generating them, being controlled by them,
+them,  using them,  generating them, being associated with them,
 etc.</p>
 
 
@@ -367,7 +368,7 @@
     <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 in such a provenance claim. </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>
 
@@ -387,7 +388,7 @@
 
 
 
-<section>
+<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:
@@ -404,19 +405,19 @@
 
 </section>
 
-<section>
+<section id="event-ordering">
 <h4>Event Ordering</h4>
 
 <p>To allow for minimalistic clock assumptions, like Lamport
-[[CLOCK]], PROV-DM relies on a notion of relative ordering of <a title="event">events</a>,
-without using physical clocks. This specification assumes that a partial order exists between <a title="event">events</a>.
+[[CLOCK]], PROV-DM relies on a notion of relative ordering of <a title="event">instantaneous events</a>,
+without using physical clocks. This specification assumes that a partial order exists between <a title="event">instantaneous events</a>.
 </p>
 
 
 <p>Specifically, <dfn id="dfn-follows">follows</dfn> is a partial
-order between <a title="event">instantaneous events</a>, indicating that an <a title="event">instantaneous event</a> occurs after another.
+order between <a title="event">instantaneous events</a>, indicating that an <a title="event">instantaneous event</a> occurs at the same time as or after another.
 For symmetry, <dfn id="dfn-precedes">precedes</dfn> is defined as
-the inverse of follows. </p>
+the inverse of follows. (Hence, these relations are reflexive and transitive.)</p>
 
 
 <p> How such partial order is realized in practice is beyond the scope
@@ -432,7 +433,7 @@
 
 
 <p>This specification introduces a set of "temporal interpretation"
-rules allowing to derive <a title="event">instantaneous event</a> ordering constraints from
+rules allowing the derivation of <a title="event">instantaneous event</a> ordering constraints from
 provenance records.  According to such temporal interpretation,
 provenance records MUST satisfy such constraints.  We note that the
 actual verification of such ordering constraints is also outside the
@@ -455,7 +456,7 @@
 
     </section> 
 
-    <section> 
+    <section id="prov-asn-intro"> 
 <h3>PROV-ASN: The Provenance Abstract Syntax Notation</h3>
 
 <p>This specification defines PROV-DM, a data model for provenance, consisting of records describing how people, entities, and activities, were involved in producing,
@@ -482,7 +483,7 @@
 
 
 <p>The formal semantics of PROV-DM is defined at
-[[PROV-SEMANTICS]] and its encoding in the OWL2 Web Ontology Language at [[!PROV-O]].
+[[PROV-SEM]] and its encoding in the OWL2 Web Ontology Language at [[!PROV-O]].
 </p>
 
 
@@ -492,11 +493,11 @@
 
     </section> 
 
-    <section> 
-<h3>Representation, Assertion, and Inference</h3>
+    <section id="representation-record-assertion-inference"> 
+<h3>Representation, Record, Assertion, and Inference</h3>
 
 <p>
-PROV-DM is a provenance data model designed to express <em>representations</em> of the world. 
+PROV-DM is a provenance data model designed to express <em>representations</em> of the world.  Such representations are structured according to a set of <em>records</em>.
 </p>
 
 <div class="anexample">
@@ -505,8 +506,8 @@
 
 
 <p>
-These representations 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 representations.
-This specification does not define a notion of consistency between different sets of assertions (whether by the same asserter or different asserters).
+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>
 
@@ -518,28 +519,28 @@
 <p>The data model is designed to capture activities that happened in the past, as opposed to activities
 that may or will happen. 
 However, this distinction is not formally enforced.
-Therefore, all PROV-DM assertions SHOULD be interpreted as a record of what has happened, as opposed to what may or will happen.</p>
+Therefore, all PROV-DM records SHOULD be interpreted as a description of what has happened, as opposed to what may or will happen.</p>
 
 
 
 <p> 
-This specification does not prescribe the means by which an asserter arrives at assertions; for example, assertions can be composed on the basis of observations, reasoning, or any other means. 
+This specification does not prescribe the means by which an asserter arrives at records; for example, records can be composed on the basis of observations, reasoning, or any other means. 
 </p>
 
 
 <p>
-Sometimes, inferences about the world can be made from representations
+Sometimes, inferences about the world can be made from records
 conformant to the PROV-DM data model. When this is the case, this
 specification defines such inferences, allowing new provenance records
 to be inferred from existing ones. Hence, representations of the world
-can result either from direct assertions by asserters or from
-application of inferences defined by this specification.
+can result either from direct assertions of records by asserters or from inference of new records
+by application of inference rules defined by this specification.
 </p>
 
 
 
 </section>
-    <section> 
+    <section id="grammar-notation"> 
 <h3>Grammar Notation</h3>
 
 <p>This specification includes a grammar for PROV-ASN expressed using the Extended  Backus-Naur Form (EBNF) notation.</p>
@@ -583,6 +584,10 @@
     <section id="prov-dm-overview"> 
 <h2>PROV-DM: An Overview </h2>
 
+<div class="note">
+Paolo, TODO: update figure and text. Replace wasComplementOf by alternateOf/specializationOf. 
+</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>
 
@@ -639,32 +644,33 @@
 <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>
 
 
-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]].
-
-
-
-
-
-<div class='pending'>Comments on section 3.2. This is <a href="http://www.w3.org/2011/prov/track/issues/71">ISSUE-71</a></div>
-
-    <section> 
+<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>
+
+
+
+
+
+    <section id="file-scenario"> 
 <h3>A File Scenario</h3>
 
 
 <p>This scenario is concerned with the evolution of a crime statistics
 file (referred to as e0) stored on a shared file system and which
 journalists Alice, Bob, Charles, David, and Edith can share and
-edit. We consider various <a title="event">events</a> in the evolution of file e0;
+edit. 
+ The file e0 evolution can be mapped to an event line,
+in which we consider various <a title="event">events</a>;
 <a title="event">events</a> listed below follow each other, unless otherwise specified.</p>
 
 
 
 <p>
-<a>Event</a> evt1: Alice creates (a0) an empty file in /share/crime.txt.  We denote this file e1.
+<a>Event</a> evt1: Alice creates (activity: a0) an empty file in /share/crime.txt.  We denote this file e1.
 </p>
 
 <p>
-<a>Event</a> evt2: Bob appends (a1) the following line to /share/crime.txt:</p>
+<a>Event</a> evt2: Bob appends (activity: a1) the following line to /share/crime.txt:</p>
 <pre>
 There was a lot of crime in London last month.
 </pre>
@@ -675,7 +681,7 @@
 </p>
 
 <p>
-<a>Event</a> evt4: David edits (a3) file /share/crime.txt as follows.</p>
+<a>Event</a> evt4: David edits (activity: a3) file /share/crime.txt as follows.</p>
 <pre>
 There was a lot of crime in London and New York last month.
 </pre>
@@ -683,11 +689,11 @@
 We denote the revised file e3.
 </p>
 
-<p><a>Event</a> evt5: Edith emails (a4) the contents of /share/crime.txt as an attachment, referred to as e5.
+<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 (a5) on the file /share/crime.txt.
- The file after grammatical checking is referred to as e6.
+<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>
 
 </section> 
@@ -700,12 +706,17 @@
 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", ex:content="" ])
-entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London last month."])
-entity(e3, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month."])
+entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", 
+             ex:content="" ])
+entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", 
+             ex:content="There was a lot of crime in London last month."])
+entity(e3, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", 
+             ex:content="There was a lot of crime in London and New York last month."])
 entity(e4)
 entity(e5)
-entity(e6, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month.", ex:grammarchecked="yes"])
+entity(e6, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", 
+             ex:content="There was a lot of crime in London and New York last month.", 
+             ex:grammarchecked="yes"])
 </pre>
 
 
@@ -727,14 +738,14 @@
 
 
 <p>
-Activity Records (described in <a href="#record-Activity">Section Activity</a>) represent activities in the scenario.</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"])
 activity(a2, 2011-11-16T17:00:00,,[prov:type="email"])
 activity(a3, 2011-11-17T09:00:00,,[prov:type="edit"])
-activity(a4, 2011-11-17T09:30:00,,[prov:type="email"])
-activity(a5, , ,[prov:type="grammarcheck"])
+activity(a4, 2011-11-17T09:50:00,,[prov:type="email"])
+activity(a5, 2011-11-17T09:30:00, ,[prov:type="grammarcheck"])
 </pre>
 
 
@@ -780,14 +791,17 @@
 </pre>
 
 
+<div class="note">
+Paolo, TODO: check these are the relations alternate/specialization that appear in figure.
+</div>
 
 <p>
-wasComplementOf:   (this relation is described in <a href="#record-complement-of">Section wasComplementOf</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> complement <span class="name">e0</span> with an attribute <span class="name">content</span>.  Likewise, the one denoted by <span class="name">e6</span> complements 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>
-wasComplementOf(e1,e0)
-wasComplementOf(e2,e0)
-wasComplementOf(e3,e0)
-wasComplementOf(e6,e3) 
+specializationOf(e1,e0)
+specializationOf(e2,e0)
+specializationOf(e3,e0)
+specializationOf(e6,e3) 
 </pre>
 
 
@@ -821,7 +835,8 @@
 </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.
 <pre>
-entity(gr1,[prov:type="prov:Plan"%% xsd:QName, ex:url="http://example.org/grammarRules.html" %% xsd:anyURI])
+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>
@@ -832,20 +847,24 @@
 </section> 
 
 
-    <section> 
+    <section id="graphical-illustration"> 
 <h3>Graphical Illustration</h3>
 
 
 <p>
-Provenance assertions 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 assertions.  Therefore, it cannot 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 Complementarity are represented as directed edges.</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 style="text-align: center;">
-<img src="example-graphical.png" alt="example"/>
+<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?
+</div>
+
+<div style="text-align: center; ">
+<img src="example-graphical.png" alt="example" style="max-width: 98%; "/>
 </div>
 <br/>
 <div style="text-align: center;">
@@ -863,22 +882,15 @@
 
 <p>This section contains the normative specification of PROV-DM core, the core of the PROV data model.</p>
 
-<div class="note">
-In a next iteration of this document, it is proposed to reorganize
-section 5 as follows.  First, the presentation of the data model
-alone. Second, its temporal interpretation. Third, the constraints and
-inferences associated with well-formed accounts.  
-</div>
-
    <section id="PROV-DM-record"> 
       
 <h3>Record</h3>
 
-<p>This specification introduced <a>provenance</a> as a record
+<p>This specification introduced <a>provenance</a> as a set of records
 describing the people, institutions, entities, and activities,
 involved in producing, influencing, or delivering a piece of data or a
 thing in the world. PROV-DM is a data model defining the structure and
-meaning of such record.</p>
+meaning of such records.</p>
 
 
 <p>Concretely, PROV-DM consists of a set of constructs to formulate representations of the world and constraints that must be satisfied by them.
@@ -898,7 +910,8 @@
 <a>responsibility record</a>,
 <a>start record</a>,
 <a>end record</a>,
-<a>complementarity record</a>, 
+<a>alternate record</a>, 
+<a>specialization record</a>, 
 <a>annotation record</a>, and
 <a>account record</a>.
 </a>
@@ -951,9 +964,12 @@
    <section id="record-element"> 
 <h3>Element</h3>
 
-<p>This section describes all the PROV-DM records referred to as element records. (They 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>
+</div>
 
    <section id="record-Entity"> 
       
@@ -962,7 +978,7 @@
 <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 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>
@@ -972,7 +988,7 @@
 
 
 <p>
-The assertion of an entity record, <span class="name">entity(id, [ attr1=val1, ...])</span>, 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>
@@ -1020,7 +1036,7 @@
 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/orthogonal of each other.</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>
 
 <li>A characterization interval may collapse into a single instant.</li>
 
@@ -1056,9 +1072,10 @@
 
 
 
-<div class='note'>The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define wasComplementOf more precisely. It would also allow us to address 
-<a href="http://www.w3.org/2011/prov/track/issues/108">ISSUE-108</a>.
-Beginning and end of characterization interval could be expressed by attributes (similarly to activities). </div>
+<div class='issue'>The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define wasComplementOf more precisely. 
+Beginning and end of characterization interval could be expressed by attributes (similarly to activities). 
+How do we define the end of an entity? This is <a href="http://www.w3.org/2011/prov/track/issues/204">ISSUE-204</a>.
+</div>
 
 
  
@@ -1073,10 +1090,10 @@
 
 <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>Such start and end times constitute <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>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 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>
@@ -1106,11 +1123,12 @@
 
 <div class="anexample">
 <p>
-The following activity assertion</p>
+The following activity record</p>
 <pre class="codeexample">
-activity(a1,2011-11-16T16:05:00,2011-11-16T16:06:00,[ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
+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>identified by identifier <span class="name">a1</span>, states the existence of an activity with recipe link <span class="name">add-crime-in-london</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">
@@ -1157,7 +1175,7 @@
 From an inter-operability perspective, it is useful to define some basic categories of agents since
 it will improve the use of provenance records by applications.  
 There should be very few of these basic categories to keep the model simple and accessible. 
-There are three types of agents in the model:
+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> 
@@ -1197,7 +1215,7 @@
 
 entity(e3) and wasAssociatedWith(a1,e3,[prov:role="sponsor"])
 </pre>
-<p>the agent record identified by <span class="name">e1</span> is an explicit agent assertion 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
@@ -1211,7 +1229,7 @@
 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 delete 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>
 
@@ -1221,7 +1239,7 @@
 
 <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>An <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> 
+<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> 
 
 <p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
 </p>
@@ -1259,9 +1277,16 @@
 </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). In note records, it is OPTIONAL for attribute-value pairs to be representations  of something in the world. If they are a representation of something in the world, then it MAY change value for the corresponding duration. If attribute-value pairs of a note record are a representation of something in the world that does not change, they are not regarded as determining characteristics of an entity or activity, for the purpose of provenance. 
+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.
+If a note record's attribute-value pair represents an entity's situation 
+in the world, no requirement is made on this situation to be unchanged for 
+the entitys' characterization interval.
 </p>
 
+<div class='issue'> Comments on notes and their attributes appear  in <a href="http://www.w3.org/2011/prov/track/issues/189">ISSUE-189</a>.</div>
 
    </section> 
 
@@ -1278,10 +1303,10 @@
 <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="complementarity record">wasComplementOf</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>
+<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>&mdash;</td><td><a title="annotation record">hasAnnotation</a></td></tr>
+<tr><td>Activity</td><td><a title="usage record">used</a></td><td>&mdash;</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>&mdash;</td><td>&mdash;</td><td><a title="responsibility record">actedOnBehalfOf</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
+<tr><td>Note</td><td>&mdash;</td><td>&mdash;</td><td>&mdash;</td><td><a title="annotation record">hasAnnotation</a></td></tr>
 </table>
 </div>
 
@@ -1380,6 +1405,10 @@
 <div class='note'>TODO: Introduce the well-formed-ness constraint in a entirely separate section.</div>
 -->
 
+
+<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.
+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>.</div>
 </section>
 
 
@@ -1488,6 +1517,9 @@
 told the student to put up the web page.  So there is some notion of
 responsibility that needs to be captured. </p>
 
+<p>Examples of activity association  include designing, participation, initiation and termination, timetabling or sponsoring. </p>
+
+
 <p>Provenance reflects activities that have occurred.  In some  
 cases, those activities reflect the execution of a plan that was  
 designed in advance to guide the execution.  PROV-DM allows attaching  
@@ -1496,7 +1528,6 @@
 validate the execution as represented in the provenance record, to  
 manage expectation failures, or to provide explanations.</p>
 
-<p>Examples of activity association  include designing, participation, initiation and termination, timetabling or sponsoring. </p>
 
 
 
@@ -1546,7 +1577,7 @@
 </div>
 
 <div class="anexample">
-In the following example, a researcher and an operator agents are asserted to be associated with an activity. The designer's goals are achieved by a workflow <span class="name">ex:wf</span>.   
+In the following example, a designer and an operator agents are asserted to be associated with an activity. The designer's goals are achieved by a workflow <span class="name">ex:wf</span>.   
 <pre class="codeexample">
 activity(ex:a,[prov:type="workflow execution"])
 agent(ex:ag1,[prov:type="operator"])
@@ -1560,7 +1591,12 @@
 </div>
 
 <div class='issue'> The activity association record does not allow for a plan to be asserted without an agent.
-This seems over-restrictive. Raised in <a href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
+This seems over-restrictive. Discussed in the context of <a href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
+
+
+<div class='issue'> Agents should not be inferred. WasAssociatedWith should also work with entities.
+This is <a href="http://www.w3.org/2011/prov/track/issues/206">ISSUE-206</a>.</div>
+
 
 </section>
 
@@ -1620,10 +1656,15 @@
 wasEndedby(a,ag,[ex:mode="manual"])
 </pre>
 <p>state that the activity, represented by the activity record denoted by <span class="name">a</span>
-was started and ended by an agent, represented by record denoted by  <span class="name">ah</span>, in "manual" mode, an application specific characterization of these relations.
+was started and ended by an agent, represented by record denoted by  <span class="name">ag</span>, in "manual" mode, an application specific characterization of these relations.
 </p>
 </div>
 
+<div class='issue'> 
+Should we define start/end records as representation of activity start/end events.
+Should time be associated with these events rather than with activities. This will be similar to what
+we do for entities. This is issue <a href="http://www.w3.org/2011/prov/track/issues/207">ISSUE-207</a>.</div>
+
 
 </section>
 
@@ -1817,7 +1858,7 @@
 </div>
 
 <div class="anexample">
-In the following example, a programmer, a researcher and a funder agents are asserted.  The porgrammer 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"])
@@ -2051,8 +2092,8 @@
 some <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">attrs1</span>, <span class="name">attrs2</span>, and <span class="name">a</span>, one
 cannot infer derivation <span class="name">wasDerivedFrom(e2, e1, a, g, u)</span>
 or <span class="name">wasDerivedFrom(e2,e1)</span> since 
-of <span class="name">e2</span> cannot possibly be determined by
-of <span class="name">e1</span>, given the creation of <span class="name">e2</span> <a>precedes</a> the use
+of <span class="name">e2</span> cannot possibly be derived from
+ <span class="name">e1</span>, given the creation of <span class="name">e2</span> <a>precedes</a> the use
 of <span class="name">e1</span>.
 </p>
 
@@ -2067,12 +2108,13 @@
 
 
 <div class='issue'>Several points were raised about the attribute steps.
-Its name, its default value   <a href="http://www.w3.org/2011/prov/track/issues/180">ISSUE-180</a>.</div> <a href="http://www.w3.org/2011/prov/track/issues/179">ISSUE-179</a>.</div>
+Its name, its default value   <a href="http://www.w3.org/2011/prov/track/issues/180">ISSUE-180</a>.
+ <a href="http://www.w3.org/2011/prov/track/issues/179">ISSUE-179</a>.</div>
 
 </section>
 
 
-<section id="record-complement-of">
+<section id="record-alternate-specialization">
 
 <h4>Alternate  and Specialization Records</h4>
 
@@ -2114,6 +2156,14 @@
     <li><span class="name">alternateOf(B,A)</span> is <strong>symmetric</strong>:   <span class="name">alternateOf(B,A)</span> implies  <span class="name">alternateOf(A,B)</span>.
   </ul>
 
+<div class="note">
+Paolo, TODO: similarly to other records, one needs to provide a standalone definition for these  records, and also enumerate their components.
+</div>
+
+<p>A <dfn id="dfn-Alternate">alternate record</dfn> ...</p>
+
+<p>A <dfn id="dfn-Specialization">specialization record</dfn> ...</p>
+
 <!--
   <h5>Case of entities with known limited validity</h5>
 
@@ -2368,7 +2418,7 @@
 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>) represented by entity records 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>
 
@@ -2428,8 +2478,9 @@
 <span class="name">)</span> 
 </div>
 
-<div class='note'>
-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. </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.
+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">
 <p>
@@ -2460,7 +2511,7 @@
 <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>
 
-<p>Whilst constraint <a href="#identified-entity-in-account">identified-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>
+<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>
 
 <div class="anexample">
 <p>
@@ -2472,7 +2523,7 @@
           entity(e,[prov:type="person", ex:weight=50, ex:age=30])
           ...)
 </pre>
-<p>Application of <a href="#identified-entity-in-account">identified-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.
+<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.
 </p></div>
 
 <p>Account records can be nested since  an account record can occur among the records being wrapped by another account. </p>
@@ -2547,7 +2598,7 @@
 <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 records. A record container is the root of a provenance record and can be exploited to package up prov-dm records in response to a request for the provenance of something ([[!PROV-PAQ]]). 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 records. A record container is the root of a provenance record and can be exploited to package up prov-dm records 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>
 
@@ -2587,8 +2638,8 @@
 </div>
 
 
-
-
+<div class='issue'>
+Clarify what records are. This is <a href="http://www.w3.org/2011/prov/track/issues/208">ISSUE-208</a>. </div>
 </section>
 </section>
 
@@ -2769,7 +2820,7 @@
 </div>
 
 <div class='note'>
-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. </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>
 
@@ -3166,7 +3217,7 @@
 </section>
 
 
-<section>
+<section id="recod-attribution">
 <h3>Attribution Record</h3> 
 
 <p>An attribution record represents that an entity is ascribed to an agent and is compliant with the <span class="nonterminal">attributionRecord</span> production.</p>
@@ -3210,7 +3261,7 @@
 </section>
 
 
-<section>
+<section id="record-quotation">
 <h3>Quotation Record</h3>
 
 
@@ -3262,7 +3313,7 @@
 </section>
 
 
-<section>
+<section id="record-summary">
 <h3>Summary Record</h3>
 <p>A <dfn>summary record</dfn> represents that an entity (expected to be a document) is a synopsis or abbreviation of another entity (also expected to be a document). </p>
 
@@ -3297,7 +3348,7 @@
 
 </section>
 
-<section>
+<section id="record-orignal-source">
 <h3>Original Source Record</h3>
 
 <p>An <dfn>original source record</dfn> represents an entity in
@@ -3736,7 +3787,7 @@
 </div>
 
 
-<div class="note">
+<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.
 
 <p><a href="examples/sculpture.prov-asn">Sculpture example in ASN</a></p>