prov-dm examples have been added to the testcases/prov-dm folder
authorkbelhajj
Mon, 26 Nov 2012 11:25:03 +0000
changeset 5053 c27c4faa0797
parent 5052 49e70a1f02a3 (current diff)
parent 5051 bb51fe9d073d (diff)
child 5055 ddcc28d40625
prov-dm examples have been added to the testcases/prov-dm folder
--- a/mention/prov-mention.html	Mon Nov 26 11:23:25 2012 +0000
+++ b/mention/prov-mention.html	Mon Nov 26 11:25:03 2012 +0000
@@ -1039,7 +1039,7 @@
 which provenance of provenance can be expressed.</p>
 
 <p>
-In  applications where provenance is created by multiple parties over time, it is useful for provenance descriptions of one party to link to provenance descriptions of another party. To address this issue, this document introduces a relation allowing an entity description to be linked to another entity description occurring in another bundle.
+In  applications where provenance is created by multiple parties over time, it is useful for provenance descriptions created by one party to link to provenance descriptions created by another party. To address this issue, this document introduces a relation allowing an entity description to be linked to another entity description occurring in another bundle.
 </p>
 
 <p>The  <a href="http://www.w3.org/TR/2012/WD-prov-overview-20121211/">PROV Document Overview</a> describes the overall state of PROV, and should be read before other PROV documents.</p>
@@ -1080,8 +1080,57 @@
 
 
 
-    <section id="introduction"> 
-      <h2>Introduction</h2> 
+<section id="introduction"> 
+<h2>Introduction</h2> 
+
+<p>
+<a href="http://www.w3.org/TR/2012/CR-prov-dm-20121211/">Provenance</a>
+is a record that describes the people, institutions, entities, and
+activities involved in producing, influencing, or delivering a piece
+of data or a thing. The specifications [[!PROV-O]], [[!PROV-DM]],
+[[!PROV-N]], and [[PROV-XML]] have respectively defined the PROV
+ontology, the PROV conceptual model, the PROV notation, and the PROV
+XML schema, allowing provenance descriptions to be expressed,
+represented in various representations, and interchanged between systems across the Web. 
+</p>
+
+<p>The provenance of information is crucial in deciding whether information is to be trusted, how it should be integrated with other diverse information sources, and how to give credit to its originators when reusing it.  To support this, provenance should be trusted, and therefore, provenance of provenance is itself a critical aspect of an information infrastructure such as the Web. To this end, PROV introduces the concept of <a href="http://www.w3.org/TR/2012/CR-prov-dm-20121211/#concept-bundle">Bundle</a>: defined as a set of provenance descriptions,  it is a mechanism by which provenance of provenance can be expressed (see also <a href="http://www.w3.org/TR/2012/CR-prov-o-20121211/#Bundle">Bundle</a> [[!PROV-O]] and <a href="http://www.w3.org/TR/2012/WD-prov-xml-20121211/#term-Bundle">Bundle</a> [[PROV-XML]]). With bundles, blobs of provenance descriptions can be given names and can itself be regarded as entities, whose provenance can be described using PROV. </p>
+
+
+<verbatim>
+the key aspect of mention of is that you name the entity and the bundle in which the entity is described. The Bundle IS the specialization. ←
+… without mention, you can still link the entities, but you lose the ability to mention the bundle. ←
+
+Timothy Lebo: mentionOf's power comes in when you don't have control over the entire system. ←
+
+ a lab with multiple documents and multiple people. You just want to mention it, not repeat the provenance. ←
+… it's interesting to provide your own view on the entity that you're using. ←
+
+… as a primary producer, I wont' use mention of, but for anyone that wants to augment my Entiteis, they need mentionOf to do it. ←
+
+Curt Tilmes: when yoiu do your own provenance, you ond't need it, but metnionOf lets you "reach into" someone else's bundle. ←
+
+Hook Hua: having it formally in DM would uniformly manifest implementations in different encodigns. we're not relying on serializations to do the linking. ←
+
+
+Graham Klyne: in IETF, "experimental track", mention of is in this. ←
+
+Curt Tilmes: the key is not provenance expression/represtionation, ti's for analysis. ←
+
+
+Hook Hua: it is very important. ←
+
+… each bundle is handled by different institutions, gov entities. ←
+
+… interop is key here. ←
+
+Curt Tilmes: we have a lot of cases where data is processed, then next org processes. each uses their own bundles. ←
+
+… each needs a way to reference across those bundles. ←
+
+… seems that mentionOf provides a capability that will be needed at some point. ←
+
+</verbatim>
 
 </section> 
 
@@ -1095,7 +1144,7 @@
 <p>An entity <span class="name">e1</span> may be mentioned in a bundle <span class="name">b</span>, which contains some
  descriptions about this entity <span class="name">e1</span>: how <span class="name">e1</span> was generated and used, which activities <span class="name">e1</span> is involved with, the agents <span class="name">e1</span> is attributed to, etc. Other bundles may contain other descriptions about the same entity <span class="name">e1</span>.
 Some applications may want to interpret
-this entity <span class="name">e1</span> with respect to the descriptions found in the bundle <span class="name">b</span> it occurs in. To this end, PROV allows a new entity <span class="name">e2</span> to be created, which is a specialization of the preceding entity <span class="name">e1</span>, and which presents an additional aspect:  the bundle <span class="name">b</span> containing some descriptions of <span class="name">e1</span>.  With this relation, applications that process <span class="name">e2</span>
+the latter descriptions of entity <span class="name">e1</span> with respect to the descriptions found in the bundle <span class="name">b</span> it occurs in. To this end, PROV allows a new entity <span class="name">e2</span> to be created, which is a specialization of the preceding entity <span class="name">e1</span>, and which presents an additional aspect:  the bundle <span class="name">b</span> containing some descriptions of <span class="name">e1</span>.  With this relation, applications that process <span class="name">e2</span>
 can know that the attributes of <span class="name">e2</span> may have been computed according to the descriptions of <span class="name">e1</span> in <span class="name">b</span>.</p>
 
 
--- a/paq/prov-aq.html	Mon Nov 26 11:23:25 2012 +0000
+++ b/paq/prov-aq.html	Mon Nov 26 11:25:03 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">
   &lt;http://example.org/dataset/&gt; 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&amp;<b>steps</b>=2 HTTP/1.1
-Host: example.com</pre>
+  GET /provenance/service?<b>target</b>=http://www.example.com/entity&amp;<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: &lt;http://acme.example.org/provenance/super-widget&gt;; rel=http://www.w3.org/ns/prov#hasProvenance
-  S: Link: &lt;http://acme.example.org/pingback/super-widget&gt;; rel=http://www.w3.org/ns/prov#provPingback
+  S: Link: &lt;http://acme.example.org/provenance/super-widget&gt;; 
+           rel=http://www.w3.org/ns/prov#hasProvenance
+  S: Link: &lt;http://acme.example.org/pingback/super-widget&gt;; 
+           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: &lt;http://wile-e.example.org/contraption&gt; prov:tracedTo &lt;http://acme.example.org/super-widget&gt; .
+  C: &lt;http://wile-e.example.org/contraption&gt; 
+  C:     prov:wasDerivedFrom &lt;http://acme.example.org/super-widget&gt; .
 
-  S: 200 Thanks!
-  S: Link: &lt;http://acme.example.org/provenance/super-widget&gt;; rel=http://www.w3.org/ns/prov#hasProvenance;
+  S: 200 OK
+  S: Link: &lt;http://acme.example.org/provenance/super-widget&gt;; 
+           rel=http://www.w3.org/ns/prov#hasProvenance;
            anchor=http://acme.example.org/super-widget
-  S: Link: &lt;http://acme.example.org/pingback/super-widget&gt;; rel=http://www.w3.org/ns/prov#provPingback;
+  S: Link: &lt;http://acme.example.org/pingback/super-widget&gt;; 
+           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>
  
 <!-- ===================================================================================== -->