Issue 165 - in section 2, add note that non-contradition applies to /correct/ provenance
--- a/paq/prov-aq.html Thu Jan 05 12:29:39 2012 +0000
+++ b/paq/prov-aq.html Thu Jan 05 12:41:19 2012 +0000
@@ -218,20 +218,24 @@
<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 web mechanisms.
- </p>
- <p>
- Provenance assertions are about occurring or completed activities and the entities they involve. 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>
- 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 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>
+ <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 occurring or completed activities and the entities they involve. 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>
+ 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 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>
+ <p class="note">
+ The references above to provenance assertions being non-contradictory and non-changing are made with respect to <em>correct</em> provenance information. As with any other form of information published on the web, provenance may be subject to errors and omissions, and applications should attempt to be robust in the face of such. The requirement for provenance information to be non-contradictory should not be taken as an injunction against the correction of any errors that may occur.
+ </p>
+
</section>
<!-- == Sect 3 =================================================================================== -->