--- a/paq/provenance-access.html Fri Aug 19 15:03:51 2011 +0100
+++ b/paq/provenance-access.html Fri Aug 19 18:24:09 2011 +0100
@@ -143,7 +143,7 @@
<dt><dfn>Service-URI</dfn></dt>
<dd>the URI of a <a class="internalDFN">provenance service</a>.</dd>
<dt><dfn>Resource</dfn></dt>
- <dd>a web resource, as <a href="http://www.w3.org/TR/webarch/#id-resources">described</a> by the Architecture of the World Wide Web [[WEBARCH]], section 2.2. A resource may be associated with multiple <a title="context" class="internalDFN">contexts</a> (see <a href="#provenance-context" class="sectionRef"></a> for discussion)</dd>
+ <dd>also referred to as <dfn>web resource</dfn>: a resource as <a href="http://www.w3.org/TR/webarch/#id-resources">described</a> by the Architecture of the World Wide Web [[WEBARCH]], section 2.2. A resource may be associated with multiple <a title="context" class="internalDFN">contexts</a> (see <a href="#provenance-context" class="sectionRef"></a> for discussion)</dd>
</dl>
</p>
@@ -159,7 +159,7 @@
This section has been drafted to address a number of concerns: (a) to avoid previous use of "Target" for the topic of a provenance assertion (cf. http://www.w3.org/2011/prov/track/issues/74), and (b) to clarify the use of different resources as views on a dynamic or variable subject of provenance.
</p>
<p>
- Fundamentally, <a class="internalDFN">provenance information</a> is <em>about</em> web resources, in the <a href="http://www.w3.org/TR/webarch/#id-resources">sense described</a> by the Architecture of the World Wide Web [[WEBARCH]]. In general, web resources may vary over time and context: e.g., a resource describing the weather in London changes from day-to-day, or one listing 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-varying web resources (e.g. the weather forecast for London on a particular day may have been derived from a particular set of Meteorological Office data).
+ Fundamentally, <a class="internalDFN">provenance information</a> is <em>about</em> <a class="internalDFN">resources</a>. In general, resources may vary over time and context: e.g., a resource describing the weather in London changes from day-to-day, or one listing 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-varying web resources (e.g. the 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 the notion of contexts. A <a class="internalDFN">context</a> is simply a web resource that is a contextualized view or instance of an original web 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 through its lifetime. Separate URIs for each individual revision would then be context-URIs, denoting the specification at a 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.
@@ -205,17 +205,20 @@
</ul>
These particular cases are selected as corresponding to primary current web protocol and data 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 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">4.1.1</a> and <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/#httplink">4.1.3</a>).
+ </p>
<section>
<h2>Resource 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 class="pending">
The link relation indicating a context_URI has been called "anchor" (as opposed to, say, "context"), following terminology used for the HTTP Link element.
</p>
<p class="issue">
- Pick one or allow either of the following?:
+ Pick one or allow either of the following options for indicating the context-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?
+ </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).
</p>
<p>
The same basic mechanism can be used for referencing provenance information, for which two new link relation types are registered according to the template in <a href="#iana-considerations" class="sectionRef"></a>:
@@ -232,14 +235,14 @@
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 context is identified as <code><cite>context-URI</cite></code>.
</p>
<p class="issue">
- - I believe there is no guarantee that the provenance-URI will provide provenance information about the context-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 context-uri.
+ [Yogesh]: I believe there is no guarantee that the provenance-URI will provide provenance information about the context-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 context-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 in sect 2 about interpreting provenance information?
</p>
<p>
If no <code>anchor</code> link is provided then the <code><cite>context-URI</cite></code> is assumed to be the URI of the resource.
</p>
- <p>
+ <p>
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>
@@ -269,7 +272,6 @@
<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="anchor" href="<cite>context-URI</cite>">
<title>Welcome to example.com</title>
@@ -320,7 +322,6 @@
<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>service-URI</cite>">
<link rel="anchor" href="<cite>context-URI</cite>">
<title>Welcome to example.com</title>
@@ -339,9 +340,6 @@
<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>
@@ -357,6 +355,16 @@
</p>
<p class="issue">
@@TODO: needs to be completed.
+ <br/><br/>
+ Discussion:
+ <br/><br/>
+ The containing RDF resource is the subject. For RDF documents, this is sometimes written as an empty URI-reference; e.g.<br/>
+ <code>
+ <rdf:Description rdf:about=""><br/>
+ <prov:hasProvenance rdf:resource="(provenance_URI)"/><br/>
+ </rdf:Description><br/>
+ </code>
+ (If publishing the RDF in a named graph, then use the URI of the graph.)
</p>
<p>
@@TODO: example
@@ -399,7 +407,6 @@
<!-- == Sect 4 =================================================================================== -->
-
<section>
<h2>Provenance discovery services</h2>
<p class="pending">
@@ -476,7 +483,7 @@
{
"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}",
+ "provenance_template": "http://example.info/provenance_service/provenance/?uri={uri}"
}
</pre>
</code>
@@ -492,7 +499,7 @@
<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}" ;
+ provds:provenance_template "http://example.info/provenance_service/provenance/?uri={uri}"
.
</pre>
</code>
@@ -811,6 +818,9 @@
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
+ The editors acknowledge the contribution and review from members of the provenance working group, and in particular detailed reviews and suggestions for improvement provided by Yogesh Simmhan, Olaf Hartig, ...
+ </p>
+ <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>
@@ -820,7 +830,7 @@
<section class="appendix">
<h2>Motivating scenario</h2>
<p class="pending">
- I propose to remove this appendix on publication.
+ I propose to replace this appendix with text based on Yogesh's walk-through of the scenario, renaming to be something like "Motivating scenario and examples"
</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>