--- a/paq/prov-aq.html	Mon Nov 19 18:11:19 2012 +0000
+++ b/paq/prov-aq.html	Mon Nov 19 18:53:44 2012 +0000
@@ -263,7 +263,7 @@
             <dd>a service that provides <a class="internalDFN">provenance information</a> given a <a class="internalDFN">target-URI</a>.</dd>
             <a href="#dfn-service-uri"><dt><dfn>Service-URI</dfn></dt></a>
             <dd>the URI of a <a class="internalDFN">provenance service</a>.</dd>
-            <dt><a href="#dfn-access"><dfn>Accessing</dfn></a> provenance information</dt>
+            <dt><a href="#dfn-accessing"><dfn>Accessing</dfn></a> provenance information</dt>
             <dd>Given the identity of a resource, the process of discovering and retrieving some <a class="internalDFN">provenance information</a> about that resource.  This may involve <a class="internalDFN">locating</a> a provenance information resource, then performing an HTTP GET to retrieve it, or locating a service and querying the service for provenance information about an identified resource, or some other mechanism not covered in this document.</dd>
             <dt><a href="#dfn-locating"><dfn>Locating</dfn></a> provenance information</dt>
             <dd>Given the identity of a resource, discovery of a URI at which some <a class="internalDFN">provenance information</a> about that resource may be retrieved.</dd>
@@ -569,7 +569,7 @@
      
 
      <section>
-        <h2>HTTP GET</h2>
+        <h2>Provenance service invocation</h2>
         <div>This protocol combines the <a class="internalDFN">target-URI</a> with the <a class="internalDFN">service-URI</a> to formulate an HTTP GET request, according to the following convention:
           <pre class="pattern">
   GET /provenance/service?<b>target</b>=http://www.example.com/entity HTTP/1.1
@@ -577,9 +577,14 @@
         </div>
         <div>The embedded target-URI (<code>http://www.example.com/entity</code>) identifies the resource for which provenance information is to be returned. Any server that implements this protocol and receives a request URI in this form SHOULD return provenance information 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]].
         </div>
-        <p>If the provenance information identified in the request does not exist in the server, a 404 Not Found response code SHOULD be returned.
+        <p>
+          If the provenance information identified in the request does not exist in the server, a 404 Not Found response code SHOULD be returned.
         </p>
-        <p>The format of returned provenance information is not defined here, but may be established through content type negotiation using <code>Accept:</code> header fields in the HTTP request. A provenance service SHOULD be capable of returning RDF using the vocabulary defined by [[PROV-O]], in any standard RDF serialization (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>
+          The format of returned provenance information is not defined here, but may be established through content type negotiation using <code>Accept:</code> header fields in the HTTP request. A provenance service SHOULD be capable of returning RDF using the vocabulary defined by [[PROV-O]], in any standard RDF serialization (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-service-description" class="sectionRef"></a>.
         </p>
       </section>
 
@@ -601,14 +606,33 @@
       <!-- <section class="informative"> -->
       <section>
         <h2>Provenance service description</h2>
-        <p>Dereferencing a provenance service URI should yield a provenance service description. This is to be compatible with the constraints of [[REST-APIs]]. The provenance service description should be available as RDF (in any of its common serializations, and determined through HTTP content negotiation), and it should contain RDF statements of the form:
+        <p>
+          Dereferencing a provenance service URI should yield a provenance service description. This is to follow the constraints of [[REST-APIs]]. The provenance service description should be available as RDF (in any of its common serializations as determined by HTTP content negotiation), and it should contain RDF statements of the form:
         </p>
         <pre class="pattern">
   &lt;<cite>service-URI</cite>&gt; a prov:ProvenanceService ;
     prov:provenanceUriTemplate "<cite>service-URI</cite>?target={+uri}" .</pre>
-        <p>where <cite><code>service-URI</code></cite> is the URI of the provenance service.  Note that the object of the <code>prov:provenanceUriTemplate</code> statement is a literal text value, not a URI.
+        <p>
+          where <cite><code>service-URI</code></cite> is the URI of the provenance service.  Note that the object of the <code>prov:provenanceUriTemplate</code> statement is a literal text value, not a URI.
         </p>
-        <p>A client may retrieve this service description and extract the associated value for <code>prov:provenance-URI-template</code>.  This value is a string containing a URI template [[URI-template]] (level 2). A URI for the desired provenance information is obtained by expanding the URI template with the variable <code>uri</code> set to the resource-URI for which provenance is required.  If the target-URI contains '#' or '&amp;' these  must be %-escaped as <code>%23</code> or <code>%26</code> respectively before template expansion [[RFC3986]].
+        <p>
+          A client should retrieve this service description and extract the associated value for <code>prov:provenance-URI-template</code>.  This value is a string containing a URI template [[URI-template]] (level 2 or above). A URI for the desired provenance information is obtained by expanding the URI template with the variable <code>uri</code> set to the resource-URI for which provenance is required.  If the target-URI contains '#' or '&amp;' these  must be %-escaped as <code>%23</code> or <code>%26</code> respectively before template expansion [[RFC3986]].
+        </p>
+        <p>
+          A provenance service MAY recognize additional parameters encoded as part of a URI for provenance information.  If it does, it SHOULD include these in the provenance URI template in the service description, so that clients may know how a URI is formed using this additional information.
+          For example, a 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">
+  &lt;<cite>service-URI</cite>&gt; a prov:ProvenanceService ;
+    prov:provenanceUriTemplate "<cite>service-URI</cite>?target={+uri}{&amp;steps}" .</pre>
+        <p>
+          which might result in an HTTP request for provenance looking like this:
+        </p>
+        <pre class="pattern">
+GET /provenance/service?<b>target</b>=http://www.example.com/entity&amp;<b>steps</b>=2 HTTP/1.1
+Host: example.com</pre>
+        <p>
+          Note that in this case, a "level 3" URI template feature is used [[URI-template]].
         </p>
         <p>While use of RDF for service descriptions is a recommended option, this specification does not preclude the use of non-RDF formats that a service may choose to offer, and which can be selected using HTTP content negotiation.
         </p>
@@ -622,20 +646,19 @@
     <h2>Best practice</h2> 
 
       <p class="TODO">
-        @@TODO: rtemove this section; cover in FAQ
+        @@TODO: remove this section; cover in FAQ
       </p>
 
       <section id="querying-provenance-information">
         <h2>Using SPARQL for provenance queries</h2>
         <p>
           Simply identifying and retrieving provenance information as a resource on the Web may not always meet the requirements of a particular application or service, e.g.:</p>
-          <ul>
-            <li>the resource for which provenance information is required is not identified by a known URI</li>
-            <li>the provenance information for a resource is not directly identified by a known URI</li>
-            <li>a requirement to access provenance information for a number of distinct but related resources in a single atomic operation</li>
-            <li><i>etc.</i></li>
-          </ul>
-   
+        <ul>
+          <li>the resource for which provenance information is required is not identified by a known URI</li>
+          <li>the provenance information for a resource is not directly identified by a known URI</li>
+          <li>a requirement to access provenance information for a number of distinct but related resources in a single atomic operation</li>
+          <li><i>etc.</i></li>
+        </ul>
         <p>
           A provenance query service provides an alternative way to access provenance information and/or provenance-URIs.  An application will need a URI for the provenance query service, and some relevant information about the resource whose provenance is to be accessed.
         </p>