--- a/paq/provenance-access.html Tue Aug 09 15:47:01 2011 +0200
+++ b/paq/provenance-access.html Tue Aug 09 17:28:35 2011 +0100
@@ -21,6 +21,11 @@
"RFC3297" : "G. Klyne; R. Iwazaki; D. Crocker. <a href=\"http://www.ietf.org/rfc/rfc3297.txt\"><cite>Content Negotiation for Messaging Services based on Email.</cite></a> July 2002. Internet RFC 3297. URL: <a href=\"http://www.ietf.org/rfc/rfc3297.txt\">http://www.ietf.org/rfc/rfc3297.txt</a>",
"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."+
+ "URL: <a href=\"http://tools.ietf.org/html/draft-gregorio-uritemplate-05\"><cite>http://tools.ietf.org/html/draft-gregorio-uritemplate-05</cite></a>",
};
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
@@ -103,60 +108,66 @@
<section>
<h2>Introduction</h2>
<p>
- @@TODO
+ @@TODO Introductory text
</p>
<h2>Concepts</h2>
- In defining the specification below, we make use of the following concepts.
- <ul>
- <li> Provenance information - refers to provenance represented in some fashion.</li>
- <li> The URI identifying provenance</li>
- <li> Target - the entity that one wants to know the provenance of. </li>
- <li> Target-URI - the URI of a target, which allows the target to be found in some provenance information</li>
- <li> Provenance Service: A service that provides provenance information for a Target given a Target-URI </li>
- <li> Service-URI: A URI of a Provenance Service.
- <li> Resource: a web resource. A resource may have multiple associated targets</li>
- </ul>
+ <p>
+ In defining the specification below, we make use of the following concepts.
+ <dl>
+ <dt>Provenance information</dt>
+ <dd>refers to provenance represented in some fashion.</dd>
+ <dt>Provenenance-URI</dt>
+ <dd>A URI denoting some provenance information.</dd>
+ <dt>Target</dt>
+ <dd>an entity about which one wants to know the provenance.</dd>
+ <dt>Target-URI</dt>
+ <dd>a URI denoting a target, which allows the target to be found in some provenance information.</dd>
+ <dt>Provenance service</dt>
+ <dd>a service that provides a Provenance-URI or provenance information given a Target-URI.</dd>
+ <dt>Service-URI</dt>
+ <dd>the URI of a Provenance Service.</dd>
+ <dt>Resource</dt>
+ <dd>a web resource. A resource may be associated with multiple targets, which may correspond to different IVPs of the original resource.</dd>
+ </dl>
+ </p>
+
+ <p class="issue">
+ Say something about resources and targets and IVP. Probably needs to refer to the model document discussion of IVP. Roughly, "target" is an IVP of some web resource (which may just be the resource itself. Also discuss that provenance information is expected to be static: it is only meaningful to the extent that is is always true for the designated target. Example provenance about weather in London at http://www.metoffice.gov.uk/weather/uk/se/london_forecast_weather.html might reasonably say that it is published by the Met Office. But a claim that "Updated: 1641 on Tue 9 Aug 2011" would be true only for an IVP of that resource in a constrained time window.
+ </p>
</section>
<section>
- <h2>Accessing provenance data</h2>
+ <h2>Accessing provenance information</h2>
<p>
A general expectation is that web applications may access provenance information in the same way as any web resource, by dereferencing its URI. Typically, this will be by performing an HTTP GET operation. Thus, any provenance information may be associated with a URI, and may be accessed by dereferencing that URI using normal web mechanisms.
</p>
<p>
- The problem of accessing some required provenance information then reduces to the problem of finding its URI, which is dealt with separately in section <a href="#locating-provenance" class="sectionRef"></a>.
+ This specification thus RECOMMENDS that if a publisher wishes to make provenance information available, it is published as a normal web resource, and provision is made for the Provenance-URI to be discoverable using one or more of the mechanisms described later in <a href="#locating-provenance-information" class="sectionRef"></a>.
</p>
<p>
- This specification thus RECOMMENDS that if a publisher wishes to make provenance information available, it is published as a normal web resource, and provision is made for the URI of the provenance to be discoverable.
- </p>
- <p>
- This presumption of using web retrieval to access provenance does not preclude use of other mechanisms. In particular, alternative mechanisms may be needed if there is no URI associated with some particular provenance data. One such mechanism is suggested in <a href="#querying-provenance-data" class="sectionRef"></a>.
+ 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</h2>
+ <h2>Locating provenance information</h2>
<p>
- On the presumption that provenance data is a resource that can be accessed using normal web retrieval, one needs to know a URI to dereference. The provenance URI may be known in advance, in which case there is nothing more to specify. If the provenance URI is not known, then a mechanism to discover a provenance URI must be based on some information that is available to the would-be accessor. We also wish to allow that provenance information could be provided by parties other than the provider of the original resource. Indeed, provenance data for a resource may be provided by several different parties, at different URIs, each with different concerns. (It is quite possible that contradictory provenance may be provided by different parties.)
+ On the presumption that provenance information is a resource that can be accessed using normal web retrieval, one needs to know a Provenance-URI to dereference. The Provenance-URI may be known in advance, in which case there is nothing more to specify. If a Provenance-URI is not known, then a mechanism to discover one must be based on some information that is available to the would-be accessor. We also wish to allow that provenance information could be provided by parties other than the provider of the original resource. Indeed, provenance information for a resource may be provided by several different parties, at different URIs, each with different concerns. It is quite possible that different parties may provide contradictory provenance information.
</p>
<p>
- We start by considering mechanisms for the resource provider to also indicate a provenance URI referring to the provenance of a provided or indicated resource. Because the resource provider controls the response when the resource is accessed, this allows for direct indication of a provenance URI. Three mechanisms are described here:
+ We start by considering mechanisms for the resource provider to also indicate a Provenance-URI for a provided or indicated target. Because the resource provider controls the response when the target is accessed, direct indication of a Provenance-URI is possible. Three mechanisms are described here:
<ul>
- <li>The requester knows the resource URI <em>and</em> the resource is accessed using HTTP</li>
- <li>The requester has a copy of a resource presented as HTML or XHTML</li>
- <li>The requester has a copy of a resource presented as RDF (including the range of possible RDF syntaxes, such as HTML with embedded RDFa)</li>
+ <li>The requester knows the Target-URI <em>and</em> the target is accessed using HTTP</li>
+ <li>The requester has a copy of a target presented as HTML or XHTML</li>
+ <li>The requester has a copy of a target presented as RDF (including the range of possible RDF syntaxes, such as HTML with embedded RDFa)</li>
</ul>
- These particular cases are selected as corresponding to primary current web protocol and data formats.
- </p>
-
- <p class="issue">
- The proposals so far assume the URI of the original resource. This may not always be the case (e.g. a file received by means other than web transfer), and it is desirable to have mechanisms to convey the origibnal resource URI as well as any provenance URIs. See <a href="http://www.w3.org/2011/prov/track/issues/46">ISSUE 46</a>.
+ These particular cases are selected as corresponding to primary current web protocol and data formats. Finally, in <a href="#arbitrary-target" class="sectionRef"></a>, we discuss the case of an target in an unspecified format which has been provided by some means other than HTTP.
</p>
<section>
- <h2>Resource accessed by HTTP</h2>
+ <h2>Target accessed by HTTP</h2>
<p>
For a document accessible using HTTP, POWDER [[POWDER-DR]] describes <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#httplink">a mechanism</a> for associating metadata with a resource using an HTTP <code>Link</code> header field. The <code>Link</code> header field is included in the HTTP response to a GET or HEAD operation (other HTTP operations are not excluded, but are not considered here). Since the POWDER specification was published, the HTTP linking draft has been approved by the IETF as <a href="http://tools.ietf.org/html/rfc5988">RFC 5988</a> [[LINK-REL]].
</p>
@@ -181,7 +192,10 @@
</section>
<section>
- <h2>Resource presented as HTML</h2>
+ <h2>Target presented as HTML</h2>
+ <p class="pending">
+ Addresses <a href="http://www.w3.org/2011/prov/track/issues/46">ISSUE 46</a> with target link-relation.
+ </p>
<p>
For a document presented as HTML or XHTML, without regard for how it has been obtained, POWDER [[POWDER-DR]] describes <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#assoc-markup">a mechanism</a> for associating metadata with a resource by adding a <code><Link></code> element to the HTML <code><head></code> section.
</p>
@@ -194,7 +208,7 @@
<meta name="wdr.issuedby" content="http://authority.example.org/company.rdf#me"/>
<link rel="provenance" href="<cite>provenance-URI</cite>">
<link rel="target" href="<cite>target-URI</cite>">
- <title>Welcome to example.com </title>
+ <title>Welcome to example.com</title>
</head>
<body>
...
@@ -202,7 +216,7 @@
</html>
</pre>
</code>
- The first link element provenanceidentifies the URI of provenance information for the document where the <code><cite>target-URI</cite></code> given by the target link element specifies identifier of the document within the provenance information.
+ The <code><cite>provenance-URI</cite></code> given by the <code>provenance</code> link element identifies the Provenance-URI for the document where the <code><cite>target-URI</cite></code> given by the <code>target</code> link element specifies identifier of the presented document view, and which is used within the provenance information when referring to this document.
</p>
<p>
An HTML document header MAY include multiple provenance link elements, indicating a number of different resources that are known to the creator of the document, each providing provenance about the document.
@@ -213,31 +227,38 @@
<p>
If no target link element is provided then the <code><cite>target-URI</cite></code> is assumed to be the URI of the document. It is RECOMMENDED that this only be done when the document is static.
</p>
-
- <h4> Specifying Provenance Services </h4>
- <p class="pending">
- This is a new proposal. It needs to be checked as to whether it is useful.
- </p>
- <p>
- The document creator may specify that the provenance information about the document is provided by a provenance service. This is done through the use of a third link relation type following the same pattern as above:
- </p>
- <code>
- <pre class="pattern">
+
+ <section>
+ <h2>Specifying Provenance Services</h2>
+ <p class="pending">
+ This is a new proposal. It needs to be checked as to whether it is useful. GK/PG to review nature of provenance-service-URI.
+ </p>
+ <p>
+ The document creator may specify that the provenance information about the document is provided by a provenance service. This is done through the use of a third link relation type following the same pattern as above:
+ </p>
+ <code>
+ <pre class="pattern">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="wdr.issuedby" content="http://authority.example.org/company.rdf#me"/>
<link rel="provenance-service" href="<cite>provenance-service-URI</cite>">
- <title>Welcome to example.com </title>
+ <link rel="target" href="<cite>target-URI</cite>">
+ <title>Welcome to example.com</title>
</head>
<body>
...
</body>
</html>
- </pre>
- </code>
- <p> The provenance-service link element identifies both the service and the target using one URI. The <code><cite>provenance-service-uri</cite></code> follows the form of <a href="#request-uri" class="sectionRef"></a>. There may be multiple provenance-service link elements. provenance service link elements may appear in the same document as target and provenance linke elements.
+ </pre>
+ </code>
+ <p>
+ The <code>provenance-service</code> link element identifies the service URI. Dereferencing this URI yields a service description that provides further information to enable a client to determine a Provenance-URI for a target; see <a href="#provenance-discovery-service" class="sectionRef"></a> for more details.
+ There may be multiple <code>provenance-service</code> link elements, and these MAY appear in the same document as <code>target</code> and <code>provenance</code> link elements (though, in practice, there may be little point in providing both <code>provenance</code> and <code>provenance-service</code> links).
+ </p>
+ </section>
+ <p class="issue">
+ Is this next paragraph useful? It seems out of place here: I'm not sure what it is intended to clarify. #g
</p>
-
<p>
See in particular <a href="http://tools.ietf.org/html/rfc5988#appendix-A">Appendix A. Notes on Using the Link Header with the HTML4 Format</a> of RFC5988 for further notes about using link relation types in HTML.
</p>
@@ -250,12 +271,21 @@
</section>
<section>
- <h2>Resource presented as RDF</h2>
+ <h2>Target presented as RDF</h2>
+ <p class="pending">
+ Addresses <a href="http://www.w3.org/2011/prov/track/issues/46">ISSUE 46</a> ???.
+ </p>
<p>
If a resource is presented as RDF (in any of its recognized syntaxes, including RDFa), it may contain references to its own provenance using additional RDF statements.
</p>
<p>
- For this purpose a new RDF property, <code>prov:hasProvenance</code>, is defined as a relation between two resources, where the object of the property is a resource that provides provenance data about the subject resource. Multiple <code>prov:hasProvenance</code> assertions may be made about a subject resource.
+ For this purpose a new RDF property, <code>prov:hasProvenance</code>, is defined as a relation between two resources, where the object of the property is a resource that provides provenance information about the subject resource. Multiple <code>prov:hasProvenance</code> assertions may be made about a subject resource.
+ </p>
+ <p>
+ Another new RDF property, <code>prov:hasTarget</code>, is defined to allow the RDF content to specify one or more target-URIs of the RDF document for the purpose of provenance information (similar to the use of the target link relation in HTML).
+ </p>
+ <p class="issue">
+ @@TODO: needs to be completed.
</p>
<p>
@@TODO: example
@@ -268,7 +298,10 @@
</section>
<section>
- <h2>Independent provenance discovery services</h2>
+ <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 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven.
+ </p>
<p class="pending">
Propose simple HTTP interface for discovery. cf <a href="http://www.w3.org/2011/prov/track/issues/53">ISSUE 53</a>
</p>
@@ -281,13 +314,16 @@
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" class="sectionRef"></a> will consider access to provenance for which there is no separate URI.
+ 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 URI of a resource for which provenance is required, and also has a URI for an independent provenance discovery service.
+ 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.
</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:
+ 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>
@@ -304,7 +340,7 @@
<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 URI of the resource for which provenance is required.</dd>
+ <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>
@@ -318,7 +354,7 @@
<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 is required is identified as <code>http://example.info/qdata/</code>, then the request URI to use for provenance discovery would be:
+ 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>
<pre class="example">
<code>http://example.net/provenance-discovery?uri=http://example.info/qdata/</code>
@@ -337,16 +373,15 @@
</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>
+ <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:
+ <dd>Returns one or more Provenance-URIs as part of a JSON structure [[RFC4627]], possibly including additional metadata:
<code>
<pre class="example">
[
{
"uri": "http://example.info/qdata/",
- "numProvenance": "3",
"provenance": [
"http://source1.example.info/provenance/qdata/",
"http://source2.example.info/prov/qdata/",
@@ -358,10 +393,10 @@
</code>
</dd>
<dt>application/rdf+xml</dt>
- <dd>Returns an RDF graph with one or more provenance URIs associated with the original resource,
+ <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, per <a href="#resource-presented-as-rdf" class="sectionRef"></a>.
+ to its own provenance information, per <a href="#target-presented-as-rdf" class="sectionRef"></a>.
<code>
<pre class="example">
<rdf:RDF
@@ -380,7 +415,7 @@
</dd>
<dt>text/turtle</dt>
<dd>
- Returns an RDF graph with one or more provenance URIs associated with the original resource,
+ Returns an RDF graph with one or more Provenance-URIs associated with the original resource,
presented as a Turtle or N3 document [[TURTLE]]:
<code>
<pre class="example">
@@ -397,7 +432,7 @@
</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.;)
+ 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.;)
<code>
<pre class="example">
http://source1.example.info/provenance/qdata/
@@ -415,7 +450,7 @@
<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>
+ <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>
@@ -427,34 +462,34 @@
</section>
<section>
- <h2>Querying provenance</h2>
+ <h2>Querying provenance information</h2>
<p class="pending">
This section proposes use of SPARQL queries to address requirements that are not covered by the simple retrieval and discovery services proposed above.
</p>
<p>
- There are circumstances where simply identifying and retrieving provenance as a web resource may not best fit the requirements of a particular application or service, e.g.:
+ There are circumstances where simply identifying and retrieving provenance information as a web resource may not best fit the requirements of a particular application or service, e.g.:
<ul>
- <li>the entity for which provenance is required is not identified by a known URI</li>
- <li>the provenance for an entity is not directly identified by a known URI</li>
- <li>provenance for an entity is sufficiently large or complex that it is not desirable or useful to retrieve it all in a single operation</li>
- <li>provenance for a number of distinct but related entities is required to be accessed in a single atomic operation</li>
+ <li>the entity for which provenance information is required is not identified by a known URI</li>
+ <li>the provenance information for an entity is not directly identified by a known URI</li>
+ <li>provenance information for an entity is sufficiently large or complex that it is not desirable or useful to retrieve it all in a single operation</li>
+ <li>provenance information for a number of distinct but related entities is required to be accessed in a single atomic operation</li>
<li><i>etc.</i></li>
</ul>
</p>
<p>
- For such circumstances, a provenance query service provides an alternative way to access provenance and/or provenance URIs.
+ For such circumstances, a provenance query service provides an alternative way to access provenance information and/or Provenance-URIs.
</p>
<p>
- We assume that the requesting application has the URI of a provenance query service, and some information about the resource for which provenance is required that can be used as the basis for a query. A query service is potentially a very general capability that can, in principle, subsume the provenance discovery service described in <a href="#independent-provenance-discovery-services" class="sectionRef"></a>.
+ We assume that the requesting application has the URI of a provenance query service, and some information about the resource for which provenance information is required that can be used as the basis for a query. A query service is potentially a very general capability that can, in principle, subsume the provenance discovery service described in <a href="#provenance-discovery-service" class="sectionRef"></a>, but which may be more complex to deploy and use for simple provenance discovery cases..
</p>
<p>
The details of a provenance query service is an implementation choice, to be agreed between provider and users of the service, but for ease of interoperability between different providers and users we recommend use of SPARQL [[RDF-SPARQL-PROTOCOL]] [[RDF-SPARQL-QUERY]]. The query service URI would then be the URI of a SPARQL endpoint (or, to use the SPARQL specification language, a <a href="http://www.w3.org/TR/rdf-sparql-protocol/#conformant-sparql-protocol-service">SPARQL protocol service</a>). A query service can potentially be used in many different ways, limited only by the available information and capabilities of theSPARQL query language; the following subsections provide examples for what are considered to be some plausible common scenarios.
</p>
<section>
- <h2>Find provenance URI given URI of resource</h2>
+ <h2>Find Provenance-URI given Target-URI of resource</h2>
<p>
- If the requester has a URI for the original resource, they might simply issue a simple SPARQL query for the URI(s) of any associated provenance data; e.g., if the original resource has URI <code>http://example.org/resource</code>,
+ If the requester has a Target-URI for the original resource, they might simply issue a simple SPARQL query for the URI(s) of any associated provenance information; e.g., if the original resource has URI <code>http://example.org/resource</code>,
<code>
<pre class="example">
@prefix prov: <@@TBD>
@@ -471,9 +506,9 @@
</section>
<section>
- <h2>Find provenance URI given identifying information about a resource</h2>
+ <h2>Find Provenance-URI given identifying information about a resource</h2>
<p>
- If the requester has identifying information that is not the URI of the original resource, then they will need to construct a more elaborate query to locate the target resource and obtain its provenance URI(s). The nature of identifying information that can be used in this way will depend upon the third party service used, further definition of which is out of scope for this specification. For example, a query for a document identified by a DOI, say <code>1234.5678</code>, using the PRISM vocabulary [[PRISM]] recommended by FaBio [[FABIO]], might look like this:
+ If the requester has identifying information that is not the URI of the original resource, then they will need to construct a more elaborate query to locate the target resource and obtain its Provenance-URI(s). The nature of identifying information that can be used in this way will depend upon the third party service used, further definition of which is out of scope for this specification. For example, a query for a document identified by a DOI, say <code>1234.5678</code>, using the PRISM vocabulary [[PRISM]] recommended by FaBio [[FABIO]], might look like this:
<code>
<pre class="example">
@prefix prov: <@@TBD>
@@ -491,12 +526,12 @@
</section>
<section>
- <h2>Obtain provenance directly given URI of a resource</h2>
+ <h2>Obtain provenance information directly given Target-URI of a resource</h2>
<p>
- This scenario retrieves provenance directly given the URI of a resource, and may be useful where the provenance has not been assigned a specific URI, or when the calling application is interested only in specific elements of provenance.
+ This scenario retrieves provenance information directly given the URI of a resource, and may be useful where the provenance information has not been assigned a specific URI, or when the calling application is interested only in specific elements of provenance information.
</p>
<p>
- If the original resource has URI <code>http://example.org/resource</code>, a SPARQL query for provenance might look like this:
+ If the original resource has URI <code>http://example.org/resource</code>, a SPARQL query for provenance information might look like this:
<code>
<pre class="example">
@prefix prov: <@@TBD>
@@ -510,10 +545,10 @@
}
</pre>
</code>
- This query essentially extracts all available properties and values available from the query service used that are directly about the specified resource, and returns them as an RDFG graph. This may be fine if the service contains <em>only</em> provenance about the resource, or if the non-provenance information is also of interest. A more complex query using specific provenance vocabulary terms may be needed to selectively retrieve just provenance information when other kinds might be available.
+ This query essentially extracts all available properties and values available from the query service used that are directly about the specified resource, and returns them as an RDFG graph. This may be fine if the service contains <em>only</em> provenance information about the indicated resource, or if the non-provenance information is also of interest. A more complex query using specific provenance vocabulary terms may be needed to selectively retrieve just provenance information when other kinds of information are also available.
</p>
<p class="issue">
- @@TODO: specific provenance namespace and property to be determined by the model specification? The above query pattern assumes provenance is included in direct properties about the target resource. When an RDF vocabulary is formulated provenance, this may well turn out to not be the case. A better example would probably be one that retrieves specific provenance when the vocabulary terms have been defined.
+ @@TODO: specific provenance namespace and property to be determined by the model specification? The above query pattern assumes provenance information is included in direct properties about the target resource. When an RDF provenance vocabulary is formulated, this may well turn out to not be the case. A better example would probably be one that retrieves specific provenance information when the vocabulary terms have been defined.
</p>
</section>
@@ -532,32 +567,65 @@
<section>
<h2>IANA considerations</h2>
- <p>This document requests registration of "provenance" link relation, per <a href="http://tools.ietf.org/html/rfc5988#section-6.2.1">section-6.2.1 of RFC 5988</a>. @@TODO At an appropriate time (??), the following template should be submitted to link-relations@ietf.org:
+ <p>This document requests registration of new link relations, per <a href="http://tools.ietf.org/html/rfc5988#section-6.2.1">section-6.2.1 of RFC 5988</a>. @@TODO At an appropriate time (??), the following templates should be submitted to link-relations@ietf.org:
</p>
- <p>
- <dl>
- <dt>Relation Name:</dt>
- <dd>
- <code>provenance</code>
- </dd>
- <dt>Description:</dt>
- <dd>
- the resource identified by target URI of the link provides provenance about the resource identified by the context link
- </dd>
- <dt>Reference:</dt>
- <dd>
- @@this spec, @@provenance-model-spec
- </dd>
- <dt>Notes:</dt>
- <dd>
- ...
- </dd>
- <dt>Application Data:</dt>
- <dd>
- ...
- </dd>
- </dl>
- </p>
+ <section>
+ <h2>Registration template for link relation: "provenance"</h2>
+ <p>
+ <dl>
+ <dt>Relation Name:</dt>
+ <dd>
+ <code>provenance</code>
+ </dd>
+ <dt>Description:</dt>
+ <dd>
+ the resource identified by target URI of the link provides provenance information about the resource identified by the context link
+ </dd>
+ <dt>Reference:</dt>
+ <dd>
+ @@this spec, @@provenance-model-spec
+ </dd>
+ <dt>Notes:</dt>
+ <dd>
+ ...
+ </dd>
+ <dt>Application Data:</dt>
+ <dd>
+ ...
+ </dd>
+ </dl>
+ </p>
+ </section>
+ <section>
+ <h2>Registration template for link relation: "target"</h2>
+ <p class="target">
+ The name "target" is unfortunate, as it has specific meaning in the context of a link relation (I think). Reconsider?
+ </p>
+ <p>
+ <dl>
+ <dt>Relation Name:</dt>
+ <dd>
+ <code>target</code>
+ </dd>
+ <dt>Description:</dt>
+ <dd>
+ the resource identified by target URI of the link is one for which provenance information is provided. This may be used, for example, to extract relevant information from a referenced document that contains provenance information for several targets.
+ </dd>
+ <dt>Reference:</dt>
+ <dd>
+ @@this spec, @@provenance-model-spec
+ </dd>
+ <dt>Notes:</dt>
+ <dd>
+ ...
+ </dd>
+ <dt>Application Data:</dt>
+ <dd>
+ ...
+ </dd>
+ </dl>
+ </p>
+ </section>
</section>
<section>
@@ -598,7 +666,7 @@
<li>D1, D2: use the HTTP <code>Link:</code> header. Any server providing the document may provide this information. Different servers might offer links to different provenance sources.</li>
<li>D3: information provided as an image with a known URI, but from a non-provenance-aware source. The image URI can be used as a key to access a third party provenance discovery service.
<li>D4, D6, D7, D8: information provided as an image, without a known web location. At the very least, some mechanism, not specified here, is needed to identify the image provided. In the case of an email attachment, it is possible (but not guaranteed) that the email message MIME wrapper specifies a URI for the image, which can be used as a key. Some image formats support embedded metadata which might be used for this purpose. <em>(Arbitrary data files could be wrapped in a package, say MIME multipart/related [[RFC2387]], that could include additional metadata. Image files could be wrapped in a minimal HTML document. It is not clear to me at this stage that a single mechanism is appropriate for all situations)</em>.</li>
- <li>D5: HTML email. Depending on how the HTML is constructed, the HTML header could include a <code><link></code> element. The <code>Link:</code> header might be extended for use with eMail messages [[EMAIL]], but it's not clear that would be a worthwhile effort.</li>
+ <li>D5: HTML email. Depending on how the HTML is constructed, the HTML header could include <code><link></code> elements.</li>
</ul>
</li>
<li>Lacking identification or in-band metadata, some independent identification of the thing represented by an available mechanism is required. <em>I think this is unavoidable</em></li>
@@ -623,6 +691,7 @@
<p>
There are clearly a number of capabilities needed for a provenance-aware application that are not covered by the mechanisms described above. But most of these amount to implementation details and decisions for a particular application, and as such are beyond the scope of this document to specify.
</p>
+ <p>@@TODO: move this to new section 3.4</p>
<p>
One feature not covered above that might be a candidate for specification is a common format for a data package that combines original content along with provenance-related metadata or data. At this stage, it is not clear what format that might take, but some possible candidates are:
<ul>