--- a/paq/prov-aq.html	Thu Feb 07 17:29:45 2013 +0000
+++ b/paq/prov-aq.html	Thu Feb 07 17:43:15 2013 +0000
@@ -323,11 +323,18 @@
 
       <section>
         <h2>Interpreting provenance records</h2>
+        <p class="TODO">
+          Rework terminology here and elsewhere to align with PROV-DM: talk about "entities" and "entity-URI"s.
+          Also, review second para below.  Move definition of provider/consumer to concepts section?
+        </p>
         <p>
           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>
+          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>
           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>
@@ -383,7 +390,7 @@
       </ol>
       <p>
         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.
-        How much or how little provenance is returned in a provenance record is a matter for the provider; a provenance trace may extend as linked data across multiple provenance records.
+        How much or how little provenance is returned in a provenance record is a matter for the provider, taking account that a provenance trace may extend as linked data across multiple provenance records.
       </p>
       <p>
         When there is no easy way to associate a <a class="internalDFN">provenance-URI</a> with a resource (e.g. for resources not directly web-accessible, or whose publication mechanism is controlled by someone else), a provenance description may be obtained using a provenance query service at an indicated <a class="internalDFN">service-uri</a>.
@@ -425,9 +432,6 @@
       <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 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>.
         Three mechanisms are described:
       </p>