--- a/model/ProvenanceModel.html Sat Aug 06 09:11:42 2011 +0100
+++ b/model/ProvenanceModel.html Sat Aug 06 09:11:59 2011 +0100
@@ -582,13 +582,95 @@
<h3>Derivation</h3>
+<div class='note'>This section remains very much work in progress. Many issues have been raised and discussed, and for several of them, consensus still remains difficult to reach. The presentation of derivation has been altered, and new names adopted, in the hope of clarifying this notion. Key outstanding issues include:
+<ul>
+<li> what is the exact relationship between entities attributes and derivation;
+<li> transitive nature of derivation.
+</ul></div>
+
<p><dfn id="dfn-Derivation">Derivation</dfn> expresses that some characterized thing is transformed from, created from, or affected by another characterized thing. </p>
-<p>A Derivation assertion, <b>isDerivedFrom(b1,b2)</b>:
+<p>PIL offers two different kinds of assertions by which asserters can formulate derivations. The first one is tightly connected to the notion of process execution, whereas the second one is not. The first kind of assertion is particularly suitable for asserters who have an intimate knowledge of process executions, and offers a more precise description of derivation, whereas the second does not put such a requirement on the asserter, and allows a less precise description of derivation to be asserted. From these assertions, further derivations can be inferred by transitive closure. </p>
+
+<section>
+<h4>Process Execution Linked Derivation Assertion</h4>
+
+<p>A process execution linked derivation, which, by definition of derivation, expresses that some characterized thing is transformed from, created from, or affected by another characterized thing, entails a process execution that transforms, creates or affects this characterized thing.</pe>
+
+<p>In its full form, a process-execution linked derivation assertion, noted <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>:
<ul>
-<li> refers to an entity <b>b1</b>, denoting the generated characterized thing;
-<li> refers to an entity <b>b2</b>, denoting the used characterized thing.
+<li> refers to an entity <b>e2</b>, denoting the used characterized thing;
+<li> refers to an entity <b>e1</b>, denoting the generated characterized thing;
+<li> refers to process execution <b>pe</b>;
+<li> contains a role <b>r2</b>.
+<li> contains a role <b>r1</b>.
</ul>
+This assertion expresses that the process execution <b>pe</b>, by
+using the thing denoted by <b>e1</b> with role <b>r1</b> derived the
+thing denoted by entity <b>e2</b> and generated it with
+role <b>r2</b>.
+</p>
+
+<p>
+The following inference rule allows generation and use assertions to be inferred.
+</p>
+
+<div class="inference">
+If <b>isDerivedFrom(e2,e1,pe,r2,r1)</b> holds, then <b>isGeneratedBy(e2,pe,r2)</b> and <b>uses(pe,e1,r1)</b> also hold.
+</div>
+
+
+<p>For convenience, PIL allows for a compact, process-execution linked derivation assertion, written <b>isDerivedFrom(e2,e1)</b>, which:
+<ul>
+<li> refers to an entity <b>e2</b>, denoting the generated characterized thing;
+<li> refers to an entity <b>e1</b>, denoting the used characterized thing.
+</ul>
+</p>
+
+
+<p>The compact version has the same meaning as the fully formed process-execution linked derivation, except that a process execution is known to exist, though it does not need to be asserted.
+This is formalized by the following inference rule, referred to as <em>process execution introduction</em>:<br/>
+<div class='inference'>
+If <b>isDerivedFrom(e2,e1)</b> holds, then there exists a process execution <b>pe</b>, and roles <b>r1</b>,<b>r2</b>,
+such that:
+ <b>isGeneratedBy(e2,pe,r2)</b> and <b>uses(pe,e1,r1)</b>.
+</div></p>
+
+
+
+
+<p>If <b>e2</b> is derived from <b>e1</b>, then
+this means that the thing represented by <b>e1</b> has an influence on the thing represented by <b>e2</b>, which is captured by a dependency between their attribute values; it also implies temporal ordering. These are specified as follows:</p>
+
+<p>Given a process execution <b>pe</b>, entities <b>e1</b> and <b>e2</b>, roles <b>r1</b> and <b>r2</b>, if the assertion <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>
+or <b>isDerivedFrom(e2,e1)</b> holds, if and only if:
+ the values of some attributes
+of <b>e2</b> are partly or fully determined by the values of some
+attributes of <b>e1</b>.</li>
+
+<div class='note'>Should this dependency of attributes be made explicit as argument of the derivation? By making it explicit, we would allow someone to verify the validity of the derivation.</div>
+</p>
+
+
+<p>Given a process execution <b>pe</b>, entities <b>e1</b> and <b>e2</b>, roles <b>r1</b> and <b>r2</b>, if the assertion <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>
+or <b>isDerivedFrom(e2,e1)</b> holds, then
+the use
+of characterized thing denoted by <b>e1</b> precedes the generation of
+the characterized thing denoted by <b>e2</b>.
+</p>
+
+
+
+<p>
+Note that inferring derivation from use and generation does not hold
+in general. Indeed, when a generation <b>isGeneratedBy(e2,pe,r2)</b>
+precedes <b>uses(pe,e1,r1)</b>, for
+some <b>e1</b>, <b>e2</b>, <b>r1</b>, <b>r2</b>, and <b>pe</b>, one
+cannot infer derivation <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>
+or <b>isDerivedFrom(e2,e1)</b> since the values of attributes
+of <b>e2</b> cannot possibly be determined by the values of attributes
+of <b>e1</b>, given the creation of <b>e2</b> precedes the use
+of <b>e1</b>.
</p>
<p>
@@ -597,60 +679,100 @@
</pre>
</p>
+<p>A further inference is permitted from the compact version of derivation:
+<div class='inference'>
+Given a process execution <b>pe</b>, entities <b>e1</b> and <b>e2</b>, and role <b>r2</b>,
+if <b>isDerivedFrom(e2,e1)</b> and <b>isGeneratedBy(e2,pe,r2)</b> hold, then there exists a role <b>r1</b>,
+such that <b>uses(pe,e1,r1)</b> also holds.
+</div>
+This inference is justified by the fact that <b>e2</b> is generated by at most one process execution. Hence, this process execution is also the one that uses <b>e1</b>.
+</p>
-<p>From an assertion <b>isDerivedFrom(B,A)</b>, the values of some
-attributes of B are at least partially determined by the values
-of some attributes of A.</p>
+<div class='note'>There is a suggestion by Simon that this notion of derivation is only meaningful in the context of an account. <a href="http://lists.w3.org/Archives/Public/public-prov-wg/2011Aug/0101.html">See email</a>. It is not clear it is the case anymore. However, the inference above is only meaning full if unicity of generation hold.</div>
+
+
+<p>We note that the "symmetric" inference, does not hold.
+From <b>isDerivedFrom(e2,e1)</b> and <b>uses(pe,e1)</b>, one cannot
+derive <b>isGeneratedBy(e2,pe,r2)</b> because <b>e1</b> may be used by
+many process execution, not all of them generating <b>e2</b>.</p>
-<p>Given an assertion <b>isDerivedFrom(B,A)</b>, one can infer that the use
-of characterized thing denoted by <b>A</b> precedes the generation of
-the characterized thing denoted by <b>B</b>.
+</section>
<section>
-<h4>Relationship between derivation and process execution</h4>
+<h4>Process Execution Independent Derivation Assertion</h4>
-<p>A derivation, which by definition expresses that some characterized thing is transformed from, created from, or affected by another characterized thing, entails a process execution that transforms, creates or affects this characterized thing.</p>
-<p>This is formalized by the following inference rule, referred to as <em>process execution introduction</em>:<br/>
-if <b>isDerivedFrom(e1,e0)</b> holds, then there exists a process execution <b>pe</b>, and roles <b>r0</b>,<b>r1</b>,
-such that:
- <b>isGeneratedBy(e1,pe,r1)</b> and <b>uses(pe,e0,r0)</b>.</p>
-<p>
-The converse inference does not hold. Indeed, when a generation <b>isGeneratedBy(e1,pe,r1)</b> precedes <b>uses(pe,e0,r0)</b>, for some <b>e0</b>, <b>e1</b>, <b>r0</b>, <b>r1</b>, and <b>pe</b>, one cannot infer derivation <b>isDerivedFrom(e1,e0)</b> since the values of attributes of <b>e1</b> cannot possibly be determined by the values of attributes of <b>e0</b>, given the creation of <b>e1</b> precedes the use of <b>e0</b>.
+<p>A process execution independent derivation states the existence of a derivation, by any means whether direct or not, and regardless of any process executions. </p>
+
+<p>A process execution independent derivation, written <b>isEventuallyDerivedFrom (e2, e1)</b>,
+<ul>
+<li> refers to an entity <b>e2</b>, denoting the used characterized thing;
+<li> refers to an entity <b>e1</b>, denoting the generated characterized thing;
+</ul>
+
+
+<p>If <b>e2</b> is derived (isEventuallyDerivedFrom) from <b>e1</b>, then
+this means that the thing represented by <b>e1</b> has an influence on the thing represented by <b>e2</b>,
+ which at the minimum implies temporal ordering, specified as follows:</p>
+
+<p>Given two entities <b>e1</b> and <b>e2</b>, if the assertion <b>isEventuallyDerivedFrom(e2,e1)</b>
+ holds, then:
+generation of the characterized thing denoted by <b>e1</b> precedes the generation of
+the characterized thing denoted by <b>e2</b>.
</p>
+<p>Note that temporal ordering is between generations of <b>e1</b>
+and <b>e2</b>, as opposed to process execution linked derivation,
+which implied temporal ordering between the use of <b>e1</b> and
+generation of <b>e2</b>. Indeed, in the case of
+isEventuallyDerivedFrom, nothing is known about the use of <b>e1</b>,
+since there is no associated process execution.</p>
+
+<div class='note'>Should we link isEventuallyDerivedFrom to attributes as we did for isDerivedFrom? If so, this type of inference should be presented upfront, for both.</div>
+
+
+
+
</section>
+
<section>
-<h4>Transitivity</h4>
+<h4>Transitive Derivation</h4>
-<p>The relationship <b>isDerivedFrom</b> is transitive. Indeed, given <b>isDerivedFrom(e2,e1)</b> and <b>isDerivedFrom(e1,e0)</b>, <b>e2</b> is transformed from (resp. created from/affected by)
-<b>e1</b>, which in turn is transformed from (resp. created from/affected by) <b>e0</b>. So,
-<b>e2</b> is indirectly transformed from (resp. created from/affected by)
-<b>e0</b>.
+<p>
+If <b>isDerivedFrom(e2,e1)</b> holds because attribute <b>a2.1</b> of <b>e2</b> is determined by attribute <b>a1.1</b> of <b>e1</b>,
+and if <b>isDerivedFrom(e3,e2)</b> holds because attribute <b>a3.1</b>of <b>e3</b> is determined by attribute <b>a2.2</b> of <b>e1</b>, it is not necessary the case that an attribute of <b>e3</b> is determined by an attribute of <b>e1</b>, so, an asserter may not be able to assert <b>isDerivedFrom(e3,e1)</b>. Hence, constraints on attributes invalidate transitivit in the general case.
</p>
-<p>The relationship <dfn id="dfn-isDerivedFrom+">isDerivedFrom+</dfn> is the transitive closure of <b>isDerivedFrom</b>.</p>
+<p>However, there is sense that <b>e3</b> still depends on <b>e1</b>, since <b>e3</b> could not be generated without <b>e1</b> existing. Hence, we introduce a weaker notion of derivation, which is transitive.</p>
-<p>Whereas <b>isDerivedFrom(e1,e0)</b>is an assertion that corresponds to a single process execution, <b>isDerivedFrom+(e1,e0)</b> is obtained by transitive closure <b>isDerivedFrom</b>.
-In addition, this specification introduces a further assertion <b>isDerivedFromInMultipleSteps(e1,e0)</b>, which may correspond to one or more process executions. The inference rule above (how do you reference?) cannot be used on this assertion, as the number of Process Executions involved in the derivation is not known.</p>
+<p>The relationship <dfn id="dfn-dependsOn">dependsOn</dfn> is defined as follows:
+<ul>
+<li>If <b>isDerivedFrom(e2,e1)</b> or <b>isDerivedFrom(e2,e1,pe,r2,r1)</b> holds, then <b>dependsOn(e2,e1)</b>.</li>
+<li>If <b>isEventuallyDerivedFrom(e2,e1)</b> holds, then <b>dependsOn(e2,e1)</b>.</li>
+<li>If <b>dependsOn(e3,e2)</b> and <b>dependsOn(e2,e1)</b> hold, then <b>dependsOn(e3,e1)</b>.</li>
+</ul>
+
+<p>We note that <b>dependsOn</b> cannot be asserted but can only be inferred.</p>
</section>
-<div class='issue'>Is derivation transitive? If so, it should not be introduced as an assertion. This is <a href="http://www.w3.org/2011/prov/track/issues/45">ISSUE-45</a>.</div>
+
+
+<div class='pending'>Is derivation transitive? If so, it should not be introduced as an assertion. This is <a href="http://www.w3.org/2011/prov/track/issues/45">ISSUE-45</a>.</div>
<div class='issue'>Should derivation have a time? Which time? This is <a href="http://www.w3.org/2011/prov/track/issues/43">ISSUE-43</a>.</div>
<div class='issue'>Should we specifically mention derivation of agents? This is <a href="http://www.w3.org/2011/prov/track/issues/42">ISSUE-42</a>.</div>
-<div class='issue'> Transitivity does not seem to follow from above definition. This is <a href="http://www.w3.org/2011/prov/track/issues/56">ISSUE-56</a>.</div>
+<div class='pending'> Transitivity does not seem to follow from above definition. This is <a href="http://www.w3.org/2011/prov/track/issues/56">ISSUE-56</a>.</div>
-<div class='issue'> What's the difference between one step and multi-step derivation assertion. Justification of why one entity can be generated at most once. Multi-step derivation is also transitive. This is all in <a href="http://www.w3.org/2011/prov/track/issues/67">ISSUE-67</a>.</div>
+<div class='pending'> What's the difference between one step and multi-step derivation assertion. Justification of why one entity can be generated at most once. Multi-step derivation is also transitive. This is all in <a href="http://www.w3.org/2011/prov/track/issues/67">ISSUE-67</a>.</div>
</section>
@@ -951,7 +1073,7 @@
each other.
</p>
-<div class='issue'>Revision should be a class not a property. This is <a href="http://www.w3.org/2011/prov/track/issues/48">ISSUE-48</a>.</div>
+<div class='pending'>Revision should be a class not a property. This is <a href="http://www.w3.org/2011/prov/track/issues/48">ISSUE-48</a>.</div>
<div class='pending'> What's the difference with derivation? Is it necessary? This is <a href="http://www.w3.org/2011/prov/track/issues/61">ISSUE-61</a>.</div>
@@ -960,14 +1082,36 @@
<section id="concept-Participation">
<h3>Participation</h3>
-<div class='issue'>Suggested definition for participation. This is <a href="http://www.w3.org/2011/prov/track/issues/49">ISSUE-49</a>.</div>
+<p> <dfn id="dfn-Participation">Participation</dfn> represents the involvment of a thing in an activity. It can be asserted or inferred.</p>
+
+
+<p>The construct <dfn id="dfn-hasParticipant">hasParticipant</dfn>, noted <b>hasParticipant(pe,e)</b>,
+<ul>
+<li> contains a process execution <b>pe</b>;
+<li> contains an entity <b>e</b>;
+</ul>
+
+
+Given a process execution <b>pe</b> and entity <b>e</b>, <b>hasParticipant(pe,e)</b> holds if and only if:
+<ul>
+<li> <b>uses(pe,e)</b> holds, or</li>
+<li> <b>isControlledBy(pe,e)</b> holds, or</li>
+<li> <b>isComplementOf(e1,e)</b> holds for some entities <b>e1</b>, and
+ <b>hasParticipant(pe,e1)</b> some process execution <b>pe</b>.</li>
+</ul>
+
+
+
+<div class='note'>Is there a need for a similar concept that includes generated entities?</div>
+
+<div class='pending'>Suggested definition for participation. This is <a href="http://www.w3.org/2011/prov/track/issues/49">ISSUE-49</a>.</div>
+
</section>
<section id="concept-ProvenanceContainer">
<h3>Provenance Container</h3>
-
<p>A <dfn id="dfn-ProvenanceContainer">Provenance Container</dfn> is an identifiable wrapper for a set of PIDM constructs, which allows for additional meta-information pertaining to these constructs to be expressed. A provenance container MAY contain other provenance containers.</p>
<p>Such meta-information may be asserter, date of creation, justification for assertions, and cryptographic signature. </p>
@@ -1117,7 +1261,7 @@
<li>Language constructs are represented as <b>name(arg0, arg1, ...)</b>, where the name of the construct occurs first, and is followed by its arguments.</li>
<li>For use, generation, and derivation event, the first argument is the 'effect' (i.e. most recent item) and the second argument is the 'cause' (i.e. least recent item). This order is compatible with the temporal layout of the graphical notation.
</li>
-<li> BNF grammar for the Provenance Abstract Syntax Notation,
+<li> Preliminary BNF grammar for the Provenance Abstract Syntax Notation
<pre data-include='grammar.html'></pre>
</li>
</ul>
--- a/model/derivation.html Sat Aug 06 09:11:42 2011 +0100
+++ b/model/derivation.html Sat Aug 06 09:11:59 2011 +0100
@@ -219,24 +219,31 @@
<p>A process execution independent derivation states the existence of a derivation, by any means whether direct or not, and regardless of any process executions. </p>
-<p>A process execution independent derivation, written isEventuallyDerivedFrom (e2, e1)</b>
+<p>A process execution independent derivation, written <b>isEventuallyDerivedFrom (e2, e1)</b>,
<ul>
<li> refers to an entity <b>e2</b>, denoting the used characterized thing;
<li> refers to an entity <b>e1</b>, denoting the generated characterized thing;
</ul>
-<p>If <b>e2</b> is derived from <b>e1</b>, then
-this means that the thing represented by <b>e1</b> has an influence on the thing represented by <b>e2</b>, which is captured by a dependency between their attribute values; it also implies temporal ordering. These are specified as follows:</p>
+<p>If <b>e2</b> is derived (isEventuallyDerivedFrom) from <b>e1</b>, then
+this means that the thing represented by <b>e1</b> has an influence on the thing represented by <b>e2</b>,
+ which at the minimum implies temporal ordering, specified as follows:</p>
<p>Given two entities <b>e1</b> and <b>e2</b>, if the assertion <b>isEventuallyDerivedFrom(e2,e1)</b>
holds, then:
-that the use
-of characterized thing denoted by <b>e1</b> precedes the generation of
+generation of the characterized thing denoted by <b>e1</b> precedes the generation of
the characterized thing denoted by <b>e2</b>.
</p>
-<div class='note'>Should we like isEventuallyDerivedFrom to attributes as we did for isDerivedFrom? If so, this type of inference should be presented upfront, for both.</div>
+<p>Note that temporal ordering is between generations of <b>e1</b>
+and <b>e2</b>, as opposed to process execution linked derivation,
+which implied temporal ordering between the use of <b>e1</b> and
+generation of <b>e2</b>. Indeed, in the case of
+isEventuallyDerivedFrom, nothing is known about the use of <b>e1</b>,
+since there is no associated process execution.</p>
+
+<div class='note'>Should we link isEventuallyDerivedFrom to attributes as we did for isDerivedFrom? If so, this type of inference should be presented upfront, for both.</div>
@@ -248,14 +255,20 @@
<h4>Transitivity</h4>
-<p>Show why the attributes invalidates transitivity of <b>isDerivedFrom</b>.
+<p>
+If <b>isDerivedFrom(e2,e1)</b> holds because attribute <b>a2.1</b> of <b>e2</b> is determined by attribute <b>a1.1</b> of <b>e1</b>,
+and if <b>isDerivedFrom(e3,e2)</b> holds because attribute <b>a3.1</b>of <b>e3</b> is determined by attribute <b>a2.2</b> of <b>e1</b>, it is not necessary the case that an attribute of <b>e3</b> is determined by an attribute of <b>e1</b>, so, an asserter may not be able to assert <b>isDerivedFrom(e3,e1)</b>. Hence, constraints on attributes invalidate transitivit in the general case.
</p>
-<p>The relationship <dfn id="dfn-isDerivedFrom+">isDerivedFrom+</dfn> is the transitive closure of <b>isDerivedFrom</b> and <b>isDerivedFromInMultipleSteps</b>.</p>
+<p>However, there is sense that <b>e3</b> still depends on <b>e1</b>, since <b>e3</b> could not be generated without <b>e1</b> existing. Hence, we introduce a weaker notion of derivation, which is transitive.</p>
-
+<p>The relationship <dfn id="dfn-dependsOn">dependsOn</dfn> is defined as follows:
+<ul>
+<li>If <b>isDerivedFrom(e2,e1)</b> or <b>isDerivedFrom(e2,e1,pe,r2,r1)</b> holds, then <b>dependsOn(e2,e1)</b>.</li>
+<li>If <b>isEventuallyDerivedFrom(e2,e1)</b> holds, then <b>dependsOn(e2,e1)</b>.</li>
+<li>If <b>dependsOn(e3,e2)</b> and <b>dependsOn(e2,e1)</b> hold, then <b>dependsOn(e3,e1)</b>.</li>
+</ul>
</section>
-
</section>
--- a/paq/provenance-access.html Sat Aug 06 09:11:42 2011 +0100
+++ b/paq/provenance-access.html Sat Aug 06 09:11:59 2011 +0100
@@ -19,6 +19,8 @@
"LINK-REL" : "M. Nottingham, <a href='http://www.ietf.org/rfc/rfc5988.txt'><cite>Web Linking</cite></a>, October 2010, Internet RFC 5988. URL: <a href='http://www.ietf.org/rfc/rfc5988.txt'>http://www.ietf.org/rfc/rfc5988.txt</a>",
"RFC2387" : "E. Levinson. <a href=\"http://www.ietf.org/rfc/rfc2387.txt\"><cite>The MIME Multipart/Related Content-type.</cite></a> August 1998. Internet RFC 2387. URL: <a href=\"http://www.ietf.org/rfc/rfc2387.txt\">http://www.ietf.org/rfc/rfc2387.txt</a>",
"RFC3297" : "G. Klyne; R. Iwazaki; D. Crocker. <a href=\"http://www.ietf.org/rfc/rfc3297.txt\"><cite>Content Negotiation for Messaging Services based on Email.</cite></a> July 2002. Internet RFC 3297. URL: <a href=\"http://www.ietf.org/rfc/rfc3297.txt\">http://www.ietf.org/rfc/rfc3297.txt</a>",
+ "PRISM" : "International Digital Enterprise Alliance, Inc. <a href=\"http://www.prismstandard.org/specifications/2.0/PRISM_prism_namespace_2.0.pdf\"><cite>PRISM: Publishing Requirements for Industry Standard Metadata</cite></a>. February 2008. URL: <a href=\"http://www.prismstandard.org/specifications/2.0/PRISM_prism_namespace_2.0.pdf\">http://www.prismstandard.org/specifications/2.0/PRISM_prism_namespace_2.0.pdf</a>",
+ "FABIO" : "D. Shotton; S. Peroni. <a href=\"http://speroni.web.cs.unibo.it/cgi-bin/lode/req.py?req=http:/purl.org/spar/fabio#namespacedeclarations\"><cite>FaBiO, the FRBR-aligned Bibliographic Ontology.</cite></a> June 2011. URL: <a href=\"http://speroni.web.cs.unibo.it/cgi-bin/lode/req.py?req=http:/purl.org/spar/fabio#namespacedeclarations\">http://speroni.web.cs.unibo.it/cgi-bin/lode/req.py?req=http:/purl.org/spar/fabio#namespacedeclarations</a>",
};
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
@@ -108,7 +110,7 @@
A general expectation is that web applications may access provenance information in the same way as any web resource, by dereferencing its URI. Typically, this will be by performing an HTTP GET operation. Thus, any provenance information may be associated with a URI, and may be accessed by dereferencing that URI using normal web mechanisms.
</p>
<p>
- The problem of accessing some required provenance information then reduces to the problem of finding its URI, which is dealt with separately in section <a href="#locating-provenance-data" class="sectionRef"></a>.
+ The problem of accessing some required provenance information then reduces to the problem of finding its URI, which is dealt with separately in section <a href="#locating-provenance" class="sectionRef"></a>.
</p>
<p>
This specification thus RECOMMENDS that if a publisher wishes to make provenance information available, it is published as a normal web resource, and provision is made for the URI of the provenance to be discoverable.
@@ -281,7 +283,7 @@
<pre class="example">
<code>http://example.net/provenance-discovery?uri=http://example.info/qdata/&type=application/json</code>
</pre>
- <p class="issue">
+ <p class="pending">
SameAs.org also provides URIs for directly accessing the different result formats without content negotiation, by appending an extra segment to the SameAs.org service URI. I'm reluctant to suggest this mechanism for a service with separately specified base URI, hence using the additional query parameter.
</p>
</section>
@@ -364,10 +366,12 @@
<dl>
<dt><code>200 OK</code></dt>
<dd>Provenance URI(s) returned; see above.</dd>
- <dt><code>204 No data</code></dt>
- <dd>The request was valid, but the server is returning no provenance URIs *(either because it does not know of any provenance URIs, or possibly because it declines to provide the information for policy reasons.</dd>
+ <dt><code>204 No content</code></dt>
+ <dd>The request was valid, but the server is returning no provenance URIs (either because no provenance URIs are known, or possibly because provision of provenance is restricted for policy reasons. The entity body part of the HTTP response message MUST be empty [[HTTP11]].</dd>
+ <!--
<dt><code>...</code></dt>
<dd>...</dd>
+ -->
</dl>
</p>
</section>
@@ -376,8 +380,8 @@
<section>
<h2>Querying provenance</h2>
- <p class="issue">
- This section is work in progress, incomplete, not ready for review.
+ <p class="pending">
+ This section proposes use of SPARQL queries to address requirements that are not covered by the simple retrieval and discovery services proposed above.
</p>
<p>
There are circumstances where simply identifying and retrieving provenance as a web resource may not best fit the requirements of a particular application or service, e.g.:
@@ -390,47 +394,87 @@
</ul>
</p>
<p>
- For such circumstances, a provenance query service provides an alternative way
- </p>
- <p>
- The nature of a provenance query ... service is an implementation choice, to be agreed between provider and users of the service, but for ease of interoperability between different providers and users we recommend use of SPARQL [[RDF-SPARQL-PROTOCOL]] [[RDF-SPARQL-QUERY]]. The third party service URI would then be the URI of a SPARQL endpoint (or, to use the SPARQL specification language, a <a href="http://www.w3.org/TR/rdf-sparql-protocol/#conformant-sparql-protocol-service">SPARQL protocol service</a>) which is queried for the desired provenance information.
+ For such circumstances, a provenance query service provides an alternative way to access provenance and/or provenance URIs.
</p>
<p>
- If the requester has a URI for the original resource, they simple issue a simple SPARQL query for the URI(s) of any associated provenance data; e.g., if the original resource has URI <code>http://example.org/resource</code>,
- <code>
- <pre class="example">
- @prefix prov: <@@TBD>
- SELECT ?provenance_uri WHERE
- {
- <http://example.org/resource> prov:hasProvenance ?provenance_uri
- }
- </pre>
- </code>
- </p>
- <p class="issue">
- @@TODO: specific provenance property to be determined by the model specification?
+ We assume that the requesting application has the URI of a provenance query service, and some information about the resource for which provenance is required that can be used as the basis for a query. A query service is potentially a very general capability that can, in principle, subsume the provenance discovery service described in <a href="#independent-provenance-discovery-services" class="sectionRef"></a>.
</p>
<p>
- If the requester has identifying information that is not the URI of the original resource, then they will need to construct a more elaborate query to locate the target resource and obtain its provenance URI(s). The nature of identifying information that can be used in this way will depend upon the third party service used, further definition of which is out of scope for this specification. For example, a query for a document identified by a DOI, say <code>1234.5678</code>, might look like this:
- <code>
- <pre class="example">
- @prefix prov: <@@TBD>
- @prefix idservice: <@@TBD>
- SELECT ?provenance_uri WHERE
- {
- [ idservice:hasDOI "1234.5678" ] prov:hasProvenance ?provenance_uri
- }
- </pre>
- </code>
+ The details of a provenance query service is an implementation choice, to be agreed between provider and users of the service, but for ease of interoperability between different providers and users we recommend use of SPARQL [[RDF-SPARQL-PROTOCOL]] [[RDF-SPARQL-QUERY]]. The query service URI would then be the URI of a SPARQL endpoint (or, to use the SPARQL specification language, a <a href="http://www.w3.org/TR/rdf-sparql-protocol/#conformant-sparql-protocol-service">SPARQL protocol service</a>). A query service can potentially be used in many different ways, limited only by the available information and capabilities of theSPARQL query language; the following subsections provide examples for what are considered to be some plausible common scenarios.
</p>
- <p>
- @@TODO
- </p>
+
+ <section>
+ <h2>Find provenance URI given URI of resource</h2>
+ <p>
+ If the requester has a URI for the original resource, they might simply issue a simple SPARQL query for the URI(s) of any associated provenance data; e.g., if the original resource has URI <code>http://example.org/resource</code>,
+ <code>
+ <pre class="example">
+ @prefix prov: <@@TBD>
+ SELECT ?provenance_uri WHERE
+ {
+ <http://example.org/resource> prov:hasProvenance ?provenance_uri
+ }
+ </pre>
+ </code>
+ </p>
+ <p class="issue">
+ @@TODO: specific provenance namespace and property to be determined by the model specification?
+ </p>
+ </section>
+
+ <section>
+ <h2>Find provenance URI given identifying information about a resource</h2>
+ <p>
+ If the requester has identifying information that is not the URI of the original resource, then they will need to construct a more elaborate query to locate the target resource and obtain its provenance URI(s). The nature of identifying information that can be used in this way will depend upon the third party service used, further definition of which is out of scope for this specification. For example, a query for a document identified by a DOI, say <code>1234.5678</code>, using the PRISM vocabulary [[PRISM]] recommended by FaBio [[FABIO]], might look like this:
+ <code>
+ <pre class="example">
+ @prefix prov: <@@TBD>
+ @prefix prism: <http://prismstandard.org/namespaces/basic/2.0/>
+ SELECT ?provenance_uri WHERE
+ {
+ [ prism:doi "1234.5678" ] prov:hasProvenance ?provenance_uri
+ }
+ </pre>
+ </code>
+ </p>
+ <p class="issue">
+ @@TODO: specific provenance namespace and property to be determined by the model specification?
+ </p>
+ </section>
+
+ <section>
+ <h2>Obtain provenance directly given URI of a resource</h2>
+ <p>
+ This scenario retrieves provenance directly given the URI of a resource, and may be useful where the provenance has not been assigned a specific URI, or when the calling application is interested only in specific elements of provenance.
+ </p>
+ <p>
+ If the original resource has URI <code>http://example.org/resource</code>, a SPARQL query for provenance might look like this:
+ <code>
+ <pre class="example">
+ @prefix prov: <@@TBD>
+ CONSTRUCT
+ {
+ <http://example.org/resource> ?p ?v
+ }
+ WHERE
+ {
+ <http://example.org/resource> ?p ?v
+ }
+ </pre>
+ </code>
+ This query essentially extracts all available properties and values available from the query service used that are directly about the specified resource, and returns them as an RDFG graph. This may be fine if the service contains <em>only</em> provenance about the resource, or if the non-provenance information is also of interest. A more complex query using specific provenance vocabulary terms may be needed to selectively retrieve just provenance information when other kinds might be available.
+ </p>
+ <p class="issue">
+ @@TODO: specific provenance namespace and property to be determined by the model specification? The above query pattern assumes provenance is included in direct properties about the target resource. When an RDF vocabulary is formulated provenance, this may well turn out to not be the case. A better example would probably be one that retrieves specific provenance when the vocabulary terms have been defined.
+ </p>
+ </section>
+
</section>
- <section class="informative">
+ <!-- <section class="informative"> -->
+ <section>
<h2>Provenance service discovery</h2>
- <p>
+ <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>
@@ -450,7 +494,7 @@
</dd>
<dt>Description:</dt>
<dd>
- the resource identified by target URI of the link provides provenance information about the resource identified by the context link
+ the resource identified by target URI of the link provides provenance about the resource identified by the context link
</dd>
<dt>Reference:</dt>
<dd>