--- a/paq/provenance-access-revised-service.html Thu Aug 11 11:30:45 2011 +0100
+++ b/paq/provenance-access-revised-service.html Thu Aug 11 12:21:49 2011 +0100
@@ -356,10 +356,7 @@
An earlier proposal was a simple HTTP-based service, with URI query parameters used in the construction of a specific URI for provenance information, and did not depend on a service description resource. Early but limited feedback suggested that an approach that does not prescribe URI formats (in line with REST style) would be preferable. Do other reviewers agree?
</p>
<p>
- Where provenance information is provided independently without coordination with the original resource delivery channels (e.g. by a third party), independent mechanisms for provenance discovery and/or retrieval are needed.
- </p>
- <p>
- This section describes a REST API [[REST-APIs]] for an independent provenance discovery and retrieval service.
+ This section describes a REST API [[REST-APIs]] for a provenance discovery and retrieval service, which can be implemented independently of the original resource delivery channels (e.g. by a third party service).
</p>
<p class="issue">
@@ -480,10 +477,10 @@
</p>
<p>
The examples below are for a target 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://example.info/qdata/</code>.
+ 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>.
</p>
- <p class="issue">
- Check [[URI-template]] spec to ensure the URI expansion here is correct.
+ <p class="note">
+ The template might use <code>?uri={+uri}</code> rather than just <code>?uri={uri}</code>, and thereby avoid %-escaping the <code>:</code> and <code>/</code> characters in the target resource URI, but this could cause difficulties for target URIs containing query parameters and/or fragment identifiers. In this case, the client application would need to ensure that any such characters were %-escaped <em>before</em> being passed into a URI-template expansion processor.
</p>
<section>
<h2>JSON example of provenance locations</h2>
@@ -550,17 +547,23 @@
<section>
<h2>Provenance information</h2>
<p>
- Provenance information about a resource or resources may be returned in any format allowed by the Provenance Model specification [[PROV-MODEL]], as available.
+ Provenance information about a resource or resources may be returned in any format. It is recommended that the format be one defined by the Provenance Model specification [[PROV-MODEL]].
</p>
<p>
Assuming a target resource URI <code>http://example.info/qdata/</code>, and
- using the service description example above, the provenance URI would be <code>http://example.info/provenance_service/provenance/?uri=http://example.info/qdata/</code>.
+ using the service description example above, the provenance URI would be <code>http://example.info/provenance_service/provenance/?uri=http%3A%2F%2Fexample.info%2Fqdata%2F</code>.
</p>
</section>
</section>
</section>
+
+
+
+<!-- ===================================================================================== -->
+
+
<section>
<h2>Querying provenance information</h2>
--- a/paq/provenance-access.html Thu Aug 11 11:30:45 2011 +0100
+++ b/paq/provenance-access.html Thu Aug 11 12:21:49 2011 +0100
@@ -22,10 +22,20 @@
"PRISM" : "International Digital Enterprise Alliance, Inc. <a href=\"http://www.prismstandard.org/specifications/2.0/PRISM_prism_namespace_2.0.pdf\"><cite>PRISM: Publishing Requirements for Industry Standard Metadata</cite></a>. February 2008. URL: <a href=\"http://www.prismstandard.org/specifications/2.0/PRISM_prism_namespace_2.0.pdf\">http://www.prismstandard.org/specifications/2.0/PRISM_prism_namespace_2.0.pdf</a>",
"FABIO" : "D. Shotton; S. Peroni. <a href=\"http://speroni.web.cs.unibo.it/cgi-bin/lode/req.py?req=http:/purl.org/spar/fabio#namespacedeclarations\"><cite>FaBiO, the FRBR-aligned Bibliographic Ontology.</cite></a> June 2011. URL: <a href=\"http://speroni.web.cs.unibo.it/cgi-bin/lode/req.py?req=http:/purl.org/spar/fabio#namespacedeclarations\">http://speroni.web.cs.unibo.it/cgi-bin/lode/req.py?req=http:/purl.org/spar/fabio#namespacedeclarations</a>",
"URI-template":
- "J. Gregorio; R. Fielding, ed.; M. Hadley; M. Nottingham."+
- "<a href=\"http://tools.ietf.org/html/draft-gregorio-uritemplate-05\"><cite>URI Template</cite></a>."+
- "July 2011, Work in progress."+
+ "J. Gregorio; R. Fielding, ed.; M. Hadley; M. Nottingham. "+
+ "<a href=\"http://tools.ietf.org/html/draft-gregorio-uritemplate-05\"><cite>URI Template</cite></a>. "+
+ "July 2011, Work in progress. "+
"URL: <a href=\"http://tools.ietf.org/html/draft-gregorio-uritemplate-05\"><cite>http://tools.ietf.org/html/draft-gregorio-uritemplate-05</cite></a>",
+ "REST-APIs":
+ "R. Fielding. "+
+ "<a href=\"http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven\">REST APIs must be hypertext driven</a>. "+
+ "October 2008 (blog post), "+
+ "URL: <a href=\"http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven\">http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven</a>",
+ "PROV-MODEL":
+ "L. Moreau; P. Missier. "+
+ "<a href=\"http://dvcs.w3.org/hg/prov/raw-file/tip/model/ProvenanceModel.html\"><cite>Provenance Model</cite></a>. "+
+ "2011, Work in progress. "+
+ "URL: <a href=\"http://dvcs.w3.org/hg/prov/raw-file/tip/model/ProvenanceModel.html\">http://dvcs.w3.org/hg/prov/raw-file/tip/model/ProvenanceModel.html</a>",
};
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
@@ -101,6 +111,10 @@
</script>
</head>
<body>
+
+
+<!-- ===================================================================================== -->
+
<section id='abstract'>
This document describes the use of existing mechanisms for accessing and querying provenance data about resources on the web.
</section>
@@ -143,6 +157,8 @@
</section>
</section>
+
+<!-- ===================================================================================== -->
<section>
<h2>Accessing provenance information</h2>
@@ -156,6 +172,8 @@
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>.
</p>
</section>
+
+<!-- ===================================================================================== -->
<section>
<h2>Locating provenance information</h2>
@@ -342,169 +360,223 @@
</section>
+<!-- ===================================================================================== -->
+
+
<section>
- <h2>Provenance discovery service</h2>
- <p class="issue">
- @@TODO: re-cast as a service description that defines how to construct a Provenance-URI. This should be properly RESTful, per <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven">http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven</a>
- </p>
+ <h2>Provenance discovery services</h2>
<p class="pending">
- Propose simple HTTP interface for discovery. cf <a href="http://www.w3.org/2011/prov/track/issues/53">ISSUE 53</a>
+ Propose simple HTTP interface for discovery. cf <a href="http://www.w3.org/2011/prov/track/issues/53">ISSUE 53</a>.
+ This should be properly RESTful, per <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven">http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven</a>. Have I properly interpreted the principles indicated here?
</p>
<p class="pending">
- <a href="http://www.w3.org/2011/prov/track/issues/53">ISSUE 53</a> suggests a simple REST protocol.
- The proposal here is not strictly RESTful (as I understand it), because it depends to some extent on dereferencing constructed URIs rather than simply using URIs that are provided by the discovery service. Do we care? The alternatives I can think of seem to be more complex without so much obvious practical advantage. The thrust of <a href="http://www.w3.org/2011/prov/track/issues/53">ISSUE 53</a> was to provide a <em>simple</em> service interface.
- </p>
- <p>
- <!-- The mechanisms for provenance discovery described above have all assumed the provenance URI is being supplied by the provider of the original resource. -->
- Where provenance information is provided independently without coordination with the original resource delivery channels (e.g. by a third party), independent mechanisms for provenance discovery are needed.
- </p>
- <p>
- The discovery mechanism described here focuses on finding the URI(s) for provenance information. Below, <a href="#querying-provenance-information" class="sectionRef"></a> will consider access to provenance information for which there is no separate URI.
- </p>
- <p class="issue">
- Do we want to consider a service that returns provenance information directly, using a similar interface? Using a separate service URI for this case was considered, but that seems to need yet another link relation.
- </p>
- <p>
- We assume that the requesting application has the Target-URI of a resource for which provenance information is required, and also has a URI for the provenance discovery service.
+ An earlier proposal was a simple HTTP-based service, with URI query parameters used in the construction of a specific URI for provenance information, and did not depend on a service description resource. Early but limited feedback suggested that an approach that does not prescribe URI formats (in line with REST style) would be preferable. Do other reviewers agree?
</p>
<p>
- A service based on a simple HTTP GET operation is used to retrieve the Provenance-URI(s) for a resource. In designing such a service, the main factors to consider are:
- <ul>
- <li>The construction of the HTTP request URI</li>
- <li>The content and format(s) of the expected response</li>
- <li>Possible outcomes and corresponding HTTP response status codes</li>
- </ul>
+ This section describes a REST API [[REST-APIs]] for a provenance discovery and retrieval service, which can be implemented independently of the original resource delivery channels (e.g. by a third party service).
</p>
- <p class="note">
- (The interface described here is based on that presented by <a href="http://sameas.org/about.php">SameAs.org</a>, which is also a service that essentially accepts a single URI as an input parameter, and returns a list of URIs.)
+
+ <p class="issue">
+ @@TODO: Review functions provided; review terminology use and property naming; review structure - move different format examples to a separate area?;
</p>
+
<section>
- <h2>Request URI</h2>
- <p>Given:
- <dl>
- <dt><code><cite>Service-URI</cite></code></dt>
- <dd>is the URI of the provenance discovery service.</dd>
- <dt><code><cite>Target-URI</cite></code></dt>
- <dd>is the Target-URI of the resource for which provenance information is required.</dd>
- <dt><code><cite>Content-type</cite></code></dt>
- <dd>is the desired MIME content-type of the result data.</dd>
- </dl>
- </p>
+ <h2>Using the provenance discovery API</h2>
<p>
- Then the request URI for provenance discovery may be constructed as one of:
+ This section describes general procedures for using the provenance discovery service API. Later sections describe the resources presented by the API, and their representations using RDF, Turtle and JSON. Normal HTTP content negotiation mechanisms may be used to retrieve representations formats convenient for the client application.
</p>
- <code>
- <pre class="pattern">
-<strong><cite>Service-URI</cite></strong>?uri=<strong><cite>Target-URI</cite></strong>
-<strong><cite>Service-URI</cite></strong>?uri=<strong><cite>Target-URI</cite></strong>&type=<strong><cite>Content-type</cite></strong></pre>
- </code>
- <p>
- For example, if the discovery service URI is <code>http://example.net/provenance-discovery</code> and the resource for which provenance information is required is identified as <code>http://example.info/qdata/</code>, then the request URI to use for provenance discovery would be:
+
+ <p class="issue">
+ Do we need/want both of the following cases?
</p>
- <pre class="example">
- <code>http://example.net/provenance-discovery?uri=http://example.info/qdata/</code>
- </pre>
- <p>
- Using the first form of request URI, the format of response data received may be determined by content negotiation using an HTTP <code>Accept:</code> header.
- The second form of request URI including the <code><strong><cite>Content-type</cite></strong></code> parameter requests results in the specified format without HTTP content negotiation.
- Thus, a request URI for retrieving JSON data without HTTP content negotiation may look like this:
- </p>
- <pre class="example">
-<code>http://example.net/provenance-discovery?uri=http://example.info/qdata/&type=application/json</code>
- </pre>
- <p class="pending">
- SameAs.org also provides URIs for directly accessing the different result formats without content negotiation, by appending an extra segment to the SameAs.org service URI. I'm reluctant to suggest this mechanism for a service with separately specified base URI, hence using the additional query parameter.
- </p>
+
+ <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 target resource (<code>target-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>Extract the <cite>provenance location template</cite> from the service description.</li>
+ <li>Use the provenance location template with <code>target-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>
+ </ol>
+ </p>
+ <p>
+ Any or all of URIs in the returned provenance locations may be used to retrieve provenance information, per <a href="#accessing-provenance-information" class="sectionRef"></a>.
+ </p>
+ </section>
+
+ <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>target-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>Extract the <cite>provenance information template</cite> from the service description.</li>
+ <li>Use the provenance information template with <code>target-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>
+ </ol>
+ </p>
+ </section>
+
</section>
+
<section>
- <h2>Response content and formats</h2>
- <p>If there is at least one Provenance-URI that the service is returning, a response with HTTP 200 status code is generated, along with one of the following response formats, determined by HTTP content negotiation (<code>Accept:</code> header).</p>
- <dl>
- <dt>application/json</dt>
- <dd>Returns one or more Provenance-URIs as part of a JSON structure [[RFC4627]], possibly including additional metadata:
+ <h2>Resources presented and representations used</h2>
+
+ <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.
+ </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>.
+ </p>
<code>
<pre class="example">
- [
- {
- "uri": "http://example.info/qdata/",
- "provenance": [
- "http://source1.example.info/provenance/qdata/",
- "http://source2.example.info/prov/qdata/",
- "http://source3.example.com/prov?id=qdata"
- ]
- }
- ]
+ {
+ "provenance_service_uri": "http://example.info/provenance_service/",
+ "location_template": "http://example.info/provenance_service/location/?uri={uri}",
+ "provenance_template": "http://example.info/provenance_service/provenance/?uri={uri}",
+ }
</pre>
</code>
- </dd>
- <dt>application/rdf+xml</dt>
- <dd>Returns an RDF graph with one or more Provenance-URIs associated with the original resource,
- presented as an RDF/XML document [[RDF-SYNTAX-GRAMMAR]].
- The vocabulary used is the same as that used when a resource presented as RDF contains references
- to its own provenance information, per <a href="#target-presented-as-rdf" class="sectionRef"></a>.
+ </section>
+ <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>.
+ </p>
+ <code>
+ <pre class="example">
+ @prefix provds: <http://www.w3.org/2011/provenance_discovery/@@TBD@@#> .
+ <http://example.info/provenance_service/> a provds:Service_description ;
+ provds:provenance_service_uri <http://example.info/provenance_service/> ;
+ provds:location_template "http://example.info/provenance_service/location/?uri={uri}" ;
+ provds:provenance_template "http://example.info/provenance_service/provenance/?uri={uri}" ;
+ .
+ </pre>
+ </code>
+ <p class="note">
+ 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.
+ </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>
<code>
<pre class="example">
<rdf:RDF
- xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#"
- xmlns:prov = "http://www.w3.org/@@TBD@@#"
+ xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#"
+ xmlns:provds = "http://www.w3.org/2011/provenance_discovery/@@TBD@@#"
>
- <rdf:Description rdf:about="http://example.info/qdata/">
- <prov:hasProvenance rdf:resource="http://source1.example.info/provenance/qdata/" />
- <prov:hasProvenance rdf:resource="http://source2.example.info/prov/qdata/" />
- <prov:hasProvenance rdf:resource="http://source3.example.com/prov?id=qdata" />
- </rdf:Description>
+ <provds:Service_description rdf:about="http://example.info/provenance_service/">
+ <provds:provenance_service_uri rdf:resource="http://example.info/provenance_service/" /> ;
+ <provds:location_template>http://example.info/provenance_service/location/?uri={uri}</provds:location_template> ;
+ <provds:provenance_template>http://example.info/provenance_service/provenance/?uri={uri}</provds:provenance_template> ;
+ </provds:Service_description>
</rdf:RDF>
</pre>
</code>
- </dd>
- <dt>text/turtle</dt>
- <dd>
- Returns an RDF graph with one or more Provenance-URIs associated with the original resource,
- presented as a Turtle or N3 document [[TURTLE]]:
+ </section>
+ </section>
+
+ <section>
+ <h2>Provenance locations</h2>
+ <p>
+ A resource that enumerates one or more Provenance-URIs associated with a target resource.
+ </p>
+ <p>
+ The examples below are for a target 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>.
+ </p>
+ <p class="note">
+ The template might use <code>?uri={+uri}</code> rather than just <code>?uri={uri}</code>, and thereby avoid %-escaping the <code>:</code> and <code>/</code> characters in the target resource URI, but this could cause difficulties for target URIs containing query parameters and/or fragment identifiers. In this case, the client application would need to ensure that any such characters were %-escaped <em>before</em> being passed into a URI-template expansion processor.
+ </p>
+ <section>
+ <h2>JSON example of provenance locations</h2>
+ <p>
+ This example uses JSON format [[RFC4627]], presented using MIME content type <code>application/json</code>.
+ </p>
<code>
<pre class="example">
- @prefix prov: <http://www.w3.org/@@TBD@@#> .
-
- <http://example.info/qdata/>
- prov:hasProvenance
- <http://source1.example.info/provenance/qdata/> ,
- <http://source2.example.info/prov/qdata/> ,
- <http://source3.example.com/prov?id=qdata>
- .
+ {
+ "target_uri": "http://example.info/qdata/",
+ "provenance": [
+ "http://source1.example.info/provenance/qdata/",
+ "http://source2.example.info/prov/qdata/",
+ "http://source3.example.com/prov?id=qdata"
+ ]
+ }
</pre>
</code>
- </dd>
- <dt>text/plain</dt>
- <dd>
- Returns a simple text file containing just a list of Provenance-URIs, one per line. (The original resource URI is not included in the result data.;)
+ </section>
+ <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>.
+ </p>
<code>
<pre class="example">
- http://source1.example.info/provenance/qdata/
- http://source2.example.info/prov/qdata/
- http://source3.example.com/prov?id=qdata
+ @prefix prov: <http://www.w3.org/2011/provenance/@@TBD@@#> .
+ <http://example.info/qdata/> a prov:Entity ;
+ prov:hasProvenance <http://source1.example.info/provenance/qdata/> ;
+ prov:hasProvenance <http://source2.example.info/prov/qdata/> ;
+ prov:hasProvenance <http://source3.example.com/prov?id=qdata>
+ .
</pre>
</code>
- </dd>
- </dl>
- </section>
- <section>
- <h2>Response codes</h2>
- <p>
- <dl>
- <dt><code>200 OK</code></dt>
- <dd>Provenance URI(s) returned; see above.</dd>
- <dt><code>204 No content</code></dt>
- <dd>The request was valid, but the server is returning no Provenance-URIs (either because no Provenance-URIs are known, or possibly because provision of provenance is restricted for policy reasons. The entity body part of the HTTP response message MUST be empty [[HTTP11]].</dd>
- <!--
- <dt><code>...</code></dt>
- <dd>...</dd>
- -->
- </dl>
- </p>
+ <p class="issue">
+ NOTE: The namespace URI used here for the provenance properties is different from that used in the service description. I am anticipating that it will be defined as part of the provenance model. If it is not defined as part of the provenance model, then a property name should be allocated in the provenance discovery service namespace.
+ </p>
+ <p class="issue">@@TODO: revise to conform with Provenance Model vocabulary</p>
+ </section>
+ <section>
+ <h2>RDF/XML example of provenance locations</h2>
+ <p>
+ This is essentially the same as the Turtle example above, but encoded in RDF/XML [[RDF-SYNTAX-GRAMMAR]], and presented with MIME content type <code>application/rdf+xml</code>.
+ </p>
+ <code>
+ <pre class="example">
+ <rdf:RDF
+ xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#"
+ xmlns:prov = "http://www.w3.org/2011/provenance/@@TBD@@#"
+ >
+ <prov:Entity rdf:about="http://example.info/qdata/">
+ <prov:hasProvenance rdf:resource="http://source1.example.info/provenance/qdata/" /> ;
+ <prov:hasProvenance rdf:resource="http://source2.example.info/prov/qdata/" /> ;
+ <prov:hasProvenance rdf:resource="http://source3.example.com/prov?id=qdata" /> ;
+ </prov:Entity>
+ </rdf:RDF>
+ </pre>
+ </code>
+ <p class="issue">@@TODO: revise to conform with Provenance Model vocabulary</p>
+ </section>
+ </section>
+
+ <section>
+ <h2>Provenance information</h2>
+ <p>
+ Provenance information about a resource or resources may be returned in any format. It is recommended that the format be one defined by the Provenance Model specification [[PROV-MODEL]].
+ </p>
+ <p>
+ Assuming a target resource URI <code>http://example.info/qdata/</code>, and
+ using the service description example above, the provenance URI would be <code>http://example.info/provenance_service/provenance/?uri=http%3A%2F%2Fexample.info%2Fqdata%2F</code>.
+ </p>
+ </section>
+
</section>
</section>
+
+<!-- ===================================================================================== -->
<section>
<h2>Querying provenance information</h2>
@@ -598,6 +670,8 @@
</section>
</section>
+
+<!-- ===================================================================================== -->
<!-- <section class="informative"> -->
<section>
@@ -609,6 +683,8 @@
@@TODO
</p>
</section>
+
+<!-- ===================================================================================== -->
<section>
<h2>IANA considerations</h2>
@@ -672,6 +748,8 @@
</p>
</section>
</section>
+
+<!-- ===================================================================================== -->
<section>
<h2>Security considerations</h2>
@@ -691,6 +769,8 @@
@@TODO ... more, probably
</p>
</section>
+
+<!-- ===================================================================================== -->
<section class='appendix'>
<h2>Acknowledgements</h2>
@@ -698,6 +778,9 @@
Many thanks to Robin Berjon for making our lives so much easier with his cool <a href="http://dev.w3.org/2009/dap/ReSpec.js/documentation.html">ReSpec</a> tool.
</p>
</section>
+
+<!-- ===================================================================================== -->
+
<section class="appendix">
<h2>Motivating scenario</h2>
<p class="pending">