--- a/paq/provenance-access.html Wed Aug 17 13:50:17 2011 +0100
+++ b/paq/provenance-access.html Wed Aug 17 15:10:22 2011 +0100
@@ -130,20 +130,20 @@
<p>
In defining the specification below, we make use of the following concepts.
<dl>
- <dt>Provenance information</dt>
+ <dt><dfn>Provenance information</dfn></dt>
<dd>refers to provenance represented in some fashion.</dd>
- <dt>Provenenance-URI</dt>
- <dd>a URI denoting some provenance information.</dd>
- <dt>Context</dt>
- <dd>an entity, or aspect of a resource, about which one wants to present the provenance.</dd>
- <dt>Context-URI</dt>
+ <dt><dfn>Provenenance-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>
+ <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>Provenance service</dt>
+ <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>
- <dt>Service-URI</dt>
+ <dt><dfn>Service-URI</dfn></dt>
<dd>the URI of a Provenance Service.</dd>
- <dt>Resource</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 contexts (see <a href="#provenance-context"></a> for discussion)</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>
</dl>
</p>
@@ -159,13 +159,13 @@
This section has been drafted to address a number of concerns: (a) to avoid previous use of "Target" for the topic of a provenance assertion (cf. http://www.w3.org/2011/prov/track/issues/74), and (b) to clarify the use of different resources as views on a dynamic or variable subject of provenance.
</p>
<p>
- Fundamentally, provenance information is <em>about</em> web resources, in the <a href="http://www.w3.org/TR/webarch/#id-resources">sense described</a> by the Architecture of the World Wide Web [[WEBARCH]]. In general, web 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-varying web 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> web resources, in the <a href="http://www.w3.org/TR/webarch/#id-resources">sense described</a> by the Architecture of the World Wide Web [[WEBARCH]]. In general, web 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-varying web resources (e.g. the 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 the notion of "contexts". A context 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.
+ 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 provenance information may be not universally applicable to a resource, 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 context, and a context-URI 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 a resource may return provenance information that uses one or more context-URIs to refer to the resource.
+ 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.
</p>
</section>
@@ -176,13 +176,13 @@
<section>
<h2>Accessing provenance information</h2>
<p>
- A general expectation is that web applications may access provenance information 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 URI, 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 provenance information available, it is published as a normal web resource, and provision is made for the Provenance-URI to be discoverable using one or more of the mechanisms described later in <a href="#locating-provenance-information" class="sectionRef"></a>.
+ 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>.
</p>
<p>
- This presumption of using web retrieval to access provenance information does not preclude use of other mechanisms. In particular, alternative mechanisms may be needed if there is no URI associated with some particular provenance information. A possible mechanism is suggested in <a href="#querying-provenance-information" class="sectionRef"></a>.
+ This presumption of using web retrieval to access provenance information does not preclude use of other mechanisms. In particular, alternative mechanisms may be needed if there is no URI associated with some particular provenance information. Possible mechanisms are suggested in <a href="#provenance-discovery-services" class="sectionRef"></a> and <a href="#querying-provenance-information" class="sectionRef"></a>.
</p>
</section>
@@ -191,15 +191,15 @@
<section>
<h2>Locating provenance information</h2>
<p>
- 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.
+ 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.
</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 context and is identified by a context-URI.
+ 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>.
</p>
<p>
- We start by considering mechanisms for the resource provider to indicate a provenance-URI along with a context-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:
+ 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:
<ul>
- <li>The requester knows the Resource <em>and</em> the resource is accessed using HTTP</li>
+ <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>
<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>
@@ -211,6 +211,9 @@
<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 class="pending">
+ The link relation indicating a context_URI has been called "anchor" (as opposed to, say, "context"), following terminology used for the HTTP Link element.
+ </p>
<p class="issue">
Pick one or allow either of the following?:
</p>
@@ -226,7 +229,7 @@
<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 resource context is identified by <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 for the requested resource and that the associated context is identified as <code><cite>context-URI</cite></code>.
</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.
@@ -235,7 +238,7 @@
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 <code>provenance</code> 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 include multiple <code>anchor</code> link headers, that indicate the resource may have provenance information associated with all of the indicated <code><cite>context-URIs</cite></code>.
+ An HTTP response MAY include multiple <code>provenance</code> link headers, indicating a number of different provenance resources that are known to the responding server, each providing provenance information about the accessed resource. Likewise, an HTTP response MAY include multiple <code>anchor</code> link headers, that indicate the resource may have provenance information associated with all of the indicated <code><cite>context-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="#provenance-discovery-services" class="sectionRef"></a>).
@@ -288,6 +291,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="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>
<section>
<h2>Specifying Provenance Services</h2>
@@ -313,16 +319,10 @@
</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-service" class="sectionRef"></a> for more details.
+ 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).
</p>
</section>
- <p class="issue">
- Is this next paragraph useful? It seems out of place here: I'm not sure what it is intended to clarify. #g
- </p>
- <p>
- See in particular <a href="http://tools.ietf.org/html/rfc5988#appendix-A">Appendix A. Notes on Using the Link Header with the HTML4 Format</a> of RFC5988 for further notes about using link relation types in HTML.
- </p>
<p class="note">
An alternative option would be to use an HTML <code><meta></code> element to present provenance links. The <code><Link></code> is preferred as it reflects more closely the intended goal, and has been defined with somewhat consistent applicability across HTTP, HTML and potentially RDF data. A specification to use <code><meta></code> for this would miss this opportunity to build on the existing specification and registry.
</p>
@@ -333,9 +333,6 @@
<section>
<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>
<p>
If a resource is presented as RDF (in any of its recognized syntaxes, including RDFa), it may contain references to its own provenance using additional RDF statements.
</p>
@@ -373,7 +370,7 @@
<li>MIME multipart/related [[RFC2387]]: both email and HTTP are based on MIME or MIME-derivatives, so this has the advantage of working well with the network transfer mechanisms discussed in the motivating scenarios considered.
</li>
<li>
- Composite object-packaging work from the digital library community, or which there are several (ORE, MPEG-21, BagIt @@refs) to name a handful. Practical implementations of these seem to commonly be based on the ZIP file format.
+ Composite object-packaging work from the digital library community, of which there are several (ORE, MPEG-21, BagIt @@refs) to name a handful. Practical implementations of these seem to commonly be based on the ZIP file format.
</li>
<li>
Packaging formats along the lines of those used for shipping Java web applications or (basically, a ZIP file with a manifest and some imposed structure)
@@ -420,12 +417,12 @@
<section>
<h2>Retrieve Provenance-URIs for a resource</h2>
<p>
- To use the provenance discovery service to retrieve a list of provenance-URIs for a resource, starting with the discovery service URI (<code>service-URI</code>) and the URI of the context resource (<code>context-URI</code>):
+ To use the provenance discovery service to retrieve a list of provenance-URIs for a resource, starting with the discovery service URI (<code>service-URI</code>) and the URI of the resource or context (<code>context-URI</code>):
<ol>
- <li>Dereference <code>service-URI</code> to obtain a representation of the <cite>service description</cite> in one of the formats described below.</li>
+ <li>Dereference <code>service-URI</code> to obtain a representation of the <a class="internalDFN">service description</a> in one of the formats described below.</li>
<li>Extract the <cite>provenance location template</cite> from the service description.</li>
<li>Use the provenance location template with <code>context-URI</code> for template variable <code>uri</code> to form <code>provenance-location-URI</code>.</li>
- <li>Dereference <code>provenance-location-URI</code> to obtain a <cite>provenance locations</cite> resource in one of the formats described below.</li>
+ <li>Dereference <code>provenance-location-URI</code> to obtain a <a class="internalDFN">provenance locations resource</a> in one of the formats described below.</li>
</ol>
</p>
<p>
@@ -436,12 +433,12 @@
<section>
<h2>Retrieve Provenance information for a resource</h2>
<p>
- To use the provenance discovery service to retrieve provenance information for a resource, starting with the discovery service URI (<code>service-URI</code>) and the URI of the resource (<code>context-URI</code>):
+ To use the provenance discovery service to retrieve provenance information for a resource, starting with the discovery service URI (<code>service-URI</code>) and the URI of the resource or context (<code>context-URI</code>):
<ol>
- <li>Dereference <code>service-URI</code> to obtain a representation of the <cite>service description</cite> in one of the formats described below.</li>
+ <li>Dereference <code>service-URI</code> to obtain a representation of the <a class="internalDFN">service description</a> in one of the formats described below.</li>
<li>Extract the <cite>provenance information template</cite> from the service description.</li>
<li>Use the provenance information template with <code>context-URI</code> for template variable <code>uri</code> to form <code>provenance-URI</code>.</li>
- <li>Dereference <code>provenance-URI</code> to obtain <cite>provenance information</cite> as described by the provenance model document [[PROV-MODEL]] @@TODO: fix up name, reference.</li>
+ <li>Dereference <code>provenance-URI</code> to obtain <a class="internalDFN">provenance information</a> as described by the Provenance Model specification [[PROV-MODEL]].</li>
</ol>
</p>
</section>
@@ -454,12 +451,12 @@
<section>
<h2>Service description</h2>
<p>
- Describes the provenance discovery and retrieval service and, in particular, provides URI templates [[URI-template]] for URIs to access Provenance-URIs and/or provenance information. Dereferencing the service URI returns a representation of this service description. The service description MAY contain additional metadata about the service beyond that described here: API clients are expected to ignore any metadata elements they do not understand.
+ A provenance <dfn>service description</dfn> describes the provenance discovery and retrieval service and, in particular, provides URI templates [[URI-template]] for URIs to access <a title="provenance locations resource" class="internalDFN">provenance locations resources</a> and/or <a class="internalDFN">provenance information</a>. Dereferencing the service URI returns a representation of this service description. The service description MAY contain additional metadata about the service beyond that described here: API clients are expected to ignore any metadata elements they do not understand.
</p>
<section>
<h2>JSON example of service description</h2>
<p>
- This example uses JSON format [[RFC4627]], presented using MIME content type <code>application/json</code>.
+ This example uses JSON format [[RFC4627]], presented as MIME content-type <code>application/json</code>.
</p>
<code>
<pre class="example">
@@ -474,7 +471,7 @@
<section>
<h2>RDF Turtle example of service description</h2>
<p>
- This example uses the RDF Turtle format [[TURTLE]], presented using MIME content type <code>text/turtle</code>.
+ This example uses the RDF Turtle format [[TURTLE]], presented as MIME content-type <code>text/turtle</code>.
</p>
<code>
<pre class="example">
@@ -490,12 +487,12 @@
The provenance URI templates are encoded in RDF as plain string literals, <em>not</em> as resource URIs.
</p>
<p class="issue">
- The <code>provds:provenance_service_uri</code> property is redundant given the service description node itself is specified. I've included it for discussion, as it allows the RDF/Turtle form to be very similar to the JSON form of the service description, which may or may not be an advantage. I am personally in favour of using JRON (http://decentralyze.com/2010/06/04/from-json-to-rdf-in-six-easy-steps-with-jron/ <em>Hi sandro :)</em>) for the JSON format, which would be a very small change: just use "__iri" for the "provenance_service_uri" property, and would allow all formats to be closely based on the RDF model, while affording developers the convenience of using simple JSON handling code where appropriate.
+ The <code>provds:provenance_service_uri</code> property is redundant given the service description node itself is identified. I've included it for discussion, as it allows the RDF/Turtle form to be very similar to the JSON form of the service description, which may or may not be an advantage. I am personally in favour of using JRON (http://decentralyze.com/2010/06/04/from-json-to-rdf-in-six-easy-steps-with-jron/ <em>Hi Sandro :)</em>) for the JSON format, which would be a very small change: just use "__iri" for the "provenance_service_uri" property, and would allow all formats to be closely based on the RDF model, while affording developers the convenience of using simple JSON handling code where appropriate.
</p>
</section>
<section>
<h2>RDF/XML example of service description</h2>
- <p>This is essentially the same as the Turtle example above, but encoded in RDF/XML [[RDF-SYNTAX-GRAMMAR]].</p>
+ <p>This is essentially the same as the Turtle example above, but encoded in RDF/XML [[RDF-SYNTAX-GRAMMAR]], and presented as MIME content-type <code>application/xml+rdf</code>.</p>
<code>
<pre class="example">
<rdf:RDF
@@ -517,7 +514,7 @@
<section>
<h2>Provenance locations</h2>
<p>
- A provenance locations resource enumerates one or more provenance-URIs associated with a given resource.
+ A <dfn>provenance locations resource</dfn> enumerates one or more provenance-URIs associated with a given resource.
</p>
<p>
The examples below are for a given resource URI <code>http://example.info/qdata/</code>, and using the service description example above, its URI would be <code>http://example.info/provenance_service/location/?uri=http%3A%2F%2Fexample.info%2Fqdata%2F</code>.
@@ -528,7 +525,7 @@
<section>
<h2>JSON example of provenance locations</h2>
<p>
- This example uses JSON format [[RFC4627]], presented using MIME content type <code>application/json</code>.
+ This example uses JSON format [[RFC4627]], presented as MIME content type <code>application/json</code>.
</p>
<code>
<pre class="example">
@@ -546,7 +543,7 @@
<section>
<h2>RDF Turtle example of provenance locations</h2>
<p>
- This example uses the RDF Turtle format [[TURTLE]], presented using MIME content type <code>text/turtle</code>.
+ This example uses the RDF Turtle format [[TURTLE]], presented as MIME content type <code>text/turtle</code>.
</p>
<code>
<pre class="example">