--- a/paq/releases/WD-prov-aq-20120619/prov-aq.html Wed Jun 13 14:51:43 2012 -0500
+++ b/paq/releases/WD-prov-aq-20120619/prov-aq.html Wed Jun 13 14:54:31 2012 -0500
@@ -479,7 +479,7 @@
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">target-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:
+ 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:</p>
<ul>
<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>
@@ -493,7 +493,6 @@
Ongoing work in the research community (e.g. <a href="http://eprints.ecs.soton.ac.uk/21587/">Why Linked Data is Not Enough for Scientists</a>, <a href="http://idpf.org/epub/30/spec/epub30-overview.html">ePub</a>, etc.) to encapsulate data, code, annotations and metadata into a common exchangeable format.
</li>
</ul>
- </p>
</section>
</section>
@@ -505,7 +504,7 @@
<p>
This section describes a REST-based protocol [[REST]] for provenance services with facilities for the retrieval of provenance information. The protocol specifies HTTP operations for retrieval of provenance information from a provenance service. It follows the approach of the SPARQL Graph Store HTTP Protocol [[SPARQL-HTTP]].
</p>
- <p>The introduction of this protocol is motivated by the following possible considerations:
+ <p>The introduction of this protocol is motivated by the following possible considerations: </p>
<ul>
<li>the naming authority associated with the <a class="internalDFN">target-URI</a> is not the same as the service offering provenance information</li>
<li>multiple services have <a class="internalDFN">provenance information</a> about the same resource</li>
@@ -513,7 +512,7 @@
<li>there is no dereferencable <a class="internalDFN">provenance-URI</a> containing provenance information for a particular resource</li>
<li>provenance services may provide additional extensibility points for control over returned provenance information.</li>
</ul>
- </p>
+
<section>
<h2>HTTP GET</h2>
@@ -522,8 +521,8 @@
GET /provenance/service?<b>target</b>=http://www.example.com/entity HTTP/1.1
Host: example.com</pre>
</p>
- <p>The embedded target-URI (<code>http://www.example.com/entity</code>) identifies the resource for which provenance information is to be returned. Any server that implements this protocol and receives a request URI in this form SHOULD return provenance information for the resource-URI embedded in the query component where that URI is the result of percent-decoding the value associated with the provenance-resource key. The embedded URI MUST be an absolute URI and the server MUST respond with a 400 Bad Request if it is not. If the supplied resource-URI includes a fragment identifier, the '#' MUST be %-encoded as <code>%23</code> when constructing the provenance-URI value; similarly, any '&' character in the resource-URI must be %-encoded as <code>%26</code>.
- </p>
+ <div>The embedded target-URI (<code>http://www.example.com/entity</code>) identifies the resource for which provenance information is to be returned. Any server that implements this protocol and receives a request URI in this form SHOULD return provenance information for the resource-URI embedded in the query component where that URI is the result of percent-decoding the value associated with the provenance-resource key. The embedded URI MUST be an absolute URI and the server MUST respond with a 400 Bad Request if it is not. If the supplied resource-URI includes a fragment identifier, the '#' MUST be %-encoded as <code>%23</code> when constructing the provenance-URI value; similarly, any '&' character in the resource-URI must be %-encoded as <code>%26</code>.
+ </div>
<p>If the provenance information identified in the request does not exist in the server, a 404 Not Found response code SHOULD be returned.
</p>
<p>The format of returned provenance information is not defined here, but may be established through content type negotiation using <code>Accept:</code> header fields in the HTTP request. A provenance service SHOULD be capable of returning RDF using the vocabulary defined by [[PROV-O]], in any standard RDF serialization (e.g. RDF/XML), or any other standard serialization of the Provenance Model specification [[PROV-DM]]. Services MUST identify the <code>Content-Type</code> of the information returned.
@@ -537,7 +536,7 @@
This specification does not define any specific mechanism for discovering provenance 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 service descriptions uses the provenance service type <code><provns/>ProvenanceService</code>, defined by the provenance ontology [[PROV-O]].
+ To facilitate service discovery, we recommend that RDF publication of service descriptions uses the provenance service type <code>prov:ProvenanceService</code>, defined by the provenance ontology [[PROV-O]].
The RDF service description example below in <a href="#provenance-service-description" class="sectionRef"></a> shows this use.
</p>
<p class="TODO">