--- a/paq/prov-aq.html Mon Dec 10 17:32:19 2012 +0100
+++ b/paq/prov-aq.html Mon Dec 10 19:03:29 2012 +0000
@@ -73,8 +73,8 @@
"SPARQL-HTTP":
"Chimezie Ogbuji. "+
- "<a href=\"http://www.w3.org/TR/sparql11-http-rdf-update/\"><cite>SPARQL 1.1 Service Description</cite></a>. "+
- "2011, Work in progress. "+
+ "<a href=\"http://www.w3.org/TR/sparql11-http-rdf-update/\"><cite>SPARQL 1.1 Graph Store HTTP Protocol</cite></a>. "+
+ "W3C Candidate Recommendation 8 November 2012, "+
"URL: <a href=\"http://www.w3.org/TR/sparql11-http-rdf-update/\">http://www.w3.org/TR/sparql11-http-rdf-update/</a>",
"INFO-ACC":
@@ -240,17 +240,20 @@
<section>
<h2>Introduction</h2>
<p>
- The Provenance Data Model [[PROV-DM]] and Provenance Ontology [[PROV-O]] specifications define how to represent provenance in the World Wide Web.
+ The Provenance Data Model [[PROV-DM]], Provenance Ontology [[PROV-O]] and related specifications define how to represent provenance in the World Wide Web.
</p>
<p>
This note describes how standard web protocols may be used to locate, retrieve and query provenance descriptions:
</p>
<ul>
<li>
- Simple mechanisms for retrieving and discovering provenance descriptions are described in <a href="#accessing-provenance-information" class="sectionRef"></a> and <a href="#locating-provenance-information" class="sectionRef"></a> .
+ 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>
- More advanced discovery service and query mechanisms that may be used for more demanding deployments are described in <a href="#provenance-services" class="sectionRef"></a>, <a href="#querying-provenance-information" class="sectionRef"></a> and <a href="#incremental-provenance-retrieval" class="sectionRef"></a>.
+ Provenance service mechanisms that may be used for more demanding deployments are described in <a href="#provenance-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>
</li>
</ul>
<p>
@@ -268,7 +271,7 @@
<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>
<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-information"><dfn>Provenance description</dfn></a></dt>
+ </dt><a href="#dfn-provenance-description"><dfn>Provenance description</dfn></a></dt>
<dd>refers to provenance represented in some fashion.</dd>
<dt><a href="#dfn-provenance-uri"><dfn>Provenance-URI</dfn></a></dt>
<dd>a URI denoting some <a class="internalDFN">provenance description</a>.</dd>
@@ -277,11 +280,11 @@
<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 descriptions (see <a href="#forward-provenance" class="sectionRef"></a>).</dd>
+ <dd>the URI of a provenance pingback service that can receive forward provenance descriptions (i.e. provenance describing how a resource is used - see <a href="#forward-provenance" class="sectionRef"></a>).</dd>
<dt><a href="#dfn-accessing"><dfn>Accessing</dfn></a> provenance descriptions</dt>
- <dd>Given the identity of a resource, the process of discovering and retrieving some <a class="internalDFN">provenance description</a>(s) about that resource. This may involve <a class="internalDFN">locating</a> a provenance description resource, then performing an HTTP GET to retrieve it, or locating a service and querying the service for provenance description about an identified resource, or some other mechanism not covered in this document.</dd>
+ <dd>given the identity of a resource, the process of discovering and retrieving some <a class="internalDFN">provenance description</a>(s) about that resource. This may involve <a class="internalDFN">locating</a> a provenance description resource, then performing an HTTP GET to retrieve it, or locating a service and querying the service for provenance description about an identified resource, or some other mechanism not covered in this document.</dd>
<dt><a href="#dfn-locating"><dfn>Locating</dfn></a> provenance descriptions</dt>
- <dd>Given the identity of a resource, discovery of a URI at which some <a class="internalDFN">provenance description</a> about that resource may be retrieved.</dd>
+ <dd>given the identity of a resource, discovery of a URI at which some <a class="internalDFN">provenance description</a> about that resource may be retrieved.</dd>
<!--
<a href="#dfn-..."><dt><dfn>...</dfn></dt></a>
<dd>...</dd>
@@ -296,7 +299,7 @@
Fundamentally, a <a class="internalDFN">provenance description</a> is <em>about</em> <a class="internalDFN">resource</a>s. In general, resources may vary over time and context. E.g., a resource describing the weather in London changes from day-to-day, or a listing of restaurants near you will vary depending on your location. Provenance descriptions, to be useful, must be persistent and not themselves dependent on context. Yet we may still want to make provenance assertions about dynamic or context-dependent resources (e.g. a 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 a notion of constrained resources. A <a class="internalDFN">constrained resource</a> is simply a resource (in the sense defined by [[WEBARCH]], <a href="http://www.w3.org/TR/webarch/#id-resources" class="externalRef">section 2.2</a>) that is a contextualized view or instance of some other 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 throughout its lifetime. Each individual revision would also have its own <a class="internalDFN">target-URI</a> denoting the specification at that 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. Target-URIs may use any URI scheme, and are not required to be dereferencable.
+ Provenance descriptions of dynamic and context-dependent resources are possible through a notion of constrained resources. A <a class="internalDFN">constrained resource</a> is simply a resource (in the sense defined by [[WEBARCH]], <a href="http://www.w3.org/TR/webarch/#id-resources" class="externalRef">section 2.2</a>) that is a specialization or instance of some other 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 throughout its lifetime. Each individual revision would also have its own <a class="internalDFN">target-URI</a> denoting the specification at that 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. Target-URIs may use any URI scheme, and are not required to be dereferencable.
</p>
<p>
Requests for provenance about a resource may return provenance descriptions that use one or more target-URIs to refer to versions of that resource. Some provenance descriptions may use multiple target-URIs if there are assertions referring to the same underlying resource in different contexts. For example, a provenance description for a W3C document might include information about all revisions of the document using statements that use the different target-URIs of the various revisions.
@@ -370,16 +373,18 @@
Web applications may access provenance descriptions in the same way as any resource on the Web, by dereferencing its URI (commonly using an HTTP GET operation). Thus, any provenance description may be associated with a <a class="internalDFN">provenance-URI</a>, and may be accessed by dereferencing that URI using web mechanisms.
</p>
<p>
- When there is no easy way to associate a provenance-URI with individual resources (e.g. for resources not directly web-accessible, or whose publication mechanism is controlled by someone else), one may provide provenance descriptions about multiple resources through through a service interface. A REST protocol for provenance retrieval is defined in Section <a href="#provenance-services" class="sectionRef"></a>.
+ When there is no easy way to associate a provenance-URI with individual resources (e.g. for resources not directly web-accessible, or whose publication mechanism is controlled by someone else), one may provide provenance descriptions about multiple resources through a service interface. A REST protocol for provenance retrieval is defined in Section <a href="#provenance-services" class="sectionRef"></a>.
</p>
<p>
How much or how little provenance is returned in response to a retrieval request is a matter for the provenance provider application.
</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-information" class="sectionRef"></a>.
+ 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. 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 this; we anticipate that the W3C Linked Data Platform group (<a href="http://www.w3.org/2012/ldp/" class="externalRef">www.w3.org/2012/ldp/</a>) may address this topic in due course.
+ 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.
+ </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>
</section>
@@ -418,13 +423,10 @@
<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>
</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. Finally, in <a href="#arbitrary-data" class="sectionRef"></a>, we discuss the case of a resource in an unspecified format which has been provided by some means other than HTTP.
+ 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.
</p>
<p>
- The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance descriptions. The provenance descriptions should themselves explicitly identify the target resources they describe. While a provider should avoid giving spurious information, there are no fixed semantics, particularly when multiple resources are indicated, and a client should not assume that a specific given provenance-uri will yield information about a specific given target-uri. In the general case, a client presented with multiple provenance-uris and multiple target-uris should look at all of the provenance-uris for information about any or all of the target-uris.
- </p>
- <p>
- The mechanisms specified for use with HTTP and HTML are similar to those proposed by POWDER [[POWDER-DR]] (sections <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#assoc-markup" class="externalRef">4.1.1</a> and <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#httplink" class="externalRef">4.1.3</a>).
+ The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance descriptions. The provenance descriptions should themselves explicitly identify the target resources they describe. While a provider should avoid giving spurious information, there are no fixed semantics, particularly when multiple resources are indicated, and a client should not assume that a specific given provenance-URI will yield information about a specific given target-URI. In the general case, a client presented with multiple provenance-URIs and multiple target-URIs should look at all of the provenance-URIs for information about any or all of the target-URIs.
</p>
<section>
@@ -436,9 +438,9 @@
A <code>hasProvenance</code> link relation type for referencing a provenance description may be used thus:
</p>
<pre class="pattern">Link: <cite>provenance-URI</cite>; rel="http://www.w3.org/ns/prov#hasProvenance"; anchor="<cite>target-URI</cite>"</pre>
- <p>When used in conjunction with an HTTP success response code (<code>2xx</code>), this HTTP header field indicates that <code><cite>provenance-URI</cite></code> is the URI of some provenance description associated with the requested resource, and that the associated resource is identified within the provenance description as <code><cite>target-URI</cite></code>. (See also <a href="#interpreting-provenance-information" class="sectionRef"></a>.)</p>
+ <p>When used in conjunction with an HTTP success response code (<code>2xx</code>), this HTTP header field indicates that <code><cite>provenance-URI</cite></code> is the URI of some provenance description about the originally requested resource, and that the requested resource is identified within the provenance description as <code><cite>target-URI</cite></code>. (See also <a href="#interpreting-provenance-descriptions" class="sectionRef"></a>.)</p>
<p>
- If no <code>anchor</code> parameter is provided then the <code><cite>target-URI</cite></code> is assumed to be the URI of the resource, used in the corresponding HTTP request.
+ If no <code>anchor</code> parameter is provided then the <code><cite>target-URI</cite></code> is assumed to be the URI of the requested resource used in the corresponding HTTP request.
</p>
<p>
This specification does not define the meaning of these links returned with other HTTP response codes: future revisions may define interpretations for these.
@@ -461,7 +463,7 @@
<pre class="pattern">
Link: <cite>provenance-service-URI</cite>; rel="http://www.w3.org/ns/prov#hasProvenanceService"; anchor="<cite>target-URI</cite>"</pre>
<p>
- The <code>hasProvenanceService</code> link identifies the <a class="internalDFN">service-URI</a>. Dereferencing this URI yields a service description that provides further information to enable a client to determine a <a class="internalDFN">provenance-URI</a> for a <a class="internalDFN">provenance description</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-services" class="sectionRef"></a> for more details.
+ The <code>hasProvenanceService</code> link identifies the <a class="internalDFN">service-URI</a>. Dereferencing this URI yields a service description that provides further information to enable a client to retrieve a <a class="internalDFN">provenance description</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-services" class="sectionRef"></a> for more details.
</p>
<p>
There may be multiple <code>hasProvenanceService</code> link header fields, and these may appear in an HTTP response together with <code>hasProvenance</code> link header fields (though, in simple cases, we anticipate that <code>hasProvenance</code> and <code>hasProvenanceService</code> link relations will not be used together).
@@ -474,7 +476,7 @@
When performing content negotiation for a resource, it is common for HTTP 302 or 303 redirect response codes to be used to direct a client to an appropriately-formatted resource. When accessing a resource for which provenance is available, link headers SHOULD be included with the response to the final redirected request, and not on the intermediate 303 responses. (When accessing a resource from a browser using Javascript, the intermediate 303 responses are usually handled transparently by the browser and are not visible to the HTTP client code.)
</p>
<p>
- Following content negotiation, any provenance link returned refers to the resource whose URI is used in the corresponding HTTP request, or the given anchor parameter if that is different. (The provenance description itself may also refer to other resources; see the discussion at the start of <a href="#locating-provenance-information" class="sectionRef"></a>.)
+ Following content negotiation, any provenance link returned refers to the resource whose URI is used in the corresponding HTTP request, or the given anchor parameter if that is different. (The provenance description itself may also refer to other resources; see the discussion at the start of <a href="#locating-provenance-descriptions" class="sectionRef"></a>.)
</p>
<p>
An example transaction using content negotiation and redirection might look like this (where <code>C:</code> and <code>S:</code> prefixes indicate client and server emitted data respectively):
@@ -491,7 +493,7 @@
S: HTML content for http://example.com/resource/
S: is available at http://example.com/resource/content.html
- C: GET /resource/content.rdf
+ C: GET /resource/content.html
C: Host: http://example.com/
C: Accept: text/html
@@ -567,11 +569,11 @@
<section>
<h2>Resource represented as RDF</h2>
<p>
- If a resource is represented as RDF (in any of its recognized syntaxes, including RDFa), it may contain references to its own provenance using additional RDF statements. For this purpose the link relations introduced above may be used as RDF properties: <code>prov:hasProvenance</code>, <code>prov:hasAnchor</code>, and <code>prov:hasProvenanceService</code>.
+ If a resource is represented as RDF (in any of its recognized syntaxes, including RDFa), it may contain references to its own provenance using additional RDF statements. For this purpose the link relations introduced above (<a href="#locating-provenance-descriptions" class="sectionRef"></a>) may be used as RDF properties: <code>prov:hasProvenance</code>, <code>prov:hasAnchor</code>, and <code>prov:hasProvenanceService</code>, where the <code>prov:</code> prefix here indicates the PROV namespace URI <code>http://www.w3.org/ns/prov#</code>.
(These terms may be used to indicate provenance of arbitrary other resources too, but discussion of such usage is beyond the scope of this section.)
</p>
<p>
- The RDF property <code>prov:hasProvenance</code> is a relation between two resources, where the object of the property is a resource that presents a provenance description of the subject resource. Multiple <code>prov:hasProvenance</code> assertions may be made about a subject resource. This property corresponds to a <code>hasProvenance</code> e link relation</a> used with an HTTP <code>Link</code> header field, or HTML <code><link></code> element (see above).
+ The RDF property <code>prov:hasProvenance</code> is a relation between two resources, where the object of the property is a resource that presents a provenance description of the subject resource. Multiple <code>prov:hasProvenance</code> assertions may be made about a subject resource. This property corresponds to a <code>hasProvenance</code> link relation</a> used with an HTTP <code>Link</code> header field, or HTML <code><link></code> element (see above).
</p>
<p>
Property <code>prov:hasAnchor</code> specifies a <a class="internalDFN">target-URI</a> used in the indicated provenance to refer to the containing RDF document.
@@ -600,7 +602,7 @@
<section>
<h2>Provenance services</h2>
<p>
- This section describes a REST-based protocol [[REST]] for provenance services with facilities for the retrieval of provenance descriptions. The protocol specifies HTTP operations for retrieval of a provenance description from a provenance service. It follows the approach of the SPARQL Graph Store HTTP Protocol [[SPARQL-HTTP]].
+ This section describes a REST-based protocol [[REST]] for provenance services with facilities for the retrieval of provenance descriptions. The protocol specifies HTTP operations for retrieving provenance descriptions 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>
@@ -621,7 +623,7 @@
<div>The embedded target-URI (<code>http://www.example.com/entity</code>) identifies the resource for which provenance is to be returned. Any server that implements this protocol and receives a request URI in this form SHOULD return a provenance description for the resource-URI embedded in the query component, where that URI is the result of percent-decoding the value associated with the provenance-resource key. The embedded URI MUST be an absolute URI and the server MUST respond with a 400 Bad Request if it is not. If the supplied resource-URI includes a fragment identifier, the '#' MUST be %-encoded as <code>%23</code> when constructing the provenance-URI value; similarly, any '&' character in the resource-URI must be %-encoded as <code>%26</code> [[RFC3986]].
</div>
<p>
- If the provenance identified in the request does not exist in the server, a 404 Not Found response code SHOULD be returned.
+ If the provenance described by the request does not exist in the server, a 404 Not Found response code SHOULD be returned.
</p>
<p>
The format of the returned provenance description is not defined here, but may be established through content type negotiation using <code>Accept:</code> header fields in the HTTP request. A provenance service SHOULD be capable of returning RDF using the vocabulary defined by [[PROV-O]], in any standard RDF serialization (e.g. RDF/XML), or any other standard serialization of the Provenance Model specification [[PROV-DM]]. Services MUST identify the <code>Content-Type</code> of the information returned.
@@ -705,7 +707,7 @@
<li>when was it made?</li>
</ul>
<p>
- These questions can be turned around to consider a publishers forward-looking use of a resource, like:
+ These questions can be turned around to consider a publishers' forward-looking use of a resource, like:
</p>
<ul>
<li>what new resources are based on this resource?</li>