--- a/paq/prov-aq.html	Wed Jan 04 22:22:54 2012 -0500
+++ b/paq/prov-aq.html	Thu Jan 05 11:01:27 2012 +0000
@@ -218,7 +218,7 @@
     
     <section>
       <h2>Accessing provenance information</h2>
-        <p>Web applications may access <a class="internalDFN">provenance information</a> in the same way as any web resource, by dereferencing its URI. Typically, this will be by performing an HTTP GET operation. Thus, any provenance information may be associated with a <a class="internalDFN">provenance-URI</a>, and may be accessed by dereferencing that URI using normal web mechanisms.
+        <p>Web applications may access <a class="internalDFN">provenance information</a> in the same way as any web resource, by dereferencing its URI. Typically, this will be by performing an HTTP GET operation. Thus, any provenance information may be associated with a <a class="internalDFN">provenance-URI</a>, and may be accessed by dereferencing that URI using web mechanisms.
         </p>
         <p>
           Provenance assertions are about pre-determined activities involving entities; as such, they are not dynamic.  Thus, provenance information returned at a given provenance-URI may commonly be static.  But the availability of provenance information about a resource may vary (e.g. if there is insufficient storage to keep it indefinitely, or new information becomes available at a later date), so the provenance information returned at a given URI may change, provided that such change does not contradict any previously retrieved information.
@@ -239,7 +239,7 @@
     <section>
       <h2>Locating provenance information</h2>
       <p>
-        When <a class="internalDFN">provenance information</a> is a resource that can be accessed using normal web retrieval, one needs to know a <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.
+        When <a class="internalDFN">provenance information</a> is a resource that can be accessed using web retrieval, one needs to know a <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.
       </p>
       <p>Provenance information may be provided by several parties other than the provider of the original resource, each using different provenance-URIs, and each with different concerns.  (It is possible that these different parties may provide contradictory provenance information.)
       </p>
@@ -426,7 +426,7 @@
         Service implementations may provide either discovery, retrieval or both of these services, indicated by presence of the corresponding service URI templates in the service description.  Which of these services to provide is a choice for individual service implementations.
       </p>
       <p>
-        On the Web, the normal mechanism for retrieving information is to associate it with a URI, and dereference the URI using normal retrieval mechanisms.  This approach is enabled using the provenance discovery service mechanism:  given the URI of some resource for which provenance information is required, the service returns one or more URIs from which provenance information may be obtained.  This approach may be preferred when the provenance service cannot specify the form of URIs used for identifying provenance information, or when there may be more than one source of provenance information known to the provenance service.
+        On the Web, the normal mechanism for retrieving information is to associate it with a URI, and dereference the URI using HTTP.  This approach is enabled using the provenance discovery service mechanism:  given the URI of some resource for which provenance information is required, the service returns one or more URIs from which provenance information may be obtained.  This approach may be preferred when the provenance service cannot specify the form of URIs used for identifying provenance information, or when there may be more than one source of provenance information known to the provenance service.
       </p>
       <p>
         The provenance retrieval service returns provenance information directly.  This mechanism may be preferred when the provenance information is not already presented directly to the web, or is stored in a database with a complex query protocol, or when the provenance service can control the URI from which provenance information is served and avoid the intermediate step of URI discovery.
@@ -435,7 +435,7 @@
       <section>
         <h2>Using the provenance service API</h2>
         <p>
-          This section describes general procedures for using the provenance service API.  Later sections describe the resources presented by the API, and their representation using JSON.  <a href="#provenance-service-format-examples" class="sectionRef"></a>gives examples of alternative representations. Normal HTTP content negotiation mechanisms may be used to retrieve representations using formats convenient for the client application.
+          This section describes general procedures for using the provenance service API.  Later sections describe the resources presented by the API, and their representation using JSON.  <a href="#provenance-service-format-examples" class="sectionRef"></a>gives examples of alternative representations. HTTP content negotiation mechanisms may be used to retrieve representations using formats convenient for the client application.
         </p>
 
         <section>