--- a/paq/prov-aq.html Mon Nov 26 09:41:14 2012 -0500
+++ b/paq/prov-aq.html Mon Nov 26 14:43:50 2012 +0000
@@ -199,18 +199,18 @@
This document specifies how to use standard Web protocols,
including HTTP, to obtain information about the provenance of
resources on the Web. We describe both simple access mechanisms for
-locating provenance information associated with web pages or resources, and
+locating provenance descriptions associated with web pages or resources, and
provenance query services for more complex deployments. This is
part of the larger W3C Prov provenance framework.
</section>
<section id="sotd">
- This document is part of a set of specifications produced by the W3C provenance working group to define interoperable interchange of provenance information in heterogeneous environments such as the Web. It describes the use of existing web mechanisms for discovery and retrieval of provenance information.
+ This document is part of a set of specifications produced by the W3C provenance working group to define interoperable interchange of provenance in heterogeneous environments such as the Web. It describes the use of existing web mechanisms for discovery and retrieval of provenance descriptions.
<h4>PROV Family of Specifications</h4>
This document is part of the PROV family of specifications, a set of specifications defining various aspects that are necessary to achieve the vision of inter-operable
-interchange of provenance information in heterogeneous environments such as the Web. The specifications are:
+interchange of provenance in heterogeneous environments such as the Web. The specifications are:
<ul>
<li> <a href="http://www.w3.org/TR/prov-dm/">PROV-DM</a>, the PROV data model for provenance [[PROV-DM]];</li>
<li> <a href="http://www.w3.org/TR/prov-constraints/">PROV-CONSTRAINTS</a>, a set of constraints applying to the PROV data model [[PROV-CONSTRAINTS]];</li>
@@ -240,14 +240,14 @@
<section>
<h2>Introduction</h2>
<p>
- The Provenance Data Model [[PROV-DM]] and Provenance Ontology [[PROV-O]] specifications define how to represent provenance information in the World Wide Web.
+ The Provenance Data Model [[PROV-DM]] and Provenance Ontology [[PROV-O]] specifications define how to represent provenance in the World Wide Web.
</p>
<p>
- This note describes how standard web protocols may be used to locate, retrieve and query provenance information:
+ This note describes how standard web protocols may be used to locate, retrieve and query provenance descriptions:
</p>
<ul>
<li>
- Simple mechanisms for retrieving and discovering provenance information are described in <a href="#accessing-provenance-information" class="sectionRef"></a> and <a href="#locating-provenance-information" class="sectionRef"></a> .
+ Simple mechanisms for retrieving and discovering provenance descriptions are described in <a href="#accessing-provenance-information" class="sectionRef"></a> and <a href="#locating-provenance-information" class="sectionRef"></a> .
</li>
<li>
More advanced discovery service and query mechanisms that may be used for more demanding deployments are described in <a href="#provenance-services" class="sectionRef"></a>, <a href="#querying-provenance-information" class="sectionRef"></a> and <a href="#incremental-provenance-retrieval" class="sectionRef"></a>.
@@ -265,23 +265,23 @@
<dt><a href="#dfn-resource"><dfn>Resource</dfn></a></dt>
<dd>a resource in the general sense of "whatever might be identified by a URI", as described by the Architecture of the World Wide Web [[WEBARCH]], <a href="http://www.w3.org/TR/webarch/#id-resources" class="externalRef">section 2.2</a>. A resource may be associated with multiple instances or views (<a class="internalDFN">constrained resource</a>s) with differing provenance.</dd>
<dt><a href="#dfn-constrained-resource"><dfn>Constrained resource</dfn></a></dt>
- <dd>an aspect, version or instance of a <a class="internalDFN">resource</a>, about which one may wish to present some <a class="internalDFN">provenance information</a>. For example, a weather report for a given date may be an aspect of a resource that is maintained as the current weather report. A constrained resource is itself a <a class="internalDFN">resource</a>, and may have it's own URI different from that of the original. See also [[PROV-DM]], and [[WEBARCH]] <a href="http://www.w3.org/TR/webarch/#representation-reuse" class="externalRef">section 2.3.2</a>.</dd>
+ <dd>an aspect, version or instance of a <a class="internalDFN">resource</a>, about which one may wish to present some <a class="internalDFN">provenance description</a>s. For example, a weather report for a given date may be an aspect of a resource that is maintained as the current weather report. A constrained resource is itself a <a class="internalDFN">resource</a>, and may have it's own URI different from that of the original. See also [[PROV-DM]], and [[WEBARCH]] <a href="http://www.w3.org/TR/webarch/#representation-reuse" class="externalRef">section 2.3.2</a>.</dd>
<dt><a href="#dfn-target-uri"><dfn>Target-URI</dfn></a></dt>
- <dd>a URI denoting a <a class="internalDFN">resource</a> (including any <a class="internalDFN">constrained resource</a>), which identifies that resource for the purpose of finding and expressing <a class="internalDFN">provenance information</a> associated with it (see <a href="#provenance-entities-resources" class="sectionRef"></a> for discussion)</dd>
- </dt><a href="#dfn-provenance-information"><dfn>Provenance information</dfn></a></dt>
+ <dd>a URI denoting a <a class="internalDFN">resource</a> (including any <a class="internalDFN">constrained resource</a>), which identifies that resource for the purpose of finding and expressing <a class="internalDFN">provenance descriptions</a> associated with it (see <a href="#provenance-entities-resources" class="sectionRef"></a> for discussion)</dd>
+ </dt><a href="#dfn-provenance-information"><dfn>Provenance description</dfn></a></dt>
<dd>refers to provenance represented in some fashion.</dd>
<dt><a href="#dfn-provenance-uri"><dfn>Provenance-URI</dfn></a></dt>
- <dd>a URI denoting some <a class="internalDFN">provenance information</a>.</dd>
+ <dd>a URI denoting some <a class="internalDFN">provenance description</a>.</dd>
<dt><a href="#dfn-provenance-service"><dfn>Provenance service</dfn></a></dt>
- <dd>a service that provides <a class="internalDFN">provenance information</a> given a <a class="internalDFN">target-URI</a>.</dd>
+ <dd>a service that provides a <a class="internalDFN">provenance description</a> given a <a class="internalDFN">target-URI</a>.</dd>
<dt><a href="#dfn-service-uri"><dfn>Service-URI</dfn></a></dt>
<dd>the URI of a <a class="internalDFN">provenance service</a>.</dd>
<dt><a href="#dfn-pingback-uri"><dfn>Pingback-URI</dfn></a></dt>
- <dd>the URI of a provenance pingback service that receives forward provenance information (see <a href="#forward-provenance" class="sectionRef"></a>).</dd>
- <dt><a href="#dfn-accessing"><dfn>Accessing</dfn></a> provenance information</dt>
- <dd>Given the identity of a resource, the process of discovering and retrieving some <a class="internalDFN">provenance information</a> about that resource. This may involve <a class="internalDFN">locating</a> a provenance information resource, then performing an HTTP GET to retrieve it, or locating a service and querying the service for provenance information about an identified resource, or some other mechanism not covered in this document.</dd>
- <dt><a href="#dfn-locating"><dfn>Locating</dfn></a> provenance information</dt>
- <dd>Given the identity of a resource, discovery of a URI at which some <a class="internalDFN">provenance information</a> about that resource may be retrieved.</dd>
+ <dd>the URI of a provenance pingback service that receives forward provenance descriptions (see <a href="#forward-provenance" class="sectionRef"></a>).</dd>
+ <dt><a href="#dfn-accessing"><dfn>Accessing</dfn></a> provenance descriptions</dt>
+ <dd>Given the identity of a resource, the process of discovering and retrieving some <a class="internalDFN">provenance description</a>(s) about that resource. This may involve <a class="internalDFN">locating</a> a provenance description resource, then performing an HTTP GET to retrieve it, or locating a service and querying the service for provenance description about an identified resource, or some other mechanism not covered in this document.</dd>
+ <dt><a href="#dfn-locating"><dfn>Locating</dfn></a> provenance descriptions</dt>
+ <dd>Given the identity of a resource, discovery of a URI at which some <a class="internalDFN">provenance description</a> about that resource may be retrieved.</dd>
<!--
<a href="#dfn-..."><dt><dfn>...</dfn></dt></a>
<dd>...</dd>
@@ -293,27 +293,27 @@
<section>
<h2 id="provenance-entities-resources">Provenance and resources</h2>
<p>
- Fundamentally, <a class="internalDFN">provenance information</a> is <em>about</em> <a class="internalDFN">resource</a>s. In general, resources may vary over time and context. E.g., a resource describing the weather in London changes from day-to-day, or a listing of restaurants near you will vary depending on your location. Provenance information, to be useful, must be persistent and not itself dependent on context. Yet we may still want to make provenance assertions about dynamic or context-dependent resources (e.g. a weather forecast for London on a particular day may have been derived from a particular set of Meteorological Office data).
+ Fundamentally, a <a class="internalDFN">provenance description</a> is <em>about</em> <a class="internalDFN">resource</a>s. In general, resources may vary over time and context. E.g., a resource describing the weather in London changes from day-to-day, or a listing of restaurants near you will vary depending on your location. Provenance descriptions, to be useful, must be persistent and not themselves dependent on context. Yet we may still want to make provenance assertions about dynamic or context-dependent resources (e.g. a weather forecast for London on a particular day may have been derived from a particular set of Meteorological Office data).
</p>
<p>
Provenance descriptions of dynamic and context-dependent resources are possible through a notion of constrained resources. A <a class="internalDFN">constrained resource</a> is simply a resource (in the sense defined by [[WEBARCH]], <a href="http://www.w3.org/TR/webarch/#id-resources" class="externalRef">section 2.2</a>) that is a contextualized view or instance of some other resource. For example, a W3C specification typically undergoes several public revisions before it is finalized. A URI that refers to the "current" revision might be thought of as denoting the specification throughout its lifetime. Each individual revision would also have its own <a class="internalDFN">target-URI</a> denoting the specification at that particular stage in its development. Using these, we can make provenance assertions that a particular revision was published on a particular date, and was last modified by a particular editor. Target-URIs may use any URI scheme, and are not required to be dereferencable.
</p>
<p>
- Requests for provenance about a resource may return provenance information that uses one or more target-URIs to refer to versions of that resource. Some given provenance information may use multiple target-URIs if there are assertions referring to the same underlying resource in different contexts. For example, provenance information describing a W3C document might include information about all revisions of the document using statements that use the different target-URIs of the various revisions.
+ Requests for provenance about a resource may return provenance descriptions that use one or more target-URIs to refer to versions of that resource. Some provenance descriptions may use multiple target-URIs if there are assertions referring to the same underlying resource in different contexts. For example, a provenance description for a W3C document might include information about all revisions of the document using statements that use the different target-URIs of the various revisions.
</p>
<p>
- In summary, <a class="internalDFN">provenance information</a> may be not universally applicable to a <a class="internalDFN">resource</a>, but may be expressed with respect to that resource in a restricted context (e.g. at a particular time). This restriction is itself just another resource (e.g. the weather forecast for a give date as opposed to the current weather forecast), with its own URI for referring to it within provenance information.
+ In summary, a <a class="internalDFN">provenance description</a> may be not universally applicable to a <a class="internalDFN">resource</a>, but may be expressed with respect to that resource in a restricted context (e.g. at a particular time). This restriction is itself just another resource (e.g. the weather forecast for a give date as opposed to the current weather forecast), with its own URI for referring to it within a provenance description.
</p>
</section>
<section>
- <h2>Interpreting provenance information</h2>
+ <h2>Interpreting provenance descriptions</h2>
<p>
- Any given <a class="internalDFN">provenance information</a> may contain information about several resources, referring to them using their various <a class="internalDFN">target-URI</a>s.
- Thus, when interpreting provenance information, it is important to be aware that statements about several resources may be present, and to be accordingly selective when using the information provided. (In some exceptional cases, it may be that the provenance information returned does not contain any information relating to a specific associated resource.)
+ Any given <a class="internalDFN">provenance description</a> may contain information about several resources, referring to them using their various <a class="internalDFN">target-URI</a>s.
+ Thus, when interpreting provenance descriptions, it is important to be aware that statements about several resources may be present, and to be accordingly selective when using the information provided. (In some exceptional cases, it may be that a provenance description returned does not contain any information relating to a specific associated resource.)
</p>
<p>
- Provenance information is not of itself guaranteed to be authoritative or correct. Trust in provenance information must be determined separately from trust in the original resource. Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any other resource; e.g. based on the domain that serves it, or an associated digital signature. (See also <a href="#security-considerations" class="sectionRef"></a>.)
+ A provenance description is not of itself guaranteed to be authoritative or correct. Trust in provenance descriptions must be determined separately from trust in the original resource. Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any other resource; e.g. based on the domain that serves it, or an associated digital signature. (See also <a href="#security-considerations" class="sectionRef"></a>.)
</p>
</section>
@@ -330,17 +330,17 @@
</tr>
<tr style="vertical-align: top;">
<td><a class="internalDFN">Target-URI</a></td>
- <td>Any resource for which provenance information is provided. This is an <cite>entity</cite> in the sense described by [[PROV-DM]] (<a href="http://www.w3.org/TR/prov-dm/#term-entity" class="externalRef">Entity</a>).</td>
- <td>If the URI is dereferencable, it should return a representation or description of entity for which provenance information is provided.</td>
+ <td>Any resource for which provenance is provided. This is an <a href="http://www.w3.org/TR/prov-dm/#term-entity" class="externalRef">Entity</a> in the sense described by [[PROV-DM]].</td>
+ <td>If the URI is dereferencable, it should return a representation or description of entity for which provenance is provided.</td>
</tr>
<tr style="vertical-align: top;">
<td><a class="internalDFN">Provenance-URI</a></td>
<td>A provenance description in the sense described by [[PROV-DM]] (<a href="http://www.w3.org/TR/prov-dm/#section-prov-overview" class="externalRef">PROV Overview</a>).</td>
- <td>Provenance information in any of the defined formats selectable via content negotiation.</td>
+ <td>A provenance description in any defined format, selectable via content negotiation.</td>
</tr>
<tr style="vertical-align: top;">
<td><a class="internalDFN">Service-URI</a></td>
- <td>A provenance service (i.e. a resource of type <code>prov:ProvenanceService</code>). This is the initial URI used when accessing a provenance service; following REST API style [[REST-APIs]], actual URIs for accessing provenance information are obtained via the provenance service description.</td>
+ <td>A provenance service (i.e. a resource of type <code>prov:ProvenanceService</code>). This is the initial URI used when accessing a provenance service; following REST API style [[REST-APIs]], actual URIs for accessing provenance descriptions are obtained via the provenance service description.</td>
<td>A provenance service description per <a href="#provenance-service-description" class="sectionRef"></a>. Alternative formats may be offered via HTTP content negotiation.</td>
</tr>
<tr style="vertical-align: top;">
@@ -358,60 +358,55 @@
<!-- == Sect 2 =================================================================================== -->
<section>
- <h2>Accessing provenance information</h2>
+ <h2>Accessing provenance descriptions</h2>
<p>
- This specification describes two ways to access <a class="internalDFN">provenance information</a>:
+ This specification describes two ways to access <a class="internalDFN">provenance description</a>s:
</p>
<ol>
<li>Direct access: given a <a class="internalDFN">provenance-URI</a>, simply dereference it, and</li>
<li>Indirectly via a service: given the URIs of some resource and a <a class="internalDFN">provenance service</a>, use the service to access provenance of the resource.</li>
</ol>
<p>
- Web applications may access provenance information in the same way as any resource on the Web, by dereferencing its URI (commonly using an HTTP GET operation). Thus, any provenance information may be associated with a <a class="internalDFN">provenance-URI</a>, and may be accessed by dereferencing that URI using web mechanisms.
+ Web applications may access provenance descriptions in the same way as any resource on the Web, by dereferencing its URI (commonly using an HTTP GET operation). Thus, any provenance description may be associated with a <a class="internalDFN">provenance-URI</a>, and may be accessed by dereferencing that URI using web mechanisms.
</p>
<p>
- When there is no easy way to associate a provenance-URI with individual resources (e.g. for resources not directly web-accessible, or whose publication mechanism is controlled by someone else), one may provide provenance information about multiple resources through through a service interface. A REST protocol for provenance retrieval is defined in Section <a href="#provenance-services" class="sectionRef"></a>.
+ When there is no easy way to associate a provenance-URI with individual resources (e.g. for resources not directly web-accessible, or whose publication mechanism is controlled by someone else), one may provide provenance descriptions about multiple resources through through a service interface. A REST protocol for provenance retrieval is defined in Section <a href="#provenance-services" class="sectionRef"></a>.
</p>
<p>
- How much or how little provenance information is returned in response to a retrieval request is a matter for the provenance provider application.
+ How much or how little provenance is returned in response to a retrieval request is a matter for the provenance provider application.
</p>
<p>
- When publishing provenance information, a corresponding <a class="internalDFN">provenance-URI</a> or <a class="internalDFN">service-URI</a> should be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-information" class="sectionRef"></a>.
+ When publishing provenance descriptions, corresponding <a class="internalDFN">provenance-URI</a>s or <a class="internalDFN">service-URI</a>s should be discoverable using one or more of the mechanisms described in <a href="#locating-provenance-information" class="sectionRef"></a>.
</p>
<p>
Provenance may be presented as a <a href="/TR/prov-dm/#component4" class="externalRef">bundle</a>, which <cite>is a named set of provenance descriptions, and is itself an entity, so allowing provenance of provenance to be expressed</cite> [[PROV-DM]]. There is no requirement that a bundle identifier can be dereferenced to access the corresponding provenance, but where practical it is RECOMMENDED that matters be arranged so this is possible. One possible realization of a bundle is that it is published as part of an RDF Dataset [[RDF-CONCEPTS11]] or similar composite structure. To access such a bundle would require accessing the RDF Dataset and then extracting the identified component; this in turn would require knowing a URI or some other way to retrieve the dataset. This specification does not describe a specific mechanism for this; we anticipate that the W3C Linked Data Platform group (<a href="http://www.w3.org/2012/ldp/" class="externalRef">www.w3.org/2012/ldp/</a>) may address this topic in due course.
</p>
- <!--
- <p>
- Some alternative practices for accessing provenance information are discussed in <a href="#best-practice" class="sectionRef"></a>
- </p>
- -->
</section>
<!-- == Sect 3 =================================================================================== -->
<section>
- <h2>Locating provenance information</h2>
+ <h2>Locating provenance descriptions</h2>
<p>
- If <a class="internalDFN">provenance information</a> is a resource that can be accessed using web retrieval, one needs to know its <a class="internalDFN">provenance-URI</a> to dereference. If this is known in advance, there is nothing more to specify. If a provenance-URI is not known then a mechanism to discover one must be based on information that is available to the would-be accessor. Likewise, provenance information may be exposed by a service, in which case, the <a class="internalDFN">service-URI</a> needs to be known.
+ If a <a class="internalDFN">provenance description</a> is a resource that can be accessed using web retrieval, one needs to know its <a class="internalDFN">provenance-URI</a> to dereference. If this is known in advance, there is nothing more to specify. If a provenance-URI is not known then a mechanism to discover one must be based on information that is available to the would-be accessor. Likewise, provenance descriptions may be exposed by a service, in which case, the <a class="internalDFN">service-URI</a> needs to be known.
</p>
<p>
- In the following, we refer to <a class="internalDFN">provider</a>s and <a class="internalDFN">consumer</a>s:
+ In the following, we refer to <a class="internalDFN">provider</a>s and <a class="internalDFN">consumer</a>s of provenance:
</p>
<dl>
<dt><dfn>provider</dfn></dt>
<dd>
- is any agent that collects or constructs some information and makes it available. The nature of the information or the means by which it is made available are not constrained, but the following discussion focuses on <a class="internalDFN">provenance information</a> made available by HTTP transactions (i.e. where the provenance provider is an HTTP server),
+ is an agent that collects or constructs some information and makes it available. The nature of the information or the means by which it is made available are not constrained, but the following discussion focuses on provenance descriptions made available by HTTP transactions (i.e. where the provenance provider is an HTTP server),
</dd>
<dt><dfn>consumer</dfn></dt>
<dd>
- is any agent that receives and interprets some information. We focus here on interpretation of <a class="internalDFN">provenance information</a>.
+ is an agent that receives and interprets provenance descriptions.
</dd>
</dl>
- <p>Provenance information may be offered by several providers as well as that of the original resource, each with different concerns, and presenting provenance at different locations. It is possible that these different providers may present contradictory provenance information.
+ <p>Provenance descriptions may be offered by several providers as well as that of the original resource, each with different concerns, and presenting provenance at different locations. It is possible that these different providers may present contradictory provenance.
</p>
<p>
- A consumer of some provenance information will generally need to isolate information about some specific target resource or resources. These may be <a class="internalDFN">constrained resource</a>s identified by separate target-URIs than the original resource. In such circumstances, a provenance consumer will need to know the target-URI described by the provenance information obtained.
+ The consumer of a provenance description will generally need to isolate information about some specific target resource or resources. These may be <a class="internalDFN">constrained resource</a>s identified by separate target-URIs than the original resource. In such circumstances, a provenance consumer will need to know the target-URI used by a provenance description.
</p>
<p>
We consider here mechanisms for a provider to indicate a <a class="internalDFN">provenance-URI</a> or <a class="internalDFN">Service-URI</a> along with a <a class="internalDFN">target-URI</a>.
@@ -426,7 +421,7 @@
These particular cases are selected as corresponding to primary current web protocol and data formats. Similar approaches may be possible for other protocols or resource formats. Finally, in <a href="#arbitrary-data" class="sectionRef"></a>, we discuss the case of a resource in an unspecified format which has been provided by some means other than HTTP.
</p>
<p>
- The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance information, and the provenance information itself should explicitly identify the target resources it describes. While a provider should avoid giving spurious information, there are no fixed semantics, particularly when multiple resources are indicated, and a client should not assume that a specific given provenance-uri will yield information about a specific given target-uri. In the general case, a client presented with multiple provenance-uris and multiple target-uris should look at all of the provenance-uris for information about any or all of the target-uris.
+ The mechanisms described here are intended to allow a provider to supply information that may assist a client in finding related provenance descriptions. The provenance descriptions should themselves explicitly identify the target resources they describe. While a provider should avoid giving spurious information, there are no fixed semantics, particularly when multiple resources are indicated, and a client should not assume that a specific given provenance-uri will yield information about a specific given target-uri. In the general case, a client presented with multiple provenance-uris and multiple target-uris should look at all of the provenance-uris for information about any or all of the target-uris.
</p>
<p>
The mechanisms specified for use with HTTP and HTML are similar to those proposed by POWDER [[POWDER-DR]] (sections <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#assoc-markup" class="externalRef">4.1.1</a> and <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#httplink" class="externalRef">4.1.3</a>).
@@ -435,13 +430,13 @@
<section>
<h2>Resource accessed by HTTP</h2>
<p>
- For a resource accessible using HTTP, provenance information may be indicated using an HTTP <code>Link</code> header field, as defined by <a href="http://tools.ietf.org/html/rfc5988" class="externalRef">Web Linking (RFC 5988)</a> [[LINK-REL]]. 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).
+ For a resource accessible using HTTP, a provenance description may be indicated using an HTTP <code>Link</code> header field, as defined by <a href="http://tools.ietf.org/html/rfc5988" class="externalRef">Web Linking (RFC 5988)</a> [[LINK-REL]]. 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).
</p>
<p>
- A <code>hasProvenance</code> link relation type for referencing provenance information may be used as shown:
+ A <code>hasProvenance</code> link relation type for referencing a provenance description may be used thus:
</p>
<pre class="pattern">Link: <cite>provenance-URI</cite>; rel="http://www.w3.org/ns/prov#hasProvenance"; anchor="<cite>target-URI</cite>"</pre>
- <p>When used in conjunction with an HTTP success response code (<code>2xx</code>), this HTTP header field indicates that <code><cite>provenance-URI</cite></code> is the URI of some provenance information associated with the requested resource and that the associated resource is identified within the referenced provenance information as <code><cite>target-URI</cite></code>. (See also <a href="#interpreting-provenance-information" class="sectionRef"></a>.)</p>
+ <p>When used in conjunction with an HTTP success response code (<code>2xx</code>), this HTTP header field indicates that <code><cite>provenance-URI</cite></code> is the URI of some provenance description associated with the requested resource, and that the associated resource is identified within the provenance description as <code><cite>target-URI</cite></code>. (See also <a href="#interpreting-provenance-information" class="sectionRef"></a>.)</p>
<p>
If no <code>anchor</code> parameter is provided then the <code><cite>target-URI</cite></code> is assumed to be the URI of the resource, used in the corresponding HTTP request.
</p>
@@ -449,24 +444,24 @@
This specification does not define the meaning of these links returned with other HTTP response codes: future revisions may define interpretations for these.
</p>
<p>
- An HTTP response MAY include multiple <code>hasProvenance</code> link header fields, indicating a number of different provenance resources that are known to the responding server, each providing provenance information about the accessed resource.
+ An HTTP response MAY include multiple <code>hasProvenance</code> link header fields, indicating a number of different provenance resources that are known to the responding server, each presenting a provenance description about the accessed resource.
</p>
<p>
- The presence of a <code>hasProvenance</code> 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="#provenance-services" class="sectionRef"></a>).
+ The presence of a <code>hasProvenance</code> link in an HTTP response does not preclude the possibility that other publishers may offer provenance descriptions about the same resource. In such cases, discovery of the additional provenance descriptions must use other means (e.g. see <a href="#provenance-services" class="sectionRef"></a>).
</p>
<p>
- Provenance resources indicated in this way are not guaranteed to be authoritative. Trust in the linked provenance information must be determined separately from trust in the original resource. Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any other linked resource; e.g. based on the domain that serves it, or an associated digital signature. (See also <a href="#security-considerations" class="sectionRef"></a>.)
+ Provenance indicated in this way is not guaranteed to be authoritative. Trust in the linked provenance descriptions must be determined separately from trust in the original resource. Just as in the web at large, it is a user's responsibility to determine an appropriate level of trust in any other linked resource; e.g. based on the domain that serves it, or an associated digital signature. (See also <a href="#security-considerations" class="sectionRef"></a>.)
</p>
<section>
<h2>Specifying Provenance Services</h2>
<p>
- The resource provider may indicate that provenance information about the resource is provided by a <a class="internalDFN">provenance service</a>. This is done through the use of a <code>hasProvenanceService</code> link relation type following the same pattern as above:
+ The resource provider may indicate that provenance descriptions about the resource are provided by a <a class="internalDFN">provenance service</a>. This is done through the use of a <code>hasProvenanceService</code> link relation type following the same pattern as above:
</p>
<pre class="pattern">
Link: <cite>provenance-service-URI</cite>; rel="http://www.w3.org/ns/prov#hasProvenanceService"; anchor="<cite>target-URI</cite>"</pre>
<p>
- The <code>hasProvenanceService</code> link identifies the <a class="internalDFN">service-URI</a>. Dereferencing this URI yields a service description that provides further information to enable a client to determine a <a class="internalDFN">provenance-URI</a> or retrieve <a class="internalDFN">provenance information</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-services" class="sectionRef"></a> for more details.
+ The <code>hasProvenanceService</code> link identifies the <a class="internalDFN">service-URI</a>. Dereferencing this URI yields a service description that provides further information to enable a client to determine a <a class="internalDFN">provenance-URI</a> for a <a class="internalDFN">provenance description</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-services" class="sectionRef"></a> for more details.
</p>
<p>
There may be multiple <code>hasProvenanceService</code> link header fields, and these may appear in an HTTP response together with <code>hasProvenance</code> link header fields (though, in simple cases, we anticipate that <code>hasProvenance</code> and <code>hasProvenanceService</code> link relations will not be used together).
@@ -476,10 +471,10 @@
<section>
<h2>Content negotiation, redirection and Link: headers</h2>
<p>
- When performing content negotiation for a resource, it is common for HTTP 302 or 303 redirect response codes to be used to direct a client to an appropriately-formatted resource. When accessing a resource for which provenance information is available, link headers SHOULD be included with the response to the final redirected request, and not on the intermediate 303 responses. (When accessing a resource from a browser using Javascript, the intermediate 303 responses are usually handled transparently by the browser and are not visible to the HTTP client code.)
+ When performing content negotiation for a resource, it is common for HTTP 302 or 303 redirect response codes to be used to direct a client to an appropriately-formatted resource. When accessing a resource for which provenance is available, link headers SHOULD be included with the response to the final redirected request, and not on the intermediate 303 responses. (When accessing a resource from a browser using Javascript, the intermediate 303 responses are usually handled transparently by the browser and are not visible to the HTTP client code.)
</p>
<p>
- Following content negotiation, any link to provenance information returned refers to the resource whose URI is used in the corresponding HTTP request, or the given anchor parameter if that is different. (The provenance information itself may also refer to other resources; see the discussion at the start of <a href="#locating-provenance-information" class="sectionRef"></a>.)
+ Following content negotiation, any provenance link returned refers to the resource whose URI is used in the corresponding HTTP request, or the given anchor parameter if that is different. (The provenance description itself may also refer to other resources; see the discussion at the start of <a href="#locating-provenance-information" class="sectionRef"></a>.)
</p>
<p>
An example transaction using content negotiation and redirection might look like this (where <code>C:</code> and <code>S:</code> prefixes indicate client and server emitted data respectively):
@@ -517,8 +512,8 @@
<section>
<h2>Resource represented as HTML</h2>
<div>
- For a document presented as HTML or XHTML, without regard for how it has been obtained, provenance information may be associated with a resource by adding a <code><link></code> element to the HTML <code><head></code> section.
- Two link relation types for referencing provenance information may be used as shown:
+ For a document presented as HTML or XHTML, without regard for how it has been obtained, a provenance description may be associated with a resource by adding a <code><link></code> element to the HTML <code><head></code> section.
+ Two link relation types for referencing provenance descriptions may be used as shown:
<pre class="pattern">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
@@ -535,10 +530,10 @@
The <code><cite>provenance-URI</cite></code> given by the <code>hasProvenance</code> link element identifies the provenance-URI for the document.
</p>
<p>
- The <code><cite>target-URI</cite></code> given by the <code>hasAnchor</code> link element specifies an identifier for the document that may be used within the provenance information when referring to the document.
+ The <code><cite>target-URI</cite></code> given by the <code>hasAnchor</code> link element specifies an identifier for the document that may be used within the provenance description when referring to the document.
</p>
<p>
- An HTML document header MAY include multiple <code>hasProvenance</code> link elements, indicating a number of different provenance sources that are known to the creator of the document, each of which may provide provenance information about the document.
+ An HTML document header MAY include multiple <code>hasProvenance</code> link elements, indicating a number of different provenance descriptions that are known to the creator of the document, each of which may provide provenance about the document.
</p>
<p>
If no <code>hasAnchor</code> 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 convention be used only when the document is static and has a stable URI that is reasonably expected to be available to anyone accessing the document (e.g. when delivered from a web server, or as part of a MIME structure containing content identifiers [[RFC2392]]).
@@ -547,7 +542,7 @@
<section>
<h2>Specifying Provenance Services</h2>
<p>
- The document creator may specify that the provenance information about the document is provided by a <a class="internalDFN">provenance service</a>. This is done through the use of a third link relation type following the same pattern as above:
+ The document creator may specify that the provenance about the document is provided by a <a class="internalDFN">provenance service</a>. This is done through the use of a third link relation type following the same pattern as above:
</p>
<pre class="pattern">
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -561,7 +556,7 @@
</body>
</html></pre>
<p>
- The <code>hasProvenanceService</code> link element identifies the <a class="internalDFN">service-URI</a>. Dereferencing this URI yields a service description that provides further information to enable a client to access <a class="internalDFN">provenance information</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-services" class="sectionRef"></a> for more details.
+ The <code>hasProvenanceService</code> link element identifies the <a class="internalDFN">service-URI</a>. Dereferencing this URI yields a service description that provides further information to enable a client to access <a class="internalDFN">provenance description</a> for a <a class="internalDFN">resource</a>; see <a href="#provenance-services" class="sectionRef"></a> for more details.
</p>
<p>
There MAY be multiple <code>hasProvenanceService</code> link elements, and these MAY appear in the same document as <code>provenance</code> link elements (though, in simple cases, we anticipate that <code>hasProvenance</code> and <code>hasProvenanceService</code> link relations would not be used together).
@@ -576,14 +571,14 @@
(These terms may be used to indicate provenance of arbitrary other resources too, but discussion of such usage is beyond the scope of this section.)
</p>
<p>
- The RDF property <code>prov:hasProvenance</code> is 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. This property corresponds to a <code>hasProvenance</code> e link relation</a> used with an HTTP <code>Link</code> header field, or HTML <code><link></code> element (see above).
+ The RDF property <code>prov:hasProvenance</code> is a relation between two resources, where the object of the property is a resource that presents a provenance description of the subject resource. Multiple <code>prov:hasProvenance</code> assertions may be made about a subject resource. This property corresponds to a <code>hasProvenance</code> e link relation</a> used with an HTTP <code>Link</code> header field, or HTML <code><link></code> element (see above).
</p>
<p>
- Property <code>prov:hasAnchor</code> specifies a <a class="internalDFN">target-URI</a> used in the indicated provenance information to refer to the containing RDF document.
- This corresponds to use of the <code>anchor</code> parameter in an HTTP provenance <code>Link</code> header field, or a <code>hasAnchor</code> link relation</a> in an HTML <code><link></code> element, which similarly indicate a URI used by the provenance information to refer to the described document.
+ Property <code>prov:hasAnchor</code> specifies a <a class="internalDFN">target-URI</a> used in the indicated provenance to refer to the containing RDF document.
+ This corresponds to use of the <code>anchor</code> parameter in an HTTP provenance <code>Link</code> header field, or a <code>hasAnchor</code> link relation</a> in an HTML <code><link></code> element, which similarly indicate a URI used by the provenance description to refer to the described document.
</p>
<p>
- Property <code>prov:hasProvenanceService</code> specifies a <a class="internalDFN">service-URI</a> associated with the RDF document for possible access to provenance information. This property corresponds to a <code>hasProvenanceService</code> link relation used with an HTTP <code>Link</code> header field, or HTML <code><link></code> element.
+ Property <code>prov:hasProvenanceService</code> specifies a <a class="internalDFN">service-URI</a> associated with the RDF document for accessing provenance descriptions. This property corresponds to a <code>hasProvenanceService</code> link relation used with an HTTP <code>Link</code> header field, or HTML <code><link></code> element.
</p>
<pre class="example code">
@prefix prov: <http://www.w3.org/ns/prov#>
@@ -605,15 +600,15 @@
<section>
<h2>Provenance services</h2>
<p>
- This section describes a REST-based protocol [[REST]] for provenance services with facilities for the retrieval of provenance information. The protocol specifies HTTP operations for retrieval of provenance information from a provenance service. It follows the approach of the SPARQL Graph Store HTTP Protocol [[SPARQL-HTTP]].
+ This section describes a REST-based protocol [[REST]] for provenance services with facilities for the retrieval of provenance descriptions. The protocol specifies HTTP operations for retrieval of a provenance description from a provenance service. It follows the approach of the SPARQL Graph Store HTTP Protocol [[SPARQL-HTTP]].
</p>
<p>The introduction of this protocol is motivated by the following possible considerations: </p>
<ul>
- <li>the naming authority associated with the <a class="internalDFN">target-URI</a> is not the same as the service offering provenance information</li>
- <li>multiple services have <a class="internalDFN">provenance information</a> about the same resource</li>
+ <li>the naming authority associated with the <a class="internalDFN">target-URI</a> is not the same as the service offering <a class="internalDFN">provenance description</a>s</li>
+ <li>multiple services have provenance descriptions about the same resource</li>
<li>the service associated with the target-URI is not accessible for adding additional information when handling retrieval requests</li>
- <li>there is no dereferencable <a class="internalDFN">provenance-URI</a> containing provenance information for a particular resource</li>
- <li>provenance services may provide additional extensibility points for control over returned provenance information.</li>
+ <li>there is no dereferencable <a class="internalDFN">provenance-URI</a> containing a provenance <a class="internalDFN"> for a particular resource</li>
+ <li>provenance services may provide additional extensibility points for control over returned provenance.</li>
</ul>
<section>
@@ -623,13 +618,13 @@
GET /provenance/service?<b>target</b>=http://www.example.com/entity HTTP/1.1
Host: example.com</pre>
</div>
- <div>The embedded target-URI (<code>http://www.example.com/entity</code>) identifies the resource for which provenance information is to be returned. Any server that implements this protocol and receives a request URI in this form SHOULD return provenance information for the resource-URI embedded in the query component where that URI is the result of percent-decoding the value associated with the provenance-resource key. The embedded URI MUST be an absolute URI and the server MUST respond with a 400 Bad Request if it is not. If the supplied resource-URI includes a fragment identifier, the '#' MUST be %-encoded as <code>%23</code> when constructing the provenance-URI value; similarly, any '&' character in the resource-URI must be %-encoded as <code>%26</code> [[RFC3986]].
+ <div>The embedded target-URI (<code>http://www.example.com/entity</code>) identifies the resource for which provenance is to be returned. Any server that implements this protocol and receives a request URI in this form SHOULD return a provenance description for the resource-URI embedded in the query component, where that URI is the result of percent-decoding the value associated with the provenance-resource key. The embedded URI MUST be an absolute URI and the server MUST respond with a 400 Bad Request if it is not. If the supplied resource-URI includes a fragment identifier, the '#' MUST be %-encoded as <code>%23</code> when constructing the provenance-URI value; similarly, any '&' character in the resource-URI must be %-encoded as <code>%26</code> [[RFC3986]].
</div>
<p>
- If the provenance information identified in the request does not exist in the server, a 404 Not Found response code SHOULD be returned.
+ If the provenance identified in the request does not exist in the server, a 404 Not Found response code SHOULD be returned.
</p>
<p>
- The format of returned provenance information is not defined here, but may be established through content type negotiation using <code>Accept:</code> header fields in the HTTP request. A provenance service SHOULD be capable of returning RDF using the vocabulary defined by [[PROV-O]], in any standard RDF serialization (e.g. RDF/XML), or any other standard serialization of the Provenance Model specification [[PROV-DM]]. Services MUST identify the <code>Content-Type</code> of the information returned.
+ The format of the returned provenance description is not defined here, but may be established through content type negotiation using <code>Accept:</code> header fields in the HTTP request. A provenance service SHOULD be capable of returning RDF using the vocabulary defined by [[PROV-O]], in any standard RDF serialization (e.g. RDF/XML), or any other standard serialization of the Provenance Model specification [[PROV-DM]]. Services MUST identify the <code>Content-Type</code> of the information returned.
</p>
<p>
Additional URI query parameters may be used as indicated by the service description in <a href="#provenance-service-description" class="sectionRef"></a>.
@@ -669,10 +664,10 @@
where <cite><code>service-URI</code></cite> is the URI of the provenance service. Note that the object of the <code>prov:provenanceUriTemplate</code> statement is a literal text value, not a URI.
</p>
<p>
- A client should retrieve this service description and extract the associated value for <code>prov:provenance-URI-template</code>. This value is a string containing a URI template [[URI-template]] (level 2 or above). A URI for the desired provenance information is obtained by expanding the URI template with the variable <code>uri</code> set to the resource-URI for which provenance is required. If the target-URI contains '#' or '&' these must be %-escaped as <code>%23</code> or <code>%26</code> respectively before template expansion [[RFC3986]].
+ A client should retrieve this service description and extract the associated value for <code>prov:provenance-URI-template</code>. This value is a string containing a URI template [[URI-template]] (level 2 or above). A URI for the desired provenance description is obtained by expanding the URI template with the variable <code>uri</code> set to the resource-URI for which provenance is required. If the target-URI contains '#' or '&' these must be %-escaped as <code>%23</code> or <code>%26</code> respectively before template expansion [[RFC3986]].
</p>
<p>
- A provenance service MAY recognize additional parameters encoded as part of a URI for provenance information. If it does, it SHOULD include these in the provenance URI template in the service description, so that clients may know how a URI is formed using this additional information.
+ A provenance service MAY recognize additional parameters encoded as part of a URI for the provenance description. If it does, it SHOULD include these in the provenance URI template in the service description, so that clients may know how a URI is formed using this additional information.
For example, a service might offer to include just the immediate provenance of an entity, or to also supply provenance of entities from which the target resource is derived. Suppose a service accepts an additional parameter <code>steps</code> that defines the number of previous steps to include in a provenance trace, it might publish its service description thus:
</p>
<pre class="pattern">
@@ -701,7 +696,7 @@
<section>
<h2>Forward provenance</h2>
<p>
- The mechanisms discussed in previous sections are primarily concerned with how consumers access historical provenance information from publishers, dealing with questions such as:
+ The mechanisms discussed in previous sections are primarily concerned with how consumers access historical provenance from publishers, dealing with questions such as:
</p>
<ul>
<li>what was this resource based upon?</li>
@@ -722,7 +717,7 @@
The ability to answer forward-looking questions requires some cooperation among the parties who use a resource; for example, a consumer could report use directly to the publisher, or a search engine could discover and report such downstream resource usage. To facilitate such cooperation, a publisher may implement a "ping-back" capability.
</p>
<p>
- A resource may have an associated "ping-back" URI which can be presented with PROV assertions about the resource. The ping-back URI is associated with a resource using mechanisms similar to those used for presenting a <a class="internalDFN">provenance-URI</a>, but using a <code>provPingback</code> link relation instead of <code>hasProvenance</code>. A consumer of the resource, or some other system, may perform an HTTP POST operation to the pingback URI where the POST request body contains new provenance information in one of the recognized provenance formats. For interoperability, ping-back receiving service SHOULD be able to accept al least PROV-O provenance presented as RDF/XML or Turtle.
+ A resource may have an associated "ping-back" URI which can be presented with PROV assertions about the resource. The ping-back URI is associated with a resource using mechanisms similar to those used for presenting a <a class="internalDFN">provenance-URI</a>, but using a <code>provPingback</code> link relation instead of <code>hasProvenance</code>. A consumer of the resource, or some other system, may perform an HTTP POST operation to the pingback URI where the POST request body contains provenance in one of the recognized provenance description formats. For interoperability, a ping-back receiving service SHOULD be able to accept at least PROV-O provenance presented as RDF/XML or Turtle.
</p>
<p>
For example, consider a resource that is published by acme.example.com, and is subsequently used by wile-e.example.org in the construction of some new entity; we might see an exchange along the following lines. We start with wile-e.example.org retrieving a copy of acme.example.org's resource:
@@ -739,7 +734,7 @@
:
(super-widget resource data)</pre>
<p>
- The first of the links in the response is the provenance-URI that has been described previously. The second is a distinct resource that exists to receive provenance pingbacks. Later, when a new resource has been created or action performed based upon the acme.example.org/super-widget, new provenance information may be submitted to the pingback thus:
+ The first of the links in the response is the provenance-URI that has been described previously. The second is a distinct resource that exists to receive provenance pingbacks. Later, when a new resource has been created or action performed based upon the acme.example.org/super-widget, new provenance may be submitted to the pingback thus:
</p>
<pre class="pattern">
C: POST /pingback/super-widget HTTP/1.1
@@ -772,21 +767,21 @@
<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 information is maintained. Just as provenance information can help determine a level of trust in some information, provenance information related to the provenance itself ("provenance of provenance") can help determine trust in the provenance itself.
+ Provenance is central to establishing trust in data. If a provenance description 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 is maintained. Just as provenance can help determine a level of trust in some information, a provenance description related to the provenance itself ("provenance of provenance") can help determine trust in the provenance.
</p>
<p>
- Secure HTTP (https) SHOULD be used across unsecured networks when accessing provenance information that may be used as a basis for trust decisions, or to obtain a provenance URI for same.
+ Secure HTTP (https) SHOULD be used across unsecured networks when accessing provenance that may be used as a basis for trust decisions, or to obtain a provenance URI for same.
</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 use of a trusted secure web service).
</p>
<p>
- Provenance information may provide a route for leakage of privacy-related information, combining as it does a diversity of information types with possible personally-identifying information; e.g. editing timestamps may provide clues to the working patterns of document editors, or derivation traces might indicate access to sensitive materials. In particular, note that the fact that a resource is openly accessible does not mean that its provenance information should also be. When publishing provenance, its sensitivity SHOULD be considered and appropriate access controls applied where necessary. When a provenance-aware publishing service accepts some resource for publication, the contributors SHOULD have some opportunity to review and correct or conceal any provenance information that they don't wish to be exposed. Provenance management systems SHOULD embody mechanisms for enforcement and auditing of privacy policies as they apply to provenance information.
+ Provenance descriptions may provide a route for leakage of privacy-related information, combining as it does a diversity of information types with possible personally-identifying information; e.g. editing timestamps may provide clues to the working patterns of document editors, or derivation traces might indicate access to sensitive materials. In particular, note that the fact that a resource is openly accessible does not mean that its provenance should also be. When publishing provenance, its sensitivity SHOULD be considered and appropriate access controls applied where necessary. When a provenance-aware publishing service accepts some resource for publication, the contributors SHOULD have some opportunity to review and correct or conceal any provenance that they don't wish to be exposed. Provenance management systems SHOULD embody mechanisms for enforcement and auditing of privacy policies as they apply to provenance.
</p>
- <p>Provenance information may be used by audits to establish accountability for information use [[INFO-ACC]] and to verify use of proper processes in information processing activities. Thus, provenance management systems can provide mechanisms to support auditing and enforcement of information handling policies. In such cases, provenance information itself may be a valuable target for attack by malicious agents, and care must be taken to ensure it is stored securely and in a fashion that resists attempts to tamper with it.
+ <p>Provenance descriptions may be used by audits to establish accountability for information use [[INFO-ACC]] and to verify use of proper processes in information processing activities. Thus, provenance management systems can provide mechanisms to support auditing and enforcement of information handling policies. In such cases, provenance itself may be a valuable target for attack by malicious agents, and care must be taken to ensure it is stored securely and in a fashion that resists attempts to tamper with it.
</p>
<p>
- The pingback service described in <a href="#forward-provenance" class="sectionRef"></a> might be abused for "link spamming" (similar to the way that weblog ping-backs have been used to direct viewers to spam sites). As with many such services, an application needs to find a balance between maintaining ease of submission for useful information and blocking unwanted information. We have no easy solutions for this problem, and the caveats noted above about establishing integrity of provenance information apply similarly to information provided by ping-back calls.
+ The pingback service described in <a href="#forward-provenance" class="sectionRef"></a> might be abused for "link spamming" (similar to the way that weblog ping-backs have been used to direct viewers to spam sites). As with many such services, an application needs to find a balance between maintaining ease of submission for useful information and blocking unwanted information. We have no easy solutions for this problem, and the caveats noted above about establishing integrity of provenance descriptions apply similarly to information provided by ping-back calls.
</p>
</section>
@@ -827,13 +822,13 @@
</tr>
<tr style="vertical-align: top;">
<td><code>hasProvenance</code></td>
- <td>Indicates a <a class="internalDFN">provenance-URI</a> for a resource; the resource identified by this property provides provenance information about its subject or anchor resource.
+ <td>Indicates a <a class="internalDFN">provenance-URI</a> for a resource; the resource identified by this property presents a provenance description about its subject or anchor resource.
</td>
<td><a href="#resource-accessed-by-http" class="sectionRef"></a>, <a href="#resource-represented-as-html" class="sectionRef"></a></td>
</tr>
<tr style="vertical-align: top;">
<td><code>hasProvenanceService</code></td>
- <td>Indicates a <a class="internalDFN">provenance service</a> that can provide provenance information about its subject or anchor resource.</td>
+ <td>Indicates a <a class="internalDFN">provenance service</a> that can provide provenance descriptions about its subject or anchor resource.</td>
<td><a href="#specifying-provenance-services" class="sectionRef"></a></td>
</tr>
<tr style="vertical-align: top;">