--- a/paq/provenance-access.html Fri Aug 19 11:43:43 2011 +0100
+++ b/paq/provenance-access.html Fri Aug 19 15:02:15 2011 +0100
@@ -112,12 +112,12 @@
</head>
<body>
-
-<!-- ===================================================================================== -->
<section id='abstract'>
This document describes the use of existing mechanisms for accessing and querying provenance data about resources on the web.
</section>
+
+<!-- == Sect 1 =================================================================================== -->
<section>
<h2>Introduction</h2>
@@ -132,23 +132,23 @@
<dl>
<dt><dfn>Provenance information</dfn></dt>
<dd>refers to provenance represented in some fashion.</dd>
- <dt><dfn>Provenenance-URI</dfn></dt>
+ <dt><dfn>Provenance-URI</dfn></dt>
<dd>a URI denoting some <a class="internalDFN">provenance information</a>.</dd>
<dt><dfn>Context</dfn></dt>
- <dd>an entity, or aspect of a resource, about which one wishes to present some provenance information.</dd>
+ <dd>an entity, or aspect of a <a class="internalDFN">resource</a>, about which one wishes to present some <a class="internalDFN">provenance information</a>.</dd>
<dt><dfn>Context-URI</dfn></dt>
<dd>a URI denoting a context, which allows that context to be isolated in some provenance information (see <a href="#provenance-context"></a> for discussion)</dd>
<dt><dfn>Provenance service</dfn></dt>
- <dd>a service that provides a Provenance-URI or provenance information given a resource URI or context-URI.</dd>
+ <dd>a service that provides a <a class="internalDFN">provenance-URI</a> or <a class="internalDFN">provenance information</a> given a <a class="internalDFN">resource</a> URI or a <a class="internalDFN">context-URI</a>.</dd>
<dt><dfn>Service-URI</dfn></dt>
- <dd>the URI of a Provenance Service.</dd>
+ <dd>the URI of a <a class="internalDFN">provenance service</a>.</dd>
<dt><dfn>Resource</dfn></dt>
- <dd>a web resource, as <a href="http://www.w3.org/TR/webarch/#id-resources">described</a> by the Architecture of the World Wide Web [[WEBARCH]], section 2.2. A resource may be associated with multiple <a title="context" class="internalDFN">contexts</a> (see <a href="#provenance-context"></a> for discussion)</dd>
+ <dd>a web resource, as <a href="http://www.w3.org/TR/webarch/#id-resources">described</a> by the Architecture of the World Wide Web [[WEBARCH]], section 2.2. A resource may be associated with multiple <a title="context" class="internalDFN">contexts</a> (see <a href="#provenance-context" class="sectionRef"></a> for discussion)</dd>
</dl>
</p>
<p class="issue">
- The terms context and context-URI are chosen to align with terminology used in describing the HTTP link header (a href="http://tools.ietf.org/html/rfc5988#section-5.2£>http://tools.ietf.org/html/rfc5988#section-5.2</a>) - does this terminology work in the current (ahem) context? See also next section.
+ The terms context and context-URI are chosen to align with terminology used in describing the HTTP link header (<a href="http://tools.ietf.org/html/rfc5988#section-5.2">http://tools.ietf.org/html/rfc5988#section-5.2</a>) - does this terminology work in the current (ahem) context? See also next section.
</p>
</section>
@@ -165,18 +165,18 @@
Provenance descriptions of dynamic and context-dependent resources are possible through the notion of contexts. A <a class="internalDFN">context</a> is simply a web resource that is a contextualized view or instance of an original web 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 then be context-URIs, 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.
</p>
<p>
- In summary, a key notion within the concepts outlined above is that <a class="internalDFN">provenance information</a> may be not universally applicable to a <a class="internalDFN">resource</a>, but 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 <a class="internalDFN">context</a>, and a <a class="internalDFN">context-URI</a> allows one to refer to that context within the <a class="internalDFN">provenance information</a>. The <a class="internalDFN">context-URI</a> used to describe this restricted view of a resource is also related to the resource itself, and requests for provenance about that resource may return provenance information that uses one or more context-URIs to refer to it.
+ In summary, a key notion within the concepts outlined above is that <a class="internalDFN">provenance information</a> may be not universally applicable to a <a class="internalDFN">resource</a>, but 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 <a class="internalDFN">context</a>, and a <a class="internalDFN">context-URI</a> allows one to refer to that context within the provenance information. The context-URI used to describe this restricted view of a resource is also related to the resource itself, and requests for provenance about that resource may return provenance information that uses one or more context-URIs to refer to it. Some given provenance information may use multiple context-URIs if there are provenance assertions referring to the same underlying resource in different contexts. For example, a provenance resource describing a W3C document might include information about all revisions of the document using statements that use the different context-URIs for the revisions.
</p>
</section>
</section>
-<!-- ===================================================================================== -->
+<!-- == Sect 2 =================================================================================== -->
<section>
<h2>Accessing provenance information</h2>
<p>
- A general expectation is that web applications may access <a class="internalDFN">provenance information</a> in the same way as any web resource, by dereferencing its URI. Typically, this will be by performing an HTTP GET operation. Thus, any provenance information may be associated with a URI, and may be accessed by dereferencing that URI using normal web mechanisms.
+ A general expectation is that web applications may access <a class="internalDFN">provenance information</a> in the same way as any web resource, by dereferencing its URI. Typically, this will be by performing an HTTP GET operation. Thus, any provenance information may be associated with a <a class="internalDFN">provenance-URI</a>, and may be accessed by dereferencing that URI using normal web mechanisms.
</p>
<p>
This specification thus recommends that if a publisher wishes to make <a class="internalDFN">provenance information</a> available, it is published as a normal web resource, and provision is made for the <a class="internalDFN">provenance-URI</a> to be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-information" class="sectionRef"></a>.
@@ -186,18 +186,18 @@
</p>
</section>
-<!-- ===================================================================================== -->
+<!-- == Sect 3 =================================================================================== -->
<section>
<h2>Locating provenance information</h2>
<p>
- On the presumption that <a class="internalDFN">provenance information</a> 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.
+ On the presumption that <a class="internalDFN">provenance information</a> is a resource that can be accessed using normal web retrieval, one needs to know a <a class="internalDFN">provenance-URI</a> 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 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>
- 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 <a class="internalDFN">context</a> and is identified by a <a class="internalDFN">context-URI</a>.
+ Once provenance information information is retrieved, one needs to know how to identify the view of that resource within that provenance information. This view is known as the <a class="internalDFN">context</a> and is identified by a <a class="internalDFN">context-URI</a>.
</p>
<p>
- We start by considering mechanisms for the resource provider to indicate a <a class="internalDFN">provenance-URI</a> along with a <a class="internalDFN">context-URI</a>. Because the resource provider controls the response when the resource is accessed, direct indication of these URIs is possible. Three mechanisms are described here:
+ We start by considering mechanisms for the resource provider to indicate a <a class="internalDFN">provenance-URI</a> along with a <a class="internalDFN">context-URI</a>. (Mechanisms that can be independent of the resource provision are discussed in <a href="#provenance-discovery-services" class="sectionRef"></a>). Three mechanisms are described here:
<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 presented as HTML or XHTML</li>
@@ -229,7 +229,12 @@
<pre class="pattern">
Link: <cite>provenance-URI</cite>; rel="provenance"; anchor="<cite>context-URI</cite>"</pre>
</code>
- 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 the associated context is identified as <code><cite>context-URI</cite></code>.
+ 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 information associated with the requested resource and that the associated context is identified as <code><cite>context-URI</cite></code>.
+ </p>
+ <p class="issue">
+ - I believe there is no guarantee that the provenance-URI will provide provenance information about the context-URI. Suggest we use *should* rather than (implicitly) *must* to state that the returned provenance-uri should have provenance information about the resource view identified by the context-uri.
+<br/><br/>
+I think I see your point, but I am concerned that making that possibility explicit here might be confusing for a reader. I wonder if this would be better served by a new sub-section in sect 2 about interpreting provenance information?
</p>
<p>
If no <code>anchor</code> link is provided then the <code><cite>context-URI</cite></code> is assumed to be the URI of the resource.
@@ -283,7 +288,7 @@
The <code><cite>context-URI</cite></code> given by the <code>anchor</code> link element specifies an identifier for the presented document view, and which may be 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.
+ An HTML document header MAY include multiple "provenance" link elements, indicating a number of different provenance resources that are known to the creator of the document, each of which may provide provenance information about the document.
</p>
<p>
Likewise, the header MAY include multiple "anchor" link elements indicating that, e.g., different revisions of the document can be identified in the provenance information using the different <code><cite>context-URIs</cite></code>.
@@ -291,6 +296,9 @@
<p>
If no "anchor" link element is provided then the <code><cite>context-URI</cite></code> is assumed to be the URI of the document. It is RECOMMENDED that this only be done when the document is static.
</p>
+ <p class="issue">
+ Proposing to remove the following Note:
+ </p>
<p class="note">
See <a href="http://tools.ietf.org/html/rfc5988#appendix-A">Appendix A. Notes on Using the Link Header with the HTML4 Format</a> of RFC 5988 for further notes about using link relation types in HTML.
</p>
@@ -300,6 +308,11 @@
<p class="pending">
This is a new proposal. It needs to be checked as to whether it is useful. GK/PG to review nature of provenance-service-URI.
</p>
+ <p class="issue">
+ - Any reason why provenance service URI relation has not been added to the HTTP Web Linking section as a new relation type? Is is just to finish discussions about the relation before just migrating its use to HTTP Web Linking?
+ <br/><br/>
+ This is a new section, pending wider review. It's a fairly radical change from what I did before, so I guess I was waiting to see if people were happy with the general approach, before fully integrating it.
+ </p>
<p>
The document creator may specify that the provenance information about the document is provided by a provenance service. This is done through the use of a third link relation type following the same pattern as above:
</p>
@@ -308,7 +321,7 @@
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="wdr.issuedby" content="http://authority.example.org/company.rdf#me"/>
- <link rel="provenance-service" href="<cite>provenance-service-URI</cite>">
+ <link rel="provenance-service" href="<cite>service-URI</cite>">
<link rel="anchor" href="<cite>context-URI</cite>">
<title>Welcome to example.com</title>
</head>
@@ -319,8 +332,8 @@
</pre>
</code>
<p>
- The <code>provenance-service</code> link element identifies the service URI. Dereferencing this URI yields a service description that provides further information to enable a client to determine a provenance-URI for a context; see <a href="#provenance-discovery-services" class="sectionRef"></a> for more details.
- There may be multiple <code>provenance-service</code> link elements, and these MAY appear in the same document as <code>anchor</code> and <code>provenance</code> link elements (though, in practice, there may be little point in providing both <code>provenance</code> and <code>provenance-service</code> links).
+ The <code>provenance-service</code> link element 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">context</a>; see <a href="#provenance-discovery-services" class="sectionRef"></a> for more details.
+ There may be multiple <code>provenance-service</code> link elements, and these MAY appear in the same document as <code>anchor</code> and <code>provenance</code> link elements (though, in simple cases, we anticipate that <code>provenance</code> and <code>provenance-service</code> link relations would not both be used).
</p>
</section>
<p class="note">
@@ -362,7 +375,7 @@
If a resource is presented using a data format other than HTML or RDF, and no URI for the resource is known, provenance discovery becomes trickier to achieve. This specification does not define a specific mechanism for such arbitrary resources, but this section discusses some of the options that might be considered.
</p>
<p>
- For formats which have provision for including metadata within the file (e.g. JPEG images, PDF documents, etc.), use the format-specific metadata to include a context-URI and/or provenance-URI.
+ For formats which have provision for including metadata within the file (e.g. JPEG images, PDF documents, etc.), use the format-specific metadata to include a <a class="internalDFN">context-URI</a>, <a class="internalDFN">provenance-URI</a> and/or <a class="internalDFN">service-URI</a>. Format-specific metadata provision might also be used to include <a class="internalDFN">provenance information</a> directly in the resource.
</p>
<p>
Use a generic packaging format that can combine an arbitrary data file with a separate metadata file in a known format, such as RDF. At this time, it is not clear what format that should be, but some possible candidates are:
@@ -384,7 +397,7 @@
</section>
-<!-- ===================================================================================== -->
+<!-- == Sect 4 =================================================================================== -->
<section>