--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/paq/provenance-access-revised-service.html Thu Aug 11 11:18:31 2011 +0100
@@ -0,0 +1,793 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>Provenance Access and Query</title>
+ <link rel="stylesheet" type="text/css" href="css/paq.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>
+<!-- Use local version of ReSpec.js for debugging:
+ <script src="js/respec.js" class="remove"></script>
+-->
+ <script class='remove'>
+ var addExtraReferences = function() {
+ for (var k in extraReferences)
+ berjon.biblio[k] = extraReferences[k];
+ };
+ var extraReferences = {
+ "LINK-REL" : "M. Nottingham, <a href='http://www.ietf.org/rfc/rfc5988.txt'><cite>Web Linking</cite></a>, October 2010, Internet RFC 5988. URL: <a href='http://www.ietf.org/rfc/rfc5988.txt'>http://www.ietf.org/rfc/rfc5988.txt</a>",
+ "RFC2387" : "E. Levinson. <a href=\"http://www.ietf.org/rfc/rfc2387.txt\"><cite>The MIME Multipart/Related Content-type.</cite></a> August 1998. Internet RFC 2387. URL: <a href=\"http://www.ietf.org/rfc/rfc2387.txt\">http://www.ietf.org/rfc/rfc2387.txt</a>",
+ "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>",
+ "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.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "provenance-access",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "an excellent document",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ copyrightStart: "2011",
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ // previousPublishDate: "1977-03-15",
+ // previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Graham Klyne", url: "",
+ company: "University of Oxford", companyURL: "http://www.ox.ac.uk/" },
+
+ { name: "Paul Groth", url: "",
+ company: "VU University Amsterdam", companyURL: "http://www.vu.nl/" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "Provenance Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2011/prov/wiki/Main_Page",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-prov-comments",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "",
+
+ // Add extraReferences to bibliography database
+ preProcess: [addExtraReferences],
+ };
+ </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>
+
+ <section>
+ <h2>Introduction</h2>
+ <p>
+ @@TODO Introductory text
+ </p>
+
+ <section>
+ <h2>Concepts</h2>
+ <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>
+
+ <section>
+ <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>
+ 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 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>
+ <p>
+ 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 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 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. 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>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>
+ <p>
+ The same basic mechanism can be used for referencing provenance data, for which a new link relation type is registered according to the template in <a href="#iana-considerations" class="sectionRef"></a>:
+ <p class="pattern">
+ <code>Link: <cite>provenance-URI</cite>; rel="provenance"</code>
+ </p>
+ When used in conjunction with an HTTP success response code (<code>2xx</code>), this HTTP header indicates that <code><cite>provenance-URI</cite></code> is the URI of some provenance for the requested resource. At this time, the meaning of provenance links returned with other HTTP response codes is not defined: future revisions of this specification may define interpretations for these.
+ </p>
+ <p>
+ An HTTP response MAY include multiple provenance link headers, indicating a number of different resources that are known to the responding server, each providing provenance about the accessed resource.
+ </p>
+ <p>
+ The presence of a provenance link in an HTTP response does not preclude the possibility that other publishers may offer provenance information about the same resource. In such cases, discovery of the additional provenance information must use other means (e.g. see <a href="#third-party-services" class="sectionRef"></a>).
+ </p>
+
+ <p class="issue">
+ Are the provenance resources indicated in this way to be considered authoritative? I.e. if the client trusts information returned by the server (e.g. is prepared to act on inferences based on the returned data), should it also trust the provenance data, or should trust in the linked provenance data be determined separately? If the linked data <em>is</em> to be trusted, then the data from multiple linked provenance resources MUST be consistent if it is to be meaningful. I favour an approach whereby trust in the provenance resources is established independently, which is similar to the situation for any other resource; e.g. based on the domain that serves it, or an associated digital signature.
+ </p>
+
+ </section>
+
+ <section>
+ <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>
+ <p>
+ The same basic mechanism can be used for referencing provence data, for which two new link relation types are registered according to the template in <a href="#iana-considerations" class="sectionRef"></a>:
+ <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" href="<cite>provenance-URI</cite>">
+ <link rel="target" href="<cite>target-URI</cite>">
+ <title>Welcome to example.com</title>
+ </head>
+ <body>
+ ...
+ </body>
+ </html>
+ </pre>
+ </code>
+ 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.
+ </p>
+ <p>
+ Likewise, the header MAY include multiple target link elements indicating that the document can be identified in the provenance information with multiple <code><cite>target-URIs</cite></code>.
+ </p>
+ <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>
+
+ <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>">
+ <link rel="target" href="<cite>target-URI</cite>">
+ <title>Welcome to example.com</title>
+ </head>
+ <body>
+ ...
+ </body>
+ </html>
+ </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>
+ <p class="note">
+ An alternative option would be to use an HTML <code><meta></code> element to present provenance links. The <code><Link></code> is preferred as it reflects more closely the intended goal, and has been defined with somewhat consistent applicability across HTTP, HTML and potentially RDF data. A specification to use <code><meta></code> for this would miss this opportunity to build on the existing specification and registry.
+ </p>
+ <p class="issue">
+ The POWDER specification also adds: Documents MAY also include any of the attribution data from the POWDER document in meta tags. In particular, the issuedby field is likely to be useful to user agents deciding whether or not to fetch the full POWDER document. Any attribution data encoded in meta tags within an HTML document should be the same as that in the POWDER document. In case of discrepancy, the POWDER document should be taken as more authoritative. Is there a parallel we should add here for provenance? I'm not seeing any compelling case for this.
+ </p>
+ </section>
+
+ <section>
+ <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 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
+ </p>
+ <p>
+ @@TODO: document namespace. Check naming style. Use provenance model namespace? Define as part of model?
+ </p>
+ </section>
+
+ <section>
+ <h2>Arbitrary target</h2>
+ <p class="pending">
+ We have so far decided not to try and define a common mechanism for arbitrary data, because it's not clear to us what the correct choice would be. Is this a reasonable position, or is there a real need for a generic solution for provenance discovery for arbitrary, non-web-accessible data objects?
+ </p>
+ <p>
+ If a resource is presented using a data format other than HTML or RDF, and no URI for the resource is known, provenance discovery becomes trickier to achieve. This specification does not define a specific mechanism for such arbitrary resources, but this section discusses some of the options that might be considered.
+ </p>
+ <p>
+ 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 Target-URI and/or Provenance-URI.
+ </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:
+ <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>
+ <li>
+ Composite object-packaging work from the digital library community, or which there are several (ORE, MPEG-21, BagIt @@refs) to name a handful. Practical implementations of these seem to commonly be based on the ZIP file format.
+ </li>
+ <li>
+ Packaging formats along the lines of those used for shipping Java web applications or (basically, a ZIP file with a manifest and some imposed structure)
+ </li>
+ <li>
+ 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>, ePub, etc.) to encapsulate data, code, annotations and metadata into a common exchangeable format.
+ </li>
+ </ul>
+ </p>
+ </section>
+
+ </section>
+
+
+
+
+
+
+<!-- ===================================================================================== -->
+
+
+ <section>
+ <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>.
+ 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">
+ 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.
+ </p>
+
+ <section>
+ <h2>Using the provenance discovery API</h2>
+ <p>
+ 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>
+
+ <p class="issue">
+ Do we need/want both of the following cases?
+ </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>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">
+ {
+ "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>
+ </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:provds = "http://www.w3.org/2011/provenance_discovery/@@TBD@@#"
+ >
+ <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>
+ </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://example.info/qdata/</code>.
+ </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">
+ {
+ "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>
+ </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">
+ @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>
+ <p class="pending">
+ 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 confirm 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 confirm 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 allowed by the Provenance Model specification [[PROV-MODEL]], as available.
+ </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>.
+ </p>
+ </section>
+
+ </section>
+
+ <section>
+ <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 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 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 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 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 Target-URI of resource</h2>
+ <p>
+ 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>
+ SELECT ?provenance_uri WHERE
+ {
+ <http://example.org/resource> prov:hasProvenance ?provenance_uri
+ }
+ </pre>
+ </code>
+ </p>
+ <p class="issue">
+ @@TODO: specific provenance namespace and property to be determined by the model specification?
+ </p>
+ </section>
+
+ <section>
+ <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:
+ <code>
+ <pre class="example">
+ @prefix prov: <@@TBD>
+ @prefix prism: <http://prismstandard.org/namespaces/basic/2.0/>
+ SELECT ?provenance_uri WHERE
+ {
+ [ prism:doi "1234.5678" ] prov:hasProvenance ?provenance_uri
+ }
+ </pre>
+ </code>
+ </p>
+ <p class="issue">
+ @@TODO: specific provenance namespace and property to be determined by the model specification?
+ </p>
+ </section>
+
+ <section>
+ <h2>Obtain provenance information directly given Target-URI of a resource</h2>
+ <p>
+ 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 information might look like this:
+ <code>
+ <pre class="example">
+ @prefix prov: <@@TBD>
+ CONSTRUCT
+ {
+ <http://example.org/resource> ?p ?v
+ }
+ WHERE
+ {
+ <http://example.org/resource> ?p ?v
+ }
+ </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 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 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>
+
+ </section>
+
+ <!-- <section class="informative"> -->
+ <section>
+ <h2>Provenance service discovery</h2>
+ <p class="issue">
+ (How to discover provenance services. There is nothing particular about provenance on this respect, and this section will discuss some of the available options without adding any new normative specification.)
+ </p>
+ <p>
+ @@TODO
+ </p>
+ </section>
+
+ <section>
+ <h2>IANA considerations</h2>
+ <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>
+ <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>
+ <h2>Security considerations</h2>
+ <p>
+ Provenance is central to establishing trust in data. If provenance information is corrupted, it may lead agents (human or software) to draw inappropriate and possibly harmful conclusions. Therefore, care is needed to ensure that the integrity of provenance data is maintained.
+ </p>
+ <p>
+ When using HTTP to access provenance information, or to determine a provenance URI, secure HTTP (https) SHOULD be used.
+ </p>
+ <p>
+ When retrieving a provenance URI from a document, steps SHOULD be taken to ensure the document itself is an accurate copy of the original whose author is being trusted (e.g. signature checking, or verifying its checksum aainst an author-provided secure web service). against
+ </p>
+ <p>
+ @@TODO ... privacy, access control to provenance (from Edinburgh meeting). In particular, note that the fact that a resource is openly accessible does not mean that its provenance information should also be.
+ </p>
+ <p>
+ @@TODO ... more, probably
+ </p>
+ </section>
+
+ <section class='appendix'>
+ <h2>Acknowledgements</h2>
+ <p>
+ 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">
+ I propose to remove this appendix on publication.
+ </p>
+ <p><a href="http://www.w3.org/2011/prov/wiki/ProvenanceAccessScenario">This scenario</a> was selected by the provenance working group as a touchstone for evaluating any provenance access proposal. This appendix evaluates the foregoing proposals against the requirements implied by that scenario.</p>
+ <p>
+ <ul>
+ <li>Obtaining the document D: for the purpose of this analysis, it is assumed that the access to the document is either from a known Web URI, or the document is available as HTML or RDF (the primary web standards for documents and data). The mechanisms here are in principle applicable to other document forms of a per-format basis.
+ <ul>
+ <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 <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>
+ <li>Enacting the "Oh yeah?" feature
+ <ul>
+ <li>W: once a URI for provenance information has been determined, accessing it using a web browser or other web client software should be straightforward. If the provenance is accessible via a third party query service, that may be less straightforward.</li>
+ <li>E: this scenario seems to envisage a wholesale overhaul of email client software, which seems unlikely. If a URI for provenance can be provided, the natural way to access it would be via a web client of some kind, which might be a browser or other software.</li>
+ <li>S: this scenario effectively calls for this: given an arbitrary data resource, implement a general purpose application to discover, retrieve and analyze provenance about that resource. At the present time, this is a matter for experimental development, which could be based substantially on the mechanisms described for provenance discovery and access via third party services.</li>
+ </ul>
+ </li>
+ <li>I: Accessing the provenance
+ <ul>
+ <li>W: a web client needs one or more URIs for provenance information, and/or URI(s) for a provenance query service and sufficient additional information about the resource to formulate an effective query. They may also need access information that can be used to assess (or help a user assess) the trustworthiness of provenance of information obtained, (which could be more provenance information)</li>
+ <li>E: an email client is a passive receiver of information, so asking one to retrieve provenance information is a perverse expectation. There have been some attempts to standardize email protocols that interact with the email sender (e.g. [[RFC3297]]) but such mechanisms have not been significantly deployed in practice. This case can be viewed as a variation on the shell-client case (S) below. If all provenance information is sent <em>with</em> the original content using standard email mechanisms (MIME multipart, etc.) then the email client may use that (or hand it off to a helper application) as the basis for provenance-based analysis or presentation.</li>
+ <li>S: command shell or other local application. This is the general case for provenance access. Given some arbitrary information, what does a provenance-aware application need to access the required provenance information? It may employ any of the mechanisms described above.</li>
+ </ul>
+ </li>
+ </ul>
+ </p>
+ <section>
+ <h2>Gap analysis</h2>
+ <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>
+ 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 discussed in <a href="#arbitrary-target" class="sectionRef"></a>.
+ In any case, it seems to me that a specification that is specific for provenance to the exclusion of other metadata is unlikely to obtain traction, as provenance is just part of a wider landscape of information quality, trust, preservation and more.
+ </p>
+ </section>
+ </section>
+ </body>
+</html>