--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/derivation.html Thu Aug 04 00:00:27 2011 +0100
@@ -0,0 +1,197 @@
+<!DOCTYPE html>
+<html><head>
+ <title>Provenance Model</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+<!-- PM -->
+ <style type="text/css">
+ .note { font-size:small; margin-left:50px }
+ </style>
+
+ <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
+
+ <script class="remove">
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "PIL-Model",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ subtitle : "Initial draft for internal discussion",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ // previousPublishDate: "1977-03-15",
+ // previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css", "./extra.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Luc Moreau", url: "http://www.ecs.soton.ac.uk/~lavm",
+ company: "University of Southampton, UK" },
+ { name: "Paolo Missier", url: "http://www.cs.ncl.ac.uk/people/Paolo.Missier",
+ company: "Newcastle University, UK" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ authors: [
+ { name: "TBD"},
+ ],
+
+ // name of the WG
+ wg: "Provenance Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2011/prov/wiki/Main_Page",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-prov-wg",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "",
+ };
+ </script>
+ </head>
+ <body>
+
+<section id="abstract">
+<p>This document defines a data model for Provenance.</p>
+</section>
+
+<section id="concept-Derivation">
+<h3>Derivation</h3>
+
+
+<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>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 a form of transitive closure. </p>
+
+<section>
+<h4>Process Execution Linked Derivation</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.</pe>
+
+<p>In its full form, a process-execution linked derivation assertion, <b>isDerivedFrom(e2,e1,pe,r2,r1)</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;
+<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
+characterized 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(e1,e2)</b>, which:
+<ul>
+<li> refers to an entity <b>e1</b>, denoting the generated characterized thing;
+<li> refers to an entity <b>e2</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 the process execution can be inferred to exist.
+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>.</p>
+</div></p>
+
+<p>From an assertion <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>
+or <b>isDerivedFrom(e2,e1)</b>, the values of some attributes
+of <b>e2</b> are at least partially determined by the values of some
+attributes of <b>e1</b>.</p>
+
+<p>Given an assertion <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>
+or <b>isDerivedFrom(e2,e1)</b>, one can infer that the use
+of characterized thing denoted by <b>e1</b> precedes the generation of
+the characterized thing denoted by <b>e2</b>.
+
+
+<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>
+<pre class="example">
+isDerivedFrom(e5,e3)
+</pre>
+</p>
+
+
+</section>
+
+<section>
+<h4>Process Execution Independent Derivation</h4>
+<p>Introduce here <p>isDerivedFromInMultipleSteps</p> (To be renamed).
+</section>
+
+<section>
+<h4>Transitivity</h4>
+
+
+<p>Show why the attributes invalidates transitivity of <b>isDerivedFrom</b>.
+</p>
+
+<p>The relationship <dfn id="dfn-isDerivedFrom+">isDerivedFrom+</dfn> is the transitive closure of <b>isDerivedFrom</b> and <b>isDerivedFromInMultipleSteps</b>.</p>
+
+
+</section>
+
+</section>
+
+
+
+ </body></html>