--- a/paq/prov-aq.html Thu Feb 21 15:31:53 2013 +0000
+++ b/paq/prov-aq.html Thu Feb 21 15:57:28 2013 +0000
@@ -315,6 +315,14 @@
<dd>
given the identity of a resource, discovery of a URI at which some <a class="internalDFN">provenance record</a> about that resource may be retrieved.
</dd>
+ <dt>provenance <a href="#dfn-provider"><dfn>provider</dfn></a></dt>
+ <dd>
+ is an agent that makes available provenance descriptions.
+ </dd>
+ <dt>provenance <a href="#dfn-consumer"><dfn>consumer</dfn></a></dt>
+ <dd>
+ is an agent that receives and interprets provenance records.
+ </dd>
<!--
<a href="#dfn-..."><dt><dfn>...</dfn></dt></a>
<dd>
@@ -351,6 +359,9 @@
Also, review second para below. Move definition of provider/consumer to concepts section?
</p>
<p>
+ The mechanisms described in this document are intended to allow a provider to supply information to enable a consumer to access provenance records. The provenance records themselves explicitly identify the entities they describe.
+ </p>
+ <p>
Any <a class="internalDFN">provenance record</a> may contain information about several <a class="internalDFN" href="#dfn-entity">entities</a>, referring to them using their various <a class="internalDFN">entity-URI</a>s.
Thus, when interpreting provenance records, it is important to be aware that statements about several entities may be present, and to be accordingly selective when using the information provided.
(Further, the provenance record returned may contain <em>no</em> information about the specific entity for which the request was made.)
@@ -361,6 +372,9 @@
<p>
A provenance record is not of itself guaranteed to be authoritative or correct. Trust in provenance records must be determined separately from trust in the original resource. Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any other resource; e.g. based on the domain that serves it, or an associated digital signature. (See also <a href="#security-considerations" class="sectionRef"></a>.)
</p>
+ <p>
+ 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 entity-URI. In the general case, a client presented with multiple provenance-URIs and multiple entity-URIs should look at all of the provenance-URIs for information about any or all of the entity-URIs.
+ </p>
</section>
<section>
@@ -434,6 +448,7 @@
<br/><br/>
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>
<!-- == Sect 3 =================================================================================== -->
@@ -441,37 +456,20 @@
<section>
<h2>Locating provenance records</h2>
<p>
- If a <a class="internalDFN">provenance record</a> is a resource that can be accessed using web retrieval, one needs to know its <a class="internalDFN">provenance-URI</a> to dereference. If this is known in advance, 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. Likewise, provenance may be exposed by a query service, in which case, the <a class="internalDFN">service-URI</a> needs to be known.
+ When a <a class="internalDFN">provenance record</a> can be accessed using direct web retrieval, one needs to know its <a class="internalDFN">provenance-URI</a> to dereference. If this is known in advance, 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. Likewise, provenance may be exposed by a query service, in which case, the <a class="internalDFN">service-URI</a> needs to be known.
+ </p>
+ <p>Provenance records may be offered by several providers other than that of the original resource publisher, each with different concerns, and presenting provenance at different locations. It is possible that these different providers may present contradictory provenance.
</p>
<p>
- In the following, we refer to <a class="internalDFN">provider</a>s and <a class="internalDFN">consumer</a>s of provenance:
+ Three mechanisms are defined for a <a class="internalDFN">provider</a> to indicate to a <a class="internalDFN">consumer</a> information about a <a class="internalDFN">provenance-URI</a> or <a class="internalDFN">service-URI</a> along with an <a class="internalDFN">entity-URI</a>:
</p>
- <dl>
- <dt><dfn>provider</dfn></dt>
- <dd>
- is an agent that collects or constructs some information and makes it available. The nature of the information or the means by which it is made available are not constrained, but the following discussion focuses on provenance records made available by HTTP transactions (i.e. where the provenance provider is an HTTP server),
- </dd>
- <dt><dfn>consumer</dfn></dt>
- <dd>
- is an agent that receives and interprets provenance records.
- </dd>
- </dl>
- <p>Provenance records may be offered by several providers other than that of the original resource, each with different concerns, and presenting provenance at different locations. It is possible that these different providers may present contradictory provenance.
- </p>
- <p>
- We consider here mechanisms for a provider to indicate a <a class="internalDFN">provenance-URI</a> or <a class="internalDFN">service-URI</a> along with an <a class="internalDFN">entity-URI</a>.
- Three mechanisms are described:
- </p>
- <ul>
+ <ol>
<li>The consumer knows the resource URI <em>and</em> the resource is accessible using HTTP</li>
<li>The consumer has a copy of a resource represented as HTML or XHTML</li>
<li>The consumer has a copy of a resource represented as RDF (including the range of possible RDF syntaxes, such as HTML with embedded RDFa)</li>
- </ul>
+ </ol>
<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.
- </p>
- <p class="note">
- The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance records. The provenance records 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 entity-URI. In the general case, a client presented with multiple provenance-URIs and multiple entity-URIs should look at all of the provenance-URIs for information about any or all of the entity-URIs.
+ These particular cases are selected as corresponding to current primary web protocol and data formats. Similar approaches may be defined for other protocols or resource formats.
</p>
<section>