--- a/paq/prov-aq.html Tue Feb 26 17:07:58 2013 +0000
+++ b/paq/prov-aq.html Tue Feb 26 17:19:41 2013 +0000
@@ -917,7 +917,7 @@
The defined URI template expansion process [[URI-template]] generally takes care of %-escaping characters that are not permitted in URIs. However, when expanding a template with <code>{+uri}</code>, some permitted characters such as <code>'#'</code> and <code>'&'</code> are not escaped. If the supplied entity-URI contains these characters, then they may disrupt interpretation of the resulting query URI. To prevent this, <code>'#'</code> and <code>'&'</code> characters in the entity-URI may be replaced with <code>%23</code> and <code>%26</code> respectively, before performing the URI template expansion. An alternative, simpler and more reliable approach is to use <code>{uri}</code> in the URI template string, which will cause all URI-reserved characters to be %-escaped as part of the URI-template expansion, as in the example above.
</p>
<p>
- If the provenance described by the request does not exist in the server, a suitable error response code SHOULD be returned. In the absence of any security of privacy concerns about the resource, that might be <code>404 Not Found</code>. But if the existence or non-existence of a resource is considered private or sensitive, an authorization failure or other error response may be returned.
+ If the provenance described by the request is unknown to the server, a suitable error response code SHOULD be returned. In the absence of any security of privacy concerns about the resource, that might be <code>404 Not Found</code>. But if the existence or non-existence of a resource is considered private or sensitive, an authorization failure or other error response may be returned.
</p>
<p>
The direct HTTP query service may return provenance in any available format.
@@ -933,7 +933,7 @@
<section>
<h2>Provenance query service discovery</h2>
<p>
- Previously, <a href="#locating-provenance-records" class="sectionRef"></a> has described use of HTTP <code>Link:</code> header fields and HTML <code><link></code> elements to indicate provenance query services. Beyond that, this specification does not define any specific mechanism for discovering query services. Applications may use any appropriate mechanism, including but not limited to: prior configuration, search engines, service registries, etc.
+ Previously, <a href="#locating-provenance-records" class="sectionRef"></a> has described use of HTTP <code>Link:</code> header fields, HTML <code><link></code> elements and RDF statements to indicate provenance query services. Beyond that, this specification does not define any specific mechanism for discovering query services. Applications may use any appropriate mechanism, including but not limited to: prior configuration, search engines, service registries, etc.
</p>
<p>
To facilitate service discovery, we recommend that RDF publication of dataset and service descriptions use the property <code>prov:hasQueryService</code> and the provenance service type <code>prov:ServiceDescription</code> as appropriate (see the appendix <a href="#prov-namespace" class="sectionRef"></a>).
@@ -977,7 +977,7 @@
The ability to answer forward-looking questions requires some cooperation among the parties who use a resource; for example, a consumer could report use directly to the publisher, or a search engine could discover and report such downstream resource usage. To facilitate such cooperation, a publisher may implement a "ping-back" capability.
</p>
<p>
- A resource may have an associated "ping-back" URI which can be presented with PROV assertions about the resource. The ping-back URI is associated with a resource using mechanisms similar to those used for presenting a <a class="internalDFN">provenance-URI</a>, but using a <code>provPingback</code> link relation instead of <code>hasProvenance</code>. A consumer of the resource, or some other system, may perform an HTTP POST operation to the pingback URI where the POST request body contains provenance in one of the recognized provenance formats. For interoperability, a ping-back receiving service SHOULD be able to accept at least PROV-O provenance presented as RDF/XML or Turtle.
+ A resource may have an associated "ping-back" URI which can be presented with PROV assertions about the resource. The ping-back URI is associated with a resource using mechanisms similar to those used for presenting a <a class="internalDFN">provenance-URI</a>, but using a <code>pingback</code> link relation instead of <code>hasProvenance</code>. A consumer of the resource, or some other system, may perform an HTTP POST operation to the pingback URI where the POST request body contains provenance in one of the recognized provenance formats. For interoperability, a ping-back receiving service SHOULD be able to accept at least PROV-O provenance presented as RDF/XML or Turtle.
</p>
<p>
For example, consider a resource that is published by <code>acme.example.com</code>, and is subsequently used by <code>wile-e.example.org</code> in the construction of some new entity; we might see an exchange along the following lines. We start with wile-e.example.org retrieving a copy of acme.example.org's resource:
@@ -990,7 +990,7 @@
S: Link: <http://acme.example.org/provenance/super-widget>;
rel=http://www.w3.org/ns/prov#hasProvenance
S: Link: <http://acme.example.org/pingback/super-widget>;
- rel=http://www.w3.org/ns/prov#provPingback
+ rel=http://www.w3.org/ns/prov#pingback
:
(super-widget resource data)</pre>
<p>
@@ -1010,7 +1010,7 @@
rel=http://www.w3.org/ns/prov#hasProvenance;
anchor="http://acme.example.org/super-widget"
S: Link: <http://acme.example.org/pingback/super-widget>;
- rel=http://www.w3.org/ns/prov#provPingback;
+ rel=http://www.w3.org/ns/prov#pingback;
anchor="http://acme.example.org/super-widget"</pre>
<p class="TODO">
Details to change with Stian's proposal
@@ -1056,6 +1056,9 @@
The editors acknowledge the contribution and review from members of the W3C Provenance working group for their feedback throughout the development of this specification.
</p>
<p>
+ The provenance query service description and forward provenance specifications are substantially based on proposals by Stian Soiland-Reyes (University of Manchester).
+ </p>
+ <p>
Thanks to Robin Berjon for making our lives easier with his <a href="http://dev.w3.org/2009/dap/ReSpec.js/documentation.html" class="externalRef">ReSpec</a> tool.
</p>
</section>
@@ -1130,7 +1133,7 @@
<td><a href="#direct-http-query-service-description" class="sectionRef"></a></td>
</tr>
<tr style="vertical-align: top;">
- <td><code>provPingback</code></td>
+ <td><code>pingback</code></td>
<td>Relates a resource to a provenance pingback service that may receive provenance about the resource.</td>
<td><a href="#forward-provenance" class="sectionRef"></a></td>
</tr>
@@ -1142,7 +1145,7 @@
This is seen when one considers that a <code>prov:ServiceDescription</code> may have multiple query mechanisms associated with it (e.g. a <code>prov:DirectQueryService</code> <em>and</em> an <code>sd:Service</code>). Also, they serve quite different purposes in the process of using provenance query services: look for <code>prov:ServiceDescription</code> to discover query services of any kind, then for associated <code>prov:DirectQueryService</code> or <code>sd:Service</code> resources to get details of specific mechanisms to use to access the service.
</p>
<p class="TODO">
- review provPingback in light of Stian's proposal
+ review pingback in light of Stian's proposal
</p>
</section>