--- a/paq/provenance-access.html Thu Nov 10 11:54:59 2011 +0000
+++ b/paq/provenance-access.html Thu Nov 10 12:41:59 2011 +0000
@@ -164,7 +164,15 @@
In summary, a key notion within the concepts outlined above is that <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 restricted view is called an <a class="internalDFN">entity</a>, and an <a class="internalDFN">entity-URI</a> is used to refer to it within provenance information.
</p>
</section>
-
+
+ <section>
+ <h2 id="provenance-context">Interpreting provenance information</h2>
+ <p><a class="internalDFN">Provenance information</a> describes relationships between artifacts, process executions and agents. As such, any given provenance information may contain information about several <a title="Entity" class="internalDFN">entities</a>. Within some provenance information, the entities thus described are identified by their <a class="internalDFN">Entity-URI</a>s.
+ </p>
+ <p>When interpreting provenance information, it is important to be aware that statements about several entities 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 entity.)
+ </p>
+ </section>
+
</section>
<!-- == Sect 2 =================================================================================== -->
@@ -184,7 +192,9 @@
<section>
<h2>Locating provenance information</h2>
<p>
- On the presumption that <a class="internalDFN">provenance information</a> is a resource that can be accessed using normal web retrieval, one needs to know a <a class="internalDFN">provenance-URI</a> 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 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.
+ When <a class="internalDFN">provenance information</a> is a resource that can be accessed using normal web retrieval, one needs to know a <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.
+ </p>
+ <p>Provenance information may be provided by several parties other than the provider of the original resource, each using different provenance-URIs, and each with different concerns. (It is possible that these different parties may provide contradictory provenance information.)
</p>
<p>
Once provenance information information is retrieved, one also needs to know how to locate the view of that resource within that provenance information. This view is an <a class="internalDFN">entity</a> and is identified by an <a class="internalDFN">entity-URI</a>.
@@ -204,31 +214,16 @@
<section>
<h2>Resource accessed by HTTP</h2>
- <p class="pending">
- The link relation indicating an entity_URI has been called "anchor" (as opposed to, say, "entity"), following terminology used for the HTTP Link element.
- </p>
- <p class="issue">
- Pick one or allow either of the following options for indicating the entity-URI?: I am inclined to specify the separate "provenance" and "anchor" and relation type, as that approach will be more consistent with the HTML and RDF options described below. If we do this, does it make sense to retain "anchor" as the link relation type? [Later] following discUssion with Paul, and with greater focus on specific Entity rather than context, I am now more inclined to use the second mechanism.
+ <p>
+ For a document 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">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>
- For a document 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">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).
- Two new link relation types for referencing provenance information are registered according to the template in <a href="#iana-considerations" class="sectionRef"></a>, and may be used as shown::
- <code>
- <pre class="pattern">
- Link: <cite>provenance-URI</cite>; rel="provenance"
- Link: <cite>entity-URI</cite>; rel="anchor"</pre>
- </code>
- or
+ A <code>provenance</code> link relation type for referencing provenance information is registered according to the template in <a href="#iana-considerations" class="sectionRef"></a>, and may be used as shown::
<code>
<pre class="pattern">
Link: <cite>provenance-URI</cite>; rel="provenance"; anchor="<cite>entity-URI</cite>"</pre>
</code>
- 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 information associated with the requested resource and that the associated entity is identified as <code><cite>entity-URI</cite></code>.
- </p>
- <p class="issue">
- [Yogesh]: I believe there is no guarantee that the provenance-URI will provide provenance information about the entity-URI. Suggest we use *should* rather than (implicitly) *must* to state that the returned provenance-uri should have provenance information about the resource view identified by the entity-uri.
-<br/><br/>
-I think I see your point, but I am concerned that making that possibility explicit here might be confusing for a reader. I wonder if this would be better served by a new sub-section after sect 1.2 about interpreting provenance information?
+ 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 information associated with the requested resource and that the associated entity is identified as <code><cite>entity-URI</cite></code>. (See also <a href="#interpreting-provenance-information" class="sectionRef"></a>.)
</p>
<p>
If no <code>anchor</code> link is provided then the <code><cite>entity-URI</cite></code> is assumed to be the URI of the resource.
@@ -237,14 +232,13 @@
At this time, the meaning of these 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 <code>provenance</code> link headers, indicating a number of different provenance resources that are known to the responding server, each providing provenance information about the accessed resource. Likewise, an HTTP response MAY include multiple <code>anchor</code> link headers, that indicate the resource may have provenance information associated with all of the indicated <code><cite>entity-URI</cite>s</code>.
+ An HTTP response MAY include multiple <code>provenance</code> link headers, indicating a number of different provenance resources that are known to the responding server, each providing provenance information 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="#provenance-services" class="sectionRef"></a>).
+ The presence of a <code>provenance</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>).
</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>
+ Provenance resources indicated in this way are not guaranteed to be authoritative. Trust in the linked provenance data must be determined separately from trust in the original resource, just as in the web at large, it is a users' 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. (Ssee also <a href="#security-considerations" class="sectionRef"></a>.)
</p>
</section>
@@ -523,6 +517,14 @@
</section>
+ <!-- <section class="informative"> -->
+ <section>
+ <h2>Provenance service discovery</h2>
+ <p>
+ This specification does not define any specific mechanism for discovering provenance services. Applications may use any appropriate mechanism, including but not limited to: prior configuration, search engines, service registries, etc.
+ </p>
+ </section>
+
</section>
<!-- ===================================================================================== -->
@@ -646,19 +648,6 @@
</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>
<!-- ===================================================================================== -->