--- a/paq/provenance-access.html Thu Aug 11 11:18:31 2011 +0100
+++ b/paq/provenance-access.html Thu Aug 11 11:19:34 2011 +0100
@@ -129,12 +129,16 @@
<dt>Service-URI</dt>
<dd>the URI of a Provenance Service.</dd>
<dt>Resource</dt>
- <dd>a web resource. A resource may be associated with multiple targets, which may correspond to different IVPs of the original resource.</dd>
+ <dd>a web resource. A resource may be associated with multiple targets.</dd>
</dl>
</p>
+ <p>
+ A key notion within these concepts is that a resource may not be the same as a target. Within provenance information, the provenance for a resource may be described with respect to a restricted view of that resource (e.g. the resource at a particular time). This restricted view is termed a target and a Target-URI allows one to locate that target within provenance information. Therefore, the Target-URI connects this restricted view of a resource with the resource itself.
+ </p>
+
<p class="issue">
- Say something about resources and targets and IVP. Probably needs to refer to the model document discussion of IVP. Roughly, "target" is an IVP of some web resource (which may just be the resource itself. Also discuss that provenance information is expected to be static: it is only meaningful to the extent that is is always true for the designated target. Example provenance about weather in London at http://www.metoffice.gov.uk/weather/uk/se/london_forecast_weather.html might reasonably say that it is published by the Met Office. But a claim that "Updated: 1641 on Tue 9 Aug 2011" would be true only for an IVP of that resource in a constrained time window.
+ Are we treading to much on the model territory here? How can we explain this only a target identifies an Entity in the provenance model?
</p>
</section>
@@ -159,29 +163,39 @@
On the presumption that provenance information is a resource that can be accessed using normal web retrieval, one needs to know a Provenance-URI to dereference. The Provenance-URI may be known in advance, in which case there is nothing more to specify. If a Provenance-URI is not known, then a mechanism to discover one must be based on some information that is available to the would-be accessor. We also wish to allow that provenance information could be provided by parties other than the provider of the original resource. Indeed, provenance information for a resource may be provided by several different parties, at different URIs, each with different concerns. It is quite possible that different parties may provide contradictory provenance information.
</p>
<p>
- We start by considering mechanisms for the resource provider to also indicate a Provenance-URI for a provided or indicated target. Because the resource provider controls the response when the target is accessed, direct indication of a Provenance-URI is possible. Three mechanisms are described here:
+ Once provenance information information is retrieved, one needs how to identify the view of that resource within that provenance information. This view is known as the target and is identified by a Target-URI.
+ </p>
+ <p>
+ We start by considering mechanisms for the resource provider to indicate a Provenance-URI along with a Target-URI. Because the resource provider controls the response when the resource is accessed, direct indication of these URIs is possible. Three mechanisms are described here:
<ul>
- <li>The requester knows the Target-URI <em>and</em> the target is accessed using HTTP</li>
- <li>The requester has a copy of a target presented as HTML or XHTML</li>
- <li>The requester has a copy of a target presented as RDF (including the range of possible RDF syntaxes, such as HTML with embedded RDFa)</li>
+ <li>The requester knows the Resource <em>and</em> the resource is accessed using HTTP</li>
+ <li>The requester has a copy of a resource presented as HTML or XHTML</li>
+ <li>The requester has a copy of a resource presented as RDF (including the range of possible RDF syntaxes, such as HTML with embedded RDFa)</li>
</ul>
- These particular cases are selected as corresponding to primary current web protocol and data formats. Finally, in <a href="#arbitrary-target" class="sectionRef"></a>, we discuss the case of an target 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. Finally, in <a href="#arbitrary-target" class="sectionRef"></a>, we discuss the case of a resource in an unspecified format which has been provided by some means other than HTTP.
</p>
<section>
- <h2>Target accessed by HTTP</h2>
+ <h2>Resource accessed by HTTP</h2>
<p>
For a document accessible using HTTP, POWDER [[POWDER-DR]] describes <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#httplink">a mechanism</a> for associating metadata with a resource using an HTTP <code>Link</code> header field. The <code>Link</code> header field is included in the HTTP response to a GET or HEAD operation (other HTTP operations are not excluded, but are not considered here). Since the POWDER specification was published, the HTTP linking draft has been approved by the IETF as <a href="http://tools.ietf.org/html/rfc5988">RFC 5988</a> [[LINK-REL]].
</p>
<p>
- The same basic mechanism can be used for referencing provenance data, for which a new link relation type is registered according to the template in <a href="#iana-considerations" class="sectionRef"></a>:
+ The same basic mechanism can be used for referencing provenance information, for which two new link relation types are registered according to the template in <a href="#iana-considerations" class="sectionRef"></a>:
<p class="pattern">
<code>Link: <cite>provenance-URI</cite>; rel="provenance"</code>
+ <code>Link: <cite>target-URI</cite>; rel="target"</code>
</p>
- When used in conjunction with an HTTP success response code (<code>2xx</code>), this HTTP header indicates that <code><cite>provenance-URI</cite></code> is the URI of some provenance for the requested resource. At this time, the meaning of provenance links returned with other HTTP response codes is not defined: future revisions of this specification may define interpretations for these.
+ When used in conjunction with an HTTP success response code (<code>2xx</code>), this HTTP header indicates that <code><cite>provenance-URI</cite></code> is the URI of some provenance for the requested resource and that resource's associated target is identified by the <code><cite>target-URI</cite></code>.
</p>
<p>
- An HTTP response MAY include multiple provenance link headers, indicating a number of different resources that are known to the responding server, each providing provenance about the accessed resource.
+ If no target link is provided then the <code><cite>target-URI</cite></code> is assumed to be the URI of the resources. It is RECOMMENDED that this only be done when the resource is static.
+ </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.
+ </p>
+ <p>
+ An HTTP response MAY include multiple provenance link headers, indicating a number of different resources that are known to the responding server, each providing provenance about the accessed resource. Likewise, an HTTP response MAY inclue multiple target link headers, that indicate the resource may be identified within provenance information using all of these <code><cite>target-URIs</cite></code>.
</p>
<p>
The presence of a provenance link in an HTTP response does not preclude the possibility that other publishers may offer provenance information about the same resource. In such cases, discovery of the additional provenance information must use other means (e.g. see <a href="#third-party-services" class="sectionRef"></a>).
@@ -194,7 +208,7 @@
</section>
<section>
- <h2>Target presented as HTML</h2>
+ <h2>Resource presented as HTML</h2>
<p class="pending">
Addresses <a href="http://www.w3.org/2011/prov/track/issues/46">ISSUE 46</a> with target link-relation.
</p>
@@ -202,7 +216,7 @@
For a document presented as HTML or XHTML, without regard for how it has been obtained, POWDER [[POWDER-DR]] describes <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#assoc-markup">a mechanism</a> for associating metadata with a resource by adding a <code><Link></code> element to the HTML <code><head></code> section.
</p>
<p>
- The same basic mechanism can be used for referencing provence data, for which two new link relation types are registered according to the template in <a href="#iana-considerations" class="sectionRef"></a>:
+ The same basic mechanism can be used for referencing provence information, for which two new link relation types are registered according to the template in <a href="#iana-considerations" class="sectionRef"></a>:
<code>
<pre class="pattern">
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -218,7 +232,7 @@
</html>
</pre>
</code>
- The <code><cite>provenance-URI</cite></code> given by the <code>provenance</code> link element identifies the Provenance-URI for the document where the <code><cite>target-URI</cite></code> given by the <code>target</code> link element specifies identifier of the presented document view, and which is used within the provenance information when referring to this document.
+ The <code><cite>provenance-URI</cite></code> given by the <code>provenance</code> link element identifies the Provenance-URI for the document where the <code><cite>target-URI</cite></code> given by the <code>target</code> link element specifies the identifier of the presented document view, and which is used within the provenance information when referring to this document.
</p>
<p>
An HTML document header MAY include multiple provenance link elements, indicating a number of different resources that are known to the creator of the document, each providing provenance about the document.
@@ -273,7 +287,7 @@
</section>
<section>
- <h2>Target presented as RDF</h2>
+ <h2>Resource presented as RDF</h2>
<p class="pending">
Addresses <a href="http://www.w3.org/2011/prov/track/issues/46">ISSUE 46</a> ???.
</p>
@@ -298,7 +312,7 @@
</section>
<section>
- <h2>Arbitrary target</h2>
+ <h2>Arbitrary data</h2>
<p class="pending">
We have so far decided not to try and define a common mechanism for arbitrary data, because it's not clear to us what the correct choice would be. Is this a reasonable position, or is there a real need for a generic solution for provenance discovery for arbitrary, non-web-accessible data objects?
</p>