--- a/paq/provenance-access.html	Thu Nov 17 12:09:55 2011 +0000
+++ b/paq/provenance-access.html	Thu Nov 17 12:10:43 2011 +0000
@@ -155,7 +155,7 @@
           Fundamentally, <a class="internalDFN">provenance information</a> is <em>about</em> <a class="internalDFN">resources</a>.  In general, resources may vary over time and context.  E.g., a resource describing the weather in London changes from day-to-day, or one listing restaurants near you will vary depending on your location.  Provenance information, to be useful, must be persistent and not itself dependent on context.  Yet we may still want to make provenance assertions about dynamic or context-dependent web resources (e.g. the 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 the notion of entities.  An <a class="internalDFN">entity</a> is simply a web resource that is a contextualized view or instance of an original web 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 through its lifetime.  Separate URIs for each individual revision would then be <a class="internalDFN">entity-URIs</a>, denoting the specification at a 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.
+          Provenance descriptions of dynamic and context-dependent resources are possible through the notion of entities.  An <a class="internalDFN">entity</a> is simply a web resource that is a contextualized view or instance of an original web 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 through its lifetime.  Separate URIs for each individual revision would then be <a class="internalDFN">entity-URIs</a>, denoting the specification at a 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.  Entity-URIs may use any URI scheme, and are not required to be dereferencable.
         </p>
         <p>
            Requests for provenance about a resource may return provenance information that uses one or more entity-URIs to refer to it.  Some given provenance information may use multiple entity-URIs if there are assertions referring to the same underlying resource in different contexts.  For example, provenance information describing a W3C document might include information about all revisions of the document using statements that use the different entity-URIs of the various revisions.
@@ -181,9 +181,17 @@
       <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>
-        <p>When publishing provenance as a normal web resource, the <a class="internalDFN">provenance-URI</a> should be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-information" class="sectionRef"></a>.
+        <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.
         </p>
-        <p>If there is no URI for some particular provenance information, then alternative mechanisms may be needed. Possible mechanisms are suggested in <a href="#provenance-services" class="sectionRef"></a> and <a href="#querying-provenance-information" class="sectionRef"></a>.
+        <p>
+          How much or how little provenance information is returned in response to to a retrieval request is a matter for the provenance provider application.  At a minimum, for as long as provenance information about an entity remains available, sufficient should be returned to enable a client application to walk the provenance graph per <a class="sectionRef" href="#incremental-provenance-retrieval"></a>.
+        </p>
+        <p>
+        When publishing provenance as a normal web resource, the <a class="internalDFN">provenance-URI</a> should be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-information" class="sectionRef"></a>.
+        </p>
+        <p>
+          If there is no URI for some particular provenance information, then alternative mechanisms may be needed. Possible mechanisms are suggested in <a href="#provenance-services" class="sectionRef"></a> and <a href="#querying-provenance-information" class="sectionRef"></a>.
         </p>
     </section>