--- a/paq/prov-aq.html Mon Nov 26 09:14:22 2012 +0000
+++ b/paq/prov-aq.html Mon Nov 26 11:08:57 2012 +0000
@@ -84,7 +84,7 @@
"<a href=\"http://doi.acm.org/10.1145/1349026.1349043\">http://doi.acm.org/10.1145/1349026.1349043</a>, "+
"<a href=\"http://dig.csail.mit.edu/2008/06/info-accountability-cacm-weitzner.pdf\">http://dig.csail.mit.edu/2008/06/info-accountability-cacm-weitzner.pdf</a> (alt)",
- "VOiD":
+ "VoID":
"Keith Alexander, Richard Cyganiak, Michael Hausenblas, Jun Zhao. "+
"<a href=\"http://www.w3.org/TR/void/\"><cite>Describing Linked Datasets with the VoID Vocabulary</cite></a>, "+
"W3C Interest Group Note 03 March 2011, "+
@@ -638,7 +638,7 @@
To facilitate service discovery, we recommend that RDF publication of dataset and service descriptions use the property <code>prov:hasProvenanceService</code> and the provenance service type <code>prov:ProvenanceService</code> as appropriate (see the appendix <a href="#prov-namespace" class="sectionRef"></a>).
</p>
<p>
- For example, a VOiD description [[VOiD]] of a dataset might indicate a provenance service providing information about that dataset, and by extension the resources it contains:
+ For example, a VoID description [[VoID]] of a dataset might indicate a provenance service providing information about that dataset:
</p>
<pre class="pattern">
<http://example.org/dataset/> a void:Dataset ;
@@ -674,8 +674,8 @@
which might result in an HTTP request for provenance looking like this:
</p>
<pre class="pattern">
-GET /provenance/service?<b>target</b>=http://www.example.com/entity&<b>steps</b>=2 HTTP/1.1
-Host: example.com</pre>
+ GET /provenance/service?<b>target</b>=http://www.example.com/entity&<b>steps</b>=2 HTTP/1.1
+ Host: example.com</pre>
<p>
Note that in this case, a "level 3" URI template feature is used [[URI-template]].
</p>
@@ -690,7 +690,7 @@
<section>
<h2>Forward provenance</h2>
<p>
- The mechanisms discussed in previous sections are primarily concerned with accessing historical provenance information, dealing with question such as:
+ The mechanisms discussed in previous sections are primarily concerned with how consumers access historical provenance information from publishers, dealing with questions such as:
</p>
<ul>
<li>what was this resource based upon?</li>
@@ -699,7 +699,7 @@
<li>when was it made?</li>
</ul>
<p>
- These questions can be turned around to consider the forward-looking use of a resource, with questions like:
+ These questions can be turned around to consider a publishers forward-looking use of a resource, like:
</p>
<ul>
<li>what new resources are based on this resource?</li>
@@ -708,22 +708,27 @@
<li><i>etc.</i></li>
</ul>
<p>
- Answering such questions is assumed to be based on cooperation of other parties who actually use a rsource (or maybe of search engines that can discover such usage). To facilitate such cooperation, a resource may have an associated "ping-back" URI which can be presented with forward provenance information about how the resource has been used. 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>. When the resource is used, and new provenance information created that refers to it, the user may perform an HTTP POST operation to the pingback URI where the POST request body contains the new provenance information in one of the recognized provenance formats. The for interoperability, ping-back receiving service SHOULD be able to accept al least PROV-O provenance presented as RDF/XML or Turtle.
+ 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>
- 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 artifact; 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:
+ 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.
+ </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:
</p>
<pre class="pattern">
C: GET /super-widget HTTP/1.1
C: Host: acme.example.org
S: 200 OK
- S: Link: <http://acme.example.org/provenance/super-widget>; rel=http://www.w3.org/ns/prov#hasProvenance
- S: Link: <http://acme.example.org/pingback/super-widget>; rel=http://www.w3.org/ns/prov#provPingback
+ S: Link: <http://acme.example.org/provenance/super-widget>;
+ rel=http://www.w3.org/ns/prov#hasProvenance
+ S: Link: <http://acme.example.org/pingback/super-widget>;
+ rel=http://www.w3.org/ns/prov#provPingback
:
(super-widget resource data)</pre>
<p>
- The first of the links in the response is the proveance-URI that has been described previously. The second is a separate 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 information may be submitted to the pingback thus:
</p>
<pre class="pattern">
C: POST /pingback/super-widget HTTP/1.1
@@ -731,19 +736,22 @@
C: Content-type: text/turtle
:
C:
- C: <http://wile-e.example.org/contraption> prov:tracedTo <http://acme.example.org/super-widget> .
+ C: <http://wile-e.example.org/contraption>
+ C: prov:wasDerivedFrom <http://acme.example.org/super-widget> .
- S: 200 Thanks!
- S: Link: <http://acme.example.org/provenance/super-widget>; rel=http://www.w3.org/ns/prov#hasProvenance;
+ S: 200 OK
+ S: Link: <http://acme.example.org/provenance/super-widget>;
+ rel=http://www.w3.org/ns/prov#hasProvenance;
anchor=http://acme.example.org/super-widget
- S: Link: <http://acme.example.org/pingback/super-widget>; rel=http://www.w3.org/ns/prov#provPingback;
+ S: Link: <http://acme.example.org/pingback/super-widget>;
+ rel=http://www.w3.org/ns/prov#provPingback;
anchor=http://acme.example.org/super-widget</pre>
<p>
- There is no required server response to a pingback POST request.
- In this example the pingback service responds with links to provenance and pingback for the original resource (note that the <code>Link:</code> headers returned contain explicit <code>anchor</code> parameters with the URI of the original resource; without these, the links would relate the indicated URIs to the POST request URI.
+ There is no required information in the server response to a pingback POST request.
+ In this example the pingback service responds with links to provenance and pingback for the original resource (note that the <code>Link:</code> headers returned contain explicit <code>anchor</code> parameters with the URI of the original resource; without these, the links would relate the indicated URIs to the POST request URI <code>http://acme.example.org/pingback/super-widget</code>).
</p>
<p>
- The only defined operation for a pingback resource is a POST, which is required to provide some provenance information that possible to the original resource with which the pingback is associated. A pingback service MAY respond to other requests, but no requirements are imposed on how it responds to such operations. In particular, it is not specified here how a pingback service should respond to an HTTP GET request.
+ The only defined operation for a pingback resource is a POST, which provides a PROV assertion about the original resource with which it is associated. A pingback service MAY respond to other requests, but no requirements are imposed on how it responds to such operations. In particular, it is not specified here how a pingback resource should respond to an HTTP GET request. This leaves open a possibility that the pingback resource MAY have the same URI as the original resource, provided that the original does not respond to POST in some different way.
</p>
</section>
@@ -766,6 +774,9 @@
</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>
+ <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.
+ </p>
</section>
<!-- ===================================================================================== -->