--- a/paq/prov-aq.html Tue Nov 20 10:46:38 2012 -0500
+++ b/paq/prov-aq.html Tue Nov 20 16:00:47 2012 +0000
@@ -257,20 +257,22 @@
<p>In defining the specification below, we make use of the following concepts.</p>
<dl>
- <a href="#dfn-resource"><dt><dfn>Resource</dfn></dt></a>
+ <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>
- <a href="#dfn-constrained-resource"><dt><dfn>Constrained resource</dfn></dt></a>
+ <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 information</a>. 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>
- <a href="#dfn-target-uri"><dt><dfn>Target-URI</dfn></dt></a>
+ <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 information</a> associated with it (see <a href="#provenance-entities-resources" class="sectionRef"></a> for discussion)</dd>
- <a href="#dfn-provenance-information"><dt><dfn>Provenance information</dfn></dt></a>
+ </dt><a href="#dfn-provenance-information"><dfn>Provenance information</dfn></a></dt>
<dd>refers to provenance represented in some fashion.</dd>
- <a href="#dfn-provenance-uri"><dt><dfn>Provenance-URI</dfn></dt></a>
+ <dt><a href="#dfn-provenance-uri"><dfn>Provenance-URI</dfn></a></dt>
<dd>a URI denoting some <a class="internalDFN">provenance information</a>.</dd>
- <a href="#dfn-provenance-service"><dt><dfn>Provenance service</dfn></dt></a>
+ <dt><a href="#dfn-provenance-service"><dfn>Provenance service</dfn></a></dt>
<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>
+ <dt><a href="#dfn-service-uri"><dfn>Service-URI</dfn></a></dt>
<dd>the URI of a <a class="internalDFN">provenance service</a>.</dd>
+ <dt><a href="#dfn-pingback-uri"><dfn>Pingback-URI</dfn></a></dt>
+ <dd>the URI of a provenance pingback service that receives forward provenance information (see <a href="#forward-provenance" class="sectionRef"></a>).</dd>
<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>
@@ -310,7 +312,6 @@
</p>
</section>
-
<section>
<h2>URI types and dereferencing</h2>
<p>
@@ -337,6 +338,11 @@
<td>A provenance service (i.e. a resource of type <code>prov:ProvenanceService</code>). This is the initial URI used when accessing a provenance service; following REST API style [[REST-APIs]], actual URIs for accessing provenance information are obtained via the provenance service description.</td>
<td>A provenance service description per <a href="#provenance-service-description" class="sectionRef"></a>. Alternative formats may be offered via HTTP content negotiation.</td>
</tr>
+ <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>
+ </tr>
</table>
<p>
</p>
@@ -594,14 +600,13 @@
This section describes a REST-based protocol [[REST]] for provenance services with facilities for the retrieval of provenance information. The protocol specifies HTTP operations for retrieval of provenance information from a provenance service. It follows the approach of the SPARQL Graph Store HTTP Protocol [[SPARQL-HTTP]].
</p>
<p>The introduction of this protocol is motivated by the following possible considerations: </p>
- <ul>
- <li>the naming authority associated with the <a class="internalDFN">target-URI</a> is not the same as the service offering provenance information</li>
- <li>multiple services have <a class="internalDFN">provenance information</a> about the same resource</li>
- <li>the service associated with the target-URI is not accessible for adding additional information when handling retrieval requests</li>
- <li>there is no dereferencable <a class="internalDFN">provenance-URI</a> containing provenance information for a particular resource</li>
- <li>provenance services may provide additional extensibility points for control over returned provenance information.</li>
- </ul>
-
+ <ul>
+ <li>the naming authority associated with the <a class="internalDFN">target-URI</a> is not the same as the service offering provenance information</li>
+ <li>multiple services have <a class="internalDFN">provenance information</a> about the same resource</li>
+ <li>the service associated with the target-URI is not accessible for adding additional information when handling retrieval requests</li>
+ <li>there is no dereferencable <a class="internalDFN">provenance-URI</a> containing provenance information for a particular resource</li>
+ <li>provenance services may provide additional extensibility points for control over returned provenance information.</li>
+ </ul>
<section>
<h2>Provenance service invocation</h2>
@@ -683,6 +688,69 @@
<!-- ==== Section 5 ===================================================================================== -->
<section>
+ <h2>Forward provenance</h2>
+ <p>
+ The mechanisms discussed in previous sections are primarily concerned with accessing historical provenance information, dealing with question such as:
+ </p>
+ <ul>
+ <li>what was this resource based upon?</li>
+ <li>how was it constructed?</li>
+ <li>who made it?</li>
+ <li>when was it made?</li>
+ </ul>
+ <p>
+ These questions can be turned around to consider the forward-looking use of a resource, with questions like:
+ </p>
+ <ul>
+ <li>what new resources are based on this resource?</li>
+ <li>what has this resource been used for?</li>
+ <li>who has used it?</li>
+ <li><i>etc.</i></li>
+ </ul>
+ <p>
+ Answering such questions is assumed to be based on cooperation of other parties who actually use a rsource (or maybe of search engines that can discover such usage). To facilitate such cooperation, a resource may have an associated "ping-back" URI which can be presented with forward provenance information about how the resource has been used. The ping-back URI is associated with a resource using mechanisms similar to those used for presenting a <a class="internalDFN">provenance-URI</a>, but using a <code>provPingback</code> link relation instead of <code>hasProvenance</code>. When the resource is used, and new provenance information created that refers to it, the user may perform an HTTP POST operation to the pingback URI where the POST request body contains the new provenance information in one of the recognized provenance formats. The for interoperability, ping-back receiving service SHOULD be able to accept al least PROV-O provenance presented as RDF/XML or Turtle.
+ </p>
+ <p>
+ For example, consider a resource that is published by acme.example.com, and is subsequently used by wile-e.example.org in the construction of some new artifact; we might see an exchange along the following lines. We start with wile-e.example.org retrieving a copy of acme.example.org's resource:
+ </p>
+ <pre class="pattern">
+ C: GET /super-widget HTTP/1.1
+ C: Host: acme.example.org
+
+ S: 200 OK
+ S: Link: <http://acme.example.org/provenance/super-widget>; rel=http://www.w3.org/ns/prov#hasProvenance
+ S: Link: <http://acme.example.org/pingback/super-widget>; rel=http://www.w3.org/ns/prov#provPingback
+ :
+ (super-widget resource data)</pre>
+ <p>
+ The first of the links in the response is the proveance-URI that has been described previously. The second is a separate resource that exists to receive provenance pingbacks. Later, when a new resource has been created or action performed based upon the acme.example.org/super-widget, new provenance information may be submitted to the pingback thus:
+ </p>
+ <pre class="pattern">
+ C: POST /pingback/super-widget HTTP/1.1
+ C: Host: acme.example.org
+ C: Content-type: text/turtle
+ :
+ C:
+ C: <http://wile-e.example.org/contraption> prov:tracedTo <http://acme.example.org/super-widget> .
+
+ S: 200 Thanks!
+ S: Link: <http://acme.example.org/provenance/super-widget>; rel=http://www.w3.org/ns/prov#hasProvenance;
+ anchor=http://acme.example.org/super-widget
+ S: Link: <http://acme.example.org/pingback/super-widget>; rel=http://www.w3.org/ns/prov#provPingback;
+ anchor=http://acme.example.org/super-widget</pre>
+ <p>
+ There is no required server response to a pingback POST request.
+ In this example the pingback service responds with links to provenance and pingback for the original resource (note that the <code>Link:</code> headers returned contain explicit <code>anchor</code> parameters with the URI of the original resource; without these, the links would relate the indicated URIs to the POST request URI.
+ </p>
+ <p>
+ The only defined operation for a pingback resource is a POST, which is required to provide some provenance information that possible to the original resource with which the pingback is associated. A pingback service MAY respond to other requests, but no requirements are imposed on how it responds to such operations. In particular, it is not specified here how a pingback service should respond to an HTTP GET request.
+ </p>
+
+ </section>
+
+<!-- ==== Section 6 ===================================================================================== -->
+
+ <section>
<h2>Security considerations</h2>
<p>
Provenance is central to establishing trust in data. If provenance information is corrupted, it may lead agents (human or software) to draw inappropriate and possibly harmful conclusions. Therefore, care is needed to ensure that the integrity of provenance information is maintained. Just as provenance information can help determine a level of trust in some information, provenance information related to the provenance itself ("provenance of provenance") can help determine trust in the provenance itself.
@@ -751,6 +819,11 @@
<td>Relates a provenance service to a URI template string for constructing provenance-URIs</td>
<td><a href="#provenance-service-description" class="sectionRef"></a></td>
</tr>
+ <tr style="vertical-align: top;">
+ <td><code>provPingback</code></td>
+ <td>Relates a resource to a provenance pingback service</td>
+ <td><a href="#forward-provenance" class="sectionRef"></a></td>
+ </tr>
</table>
</section>