preparing prov-links
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Mon, 25 Mar 2013 16:15:32 +0000
changeset 5981 0b00701898ab
parent 5980 3a438b8b9b9b (current diff)
parent 5979 cd9d155c1be3 (diff)
child 5982 a81494bfde7d
preparing prov-links
--- a/paq/prov-aq.html	Mon Mar 25 16:15:21 2013 +0000
+++ b/paq/prov-aq.html	Mon Mar 25 16:15:32 2013 +0000
@@ -18,7 +18,7 @@
 -->
     <!-- Include bibliography file defined for PROV-DM: -->
     <script src="../model/provbib.js" class="remove"></script>
-    <!-- Define bibliography specific for PROV-AQ: @@TODO merge all additional bibliographies for PROV documents? -->
+
     <script class='remove'>
       var addExtraReferences = function() {
           for (var k in extraReferences)
@@ -117,7 +117,7 @@
           // subtitle   :  "an excellent document",
 
           // if you wish the publication date to be other than today, set this
-           publishDate:  "2013-03-12",
+          // publishDate:  "2013-03-12",
 
           // if the specification's copyright date is a range of years, specify
           // the start date here:
@@ -268,7 +268,7 @@
           </li>
         </ul>
       <p>
-        Most mechanisms described in this note are independent of the provenance format used, and may be used to access provenance in any available format.  For interoperable provenance publication, use of PROV-O represented in a standardized RDF format is recommended.  Where alternative formats are available, selection may be made by content negotiation.
+        Most mechanisms described in this note are independent of the provenance format used, and may be used to access provenance in any available format.  For interoperable provenance publication, use of PROV represented in any of its specified formats is recommended.  Where alternative formats are available, selection may be made by HTTP content negotiation [[HTTP11]].
       </p>
       <p>
         For ease of reference, the main body of this document contains some links to external web pages.  Such links are distinguished from internal references thus: <a href="http://www.w3.org/2011/prov/wiki/Main_Page" class="externalRef">W3C Provenance Working Group</a>.
@@ -477,11 +477,14 @@
       </p>
       <p>Provenance records may be offered by several <a class="internalDFN">provider</a>s other than that of the original resource publisher, each with different concerns, and presenting provenance at different locations.  It is possible that these different providers may present contradictory provenance.
       </p>
+      <p class="note">
+        The mechanisms used with HTTP and HTML/RDF are slightly inconsistent in their approach to specifying <code><cite>target-URI</cite></code> values.  In HTTP <code>Link:</code> headers, an optional <code>anchor=</code> parameter may be supplied for each such header.  In HTML and RDF, separate <code>#has_anchor</code> relations are defined.  It was felt that avoiding reinvention of existing mechanisms was more important than being completely consistent.  If anchors are processed as described in <a href="#interpreting-provenance-records" class="sectionRef"></a> (3rd paragraph), observable behaviour across all approaches should be consistent.
+      </p>
 
       <section>
         <h2>Resource accessed by HTTP</h2>
         <p>
-          For a resource accessible using HTTP, a provenance record may be indicated using an HTTP <code>Link</code> header field, as defined by <a href="http://tools.ietf.org/html/rfc5988#section-5" 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 record may be indicated using an HTTP <code>Link:</code> header field, as defined by <a href="http://tools.ietf.org/html/rfc5988#section-5" 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>has_provenance</code> link relation type for referencing a provenance record may be used thus:
@@ -520,11 +523,6 @@
   S:  :
   S: &lt;/html&gt;
         </pre>
-        <p class="TODO">
-          Tim comment (14): Should a reference to the forward provenance section be included, too?
-          <br/>
-          [GK] I don't see the need.  Forward provenance is not primarily *about* the same resource, IMO, and I think mentioning it here could be more confusing than helpful.
-        </p>
 
         <section>
           <h2>Specifying Provenance Query Services</h2>
@@ -626,9 +624,6 @@
         <p>
           An HTML document header MAY present multiple <code><cite>provenance-URI</cite></code>s over several <code>#has_provenance</code> link elements, indicating a number of different provenance records that are known to the publisher of the document, each of which may provide provenance about the document (see <a href="#interpreting-provenance-records" class="sectionRef"></a>).
         </p>
-        <p class="TODO">
-          Check with Dong:  I think the cross reference should make the assumptions explicit.  I, too, feel this material is not strictly needed, but was previously asked to add some clarification about mutliple links.
-        </p>
 
         <section>
           <h2>Specifying Provenance Query Services</h2>
@@ -652,10 +647,6 @@
           <p>
             There MAY be multiple <code>#has_query_service</code> link elements, and these MAY appear in the same document as <code>#has_provenance</code> link elements (though we do not anticipate that <code>#has_provenance</code> and <code>#has_query_service</code> link relations will commonly be used together).
           </p>
-        <p class="TODO">
-          Check with Dong:  This test was already revised in response to earlier comment.
-          I, too, feel this material is not strictly needed, but was previously asked to add some clarification.
-        </p>
 
         </section>
 
@@ -701,7 +692,7 @@
     <section>
       <h2>Provenance query services</h2>
       <p>
-        This section describes a simple HTTP query protocol for accessing provenance records, and also a mechanism for locating a SPARQL service endpoint [[SPARQL-SD]]. The HTTP protocol specifies HTTP operations for retrieving provenance records from a provenance query service, following the approach of the SPARQL Graph Store HTTP Protocol [[SPARQL-HTTP]].
+        This section describes a simple HTTP query protocol for accessing provenance records, and also a mechanism for locating a SPARQL service endpoint [[SPARQL-SD]]. The HTTP query protocol specifies HTTP operations [[HTTP11]] for retrieving provenance records from a provenance query service, following the approach of the SPARQL Graph Store HTTP Protocol [[SPARQL-HTTP]].
       </p>
       <p>
         The introduction of query services is motivated by the following possible considerations: 
@@ -759,12 +750,8 @@
       <!-- <section class="informative"> -->
       <section>
         <h2>Provenance query service description</h2>
-        <p class="TODO">
-          Review.  Stian suggests recommending use of JSON-LD.  I am resisting this because it is clearly allowed by "RDF (in any of its common serializations as determined by HTTP content negotiation)", focusing on a particular format as part of the underlying mechanism seems to go against REST principles, and at this stage it seems that promoting any particular format will draw objections from proponents of other formats.  I've taken a different tack, making the text more open about possible service description formats, while specifically presenting a description based on the RDF model.
-        </p>
         <p>
-          Dereferencing a <a class="internalDFN">service-URI</a> yields a service description. The service description presented here may be supplied as RDF (in any of its common serializations as determined by HTTP content negotiation), and it may contain descriptions of one or more available query mechanisms.  Each query mechanism is associated with an RDF type, as explained below.
-          (The presentation here of RDF service descriptions does not preclude use of non-RDF formats selectable by HTTP content negotiation.)
+          Dereferencing a <a class="internalDFN">service-URI</a> yields a service description. The service description may be in any format selectable through content negotiation, and it may contain descriptions of one or more available query mechanisms.  The format described here uses RDF, serialized as Turtle [[TURTLE]], but any selectable RDF serialization could be used.  In this RDF service description, each query mechanism is associated with an RDF type, as explained below.
         </p>
         <p>
           The overall structure of a service description is as follows:
@@ -919,7 +906,7 @@
         </p>
         <p>
           The direct HTTP query service may return provenance in any available format.
-          For interoperable provenance publication, use of the PROV-O vocabulary [[PROV-O]] represented in a standardized RDF format is recommended.  Where alternative formats are available, selection may be made by content negotiation, using <code>Accept:</code> header fields in the HTTP request.
+          For interoperable provenance publication, use of PROV represented in any of its specified formats is recommended.  Where alternative formats are available, selection may be made by content negotiation, using <code>Accept:</code> header fields in the HTTP request.
           Services MUST identify the <code>Content-Type</code> of the provenance returned.
         </p>
         <p>
@@ -1154,10 +1141,6 @@
     <section class='appendix'>
       <h2 id="prov-namespace">Terms added to prov: namespace</h2>
 
-      <p class="TODO">
-        Possible renaming of service description relations to lowercase-only forms?
-      </p>
-
       <p>
         This specification defines the following additional names in the provenance namespace
         with URI <a href="http://www.w3.org/ns/prov#" class="externalRef">http://www.w3.org/ns/prov#</a>.
@@ -1242,17 +1225,35 @@
     
     <section class='appendix'>
       <h2>Changes log</h2>
+
       <p class=TODO>
-        Always update copy of mercurial change log. Below are changes since 19 June.
+        Always update copy of mercurial change log in review copies.<br/>
+        Remove this section on final publication.
+      </p>
+
+      <section>
+        <h2>Changes since 20130312 publication</h2>
+        <!--
+            hg log -r tip:b665bc9447ce \
+              - -template "<dt>{date|isodate} {node|short} {author}</dt><dd>{desc}</dd>\n" \
+              prov-aq.html
+          -->
+        <dl>
+<dt>2013-03-25 16:11 +0000 bb6113fa4e67 Graham Klyne</dt><dd>Clean up TODO flags</dd>
+<dt>2013-03-25 15:48 +0000 700014e20954 Graham Klyne</dt><dd>Add note in section 3 to acknowledge ISSUE-628 (but no substantive change)</dd>
+<dt>2013-03-25 15:30 +0000 4f3bbad454f0 Graham Klyne</dt><dd>Tune service description text to make it clear that service descriptions other than RDF are OK</dd>
+<dt>2013-03-25 15:21 +0000 b665bc9447ce Graham Klyne</dt><dd>Revised description of recommended provenance formats per WG discussion.  Added reference to HTTP 1.1 spec.</dd>
+        </dl>
+      </section>
+
+      <section>
+        <h2>Changes since 20120619 publication</h2>
         <!--
             hg log -r tip:d0af0446868d \
               - -template "<dt>{date|isodate} {node|short} {author}</dt><dd>{desc}</dd>\n" \
               prov-aq.html
           -->
-      </p>
-      <section>
-        <h2>Changes since 20120619 publication</h2>
-          <dl>
+        <dl>
 <dt>2013-02-27 16:23 +0000 35385cbbfb9f Graham Klyne</dt><dd>Further refinements and bug fixes in the forward provenance section</dd>
 <dt>2013-02-27 15:33 +0000 2dfd7fac85c9 Graham Klyne</dt><dd>Merge</dd>
 <dt>2013-02-27 15:19 +0000 bae275eaaf81 Stian Soiland-Reyes</dt><dd>Added Stian as PROV-AQ author</dd>