Editorial fixes suggested by Tim, and replace 'provenance description' with 'provenance record', following PROV-DM
authorGraham Klyne
Thu, 07 Feb 2013 16:41:47 +0000
changeset 5505 cf11871bb9ba
parent 5504 4d16b451fc1a
child 5506 a53fb5b58d8f
Editorial fixes suggested by Tim, and replace 'provenance description' with 'provenance record', following PROV-DM
paq/prov-aq.html
--- a/paq/prov-aq.html	Thu Feb 07 15:53:32 2013 +0000
+++ b/paq/prov-aq.html	Thu Feb 07 16:41:47 2013 +0000
@@ -205,7 +205,7 @@
 This document specifies how to use standard Web protocols,
 including HTTP, to obtain information about the provenance of
 resources on the Web. We describe both simple access mechanisms for
-locating provenance descriptions associated with web pages or resources, and
+locating provenance records associated with web pages or resources, and
 provenance query services for more complex deployments. This is
 part of the larger W3C PROV provenance family of documents.
 
@@ -221,7 +221,7 @@
 <li> <a href="http://www.w3.org/TR/2012/WD-prov-overview-20121211/">PROV-OVERVIEW</a> (To be published as Note), an overview of the PROV family of documents [[PROV-OVERVIEW]];</li>
 <li> <a href="http://www.w3.org/TR/2012/WD-prov-primer-20121211/">PROV-PRIMER</a> (To be published as Note), a primer for the PROV data model [[PROV-PRIMER]];</li>
 <li> <a href="http://www.w3.org/TR/2012/CR-prov-o-20121211/">PROV-O</a> (Candidate Recommendation), the PROV ontology, an OWL2 ontology allowing the mapping of PROV to RDF [[!PROV-O]];</li>
-<li> <a href="http://www.w3.org/TR/2012/CR-prov-dm-20121211/">PROV-DM</a> (Candidate Recommendation), the PROV data model for provenance (this document);</li>
+<li> <a href="http://www.w3.org/TR/2012/CR-prov-dm-20121211/">PROV-DM</a> (Candidate Recommendation), the PROV data model for provenance;</li>
 <li> <a href="http://www.w3.org/TR/2012/CR-prov-n-20121211/">PROV-N</a> (Candidate Recommendation), a notation for provenance aimed at human consumption [[!PROV-N]];</li>
 <li> <a href="http://www.w3.org/TR/2012/CR-prov-constraints-20121211/">PROV-CONSTRAINTS</a> (Candidate Recommendation), a set of constraints applying to the PROV data model [[!PROV-CONSTRAINTS]];</li>
 <li> <a href="http://www.w3.org/TR/2012/WD-prov-xml-20121211/">PROV-XML</a> (To be published as Note),  an XML schema for the PROV data model [[PROV-XML]].</li>
@@ -249,14 +249,14 @@
     <section>
       <h2>Introduction</h2>
       <p>
-        The Provenance Data Model [[PROV-DM]], Provenance Ontology [[PROV-O]] and related specifications (see the [[PROV-OVERVIEW]]) define how to represent provenance in the World Wide Web.
+        The Provenance Data Model [[PROV-DM]], Provenance Ontology [[PROV-O]] and related specifications define how to represent provenance in the World Wide Web (see the [[PROV-OVERVIEW]]).
       </p>
       <p>
-        This note describes how standard web protocols may be used to locate, retrieve and query provenance descriptions:
+        This note describes how standard web protocols may be used to locate, retrieve and query provenance records:
       </p>
         <ul>
           <li>
-            Simple mechanisms for retrieving and discovering provenance descriptions are described in <a href="#accessing-provenance-descriptions" class="sectionRef"></a> and <a href="#locating-provenance-descriptions" class="sectionRef"></a> .
+            Simple mechanisms for retrieving and discovering provenance records are described in <a href="#accessing-provenance-descriptions" class="sectionRef"></a> and <a href="#locating-provenance-descriptions" class="sectionRef"></a> .
           </li>
           <li>
             Provenance query mechanisms that may be used for more demanding deployments are described in <a href="#provenance-query-services" class="sectionRef"></a>.
@@ -277,23 +277,23 @@
             <dt><a href="#dfn-resource"><dfn>Resource</dfn></a></dt>
             <dd>a resource in the general sense of "whatever might be identified by a URI", as described by the Architecture of the World Wide Web [[WEBARCH]], <a href="http://www.w3.org/TR/webarch/#id-resources" class="externalRef">section 2.2</a>. A resource may be associated with multiple instances or views (<a class="internalDFN">constrained resource</a>s) with differing provenance.</dd>
             <dt><a href="#dfn-constrained-resource"><dfn>Constrained resource</dfn></a></dt>
-            <dd>an aspect, version or instance of a <a class="internalDFN">resource</a>, about which one may wish to present some <a class="internalDFN">provenance description</a>s. For example, a weather report for a given date may be an aspect of a resource that is maintained as the current weather report. A constrained resource is itself a <a class="internalDFN">resource</a>, and may have its own URI different from that of the original.  See also [[PROV-DM]], and [[WEBARCH]] <a href="http://www.w3.org/TR/webarch/#representation-reuse" class="externalRef">section 2.3.2</a>.</dd>
+            <dd>an aspect, version or instance of a <a class="internalDFN">resource</a>, about which one may wish to present a <a class="internalDFN">provenance record</a>s. For example, a weather report for a given date may be an aspect of a resource that is maintained as the current weather report. A constrained resource is itself a <a class="internalDFN">resource</a>, and may have its own URI different from that of the original.  See also [[PROV-DM]], and [[WEBARCH]] <a href="http://www.w3.org/TR/webarch/#representation-reuse" class="externalRef">section 2.3.2</a>.</dd>
             <dt><a href="#dfn-target-uri"><dfn>Target-URI</dfn></a></dt>
-            <dd>a URI denoting a <a class="internalDFN">resource</a> (including any <a class="internalDFN">constrained resource</a>), which identifies that resource for the purpose of finding and expressing <a class="internalDFN">provenance descriptions</a> associated with it (see <a href="#provenance-entities-resources" class="sectionRef"></a> for discussion).</dd>
-            </dt><a href="#dfn-provenance-description"><dfn>Provenance description</dfn></a></dt>
+            <dd>a URI denoting a <a class="internalDFN">resource</a> (including any <a class="internalDFN">constrained resource</a>), which identifies that resource for the purpose of finding and expressing provenance associated with it.</dd>
+            </dt><a href="#dfn-provenance-record"><dfn>Provenance record</dfn></a></dt>
             <dd>refers to provenance represented in some fashion.</dd>
             <dt><a href="#dfn-provenance-uri"><dfn>Provenance-URI</dfn></a></dt>
-            <dd>a URI denoting some <a class="internalDFN">provenance description</a>.</dd>
+            <dd>a URI denoting some <a class="internalDFN">provenance record</a>.</dd>
             <dt><a href="#dfn-provenance-query-service"><dfn>Provenance query service</dfn></a></dt>
-            <dd>a query service that provides a <a class="internalDFN">provenance description</a> given a <a class="internalDFN">target-URI</a> or other information about the desired provenance.</dd>
+            <dd>a query service that accesses provenance given a <a class="internalDFN">target-URI</a> or other information about the desired provenance.</dd>
             <dt><a href="#dfn-service-uri"><dfn>Service-URI</dfn></a></dt>
             <dd>the URI of a <a class="internalDFN">provenance query service</a>.</dd>
             <dt><a href="#dfn-pingback-uri"><dfn>Pingback-URI</dfn></a></dt>
-            <dd>the URI of a provenance pingback service that can receive forward provenance descriptions (i.e. provenance describing how a resource is used - see <a href="#forward-provenance" class="sectionRef"></a>).</dd>
-            <dt><a href="#dfn-accessing"><dfn>Accessing</dfn></a> provenance descriptions</dt>
-            <dd>given the identity of a resource, the process of discovering and retrieving some <a class="internalDFN">provenance description</a>(s) about that resource.  This may involve <a class="internalDFN">locating</a> a provenance description resource, then performing an HTTP GET to retrieve it, or locating and using a query service for provenance description about an identified resource, or some other mechanism not covered in this document.</dd>
-            <dt><a href="#dfn-locating"><dfn>Locating</dfn></a> provenance descriptions</dt>
-            <dd>given the identity of a resource, discovery of a URI at which some <a class="internalDFN">provenance description</a> about that resource may be retrieved.</dd>
+            <dd>the URI of a provenance pingback service that can receive forward provenance (i.e. provenance describing how a resource is used after it has been created - see <a href="#forward-provenance" class="sectionRef"></a>).</dd>
+            <dt><a href="#dfn-accessing"><dfn>Accessing</dfn></a> provenance records</dt>
+            <dd>given the identity of a resource, the process of discovering and retrieving some <a class="internalDFN">provenance record</a>(s) about that resource.  This may involve <a class="internalDFN">locating</a> a provenance record, then performing an HTTP GET to retrieve it, or locating and using a query service for provenance about an identified resource, or some other mechanism not covered in this document.</dd>
+            <dt><a href="#dfn-locating"><dfn>Locating</dfn></a> provenance records</dt>
+            <dd>given the identity of a resource, discovery of a URI at which some <a class="internalDFN">provenance record</a> about that resource may be retrieved.</dd>
             <!--
             <a href="#dfn-..."><dt><dfn>...</dfn></dt></a>
             <dd>...</dd>
@@ -305,27 +305,27 @@
       <section>
         <h2 id="provenance-entities-resources">Provenance and resources</h2>
         <p>
-          Fundamentally, a <a class="internalDFN">provenance description</a> is <em>about</em> <a class="internalDFN">resource</a>s.  In general, resources may vary over time and context.  E.g., a resource describing the weather in London changes from day-to-day, or a listing of restaurants near you will vary depending on your location.  Provenance descriptions, to be useful, must be persistent and not themselves dependent on context.  Yet we may still want to make provenance assertions about dynamic or context-dependent resources (e.g. a weather forecast for London on a particular day may have been derived from a particular set of Meteorological Office data).
+          Fundamentally, a <a class="internalDFN">provenance record</a> is <em>about</em> <a class="internalDFN">resource</a>s.  In general, resources may vary over time and context.  E.g., a resource describing the weather in London changes from day-to-day, or a listing of restaurants near you will vary depending on your location.  Provenance records, to be useful, must be persistent and not themselves dependent on context.  Yet we may still want to make provenance assertions about dynamic or context-dependent resources (e.g. a weather forecast for London on a particular day may have been derived from a particular set of Meteorological Office data).
         </p>
         <p>
-          Provenance descriptions of dynamic and context-dependent resources are possible through a notion of constrained resources.  A <a class="internalDFN">constrained resource</a> is simply a resource (in the sense defined by [[WEBARCH]], <a href="http://www.w3.org/TR/webarch/#id-resources" class="externalRef">section 2.2</a>) that is a specialization or instance of some other resource.  For example, a W3C specification typically undergoes several public revisions before it is finalized.  A URI that refers to the "current" revision might be thought of as denoting the specification throughout its lifetime.  Each individual revision would also have its own <a class="internalDFN">target-URI</a> denoting the specification at that particular stage in its development.  Using these, we can make provenance assertions that a particular revision was published on a particular date, and was last modified by a particular editor.  Target-URIs may use any URI scheme, and are not required to be dereferencable.
+          Provenance records for dynamic and context-dependent resources are possible through a notion of constrained resources.  A <a class="internalDFN">constrained resource</a> is simply a resource (in the sense defined by [[WEBARCH]], <a href="http://www.w3.org/TR/webarch/#id-resources" class="externalRef">section 2.2</a>) that is a specialization or instance of some other resource.  For example, a W3C specification typically undergoes several public revisions before it is finalized.  A URI that refers to the "current" revision might be thought of as denoting the specification throughout its lifetime.  Each individual revision would also have its own <a class="internalDFN">target-URI</a> denoting the specification at that particular stage in its development.  Using these, we can make provenance assertions that a particular revision was published on a particular date, and was last modified by a particular editor.  Target-URIs may use any URI scheme, and are not required to be dereferencable.
         </p>
         <p>
-           Requests for provenance about a resource may return provenance descriptions that use one or more target-URIs to refer to versions of that resource.  Some provenance descriptions may use multiple target-URIs if there are assertions referring to the same underlying resource in different contexts.  For example, a provenance description for a W3C document might include information about all revisions of the document using statements that use the different target-URIs of the various revisions.
+           Requests for provenance about a resource may return provenance records that use one or more target-URIs to refer to versions of that resource.  Some provenance records may use multiple target-URIs if there are assertions referring to the same underlying resource in different contexts.  For example, a provenance record for a W3C document might include information about all revisions of the document using statements that use the different target-URIs of the various revisions.
         </p>
         <p>
-          In summary, a <a class="internalDFN">provenance description</a> may be not universally applicable to a <a class="internalDFN">resource</a>, but may be expressed with respect to that resource in a restricted context (e.g. at a particular time). This restriction is itself just another resource (e.g. the weather forecast for a give date as opposed to the current weather forecast), with its own URI for referring to it within a provenance description.
+          In summary, a <a class="internalDFN">provenance record</a> may be not universally applicable to a <a class="internalDFN">resource</a>, but may be expressed with respect to that resource in a restricted context (e.g. at a particular time). This restriction is itself just another resource (e.g. the weather forecast for a give date as opposed to the current weather forecast), with its own URI for referring to it within a provenance record.
         </p>
       </section>
 
       <section>
-        <h2>Interpreting provenance descriptions</h2>
+        <h2>Interpreting provenance records</h2>
         <p>
-          Any given <a class="internalDFN">provenance description</a> may contain information about several resources, referring to them using their various <a class="internalDFN">target-URI</a>s.
-          Thus, when interpreting provenance descriptions, it is important to be aware that statements about several resources may be present, and to be accordingly selective when using the information provided.  (In some exceptional cases, it may be that a provenance description returned does not contain any information relating to a specific associated resource.)
+          Any given <a class="internalDFN">provenance record</a> may contain information about several resources, referring to them using their various <a class="internalDFN">target-URI</a>s.
+          Thus, when interpreting provenance records, it is important to be aware that statements about several resources may be present, and to be accordingly selective when using the information provided.  (In some exceptional cases, it may be that a provenance record returned does not contain any information relating to a specific associated resource.)
         </p>
         <p>
-          A provenance description is not of itself guaranteed to be authoritative or correct. Trust in provenance descriptions must be determined separately from trust in the original resource. Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any other resource; e.g. based on the domain that serves it, or an associated digital signature. (See also <a href="#security-considerations" class="sectionRef"></a>.)
+          A provenance record is not of itself guaranteed to be authoritative or correct. Trust in provenance records must be determined separately from trust in the original resource. Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any other resource; e.g. based on the domain that serves it, or an associated digital signature. (See also <a href="#security-considerations" class="sectionRef"></a>.)
         </p>
       </section>
 
@@ -347,12 +347,12 @@
           </tr>
           <tr style="vertical-align: top;">
             <td><a class="internalDFN">Provenance-URI</a></td>
-            <td>A provenance description in the sense described by [[PROV-DM]] (<a href="http://www.w3.org/TR/prov-dm/#section-prov-overview" class="externalRef">PROV Overview</a>).</td>
-            <td>A provenance description in any defined format, selectable via content negotiation.</td>
+            <td>A provenance record in the sense described by [[PROV-DM]] (<a href="http://www.w3.org/TR/prov-dm/#section-prov-overview" class="externalRef">PROV Overview</a>).</td>
+            <td>A provenance record in any defined format, selectable via content negotiation.</td>
           </tr>
           <tr style="vertical-align: top;">
             <td><a class="internalDFN">Service-URI</a></td>
-            <td>A provenance query service (i.e. a resource of type <code>prov:ProvenanceQueryService</code>).  This is the initial URI used when accessing a provenance query service; following REST API style [[REST-APIs]], actual URIs for accessing provenance descriptions are determined via the query service description.</td>
+            <td>A provenance query service (i.e. a resource of type <code>prov:ProvenanceQueryService</code>).  This is the initial URI used when accessing a provenance query service; following REST API style [[REST-APIs]], actual URIs for accessing provenance are determined via the query service description.</td>
             <td>A provenance query service description per <a href="#provenance-query-service-description" class="sectionRef"></a>.  Alternative formats may be offered via HTTP content negotiation.</td>
           </tr>
           <tr style="vertical-align: top;">
@@ -370,28 +370,28 @@
 <!-- == Sect 2 =================================================================================== -->
     
     <section>
-      <h2>Accessing provenance descriptions</h2>
+      <h2>Accessing provenance records</h2>
       <p>
-        This specification describes two ways to access <a class="internalDFN">provenance description</a>s:
+        This specification describes two ways to access <a class="internalDFN">provenance record</a>s:
       </p>
       <ol>
         <li>Direct access: given a <a class="internalDFN">provenance-URI</a>, simply dereference it, and</li>
         <li>Indirectly via a query service: given the URIs of some resource (or maybe other information) and a <a class="internalDFN">provenance query service</a>, use the service to access provenance of the resource.</li>
       </ol>
       <p>
-        Web applications may access a provenance description in the same way as any resource on the Web, by dereferencing its URI (commonly using an HTTP GET operation). Thus, any provenance description may be associated with a <a class="internalDFN">provenance-URI</a>, and may be accessed by dereferencing that URI using web mechanisms.
+        Web applications may access a provenance record in the same way as any resource on the Web, by dereferencing its URI (commonly using an HTTP GET operation). Thus, any provenance record may be associated with a <a class="internalDFN">provenance-URI</a>, and may be accessed by dereferencing that URI using web mechanisms.
       </p>
       <p>
-        When there is no easy way to associate a provenance-URI with individual resources (e.g. for resources not directly web-accessible, or whose publication mechanism is controlled by someone else), one may provide provenance descriptions about multiple resources through a provenance query service.  A REST protocol for provenance querying is defined in Section <a href="#provenance-query-services" class="sectionRef"></a>; also described there is a mechanism for locating a SPARQL query service.
+        When there is no easy way to associate a provenance-URI with individual resources (e.g. for resources not directly web-accessible, or whose publication mechanism is controlled by someone else), one may provide provenance about multiple resources through a provenance query service.  A REST protocol for provenance querying is defined in Section <a href="#provenance-query-services" class="sectionRef"></a>; also described there is a mechanism for locating a SPARQL query service.
       </p>
       <p>
         How much or how little provenance is returned in response to a retrieval request is a matter for the provenance provider application.  
       </p>
       <p>
-        Retrieved provenance is not guaranteed to be authoritative.  Trust in provenance descriptions must be determined separately from trust in the original resource that they may describe.  Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any resource; e.g. based on the domain that serves it, or an associated digital signature. (See also <a href="#security-considerations" class="sectionRef"></a>.)
+        Retrieved provenance is not guaranteed to be authoritative.  Trust in provenance records must be determined separately from trust in the original resource that they may describe.  Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any resource; e.g. based on the domain that serves it, or an associated digital signature. (See also <a href="#security-considerations" class="sectionRef"></a>.)
       </p>
       <p>
-        When publishing provenance descriptions, corresponding <a class="internalDFN">provenance-URI</a>s or <a class="internalDFN">service-URI</a>s should be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-descriptions" class="sectionRef"></a>.
+        When publishing provenance records, corresponding <a class="internalDFN">provenance-URI</a>s or <a class="internalDFN">service-URI</a>s should be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-descriptions" class="sectionRef"></a>.
       </p>
       <p>
         Provenance may be presented as a <a href="/TR/prov-dm/#component4" class="externalRef">bundle</a>, which is "<cite>a named set of provenance descriptions, and is itself an entity, so allowing provenance of provenance to be expressed</cite>" [[PROV-DM]].  There is no requirement that a bundle identifier can be dereferenced to access the corresponding provenance, but where practical it is RECOMMENDED that matters be arranged so this is possible.  One possible realization of a bundle is that it is published as part of an RDF Dataset [[RDF-CONCEPTS11]] or similar composite structure containing multiple RDF graphs in a single document. To access such a bundle would require accessing the RDF Dataset and then extracting the identified component; this in turn would require knowing a URI or some other way to retrieve the dataset.  This specification does not describe a specific mechanism for extracting components from a document containing multiple graphs.
@@ -403,9 +403,9 @@
 <!-- == Sect 3 =================================================================================== -->
     
     <section>
-      <h2>Locating provenance descriptions</h2>
+      <h2>Locating provenance records</h2>
       <p>
-        If a <a class="internalDFN">provenance description</a> is a resource that can be accessed using web retrieval, one needs to know its <a class="internalDFN">provenance-URI</a> to dereference.  If this is known in advance, there is nothing more to specify.  If a provenance-URI is not known then a mechanism to discover one must be based on information that is available to the would-be accessor. Likewise, provenance descriptions may be exposed by a query service, in which case, the <a class="internalDFN">service-URI</a> needs to be known.
+        If a <a class="internalDFN">provenance record</a> is a resource that can be accessed using web retrieval, one needs to know its <a class="internalDFN">provenance-URI</a> to dereference.  If this is known in advance, there is nothing more to specify.  If a provenance-URI is not known then a mechanism to discover one must be based on information that is available to the would-be accessor. Likewise, provenance may be exposed by a query service, in which case, the <a class="internalDFN">service-URI</a> needs to be known.
       </p>
       <p>
         In the following, we refer to <a class="internalDFN">provider</a>s and <a class="internalDFN">consumer</a>s of provenance:
@@ -413,17 +413,17 @@
       <dl>
         <dt><dfn>provider</dfn></dt>
         <dd>
-          is an agent that collects or constructs some information and makes it available.  The nature of the information or the means by which it is made available are not constrained, but the following discussion focuses on provenance descriptions made available by HTTP transactions (i.e. where the provenance provider is an HTTP server),
+          is an agent that collects or constructs some information and makes it available.  The nature of the information or the means by which it is made available are not constrained, but the following discussion focuses on provenance records made available by HTTP transactions (i.e. where the provenance provider is an HTTP server),
         </dd>
         <dt><dfn>consumer</dfn></dt>
         <dd>
-          is an agent that receives and interprets provenance descriptions.
+          is an agent that receives and interprets provenance records.
         </dd>
       </dl>
-      <p>Provenance descriptions may be offered by several providers as well as that of the original resource, each with different concerns, and presenting provenance at different locations.  It is possible that these different providers may present contradictory provenance.
+      <p>Provenance records may be offered by several providers other than that of the original resource, each with different concerns, and presenting provenance at different locations.  It is possible that these different providers may present contradictory provenance.
       </p>
       <p>
-        The consumer of a provenance description will generally need to isolate information about some specific target resource or resources.  These may be <a class="internalDFN">constrained resource</a>s identified by separate target-URIs than the original resource.  In such circumstances, a provenance consumer will need to know the target-URI used by a provenance description.
+        The consumer of a provenance record will generally need to isolate information about some specific target resource or resources.  These may be <a class="internalDFN">constrained resource</a>s identified by separate target-URIs than the original resource, in which case a provenance consumer will need to know the target-URI used.
       </p>
       <p>
         We consider here mechanisms for a provider to indicate a <a class="internalDFN">provenance-URI</a> or <a class="internalDFN">service-URI</a> along with a <a class="internalDFN">target-URI</a>.
@@ -438,19 +438,19 @@
         These particular cases are selected as corresponding to primary current web protocol and data formats.  Similar approaches  may be possible for other protocols or resource formats.
       </p>
       <p>
-        The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance descriptions.  The provenance descriptions should themselves explicitly identify the target resources they describe.  While a provider should avoid giving spurious information, there are no fixed semantics, particularly when multiple resources are indicated, and a client should not assume that a specific given provenance-URI will yield information about a specific given target-URI.  In the general case, a client presented with multiple provenance-URIs and multiple target-URIs should look at all of the provenance-URIs for information about any or all of the target-URIs.
+        The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance records.  The provenance records should themselves explicitly identify the target resources they describe.  While a provider should avoid giving spurious information, there are no fixed semantics, particularly when multiple resources are indicated, and a client should not assume that a specific given provenance-URI will yield information about a specific given target-URI.  In the general case, a client presented with multiple provenance-URIs and multiple target-URIs should look at all of the provenance-URIs for information about any or all of the target-URIs.
       </p>
 
       <section>
         <h2>Resource accessed by HTTP</h2>
         <p>
-          For a resource accessible using HTTP, a provenance description may be indicated using an HTTP <code>Link</code> header field, as defined by <a href="http://tools.ietf.org/html/rfc5988" class="externalRef">Web Linking (RFC 5988)</a> [[LINK-REL]].  The <code>Link</code> header field is included in the HTTP response to a GET or HEAD operation (other HTTP operations are not excluded, but are not considered here).
+          For a resource accessible using HTTP, a provenance record may be indicated using an HTTP <code>Link</code> header field, as defined by <a href="http://tools.ietf.org/html/rfc5988" class="externalRef">Web Linking (RFC 5988)</a> [[LINK-REL]].  The <code>Link</code> header field is included in the HTTP response to a GET or HEAD operation (other HTTP operations are not excluded, but are not considered here).
         </p>
         <p>
-          A <code>hasProvenance</code> link relation type for referencing a provenance description may be used thus:
+          A <code>hasProvenance</code> link relation type for referencing a provenance record may be used thus:
         </p>
         <pre class="pattern">Link: &lt;<cite>provenance-URI</cite>&gt;; rel="http://www.w3.org/ns/prov#hasProvenance"; anchor="<cite>target-URI</cite>"</pre>
-        <p>When used in conjunction with an HTTP success response code (<code>2xx</code>), this HTTP header field indicates that <code><cite>provenance-URI</cite></code> is the URI of some provenance description about the originally requested resource, and that the requested resource is identified within the provenance description as <code><cite>target-URI</cite></code>. (See also <a href="#interpreting-provenance-descriptions" class="sectionRef"></a>.)</p>
+        <p>When used in conjunction with an HTTP success response code (<code>2xx</code>), this HTTP header field indicates that <code><cite>provenance-URI</cite></code> is the URI of a provenance record about the originally requested resource, and that the requested resource is identified within the provenance record as <code><cite>target-URI</cite></code>. (See also <a href="#interpreting-provenance-descriptions" class="sectionRef"></a>.)</p>
         <p>
           If no <code>anchor</code> parameter is provided then the <code><cite>target-URI</cite></code> is assumed to be the URI of the requested resource used in the corresponding HTTP request.
         </p>
@@ -458,21 +458,21 @@
           This specification does not define the meaning of these links returned with other HTTP response codes: future revisions may define interpretations for these.
         </p>
         <p>
-          An HTTP response MAY include multiple <code>hasProvenance</code> link header fields, indicating a number of different provenance resources that are known to the responding server, each presenting a provenance description about the accessed resource.
+          An HTTP response MAY include multiple <code>hasProvenance</code> link header fields, indicating a number of different provenance resources that are known to the responding server, each referencing a provenance record about the accessed resource.
         </p>
         <p>
-          The presence of a <code>hasProvenance</code> link in an HTTP response does not preclude the possibility that other publishers may offer provenance descriptions about the same resource.  In such cases, discovery of the additional provenance descriptions must use other means (e.g. see <a href="#provenance-query-services" class="sectionRef"></a>).
+          The presence of a <code>hasProvenance</code> link in an HTTP response does not preclude the possibility that other publishers may offer provenance records about the same resource.  In such cases, discovery of the additional provenance records must use other means (e.g. see <a href="#provenance-query-services" class="sectionRef"></a>).
         </p>
 
         <section>
           <h2>Specifying Provenance Query Services</h2>
           <p>
-            The resource provider may indicate that provenance descriptions about the resource are provided by a <a class="internalDFN">provenance query service</a>. This is done through the use of a <code>hasQueryService</code> link relation type following the same pattern as above:
+            The resource provider may indicate that provenance records about the resource are provided by a <a class="internalDFN">provenance query service</a>. This is done through the use of a <code>hasQueryService</code> link relation type following the same pattern as above:
           </p>
           <pre class="pattern">
 Link: &lt;<cite>provenance-service-URI</cite>&gt;; rel="http://www.w3.org/ns/prov#hasQueryService"; anchor="<cite>target-URI</cite>"</pre>
           <p>
-            The <code>hasQueryService</code> link identifies the <a class="internalDFN">service-URI</a>.  Dereferencing this URI yields a service description that provides further information to enable a client to submit a query to retrieve a <a class="internalDFN">provenance description</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-query-services" class="sectionRef"></a> for more details.
+            The <code>hasQueryService</code> link identifies the <a class="internalDFN">service-URI</a>.  Dereferencing this URI yields a service description that provides further information to enable a client to submit a query to retrieve a <a class="internalDFN">provenance record</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-query-services" class="sectionRef"></a> for more details.
           </p>
           <p>
           There may be multiple <code>hasQueryService</code> link header fields, and these may appear in an HTTP response together with <code>hasProvenance</code> link header fields (though, in simple cases, we anticipate that <code>hasProvenance</code> and <code>hasQueryService</code> link relations will not be used together).
@@ -485,7 +485,7 @@
             When performing content negotiation for a resource, it is common for HTTP 302 or 303 redirect response codes to be used to direct a client to an appropriately-formatted resource.  When accessing a resource for which provenance is available, link headers SHOULD be included with the response to the final redirected request, and not on the intermediate 303 responses.  (When accessing a resource from a browser using Javascript, the intermediate 303 responses are usually handled transparently by the browser and are not visible to the HTTP client code.) 
           </p>
           <p>
-            Following content negotiation, any provenance link returned refers to the resource whose URI is used in the corresponding HTTP request, or the given anchor parameter if that is different. (The provenance description itself may also refer to other resources; see the discussion at the start of <a href="#locating-provenance-descriptions" class="sectionRef"></a>.)
+            Following content negotiation, any provenance link returned refers to the resource whose URI is used in the corresponding HTTP request, or the given anchor parameter if that is different.
           </p>
           <p>
             An example transaction using content negotiation and redirection might look like this (where <code>C:</code> and <code>S:</code> prefixes indicate client and server emitted data respectively):
@@ -523,8 +523,8 @@
       <section>
         <h2>Resource represented as HTML</h2>
         <div>
-          For a document presented as HTML or XHTML, without regard for how it has been obtained, a provenance description may be associated with a resource by adding a <code>&lt;link&gt;</code> element to the HTML <code>&lt;head&gt;</code> section.
-          Two link relation types for referencing provenance descriptions may be used as shown:
+          For a document presented as HTML or XHTML, without regard for how it has been obtained, a provenance record may be associated with a resource by adding a <code>&lt;link&gt;</code> element to the HTML <code>&lt;head&gt;</code> section.
+          Two link relation types for referencing provenance may be used:
           <pre class="pattern">
   &lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;
      &lt;head&gt;
@@ -541,10 +541,10 @@
           The <code><cite>provenance-URI</cite></code> given by the <code>hasProvenance</code> link element identifies the provenance-URI for the document.
         </p>
         <p>
-          The <code><cite>target-URI</cite></code> given by the <code>hasAnchor</code> link element specifies an identifier for the document that may be used within the provenance description when referring to the document.
+          The <code><cite>target-URI</cite></code> given by the <code>hasAnchor</code> link element specifies an identifier for the document that may be used within the provenance record when referring to the document.
         </p>
         <p>
-          An HTML document header MAY include multiple <code>hasProvenance</code> link elements, indicating a number of different provenance descriptions that are known to the creator of the document, each of which may provide provenance about the document. 
+          An HTML document header MAY include multiple <code>hasProvenance</code> link elements, indicating a number of different provenance records that are known to the creator of the document, each of which may provide provenance about the document. 
         </p>
         <p>
           If no <code>hasAnchor</code> link element is provided then the <code><cite>target-URI</cite></code> is assumed to be the URI of the document. It is RECOMMENDED that this convention be used only when the document is static and has a stable URI that is reasonably expected to be available to anyone accessing the document (e.g. when delivered from a web server, or as part of a MIME structure containing content identifiers [[RFC2392]]).
@@ -567,7 +567,7 @@
      &lt;/body&gt;
   &lt;/html&gt;</pre>
           <p>
-            The <code>hasQueryService</code> link element identifies the <a class="internalDFN">service-URI</a>.  Dereferencing this URI yields a service description that provides further information to enable a client to query for <a class="internalDFN">provenance description</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-query-services" class="sectionRef"></a> for more details.
+            The <code>hasQueryService</code> link element identifies the <a class="internalDFN">service-URI</a>.  Dereferencing this URI yields a service description that provides further information to enable a client to query for provenance about a resource; see <a href="#provenance-query-services" class="sectionRef"></a> for more details.
           </p>
           <p>
             There MAY be multiple <code>hasQueryService</code> link elements, and these MAY appear in the same document as <code>provenance</code> link elements (though, in simple cases, we anticipate that <code>hasProvenance</code> and <code>hasQueryService</code> link relations would not be used together).
@@ -582,14 +582,14 @@
           (These terms may be used to indicate provenance of arbitrary other resources too, but discussion of such usage is beyond the scope of this section.)
         </p>
         <p>
-          The RDF property <code>prov:hasProvenance</code> is a relation between two resources, where the object of the property is a resource that presents a provenance description of the subject resource.  Multiple <code>prov:hasProvenance</code> assertions may be made about a subject resource.  This property corresponds to a <code>hasProvenance</code> link relation</a> used with an HTTP <code>Link</code> header field, or HTML <code>&lt;link&gt;</code> element (see above).
+          The RDF property <code>prov:hasProvenance</code> is a relation between two resources, where the object of the property is a provenance record about the subject resource.  Multiple <code>prov:hasProvenance</code> assertions may be made about a subject resource.  This property corresponds to a <code>hasProvenance</code> link relation</a> used with an HTTP <code>Link</code> header field, or HTML <code>&lt;link&gt;</code> element (see above).
         </p>
         <p>
           Property <code>prov:hasAnchor</code> specifies a <a class="internalDFN">target-URI</a> used in the indicated provenance to refer to the containing RDF document.
-          This corresponds to use of the <code>anchor</code> parameter in an HTTP provenance <code>Link</code> header field, or a <code>hasAnchor</code> link relation</a> in an HTML <code>&lt;link&gt;</code> element, which similarly indicate a URI used by the provenance description to refer to the described document.
+          This corresponds to use of the <code>anchor</code> parameter in an HTTP provenance <code>Link</code> header field, or a <code>hasAnchor</code> link relation</a> in an HTML <code>&lt;link&gt;</code> element, which similarly indicate a URI used in the provenance record to refer to the described document.
         </p>
         <p>
-          Property <code>prov:hasQueryService</code> specifies a <a class="internalDFN">service-URI</a> associated with the RDF document for accessing provenance descriptions.  This property corresponds to a <code>hasQueryService</code> link relation used with an HTTP <code>Link</code> header field, or HTML <code>&lt;link&gt;</code> element.
+          Property <code>prov:hasQueryService</code> specifies a <a class="internalDFN">service-URI</a> for provenance queries.  This property corresponds to a <code>hasQueryService</code> link relation used with an HTTP <code>Link</code> header field, or HTML <code>&lt;link&gt;</code> element.
         </p>
         <pre class="example code">
     @prefix prov: &lt;http://www.w3.org/ns/prov#&gt;.
@@ -611,12 +611,12 @@
     <section>
       <h2>Provenance query services</h2>
       <p>
-        This section describes a simple HTTP query protocol for accessing provenance descriptions, and also a mechanism for locating a SPARQL service endpoint. The HTTP protocol specifies HTTP operations for retrieving provenance descriptions from a provenance query service, following the approach of the SPARQL Graph Store HTTP Protocol [[SPARQL-HTTP]].
+        This section describes a simple HTTP query protocol for accessing provenance records, and also a mechanism for locating a SPARQL service endpoint. The HTTP protocol specifies HTTP operations for retrieving provenance records from a provenance query service, following the approach of the SPARQL Graph Store HTTP Protocol [[SPARQL-HTTP]].
       </p>
       <p>The introduction of query services is motivated by the following possible considerations: </p>
       <ul>
-      <li>the naming authority associated with the <a class="internalDFN">target-URI</a> is not the same as the service offering <a class="internalDFN">provenance description</a>s</li>
-      <li>multiple services have provenance descriptions about the same resource</li>
+      <li>the naming authority associated with the <a class="internalDFN">target-URI</a> is not the same as the service offering <a class="internalDFN">provenance record</a>s</li>
+      <li>multiple services have provenance records about the same resource</li>
       <li>the service associated with the target-URI is not accessible for adding additional information when handling retrieval requests</li>
       <li>there is no known dereferencable <a class="internalDFN">provenance-URI</a> returning a provenance for a particular resource</li>
       <li>query services may provide additional control over what provenance is returned.</li>
@@ -661,10 +661,10 @@
             where <cite><code>service-URI</code></cite> is the URI of the provenance query service, and <code><cite>query_option_node</cite></code> is any distinct RDF subject node (i.e. a blank node or a URI).
           </p>
           <p>
-            The URI template indicated by <code>prov:provenanceUriTemplate</code> may expand to an absolute or relative URI reference.  A URI for the desired provenance description is obtained by expanding the URI template with the variable <cite><code>uri</code></cite> set to the target-URI for which provenance is required.  In this example, if the target-URI contains '#' or '&amp;' these must be %-escaped as <code>%23</code> or <code>%26</code> respectively before template expansion [[RFC3986]].  If the result is a relative reference, it is interpreted per [[RFC3986]] (section 5.2) using the URI of the service description as its base URI (which is generally the same as the query service-URI, unless HTTP redirection has been invoked).
+            The URI template indicated by <code>prov:provenanceUriTemplate</code> may expand to an absolute or relative URI reference.  A URI for the desired provenance record is obtained by expanding the URI template with the variable <cite><code>uri</code></cite> set to the target-URI for which provenance is required.  In this example, if the target-URI contains '#' or '&amp;' these must be %-escaped as <code>%23</code> or <code>%26</code> respectively before template expansion [[RFC3986]].  If the result is a relative reference, it is interpreted per [[RFC3986]] (section 5.2) using the URI of the service description as its base URI (which is generally the same as the query service-URI, unless HTTP redirection has been invoked).
           </p>
           <p>
-            A provenance query service MAY recognize additional parameters encoded as part of a URI for the provenance description.  If it does, it SHOULD include these in the provenance URI template in the service description, so that clients may discover how a URI is formed using this additional information.
+            A provenance query service MAY recognize additional parameters encoded as part of a URI for the provenance record.  If it does, it SHOULD include these in the provenance URI template in the service description, so that clients may discover how a URI is formed using this additional information.
             For example, a query service might offer to include just the immediate provenance of an entity, or to also supply provenance of entities from which the target resource is derived.  Suppose a service accepts an additional parameter <code>steps</code> that defines the number of previous steps to include in a provenance trace, it might publish its service description thus:
           </p>
           <pre class="pattern">
@@ -745,13 +745,13 @@
   GET /provenance/service?<b>target</b>=http://www.example.com/entity HTTP/1.1
   Host: example.com</pre>
         </p>
-        <p>The embedded target-URI (<code>http://www.example.com/entity</code>) identifies the resource for which provenance is to be returned. Any server that implements this protocol and receives a request URI in this form SHOULD return a provenance description for the resource-URI embedded in the query component, where that URI is the result of percent-decoding the value associated with the provenance-resource key. The embedded URI MUST be an absolute URI and the server MUST respond with a 400 Bad Request if it is not.  If the supplied resource-URI includes a fragment identifier, the '#' MUST be %-encoded as <code>%23</code> when constructing the provenance-URI value; similarly, any '&amp;' character in the resource-URI must be %-encoded as <code>%26</code> [[RFC3986]].
+        <p>The embedded target-URI (<code>http://www.example.com/entity</code>) identifies the resource for which provenance is to be returned. Any server that implements this protocol and receives a request URI in this form SHOULD return a provenance record for the resource-URI embedded in the query component, where that URI is the result of percent-decoding the value associated with the provenance-resource key. The embedded URI MUST be an absolute URI and the server MUST respond with a 400 Bad Request if it is not.  If the supplied resource-URI includes a fragment identifier, the '#' MUST be %-encoded as <code>%23</code> when constructing the provenance-URI value; similarly, any '&amp;' character in the resource-URI must be %-encoded as <code>%26</code> [[RFC3986]].
         </p>
         <p>
           If the provenance described by the request does not exist in the server, a <code>404 Not Found</code> response code SHOULD be returned.
         </p>
         <p>
-          The format of the returned provenance description is not defined here, but may be established through content type negotiation using <code>Accept:</code> header fields in the HTTP request.  A provenance query service SHOULD be capable of returning RDF using the vocabulary defined by [[PROV-O]], in at least one of the standard RDF serializations (e.g. RDF/XML), or any other standard serialization of the Provenance Model specification [[PROV-DM]].  Services MUST identify the <code>Content-Type</code> of the information returned.
+          The format of the returned provenance record is not defined here, but may be established through content type negotiation using <code>Accept:</code> header fields in the HTTP request.  A provenance query service SHOULD be capable of returning RDF using the vocabulary defined by [[PROV-O]], in at least one of the standard RDF serializations (e.g. RDF/XML), or any other standard serialization of the Provenance Model specification [[PROV-DM]].  Services MUST identify the <code>Content-Type</code> of the information returned.
         </p>
         <p>
           Additional URI query parameters may be used as indicated by the service description in <a href="#provenance-query-service-description" class="sectionRef"></a>.
@@ -806,7 +806,7 @@
         The ability to answer forward-looking questions requires some cooperation among the parties who use a resource; for example, a consumer could report use directly to the publisher, or a search engine could discover and report such downstream resource usage.  To facilitate such cooperation, a publisher may implement a "ping-back" capability.
       </p>
       <p>
-        A resource may have an associated "ping-back" URI which can be presented with PROV assertions about the resource.  The ping-back URI is associated with a resource using mechanisms similar to those used for presenting a <a class="internalDFN">provenance-URI</a>, but using a <code>provPingback</code> link relation instead of <code>hasProvenance</code>.  A consumer of the resource, or some other system, may  perform an HTTP POST operation to the pingback URI where the POST request body contains provenance in one of the recognized provenance description formats.  For interoperability, a ping-back receiving service SHOULD be able to accept at least PROV-O provenance presented as RDF/XML or Turtle.
+        A resource may have an associated "ping-back" URI which can be presented with PROV assertions about the resource.  The ping-back URI is associated with a resource using mechanisms similar to those used for presenting a <a class="internalDFN">provenance-URI</a>, but using a <code>provPingback</code> link relation instead of <code>hasProvenance</code>.  A consumer of the resource, or some other system, may  perform an HTTP POST operation to the pingback URI where the POST request body contains provenance in one of the recognized provenance formats.  For interoperability, a ping-back receiving service SHOULD be able to accept at least PROV-O provenance presented as RDF/XML or Turtle.
       </p>
       <p>
         For example, consider a resource that is published by acme.example.com, and is subsequently used by wile-e.example.org in the construction of some new entity;  we might see an exchange along the following lines.  We start with wile-e.example.org retrieving a copy of acme.example.org's resource:
@@ -856,7 +856,7 @@
     <section>
       <h2>Security considerations</h2>
       <p>
-        Provenance is central to establishing trust in data.  If a provenance description is corrupted, it may lead agents (human or software) to draw inappropriate and possibly harmful conclusions.  Therefore, care is needed to ensure that the integrity of provenance is maintained.  Just as provenance can help determine a level of trust in some information, a provenance description related to the provenance itself ("provenance of provenance") can help determine trust in the provenance.
+        Provenance is central to establishing trust in data.  If provenance is corrupted, it may lead agents (human or software) to draw inappropriate and possibly harmful conclusions.  Therefore, care is needed to ensure that the integrity of provenance is maintained.  Just as provenance can help determine a level of trust in some information, a provenance record related to the provenance itself ("provenance of provenance") can help determine trust in the provenance.
       </p>
       <p>
         Secure HTTP (https) SHOULD be used across unsecured networks when accessing provenance that may be used as a basis for trust decisions, or to obtain a provenance URI for same.
@@ -865,12 +865,12 @@
         When retrieving a provenance URI from a document, steps SHOULD be taken to ensure the document itself is an accurate copy of the original whose author is being trusted (e.g. signature checking, or use of a trusted secure web service).
       </p>
       <p>
-        Provenance descriptions may provide a route for leakage of privacy-related information, combining as it does a diversity of information types with possible personally-identifying information; e.g. editing timestamps may provide clues to the working patterns of document editors, or derivation traces might indicate access to sensitive materials.  In particular, note that the fact that a resource is openly accessible does not mean that its provenance should also be.  When publishing provenance, its sensitivity SHOULD be considered and appropriate access controls applied where necessary.  When a provenance-aware publishing service accepts some resource for publication, the contributors SHOULD have some opportunity to review and correct or conceal any provenance that they don't wish to be exposed.  Provenance management systems SHOULD embody mechanisms for enforcement and auditing of privacy policies as they apply to provenance.
+        Provenance may present a route for leakage of privacy-related information, combining as it does a diversity of information types with possible personally-identifying information; e.g. editing timestamps may provide clues to the working patterns of document editors, or derivation traces might indicate access to sensitive materials.  In particular, note that the fact that a resource is openly accessible does not mean that its provenance should also be.  When publishing provenance, its sensitivity SHOULD be considered and appropriate access controls applied where necessary.  When a provenance-aware publishing service accepts some resource for publication, the contributors SHOULD have some opportunity to review and correct or conceal any provenance that they don't wish to be exposed.  Provenance management systems SHOULD embody mechanisms for enforcement and auditing of privacy policies as they apply to provenance.
       </p>
-      <p>Provenance descriptions may be used by audits to establish accountability for information use [[INFO-ACC]] and to verify use of proper processes in information processing activities.  Thus, provenance management systems can provide mechanisms to support auditing and enforcement of information handling policies. In such cases, provenance itself may be a valuable target for attack by malicious agents, and care must be taken to ensure it is stored securely and in a fashion that resists attempts to tamper with it.
+      <p>Provenance may be used by audits to establish accountability for information use [[INFO-ACC]] and to verify use of proper processes in information processing activities.  Thus, provenance management systems can provide mechanisms to support auditing and enforcement of information handling policies. In such cases, provenance itself may be a valuable target for attack by malicious agents, and care must be taken to ensure it is stored securely and in a fashion that resists attempts to tamper with it.
       </p>
       <p>
-        The pingback service described in <a href="#forward-provenance" class="sectionRef"></a> might be abused for "link spamming" (similar to the way that weblog ping-backs have been used to direct viewers to spam sites).  As with many such services, an application needs to find a balance between maintaining ease of submission for useful information and blocking unwanted information.  We have no easy solutions for this problem, and the caveats noted above about establishing integrity of provenance descriptions apply similarly to information provided by ping-back calls.
+        The pingback service described in <a href="#forward-provenance" class="sectionRef"></a> might be abused for "link spamming" (similar to the way that weblog ping-backs have been used to direct viewers to spam sites).  As with many such services, an application needs to find a balance between maintaining ease of submission for useful information and blocking unwanted information.  We have no easy solutions for this problem, and the caveats noted above about establishing integrity of provenance records apply similarly to information provided by ping-back calls.
       </p>
     </section>
  
@@ -889,7 +889,7 @@
 <!-- ===================================================================================== -->
     
     <section class='appendix'>
-      <h2 id="prov-namespace">Names added to prov: namespace</h2>
+      <h2 id="prov-namespace">Terms added to prov: namespace</h2>
 
       <p>
         This specification defines the following additional names in the provenance namespace
@@ -916,13 +916,13 @@
           </tr>
           <tr style="vertical-align: top;">
             <td><code>hasProvenance</code></td>
-            <td>Indicates a <a class="internalDFN">provenance-URI</a> for a resource;  the resource identified by this property presents a provenance description about its subject or anchor resource.
+            <td>Indicates a <a class="internalDFN">provenance-URI</a> for a resource;  the resource identified by this property presents a provenance record about its subject or anchor resource.
             </td>
             <td><a href="#resource-accessed-by-http" class="sectionRef"></a>, <a href="#resource-represented-as-html" class="sectionRef"></a></td>
           </tr>
           <tr style="vertical-align: top;">
             <td><code>hasQueryService</code></td>
-            <td>Indicates a <a class="internalDFN">provenance query service</a> that can provide provenance descriptions related to its subject or anchor resource.</td>
+            <td>Indicates a <a class="internalDFN">provenance query service</a> that can access provenance  related to its subject or anchor resource.</td>
             <td><a href="#specifying-provenance-query-services" class="sectionRef"></a></td>
           </tr>
           <tr style="vertical-align: top;">