--- a/paq/prov-aq.html Thu Feb 07 14:51:07 2013 +0000
+++ b/paq/prov-aq.html Thu Feb 07 15:42:32 2013 +0000
@@ -259,10 +259,10 @@
Simple mechanisms for retrieving and discovering provenance descriptions are described in <a href="#accessing-provenance-descriptions" class="sectionRef"></a> and <a href="#locating-provenance-descriptions" class="sectionRef"></a> .
</li>
<li>
- Provenance query service mechanisms that may be used for more demanding deployments are described in <a href="#provenance-query-services" class="sectionRef"></a>.
+ Provenance query mechanisms that may be used for more demanding deployments are described in <a href="#provenance-query-services" class="sectionRef"></a>.
</li>
<li>
- A simple "ping-back" mechanism allowing for collection of forward provenance is described in <a href="#forward-provenance" class="sectionRef"></a>
+ A simple "ping-back" mechanism allowing for discovery of "forward provenance" (i.e. provenance about future resources that are based upon or influenced by an entity) is described in <a href="#forward-provenance" class="sectionRef"></a>.
</li>
</ul>
<p>
@@ -277,7 +277,7 @@
<dt><a href="#dfn-resource"><dfn>Resource</dfn></a></dt>
<dd>a resource in the general sense of "whatever might be identified by a URI", as described by the Architecture of the World Wide Web [[WEBARCH]], <a href="http://www.w3.org/TR/webarch/#id-resources" class="externalRef">section 2.2</a>. A resource may be associated with multiple instances or views (<a class="internalDFN">constrained resource</a>s) with differing provenance.</dd>
<dt><a href="#dfn-constrained-resource"><dfn>Constrained resource</dfn></a></dt>
- <dd>an aspect, version or instance of a <a class="internalDFN">resource</a>, about which one may wish to present some <a class="internalDFN">provenance description</a>s. For example, a weather report for a given date may be an aspect of a resource that is maintained as the current weather report. A constrained resource is itself a <a class="internalDFN">resource</a>, and may have it's own URI different from that of the original. See also [[PROV-DM]], and [[WEBARCH]] <a href="http://www.w3.org/TR/webarch/#representation-reuse" class="externalRef">section 2.3.2</a>.</dd>
+ <dd>an aspect, version or instance of a <a class="internalDFN">resource</a>, about which one may wish to present some <a class="internalDFN">provenance description</a>s. For example, a weather report for a given date may be an aspect of a resource that is maintained as the current weather report. A constrained resource is itself a <a class="internalDFN">resource</a>, and may have its own URI different from that of the original. See also [[PROV-DM]], and [[WEBARCH]] <a href="http://www.w3.org/TR/webarch/#representation-reuse" class="externalRef">section 2.3.2</a>.</dd>
<dt><a href="#dfn-target-uri"><dfn>Target-URI</dfn></a></dt>
<dd>a URI denoting a <a class="internalDFN">resource</a> (including any <a class="internalDFN">constrained resource</a>), which identifies that resource for the purpose of finding and expressing <a class="internalDFN">provenance descriptions</a> associated with it (see <a href="#provenance-entities-resources" class="sectionRef"></a> for discussion).</dd>
</dt><a href="#dfn-provenance-description"><dfn>Provenance description</dfn></a></dt>
@@ -358,7 +358,7 @@
<tr style="vertical-align: top;">
<td><a class="internalDFN">Pingback-URI</a></td>
<td>A provenance pingback service. This is a service to which provenance pingback information can be submitted using an HTTP POST operation per <a href="#forward-provenance" class="sectionRef"></a>. No other operations are specified.</td>
- <td>(None specified; a provenance pingback service may choose to return useful information.)</td>
+ <td>None specified (the owner of a provenance pingback URI may choose to return useful information, but is not required to do so.)</td>
</tr>
</table>
<p>
@@ -388,10 +388,13 @@
How much or how little provenance is returned in response to a retrieval request is a matter for the provenance provider application.
</p>
<p>
+ Retrieved provenance is not guaranteed to be authoritative. Trust in provenance descriptions must be determined separately from trust in the original resource that they may describe. Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any 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>
+ <p>
When publishing provenance descriptions, corresponding <a class="internalDFN">provenance-URI</a>s or <a class="internalDFN">service-URI</a>s should be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-descriptions" class="sectionRef"></a>.
</p>
<p>
- Provenance may be presented as a <a href="/TR/prov-dm/#component4" class="externalRef">bundle</a>, which <cite>is a named set of provenance descriptions, and is itself an entity, so allowing provenance of provenance to be expressed</cite> [[PROV-DM]]. There is no requirement that a bundle identifier can be dereferenced to access the corresponding provenance, but where practical it is RECOMMENDED that matters be arranged so this is possible. One possible realization of a bundle is that it is published as part of an RDF Dataset [[RDF-CONCEPTS11]] or similar composite structure containing multiple RDF graphs in a single document. To access such a bundle would require accessing the RDF Dataset and then extracting the identified component; this in turn would require knowing a URI or some other way to retrieve the dataset. This specification does not describe a specific mechanism for extracting components from a document containing multiple graphs.
+ Provenance may be presented as a <a href="/TR/prov-dm/#component4" class="externalRef">bundle</a>, which is "<cite>a named set of provenance descriptions, and is itself an entity, so allowing provenance of provenance to be expressed</cite>" [[PROV-DM]]. There is no requirement that a bundle identifier can be dereferenced to access the corresponding provenance, but where practical it is RECOMMENDED that matters be arranged so this is possible. One possible realization of a bundle is that it is published as part of an RDF Dataset [[RDF-CONCEPTS11]] or similar composite structure containing multiple RDF graphs in a single document. To access such a bundle would require accessing the RDF Dataset and then extracting the identified component; this in turn would require knowing a URI or some other way to retrieve the dataset. This specification does not describe a specific mechanism for extracting components from a document containing multiple graphs.
</p>
<p class="note">The W3C Linked Data Platform group (<a href="http://www.w3.org/2012/ldp/" class="externalRef">www.w3.org/2012/ldp/</a>) is chartered to produce a W3C Recommendation for HTTP-based (RESTful) application integration patterns using read/write Linked Data; we anticipate that they may address access to RDF Datasets in due course.
</p>
@@ -427,9 +430,9 @@
Three mechanisms are described:
</p>
<ul>
- <li>The requester knows the resource URI <em>and</em> the resource is accessible using HTTP</li>
- <li>The requester has a copy of a resource represented as HTML or XHTML</li>
- <li>The requester has a copy of a resource represented as RDF (including the range of possible RDF syntaxes, such as HTML with embedded RDFa)</li>
+ <li>The consumer knows the resource URI <em>and</em> the resource is accessible using HTTP</li>
+ <li>The consumer has a copy of a resource represented as HTML or XHTML</li>
+ <li>The consumer has a copy of a resource represented as RDF (including the range of possible RDF syntaxes, such as HTML with embedded RDFa)</li>
</ul>
<p>
These particular cases are selected as corresponding to primary current web protocol and data formats. Similar approaches may be possible for other protocols or resource formats.
@@ -460,9 +463,6 @@
<p>
The presence of a <code>hasProvenance</code> link in an HTTP response does not preclude the possibility that other publishers may offer provenance descriptions about the same resource. In such cases, discovery of the additional provenance descriptions must use other means (e.g. see <a href="#provenance-query-services" class="sectionRef"></a>).
</p>
- <p>
- Provenance indicated in this way is not guaranteed to be authoritative. Trust in the linked provenance descriptions 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 linked 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>
<h2>Specifying Provenance Query Services</h2>
@@ -622,7 +622,7 @@
<li>query services may provide additional control over what provenance is returned.</li>
</ul>
<p>
- The query mechanisms provided by a <a class="internalDFN">provenance query service</a> are described by an RDF-format service description, which is obtained by dereferencing a <a class="internalDFN">service-URI</a>. A service description may contain information about additional mechanisms that are not described here. In keeping with REST practice, alternative non-RDF service description formats not described here may be offered and accessed using HTTP content negotiation, but such usage is not described here.
+ The query mechanisms provided by a <a class="internalDFN">provenance query service</a> are described by an RDF-format service description, which is obtained by dereferencing a <a class="internalDFN">service-URI</a>. A service description may contain information about additional mechanisms that are not described here. In keeping with REST practice, alternative non-RDF service description formats not described here may be offered and accessed using HTTP content negotiation.
</p>
<p>
The general procedure for using a provenance query service is: