--- a/paq/prov-aq.html Thu Nov 08 12:13:00 2012 +0000
+++ b/paq/prov-aq.html Thu Nov 08 22:20:59 2012 +0000
@@ -7,11 +7,12 @@
<link rel="stylesheet" type="text/css" href="css/prov-aq.css" />
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!-- Use common W3C-hosted version of ReSpec.js:
+ <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
-->
- <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
<!-- Use local version of ReSpec.js for debugging:
<script src="js/respec.js" class="remove"></script>
-->
+ <script src="file:///usr/workspace/w3c-provenance/prov/paq/js/respec.js" class="remove"></script>
<script class='remove'>
var addExtraReferences = function() {
for (var k in extraReferences)
@@ -303,7 +304,7 @@
How much or how little provenance information is returned in response to a retrieval request is a matter for the provenance provider application.
</p>
<p>
- 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>.
+ It may be useful to provide provenance information about multiple resources through 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, 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>.
@@ -321,16 +322,29 @@
@@TODO: introduce producer/consumer roles to cover cases of HTTP and non-HTTP transfer of provenance discovery information.
</p>
<p>
- When <a class="internalDFN">provenance information</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 information may be exposed by a service. In this case, the <a class="internalDFN">service-URI</a> needs to be known.
- </p>
- <p>Provenance information about a resource may be provided by several parties other than the provider of that resource, each using different locations, and each with different concerns. (It is possible that these different parties may provide contradictory provenance information.)
+ If <a class="internalDFN">provenance information</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 information may be exposed by a service, in which case, the <a class="internalDFN">service-URI</a> needs to be known.
</p>
<p>
- Once provenance information about a resource is retrieved, one may also need to know how to locate information about that resource within the provenance information. This may be a <a class="internalDFN">constrained resource</a> identified by a separate <a class="internalDFN">target-URI</a>.
+ In the following, we refer to <a class="internalDFN">provider</a>s and <a class="internalDFN">consumer</a>s:
+ </p>
+ <dl>
+ <dt><dfn>provider</dfn></dt>
+ <dd>
+ is any 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 <a class="internalDFN">provenance information</a> made available by HTTP transactions (i.e. where the provenance provider is an HTTP server),
+ </dd>
+ <dt><dfn>consumer</dfn></dt>
+ <dd>
+ is any agent that receives and interprets some information. We focus here on interpretation of <a class="internalDFN">provenance information</a>.
+ </dd>
+ </dl>
+ <p>Provenance information may be offered by several providers as well as 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 information.
</p>
<p>
- We start by considering mechanisms for the resource provider to indicate a <a class="internalDFN">provenance-URI</a> or <a class="internalDFN">Service-URI</a> along with a <a class="internalDFN">target-URI</a>.
- Three mechanisms are described here:
+ A consumer of some provenance information will generally need to isolate information about some specific target resource or resources. These may be <a class="internalDFN">constrained resource</a>s identified by separate target-URIs than the original resource. In such circumstances, a provenance consumer will need to know the target-URI described by the provenance information obtained.
+ </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 a <a class="internalDFN">target-URI</a>.
+ Three mechanisms are described:
</p>
<ul>
<li>The requester knows the resource URI <em>and</em> the resource is accessible using HTTP</li>
@@ -338,10 +352,10 @@
<li>The requester has a copy of a resource represented as RDF (including the range of possible RDF syntaxes, such as HTML with embedded RDFa)</li>
</ul>
<p>
- These particular cases are selected as corresponding to primary current web protocol and data formats. Finally, in <a href="#arbitrary-data" class="sectionRef"></a>, we discuss the case of a resource 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. Similar approaches may be possible for other protocols or resource formats. Finally, in <a href="#arbitrary-data" 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>
<p>
- The mechanisms described here are intended to allow a server or data publisher to provide information that may assist a client in finding related provenance information. While a server should try not to provide spurious information, there are no fixed semantics, particularly when multiple values are provided, and a client should not assume that a specific given provenance-uri will yield information about a specific given target-uri. In the general case, a client presented with multiple provenance-uris and multiple targe-uris may look for provenance information about any or all of the target-uris in provenance information obtained from all of the provenance-uris.
+ The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance information. 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 target-uri. In the general case, a client presented with multiple provenance-uris and multiple target-uris should look at all of the provenance-uris for information about any or all of the target-uris.
</p>
<p>
The mechanisms specified for use with HTTP and HTML are similar to those proposed by POWDER [[POWDER-DR]] (sections <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#assoc-markup">4.1.1</a> and <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#httplink">4.1.3</a>).