--- a/paq/working/prov-aq.html Thu Apr 26 12:35:04 2012 +0100
+++ b/paq/working/prov-aq.html Thu Apr 26 13:19:03 2012 +0100
@@ -23,6 +23,8 @@
"RFC2387" : "E. Levinson. <a href=\"http://www.ietf.org/rfc/rfc2387.txt\"><cite>The MIME Multipart/Related Content-type.</cite></a> August 1998. Internet RFC 2387. URL: <a href=\"http://www.ietf.org/rfc/rfc2387.txt\">http://www.ietf.org/rfc/rfc2387.txt</a>",
+ "RFC2392" : "E. Levinson. <a href=\"http://www.ietf.org/rfc/rfc2392.txt\"><cite>Content-ID and Message-ID Uniform Resource Locators.</cite></a> August 1998. Internet RFC 2392. URL: <a href=\"http://www.ietf.org/rfc/rfc2392.txt\">http://www.ietf.org/rfc/rfc2392.txt</a>",
+
"RFC3297" : "G. Klyne; R. Iwazaki; D. Crocker. <a href=\"http://www.ietf.org/rfc/rfc3297.txt\"><cite>Content Negotiation for Messaging Services based on Email.</cite></a> July 2002. Internet RFC 3297. URL: <a href=\"http://www.ietf.org/rfc/rfc3297.txt\">http://www.ietf.org/rfc/rfc3297.txt</a>",
"PRISM" : "International Digital Enterprise Alliance, Inc. <a href=\"http://www.prismstandard.org/specifications/2.0/PRISM_prism_namespace_2.0.pdf\"><cite>PRISM: Publishing Requirements for Industry Standard Metadata</cite></a>. February 2008. URL: <a href=\"http://www.prismstandard.org/specifications/2.0/PRISM_prism_namespace_2.0.pdf\">http://www.prismstandard.org/specifications/2.0/PRISM_prism_namespace_2.0.pdf</a>",
@@ -241,7 +243,7 @@
<dt><dfn>Provenance-URI</dfn></dt>
<dd>a URI denoting some <a class="internalDFN">provenance information</a>.</dd>
<dt><dfn>Constrained resource</dfn></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. An 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">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 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">section 2.3.2</a>.</dd>
<dt><dfn>Target-URI</dfn></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> (see <a href="#provenance-entities-resources" class="sectionRef"></a> for discussion)</dd>
<dt><dfn>Provenance service</dfn></dt>
@@ -258,10 +260,10 @@
<section>
<h2 id="provenance-entities-resources">Provenance and resources</h2>
<p>
- Fundamentally, <a class="internalDFN">provenance information</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 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 resources (e.g. the weather forecast for London on a particular day may have been derived from a particular set of Meteorological Office data).
+ Fundamentally, <a class="internalDFN">provenance information</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 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 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">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 through its lifetime. Separate URIs for each individual revision would also have <a class="internalDFN">target-uri</a>s, each 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. 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">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 through 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 information that uses one or more target-URIs to refer to versions of that resource. Some given provenance information may use multiple target-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 target-URIs of the various revisions.
@@ -274,9 +276,7 @@
<section>
<h2>Interpreting provenance information</h2>
<p>
- <a class="internalDFN">Provenance information</a> describes relationships between <a class="internalDFN">resource</a>s, including activities and agents. Any given provenance information may contain information about several resources, referring to them using their <a class="internalDFN">target-uri</a>s.
- </p>
- <p>
+ Any given <a class="internalDFN">provenance information</a> may contain information about several resources, referring to them using their various <a class="internalDFN">target-uri</a>s.
Thus, when interpreting provenance information, it is important to be aware that statements about several resources may be present, and to be accordingly selective when using the information provided. (In some exceptional cases, it may be that the provenance information returned does not contain any information relating to a specific associated resource.)
</p>
</section>
@@ -297,7 +297,7 @@
It may be useful to provide provenance information through a service interface. A REST protocol for provenance retrieval is defined in Section <a href="#provenance-services" class="sectionRef"></a>.
</p>
<p>
- When publishing provenance information, the location of that information either at a URI or within a Service should be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-information" class="sectionRef"></a>.
+ When publishing provenance information, a corresponding <a class="internalDFN">provenance-URI</a> or <a class="internalDFN">service-URI</a> should be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-information" class="sectionRef"></a>.
</p>
<p>
Some alternative practices for accessing provenance information are discussed in <a href="#best-practice" class="sectionRef"></a>
@@ -341,7 +341,7 @@
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 information associated with the requested resource and that the associated resource is identified within the referenced provenance information as <code><cite>target-uri</cite></code>. (See also <a href="#interpreting-provenance-information" class="sectionRef"></a>.)
</p>
<p>
- If no <code>anchor</code> link 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 resource, used in the corresponding HTTP request.
</p>
<p>
At this time, the meaning of these links returned with other HTTP response codes is not defined: future revisions of this specification may define interpretations for these.
@@ -359,7 +359,7 @@
<section>
<h2>Specifying Provenance Services</h2>
<p>
- The resource provider may indicate that provenance information about the document is provided by a <a class="internalDFN">provenance service</a>. This is done through the use of a <code>provenance-service</code> link relation type following the same pattern as above:
+ The resource provider may indicate that provenance information about the resource is provided by a <a class="internalDFN">provenance service</a>. This is done through the use of a <code>provenance-service</code> link relation type following the same pattern as above:
</p>
<pre class="pattern">
Link: <cite>provenance-service-URI</cite>; anchor="<cite>target-uri</cite>"; rel="provenance-service"</pre>
@@ -394,7 +394,7 @@
The <code><cite>provenance-URI</cite></code> given by the <code>provenance</code> link element identifies the provenance-URI for the document.
</p>
<p>
- The <code><cite>target-uri</cite></code> given by the <code>anchor</code> link element specifies an specifies an identifier for the document that may be used within the provenance information when referring to the document.
+ The <code><cite>target-uri</cite></code> given by the <code>anchor</code> link element specifies an identifier for the document that may be used within the provenance information when referring to the document.
</p>
<p>
An HTML document header MAY include multiple <code>provenance</code> link elements, indicating a number of different provenance sources that are known to the creator of the document, each of which may provide provenance information about the document.
@@ -405,7 +405,7 @@
</p>
-->
<p>
- If no "anchor" link element is provided then the <code><cite>target-uri</cite></code> is assumed to be the URI of the document. It is RECOMMENDED that this convention be used only when the document is static and has an easily-determined URI.
+ If no "anchor" link element is provided then the <code><cite>target-uri</cite></code> is assumed to be the URI of the document. It is RECOMMENDED that this convention be used only when the document is static and has a stable URI that is reasonably expected to be available to anyone accessing the document (e.g. when delivered from a web server, or as part of a MIME structure containing content identifiers [[RFC2392]]).
</p>
<section>
@@ -572,16 +572,21 @@
A provenance query service provides an alternative way to access provenance information and/or provenance-URIs. An application will need a URI for the provenance query service, and some relevant information about the resource whose provenance is to be accessed.
</p>
<p>
- The details of a provenance query service is an implementation choice, but for interoperability between different providers and users we recommend use of SPARQL [[RDF-SPARQL-PROTOCOL]] [[RDF-SPARQL-QUERY]]. The query service URI would then be the URI of a SPARQL endpoint (or, to use the SPARQL specification language, a <a href="http://www.w3.org/TR/rdf-sparql-protocol/#conformant-sparql-protocol-service">SPARQL protocol service</a>). The following subsections provide examples for what are considered to be some plausible common scenarios for using SPARQL, and are not intended to cover all possibilities.
+ The details of a provenance query service is an implementation choice, but for interoperability between different providers and users we recommend use of SPARQL [[RDF-SPARQL-PROTOCOL]] [[RDF-SPARQL-QUERY]].
+ The query service URI would then be the URI of a <a href="http://www.w3.org/TR/rdf-sparql-protocol/#conformant-sparql-protocol-service">SPARQL protocol service</a>
+(often referred to as a "SPARQL endpoint").
+ The following subsections provide examples for what are considered to be some plausible common scenarios for using SPARQL, and are not intended to cover all possibilities.
</p>
<p>
A SPARQL protocol service description may be published using the <cite>SPARQL 1.1 Service Description</cite> vocabulary [[SPARQL-SD]].
</p>
-
+ <p>
+ The following subsections illustrate use cases for querying a SPARQL-based provenance query service.
+ </p>
<section>
<h2>Find a provenance-URI given a target-uri</h2>
<p>
- If the requester has an <a class="internalDFN">target-uri</a>, a simple SPARQL query may be used to return the corresponding <a class="internalDFN">provenance-URI</a>. E.g., if the original resource has a target-uri <code>http://example.org/resource</code>:
+ If the requester has a <a class="internalDFN">target-uri</a>, a simple SPARQL query may be used to return the corresponding <a class="internalDFN">provenance-URI</a>. E.g., if the original resource has a target-uri <code>http://example.org/resource</code>:
<pre class="example code">
@prefix prov: <<provns/>>
SELECT ?provenance_uri WHERE
@@ -647,7 +652,7 @@
<h2>Via Web Retrieval</h2>
<p>Publishers are not required to publish all the provenance information associated with a given resource at a particular <a class="internalDFN">provenance-URI</a>. The amount of provenance information exposed is application dependent. However, it is possible to incrementally retrieve (i.e. walk the provenance graph) by progressively looking up provenance information using HTTP. The pattern is as follows:
<ol>
- <li>For a given resource (<code>target-uri-1</code>) retrieve it's associated <code>provenance-uri-1</code> and its associated <code>target-uri-1</code> using a returned HTTP <code>Link:</code> header field (<a href="#resource-accessed-by-http" class="sectionRef"></a>)</li>
+ <li>For a given resource (<code>resource-uri</code>) retrieve it's associated <code>provenance-uri-1</code> and its associated <code>target-uri-1</code> using a returned HTTP <code>Link:</code> header field (<a href="#resource-accessed-by-http" class="sectionRef"></a>)</li>
<li>Dereference <code>provenance-uri-1</code></li>
<li>Navigate the provenance information</li>
<li>When reaching a dead-end during navigation, that is on encountering a reference to a resource (<code>target-uri-2</code>) with no provided provenance information, find its provenance-URI and continue from Step 2. (Note: an HTTP HEAD request for <code>target-uri-2</code> may be used to obtain the <code>Link:</code> headers without retrieving the resource representation.)</li>