--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/#authors.txt# Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,16 @@
+Khalid
+Paul Groth
+Simon Miles
+Graham Klyne
+James Myers
+Satya Sahoo
+
+
+
+Borderline
+Stian Soiland-Reyes
+Tim Lebo
+Jim Mccusker
+Stephen Cresswell
+James Cheney
+Ryan Golden
\ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/#derivation.html# Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,276 @@
+<!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>
+
+
+<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>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</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>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>
+<pre class="example">
+isDerivedFrom(e5,e3)
+</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>
+
+<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>
+
+
+
+</section>
+
+<section>
+<h4>Process Execution Independent Derivation</h4>
+
+
+
+
+<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>
+
+
+<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>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>
+
+
+
+ </body></html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/.#authors.txt Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,1 @@
+lavm@najah.ecs.soton.ac.uk.12730:1316872596
\ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/ProvenanceModel.html.bak Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,1566 @@
+<!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: "PIDM-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>
+
+<p>
+This is a document for internal discussion, which will ultimately
+evolve in the first Public Working Draft of the Conceptual Model.</p>
+ </section>
+
+ <section>
+ <h2>Introduction<br>
+</h2>
+ <p> To be written </p>
+
+<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [[!RFC2119]].</p>
+
+ </section>
+
+ <section>
+<h2>Motivation and Requirements</h2>
+ </section>
+
+ <section>
+<h2>A Conceptualization of the World</h2>
+
+
+<p>In the world (whether real or not), there are things, which can be
+physical, digital, conceptual, or otherwise, and activities involving
+things. Words such thing or activity should be understood with
+their informal meaning.</p>
+
+<p>When we talk about things in the world in natural language and even when we assign identifiers, we are often imprecise in ways that make it difficult to clearly and unambiguously report provenance: a resource with a URL may be understood as referring to a report available at that URL, the version of the report available there today, the report independent of where it is hosted over time, etc.</p>
+
+<p>Hence, to disambiguate things and their situation in the world as perceived by us, we introduce the concept <dfn id="concept-characterized-thing">characterized thing</dfn>, which refers to a thing and its situation in the world, as characterized by someone.</p>
+
+<div class="xmpl">
+Different users may take different perspective about a resource with a URL, which are referred to as
+three different characterized things:
+<ul>
+<li>a report available at URL, </li>
+<li>the version of the report available there today, </li>
+<li>the report independent of where it is hosted over time.</li></ul></div>
+
+
+<p>We do not assume that any characterization is more important than any other, and in fact, it is possible to describe the processing that occurred for the report to be commissioned, for individual versions to be created, for those versions to be published at the given URL, etc., each via a different characterized thing that unambiguously characterizes the report appropriately.</p>
+
+<p>In the world, <dfn id="concept-activity">activities</dfn> involve
+things in multiple ways: they consume them, they process them, they
+transform them, they modify them, they change them, they relocate
+them, they use them, they generate them, they are controlled by them,
+etc.</p>
+
+
+<p>In our conceptualization of the world, punctual events, or <dfn id="concept-event">events</dfn> for short, happen in the world, which mark changes in the world, in its activities, and in its things. In this specification, it is assumed that a partial order exists between events. How practically such order is realized is beyond the scope of this specification. Possible implementations of that ordering include a single global notion of time and Lamport's style clocks.</p>
+ </section>
+
+ <section>
+<h2>The Provenance Abstract Syntax Notation</h2>
+
+ </section>
+
+
+ <section class="informative">
+<h2>Example</h2>
+
+
+<div class='pending'>Alter example to cater for multiple ivpOf. This is <a href="http://www.w3.org/2011/prov/track/issues/33">ISSUE-33</a>.</div>
+
+<div class='resolved'>Some comments on the example. This is <a href="http://www.w3.org/2011/prov/track/issues/63">ISSUE-63</a>.</div>
+
+<div class='issue'>Comments on section 3.2. This is <a href="http://www.w3.org/2011/prov/track/issues/71">ISSUE-71</a></div>
+
+ <section>
+<h3>A File Scenario</h3>
+
+
+<p>This scenario is concerned with the evolution of a crime statistics
+file (referred to as e0) stored on a shared file system and which
+journalists Alice, Bob, Charles, David, and Edith can share and
+edit. We consider various events in the evolution of file e0;
+events listed below follow each other, unless otherwise specified.</p>
+
+
+
+<p>
+Event evt1: Alice creates (pe0) an empty file in /share/crime.txt. We denote this e1.
+</p>
+
+<p>
+Event evt2: Bob appends (pe1) the following line to /share/crime.txt:
+<pre>
+There was a lot of crime in London last month.
+</pre>
+We denote this e2.
+</p>
+
+<p>Event evt3: Charles emails (pe2) the contents of /share/crime.txt, as an
+attachment, which we refer to as e4. (Our description is not precise about the nature of e4, it could be a copy of the file that is local the mail client, that is uploaded on the mail server, or even in transit to a recipient.)
+</p>
+
+<p>
+Event evt4: David edits (pe3) file /share/crime.txt as follows.
+<pre>
+There was a lot of crime in London and New-York last month.
+</pre>
+We denote this e3.
+</p>
+
+<p>Event evt5: Edith emails (pe4) the contents of /share/crime.txt as an attachment, referred to as e5.
+</p>
+
+<p>Event evt6: between events evt4 and evt5, someone (unspecified) runs a spell checker (pe5) on the file /share/crime.txt.
+ The file after spell checking is referred to as e6.
+</p>
+
+</section>
+
+ <section>
+<h3>Encoding using the Provenance Abstract Syntax Notation</h3>
+
+In this section, the example is encoded according to the provenance data model (specified in section <a href="#data-model-concepts">concepts</a>) and expressed in the Provenance Abstract Syntax Notation. Details about the Provenance Abstract Syntax Notation can be found in <a href="#PASN-convention">appendix</a>.
+<p>
+Entities (construct described in <a href="#expression-Entity">Section Entity</a>). The file in its various forms and its copies are modelled as entities.
+<pre>
+entity(e0, [ type: "File", location: "/shared/crime.txt", creator: "Alice" ])
+entity(e1, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "" ])
+entity(e2, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London last month."])
+entity(e3, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London and New York last month."])
+entity(e4, [ ])
+entity(e5, [ ])
+entity(e6, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London and New York last month.", spellchecked: "yes"])
+</pre>
+</p>
+
+
+<p>The entities are characterized by attributes that have given values during intervals delimited by events; such intervals are referred to as <em>characterization intervals</em>. The following table lists all entities and their corresponding characterization intervals. When the end of the characterization interval is not delimited by an event described in this scenario, it is marked by "...".
+<blockquote>
+<table>
+<tr><td>Entity</td><td>Characterization Interval</td></tr>
+<tr><td>e0</td><td>evt1 - ...</td></tr>
+<tr><td>e1</td><td>evt1 - evt2</td></tr>
+<tr><td>e2</td><td>evt2 - evt4</td></tr>
+<tr><td>e3</td><td>evt4 - ...</td></tr>
+<tr><td>e4</td><td>evt3 - ...</td></tr>
+<tr><td>e5</td><td>evt5 - ...</td></tr>
+<tr><td>e6</td><td>evt6 - ... </td></tr>
+</table>
+</blockquote>
+</p>
+
+<p>
+Derivations (construct described in <a href="#expression-Derivation">Section Derivation</a>): derivations express that an entity is derived from another.
+<pre>
+wasDerivedFrom(e2,e1)
+wasDerivedFrom(e3,e2)
+wasDerivedFrom(e4,e2)
+wasDerivedFrom(e5,e3)
+</pre>
+</p>
+
+<p>
+Process Executions (construct described in <a href="#expression-ProcessExecution">Section Process Execution</a>): process execution represents an activity in the scenario.
+<pre>
+processExecution(pe0,create-file,t)
+processExecution(pe1,add-crime-in-london,t+1)
+processExecution(pe2,email,t+2)
+processExecution(pe3,edit-London-New-York,t+3)
+processExecution(pe4,email,t+4)
+processExecution(pe5,spellcheck)
+</pre>
+</p>
+
+<p>
+Generations (construct described in <a href="#expression-Generation">Section Generation</a>): generation is the event at which a file is created in a specific form. To distinguish the function that the various entities generated by a given process execution have in the context of this process execution, a role (construct described in <a href="#expression-Role">Section Role</a>) is introduced. Illustrations of such roles are outFile, outContent, out, attachment.
+<pre>
+wasGeneratedBy(e0,pe0,outFile)
+wasGeneratedBy(e1,pe0,outContent)
+wasGeneratedBy(e2,pe1,out)
+wasGeneratedBy(e3,pe3,out)
+wasGeneratedBy(e4,pe2,attachment)
+wasGeneratedBy(e5,pe4,attachment)
+wasGeneratedBy(e6,pe5,out)
+</pre>
+</p>
+
+
+<p>
+Used (construct described in <a href="#expression-Use">Section Use</a>): use is the event by which a file is read by a process execution. To distinguish the various entities used by a given process execution, a role (construct described in <a href="#expression-Role">Section Role</a>) is introduced. Illustrations of such roles are in and fileIn.
+<pre>
+used(pe1,e1,in)
+used(pe3,e2,in)
+used(pe2,e2,in)
+used(pe4,e3,in)
+used(pe5,e3,fileIn)
+</pre>
+</p>
+
+
+
+<p>
+wasComplementOf: (this relation is described in <a href="#expression-complement-of">Section wasComplementOf</a>). The crime statistics file (e0) has various contents over its existence (e1,e2,e3); the entites e1,e2,e3 complement e0 with an attribute content. Likewise, e6 complements e3 with an attributed spellchecked.
+<pre>
+wasComplementOf(e1,e0)
+wasComplementOf(e2,e0)
+wasComplementOf(e3,e0)
+wasComplementOf(e6,e3)
+</pre>
+</p>
+
+
+<p>
+Agents (construct described at <a href="#expression-Agent">Section Agent</a>): the various users are represented as agents, themselves being a type of entity.
+<pre>
+entity(a1, [ type: "Person", name: "Alice" ])
+agent(a1)
+
+entity(a2, [ type: "Person", name: "Bob" ])
+agent(a2)
+
+entity(a3, [ type: "Person", name: "Charles" ])
+agent(a3)
+
+entity(a4, [ type: "Person", name: "David" ])
+agent(a4)
+
+entity(a5, [ type: "Person", name: "Edith" ])
+agent(a5)
+</pre>
+</p>
+
+
+<p>
+Control (construct described in <a href="#expression-Control">Section Control</a>): the influence of an agent over a process execution is expressed as control, and the nature of this influence is described by a role (construct described in <a href="#expression-Role">Section Role</a>). Illustrations of such roles are creator, author and communicator.
+<pre>
+wasControlledBy(pe0,a1, creator)
+wasControlledBy(pe1,a2, author)
+wasControlledBy(pe2,a3, communicator)
+wasControlledBy(pe3,a4, author)
+wasControlledBy(pe4,a5, communicator)
+</pre>
+</p>
+</section>
+
+
+ <section>
+<h3>Graphical Illustration</h3>
+
+Provenance assertions can be illustrated as a graph.
+Details about the graphical illustration can be found in <a href="#illustration-convention">appendix</a>.
+
+<img src="example-graphical.png"/>
+<p/>
+<img src="timeline.png"/>
+</section>
+
+</section>
+
+
+ <section >
+<h2>About the Provenance Data Model</h2>
+
+<div class='issue'>The name of the data model still has to be decided by the WG. Current placeholder name is PIDM. This is <a href="http://www.w3.org/2011/prov/track/issues/31">ISSUE-31</a></div>
+
+<div class='resolved'>Data model vs Language. Misc comments raised at <a href="http://www.w3.org/2011/prov/track/issues/62">ISSUE-62</a></div>
+
+
+<p>In the world (whether real or not), there are things, which can be
+physical, digital, conceptual, or otherwise, and activities involving
+things. Words such thing or activity should be understood with
+their informal meaning.</p>
+
+<p>Furthermore, this specification is concerned with <em>characterized
+things</em>, that is, things and their situation in
+the world, as characterized by their asserters.</p>
+
+<p>
+In the rest of the document, we are concerned with the representation of such things; their situation in the world will be represented using sets of attributes.
+</p>
+
+<p>
+<div class="example">
+<b>Example</b>: a file at some point during its lifecycle, which includes multiple edits by multiple people, can be represented by its location in the file system, a creator, and content.
+</div>
+</p>
+
+
+<p>This specification defines a data model for provenance (placeholder acronym PIDM) and relies on a language, the <a href="#PASN-convention">Provenance Abstract Syntax Notation</a>, to express
+<em>instances</em> of that data model.</p>
+
+<div class='issue'>Formalism used is not explained, not applied to concepts <a href="http://www.w3.org/2011/prov/track/issues/87">ISSUE-87</a>.</div>
+
+
+<p>PIDM is a provenance data model designed to express representations
+of the world. These representations are relative to an asserter, and
+in that sense constitute assertions characterizing the
+world. Different asserters will normally contribute different
+representations, and no attempt is made to define a notion of
+consistency of such different sets of assertions. The data model
+provides the means to associate attribution to assertions.
+</p>
+
+
+
+<p>The data model is designed to capture events that happened in the past, as opposed to event
+that may or will happen.
+However, this distinction is not formally enforced.
+Therefore, all PIDM assertions SHOULD be interpreted as a record of what has happened, as opposed to what may or will happen.</p>
+
+<div class='note'>Can this be enforced formally?</div>
+
+<p>
+This specification does not prescribe the means by which an asserter arrives at assertions; for example, assertions can be composed on the basis of observations, inferences, or any other means.
+</p>
+
+
+<p>The data model includes a notion of "provenance container" that is
+ a logical grouping for a set of assertions. It serves multiple
+ purposes. First, it provides a way to attach various metadata to the
+ set of assertions. Second, it provides a scope in which some constraints may apply.
+ Third, it provides a default scope for
+ identifiers used in assertions. This means that identifiers are
+ expected to be resolvable only within the scope of a container,
+ rather than globally. Optionally, identifiers can be exported so that
+ they can be used outside their default scope. Finally, the data
+ model does not prescribe the mechanisms by which identifiers are
+ generated.</p>
+
+
+
+<p>
+Sometimes, inferences about the world can be made from assertions of the provenance data model. When this is the case, this specification defines such inferences.
+</p>
+
+<p> In this specification, the qualifier 'identifiable' is implicit whenever a reference is made to an activity or characterized thing.</p>
+
+ </section>
+
+
+
+ <section id="data-model-concepts">
+
+<h2>Provenance Data Model</h2>
+
+<p>The data model defines the following types of expressions.</p>
+
+<div class='issue'>Conceptual model needs a high level overview <a href="http://www.w3.org/2011/prov/track/issues/86">ISSUE-86</a>.</div>
+
+
+ <section id="expression-Entity">
+
+<h3>Entity</h3>
+
+<p>In PIDM, an <dfn id="dfn-entity" title="entity">entity expression</dfn> is a representation of an identifiable characterized thing.</p>
+
+<p>
+In the Provenance Abstract Syntax Notation, an entity expression's text matches the <span class="nonterminal">entity</span> production of the grammar defined in this specification document.
+</p>
+
+<div class='grammar'>
+<span class="nonterminal">entity</span> :=
+<span class="name">entity</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="name">[</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">]</span>
+<span class="name">)</span><br/>
+<!-- -->
+<span class="nonterminal">attribute-values</span> :=
+<span class="nonterminal">attribute-value</span>
+|<span class="nonterminal">attribute-value</span> <span class="name">,</span> <span class="nonterminal">attribute-values</span>
+<br/>
+<span class="nonterminal">attribute-value</span> :=
+<span class="nonterminal">attribute</span>
+<span class="name">:</span>
+<span class="nonterminal">Literal</span>
+<br/>
+</div>
+
+
+
+<p>An instance of an entity expression, noted <span class="name">entity(id, [ attr1: val1, ...])</span> in the Provenance Abstract Syntax Notation:
+<ul>
+<li> contains an identifier <span class="name">id</span> denoting a characterized thing;</li>
+<li> contains a set of attribute-value pairs <span class="name">[ attr1: val1, ...]</span>, representing this characterized thing's situation in the world.</li>
+</ul>
+</p>
+
+<p>
+The assertion of an instance of an entity expression, <span class="name">entity(id, [ attr1: val1, ...])</span>, states, from a given asserter's viewpoint, the existence of an identifiable characterized thing, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two events in the world.
+</p>
+
+
+
+<p>
+The following entity assertion,
+<pre class="example">
+entity(e0, [ type: "File", location: "/shared/crime.txt", creator: "Alice" ])
+</pre>
+states the existence of a thing of type File and location /shared/crime.txt, and creator alice, denoted by identifier e0, during some characterization interval.
+</p>
+
+Further considerations:
+<ul>
+<li>If an asserter wishes to characterize a thing with same attribute-value pairs over several intervals, then they are required to assert multiple entity expressions, each with its own identifier. </li>
+
+<li>There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.</li>
+
+<li>A characterization interval may collapse into a single instant</li>
+
+<li>An entity assertion
+ is about a characterized thing, whose situation in the world may be variant.
+ An entity assertion is made at a particular point and is invariant, in the sense that
+its attributes are assigned a value as part of that assertion.
+</li>
+
+</ul>
+
+
+
+
+<div class='pending'>Characterized entity may be variant. This is <a href="http://www.w3.org/2011/prov/track/issues/32">ISSUE-32</a></div>
+
+<div class='issue'>How is domain specific data combined with the provenance model? This is <a href="http://www.w3.org/2011/prov/track/issues/65">ISSUE-65</a>.</div>
+
+<div class='resolved'> Comments on bob <a href="http://www.w3.org/2011/prov/track/issues/60">ISSUE-60</a>.</div>
+
+<div class='resolved'>The name <b>entity</b> is used as a replacement for placeholder BOB. This is <a href="http://www.w3.org/2011/prov/track/issues/30">ISSUE-30</a>.</div>
+
+<div class='issue'>Definition of Entity is confusing, maybe over-complex <a href="http://www.w3.org/2011/prov/track/issues/85">ISSUE-85</a>.</div>
+
+
+
+
+ </section>
+
+ <section id="expression-ProcessExecution">
+
+<h3>Process Execution</h3>
+<p>A <dfn id="dfn-ProcessExecution">process execution</dfn> represents an identifiable activity, which performs a piece of work.</p>
+
+<p>The activity that a process execution represents has a duration, delimited by its start and its end; hence, it occurs over a continuous time interval. However, the process execution representing the activity need not mention time information, nor duration, because they may not be known.</p>
+
+<p> A process execution assertion, noted <span class="name">processExecution(id,rl,st,et)</span>:
+<ul>
+<li> contains an identifier <span class="name">id</span>;
+<li> MAY contain a <a href="#expression-RecipeLink">recipe link</a> <span class="name">rl</span>;
+<li> MAY contain a start time <span class="name">st</span>;
+<li> MAY contain an end time <span class="name">et</span>.
+</ul>
+</p>
+
+<p>
+<pre class="example">
+processExecution(pe1,add-crime-in-london,t+1,t+1+epsilon)
+</pre>
+</p>
+
+<p>A process execution is not an entity. Indeed, an entity represents
+a thing that exists in full at any point in its characterization
+interval, persists during this interval, and preserves the
+characteristics that makes it identifiable. Alternatively, an
+activity in something that happens, unfolds or develops through time,
+but is typically not identifiable by the characteristics it exhibits at
+any point during its duration.</p>
+
+
+<div class='note'>Elaborate justification. </div>
+
+
+
+<div class='constraint' id='start-precedes-end'><a name="PIL:0001"> From the assertion of a process execution, one can infer that the
+start precedes the end of the represented activity.</a> [<a
+href="../ontology/ProvenanceFormalModel.html#PIL:0001">PIL:0001</a>] </div>
+
+
+<div class='pending'>Should process execution be defined as a subclass of BOB. This is <a href="http://www.w3.org/2011/prov/track/issues/66">ISSUE-66</a>.</div>
+</section>
+
+<section id="expression-Generation">
+<h3>Generation<br>
+</h3>
+
+
+
+<p><dfn id="dfn-Generation">Generation</dfn> represents the creation of a new characterized thing by an activity. This characterized thing did not exist before creation.</p>
+
+
+
+<p>A Generation assertion, noted <span class="name">wasGeneratedBy(e,pe,r,t)</span>:
+<ul>
+<li> refers to an entity <span class="name">e</span>, which represents the characterized thing that is created;
+<li> refers to a process execution <span class="name">pe</span>;
+<li> contains a <a href="#expression-Role">role</a> <span class="name">r</span>;
+<li> MAY contain a "generation time" <span class="name">t</span>, the time at which the characterized thing was created.</p>
+</ul>
+</p>
+
+<p>
+<pre class="example">
+wasGeneratedBy(e2,pe1,out)
+</pre>
+</p>
+
+<p>A given entity can be generated at most by one process execution in the scope of a given <a href="#expression-Account">account</a>.
+The rationale for this constraint is as follows.
+If two process executions sequentially set different values to some attribute by means of two different generate events, then they generate distinct entities. Alternatively, for two process executions to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single process execution. </p>
+</p>
+
+<div class='constraint' id='generation-affects-attributes'><a name="PIL:0002">Given a process execution <span class="name">pe</span>, entity <span class="name">e</span>, role <span class="name">r</span>, and optional time <span class="name">t</span>,
+if the assertion <span class="name">wasGeneratedBy(e,pe,r)</span>
+or <span class="name">wasGeneratedBy(e,pe,r,t)</span> holds, the values of <em>some</em> of <span class="name">e</span>'s
+attributes are determined by the activity denoted by <span class="name">pe</span> and the
+entities used by <span class="name">pe</span>.
+Only some (possibly none) of the attributes values may be determined
+since, in an open world, not all used entities may have been
+asserted.</a> [<a href="../ontology/ProvenanceFormalModel.html#PIL:0002">PIL:0002</a>]
+</div>
+
+<div class='constraint' id='generation-pe-ordering'><a name="PIL:0003">Given an assertion <span class="name">wasGeneratedBy(x,pe,r)</span> or <span class="name">wasGeneratedBy(x,pe,r,t)</span>, one can
+infer that the generation of the thing denoted by <span class="name">x</span> precedes the end
+of <span class="name">pe</span> and follows the beginning of <span class="name">pe</span>.</a> [<a href="../ontology/ProvenanceFormalModel.html#PIL:0003">PIL:0003</a>]
+</div>
+
+
+<div class='resolved'>Need to say identifiable activity. This is <a href="http://www.w3.org/2011/prov/track/issues/39">ISSUE-39</a>. The qualifier 'identifiable' is said to be implicit in section 4. </div>
+
+<div class='resolved'>Comments on generation <a href="http://www.w3.org/2011/prov/track/issues/59">ISSUE-59</a>.</div>
+
+<div class='resolved'> Added justification for generation by a single process <a href="http://www.w3.org/2011/prov/track/issues/67">ISSUE-67</a>.</div>
+
+
+
+
+</section>
+
+
+<section id="expression-Use">
+<h3>Use</h3>
+
+<div class='resolved'>Various comments raised at <a href="http://www.w3.org/2011/prov/track/issues/64">ISSUE-64</a>.</div>
+
+<p><dfn id="dfn-Use">Use</dfn> represents the consumption of a characterized thing by an activity.</p>
+
+
+<p>A Use assertion, <span class="name">used(pe,e,r,t)</span>:
+<ul>
+<li> refers to a process execution <span class="name">pe</span>;
+<li> refers to an entity <span class="name">e</span>, representing the characterized thing that is used;
+<li> contains a <a href="#expression-Role">role</a> <span class="name">r</span>;
+<li> MAY contain a "use time" <span class="name">t</span>, the time at which the characterized thing was used.</p>
+</ul>
+</p>
+
+<p>
+<pre class="example">
+used(pe1,e1,in,t)
+</pre>
+</p>
+
+
+<p>A reference to a given entity may appear in multiple use assertions that refer
+to a given process execution, but each of those use assertions MUST have a
+distinct role.</p>
+
+
+
+
+
+<div class='constraint' id='use-attributes'><a name="PIL:0005">
+Given a process execution <span class="name">pe</span>, entity <span class="name">e</span>, role <span class="name">r</span>, and optional time <span class="name">t</span>, if
+ assertion <span class="name">used(pe,e,r)</span> or <span class="name">used(pe,e,r,t)</span> holds,
+the existence of the value of an attribute of <span class="name">e</span>' is a
+pre-condition for the activity denoted by <span class="name">pe</span> to terminate.</a>
+[<a href="../ontology/ProvenanceFormalModel.html#PIL:0005">PIL:0005</a>]</div>
+
+
+
+<div class='constraint' id='use-pe-ordering'><a name="PIL:0006">Given a process execution <span class="name">pe</span>, entity <span class="name">e</span>, role <span class="name">r</span>, and optional time <span class="name">t</span>, if
+ assertion <span class="name">used(pe,e,r)</span> or <span class="name">used(pe,e,r,t)</span> holds, one can
+infer that the use of the thing denoted by <span class="name">e</span> precedes the end
+of <span class="name">pe</span> and follows the beginning of <span class="name">pe</span>. Furthermore, we
+can infer that the generation of the thing denoted by <span class="name">e</span> always precedes
+its use.</a>
+[<a href="../ontology/ProvenanceFormalModel.html#PIL:0006">PIL:0006</a>] </div>
+
+
+<div class='issue'>Should we define a taxonomy of use? This is <a href="http://www.w3.org/2011/prov/track/issues/23">ISSUE-23</a>.</div>
+</section>
+
+
+
+<section id="expression-Derivation">
+<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>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 <span class="name">wasDerivedFrom(e2,e1,pe,r2,r1)</span>:
+<ul>
+<li> refers to an entity <span class="name">e2</span>, denoting the used characterized thing;
+<li> refers to an entity <span class="name">e1</span>, denoting the generated characterized thing;
+<li> refers to process execution <span class="name">pe</span>;
+<li> contains a role <span class="name">r2</span>.
+<li> contains a role <span class="name">r1</span>.
+</ul>
+This assertion expresses that the process execution <span class="name">pe</span>, by
+using the thing denoted by <span class="name">e1</span> with role <span class="name">r1</span> derived the
+thing denoted by entity <span class="name">e2</span> and generated it with
+role <span class="name">r2</span>.
+</p>
+
+<p>
+The following inference rule allows generation and use assertions to be inferred.
+</p>
+
+<div class="inference">
+<a name="PIL:0010">If <span class="name">wasDerivedFrom(e2,e1,pe,r2,r1)</span> holds, then
+ <span class="name">wasGeneratedBy(e2,pe,r2)</span> and <span class="name">used(pe,e1,r1)</span> also
+ hold. </a> [<a href="../ontology/ProvenanceFormalModel.html#PIL:0010">PIL:0010</a>]
+</div>
+
+
+<p>For convenience, PIL allows for a compact, process-execution linked derivation assertion, written <span class="name">wasDerivedFrom(e2,e1)</span>, which:
+<ul>
+<li> refers to an entity <span class="name">e2</span>, denoting the generated characterized thing;
+<li> refers to an entity <span class="name">e1</span>, 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'>
+ <a name="PIL:0009">
+If <span class="name">wasDerivedFrom(e2,e1)</span> holds, then there exists a process execution <span class="name">pe</span>, and roles <span class="name">r1</span>,<span class="name">r2</span>,
+such that:
+ <span class="name">wasGeneratedBy(e2,pe,r2)</span> and <span class="name">used(pe,e1,r1)</span>. [<a href="../ontology/ProvenanceFormalModel.html#PIL:0009">PIL:0009</a>]
+</div></p>
+
+
+
+
+<p>If <span class="name">e2</span> is derived from <span class="name">e1</span>, then
+this means that the thing represented by <span class="name">e1</span> has an influence on the thing represented by <span class="name">e2</span>, which is captured by a dependency between their attribute values; it also implies temporal ordering. These are specified as follows:</p>
+
+<div class='constraint' id='derivation-attributes'><a name="PIL:0007">Given a process execution <span class="name">pe</span>, entities <span class="name">e1</span> and <span class="name">e2</span>, roles <span class="name">r1</span> and <span class="name">r2</span>, the assertion <span class="name">wasDerivedFrom(e2,e1,pe,r2,r1)</span>
+or <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>if and only if</span>:
+ the values of some attributes
+of <span class="name">e2</span> are partly or fully determined by the values of some
+attributes of <span class="name">e1</span>.</a> [<a
+ href="../ontology/ProvenanceFormalModel.html#PIL:0007">PIL:0007</a>] </div>
+
+<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>
+
+
+
+<div class='constraint' id='derivation-use-generation-ordering'><a name="PIL:0008">Given a process execution <span class="name">pe</span>, entities <span class="name">e1</span> and <span class="name">e2</span>, roles <span class="name">r1</span> and <span class="name">r2</span>, <span class='conditional'>if</span> the assertion <span class="name">wasDerivedFrom(e2,e1,pe,r2,r1)</span>
+or <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span>
+the use
+of characterized thing denoted by <span class="name">e1</span> precedes the generation of
+the characterized thing denoted by <span class="name">e2</span>.</a> [<a href="../ontology/ProvenanceFormalModel.html#PIL:0008">PIL:0008</a>]
+</div>
+
+
+
+<p>
+Note that inferring derivation from use and generation does not hold
+in general. Indeed, when a generation <span class="name">wasGeneratedBy(e2,pe,r2)</span>
+precedes <span class="name">used(pe,e1,r1)</span>, for
+some <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">r1</span>, <span class="name">r2</span>, and <span class="name">pe</span>, one
+cannot infer derivation <span class="name">wasDerivedFrom(e2,e1,pe,r2,r1)</span>
+or <span class="name">wasDerivedFrom(e2,e1)</span> since the values of attributes
+of <span class="name">e2</span> cannot possibly be determined by the values of attributes
+of <span class="name">e1</span>, given the creation of <span class="name">e2</span> precedes the use
+of <span class="name">e1</span>.
+</p>
+
+<p>
+<pre class="example">
+wasDerivedFrom(e5,e3)
+</pre>
+</p>
+
+<p>A further inference is permitted from the compact version of derivation:
+<div class='inference'>
+<a name="PIL:0011">Given a process execution <span class="name">pe</span>, entities <span class="name">e1</span> and <span class="name">e2</span>, and role <span class="name">r2</span>,
+if <span class="name">wasDerivedFrom(e2,e1)</span> and <span class="name">wasGeneratedBy(e2,pe,r2)</span> hold, then there exists a role <span class="name">r1</span>,
+such that <span class="name">used(pe,e1,r1)</span> also holds.</a>
+ [<a href="../ontology/ProvenanceFormalModel.html#PIL:0011">PIL:0011</a>]
+</div>
+This inference is justified by the fact that <span class="name">e2</span> is generated by at most one process execution. Hence, this process execution is also the one that used <span class="name">e1</span>.
+</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 <span class="name">wasDerivedFrom(e2,e1)</span> and <span class="name">used(pe,e1)</span>, one cannot
+derive <span class="name">wasGeneratedBy(e2,pe,r2)</span> because <span class="name">e1</span> may be used by
+many process execution, not all of them generating <span class="name">e2</span>.</p>
+
+
+
+</section>
+
+<section>
+<h4>Process Execution Independent Derivation Assertion</h4>
+
+
+
+
+<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 <span class="name">wasEventuallyDerivedFrom (e2, e1)</span>,
+<ul>
+<li> refers to an entity <span class="name">e2</span>, denoting the used characterized thing;
+<li> refers to an entity <span class="name">e1</span>, denoting the generated characterized thing;
+</ul>
+
+
+<p>If <span class="name">e2</span> is derived (wasEventuallyDerivedFrom) from <span class="name">e1</span>, then
+this means that the thing represented by <span class="name">e1</span> has an influence on the thing represented by <span class="name">e2</span>,
+ which at the minimum implies temporal ordering, specified as follows:</p>
+
+<div class='constraint' id='derivation-generation-generation-ordering'>
+ <a name="PIL:0012">Given two entities <span class="name">e1</span> and <span class="name">e2</span>, if the assertion <span class="name">wasEventuallyDerivedFrom(e2,e1)</span>
+ holds, then:
+generation of the characterized thing denoted by <span class="name">e1</span> precedes the generation of
+the characterized thing denoted by <span class="name">e2</span>.</a>
+ [<a href="../ontology/ProvenanceFormalModel.html#PIL:0012">PIL:0012</a>]
+ </div>
+
+<p>Note that temporal ordering is between generations of <span class="name">e1</span>
+and <span class="name">e2</span>, as opposed to process execution linked derivation,
+which implies temporal ordering between the use of <span class="name">e1</span> and
+generation of <span class="name">e2</span> (see <a href="#derivation-use-generation-ordering">derivation-use-generation-ordering</a>). Indeed, in the case of
+wasEventuallyDerivedFrom, nothing is known about the use of <span class="name">e1</span>,
+since there is no associated process execution.</p>
+
+<div class='note'>Should we link wasEventuallyDerivedFrom to attributes as we did for wasDerivedFrom? If so, this type of inference should be presented upfront, for both.</div>
+
+
+
+
+
+</section>
+
+<section>
+<h4>Transitive Derivation</h4>
+
+
+<p>
+If <span class="name">wasDerivedFrom(e2,e1)</span> holds because attribute <span class="name">a2.1</span> of <span class="name">e2</span> is determined by attribute <span class="name">a1.1</span> of <span class="name">e1</span>,
+and if <span class="name">wasDerivedFrom(e3,e2)</span> holds because attribute <span class="name">a3.1</span>of <span class="name">e3</span> is determined by attribute <span class="name">a2.2</span> of <span class="name">e1</span>, it is not necessarily the case that an attribute of <span class="name">e3</span> is determined by an attribute of <span class="name">e1</span>, so, an asserter may not be able to assert <span class="name">wasDerivedFrom(e3,e1)</span>. Hence, constraints on attributes invalidate transitivity in the general case.
+</p>
+
+<p>However, there is sense that <span class="name">e3</span> still depends on <span class="name">e1</span>, since <span class="name">e3</span> could not be generated without <span class="name">e1</span> existing. Hence, we introduce a weaker notion of derivation, which is transitive.</p>
+
+<p>The relationship <dfn id="dfn-dependedOn">dependedOn</dfn> is defined as follows:
+<ul>
+<li>If <span class="name">wasDerivedFrom(e2,e1)</span> or <span class="name">wasDerivedFrom(e2,e1,pe,r2,r1)</span> holds, then <span class="name">dependedOn(e2,e1)</span>.</li>
+<li>If <span class="name">wasEventuallyDerivedFrom(e2,e1)</span> holds, then <span class="name">dependedOn(e2,e1)</span>.</li>
+<li>If <span class="name">dependedOn(e3,e2)</span> and <span class="name">dependedOn(e2,e1)</span> hold, then <span class="name">dependedOn(e3,e1)</span>.</li>
+</ul>
+
+<p>We note that <span class="name">dependedOn</span> cannot be asserted but can only be inferred.</p>
+</section>
+
+
+
+
+<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='resolved'> 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='resolved'> 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>
+
+
+
+<section id="expression-Agent">
+<h3>Agent</h3>
+
+
+
+<p>An <dfn id="dfn-Agent">agent</dfn> represents a characterized thing capable of
+activity.</p>
+
+<p> An agent construct, <span class="name">agent(e)</span>:
+<ul>
+<li> refers to an entity <span class="name">e</span>
+</ul>
+</p>
+
+<p>A characterized thing can be asserted to be an agent or can be inferred to be
+an agent by involvement in a process execution. </p>
+
+<p>
+<pre class="example">
+entity(alice, [Employee="1234"]) and agent(alice)
+
+
+entity(david) and wasControlledBy(pe,david)
+</pre>
+</p>
+
+
+
+</section>
+
+
+<section id="expression-Control">
+<h3>Control</h3>
+
+<p> <dfn id="dfn-Control">Control</dfn> represents the involvement of an agent or an entity in a process execution; a role qualifies this involvement.</p>
+
+<p>A Control assertion, noted <span class="name">wasControlledBy(pe,ag,r)</span>:
+<ul>
+<li> refers to a process execution <span class="name">pe</span>;
+<li> refers to an agent or an entity <span class="name">ag</span>;
+<li> contains a role <span class="name">r</span>.
+</ul>
+</p>
+
+<p>
+<pre class="example">
+wasControlledBy(pe3,david,"author")
+</pre>
+</p>
+
+</section>
+
+
+<section id="expression-complement-of">
+
+<h3>was Complement Of</h3>
+
+
+<p><dfn id="IVP-of">Is Complement Of</dfn> is a relationship between two characterized things asserted to have compatible characterization over some continuous time interval.<br/>
+
+The rationale for introducing this relationship is that in general, at any given time there will be multiple representations of a characterized thing, which are reflected in assertions possibly made by different asserters. In the example that follows, suppose thing "Royal Society" is represented by two asserters, each using a different set of attributes. If the asserters agree that both representations refer to "The Royal Society", the question of whether any correspondence can be established between the two representations arises naturally. This is particularly relevant when (a) the sets of properties used by the two representations overlap partially, or (b) when one set is subsumed by the other. In both these cases, we have a situation where each of the two asserters has a partial view of "The Royal Society", and establishing a correspondence between them on the shared properties is beneficial, as in case (a) each of the two representation <em>complements</em> the other, and in case (b) one of the two (that with the additional properties) complements the other.
+<p/>
+This intuition is made more precise by considering the entities that embody the representation of a characterised thing at a certain point in time. an entity, as defined above, exists only as long as all of its attributes do not change their value. As soon as one attribute, say X changes value, say from v1 to v2, the entity no longer exists and is replaced by a new one in which X=v2. Thus, if we overlap the timelines (or, more generally, the sequences of value-changing events) for the two characterised things, we can hope two establish correspondences amongst the entities that represent them at various points along that events line. The figure below illustrates this intuition.<p/>
+
+<img src="complement-of.png"/>
+
+<p/>
+Relation <em>complement-of</em> between two entities is intended to capture these correspondences, as follows. Suppose entities A and B share a set P of properties, and each of them has other properties in addition to P. If the values assigned to each property in P are <em>compatible</em> between A and B, then we say that <em>A is-complement-of B</em>, and <em>B is-complement-of A</em>, in a symmetrical fashion. In the particular case where the set P of properties of B is a struct superset of A's properties, then we say that <em>B is-complement-of A</em>, but in this case the opposite does not hold. In this case, the relation is not symmetric. (as a special case, A and B may not share any attributes at all, and yet the asserters may still stipulate that they are representing the same thing "Royal Society". The symmetric relation may hold trivially in this case).
+<p/>
+The term <em>compatible</em> used above means that a mapping can be established amongst the values of attributes in P and found in the two entities. This is generalizes to the case where attribute sets P1 and P2 of A, and B, respectively, are not identical but they can be mapped to one another. The simplest case is the identity mapping, in which A and B share attribute set P, and furthermore the values assigned to attributes in P match exactly.<br/>
+
+It is important to note that the relation holds only as long as the entities involved are valid. As soon as one attribute changes value in one of them, new correspondences need to be found amongst the new entities. Thus, the relation has a validity span that can be expressed in terms of the event lines of the thing.
+
+<!--
+The "IVP of" relationship is designed to represent pairs of entities that correspond to each other. By their own nature, an entity remains valid only as long as all of its attributes do not change their value. It follows that the correspondence "B IVP of A" is only valid within the time interval during which such invariance property holds for both A and B. When any of the property values change in either A or B, those entities are replaced by new ones, and a new correspondence may be established. Thus, "IVP of" is defined relative to the intersection of the temporal intervals for which A and B are valid.
+-->
+</p>
+
+<p>An wasComplementOf assertion is denoted <span class="name">wasComplementOf(B,A)</span>, where A and B are two entities.
+
+<p>
+<pre class="example">
+entity(rs,[created: "1870"])
+
+entity(rs_l1,[location: "loc2"])
+entity(rs_l2,[location: "The Mall"])
+
+entity(rs_m1,[membership: "250", year: "1900"])
+entity(rs_m2,[membership: "300", year: "1945"])
+entity(rs_m3,[membership: "270", year: "2010"])
+
+wasComplementOf(rs_m3, rs_l2)
+wasComplementOf(rs_m2, rs_l1)
+wasComplementOf(rs_m2, rs_l2)
+wasComplementOf(rs_m1, rs_l1)
+
+wasComplementOf(rs_l1, rs)
+wasComplementOf(rs_l2, rs)
+</pre>
+</p>
+
+<div class='constraint' id='wasComplementOf-necessary-cond'>
+ <a name="PIL:0013">An assertion "wasComplementOf(B,A)" holds over the temporal intersection of A and B, <span class='conditional'>only if</span>:
+<ol>
+<li> if a mapping can be established from an attribute X of B to an attribute Y of A, then the values of A and B must be consistent with that mapping</em> </li>
+ <li>B has some attribute that A does not have
+</li></ol></a>
+ [<a href="../ontology/ProvenanceFormalModel.html#PIL:0013">PIL:0013</a>]
+ </div>
+
+<div class='issue'>Mutual ivpOf each other should be agreed. This is <a href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a></div>
+
+<div class='issue'>Do we need a sameAsEntity relation. This is <a href="http://www.w3.org/2011/prov/track/issues/35">ISSUE-35</a></div>
+
+<div class='issue'>Is ivpOf transitive? This is <a href="http://www.w3.org/2011/prov/track/issues/45">ISSUE-45</a></div>
+
+<div class='issue'> Comments on ivpof in <a href="http://www.w3.org/2011/prov/track/issues/57">ISSUE-57</a>.</div>
+
+
+</section>
+
+<section id="expression-Time">
+<h3>Time</h3>
+
+<p><dfn id="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [[!XMLSCHEMA-2]].</p>
+
+
+
+<p>It is OPTIONAL to assert time in use, generation, and process execution.</p>
+
+<div class='resolved'> Is it appropriate to refer to ISO8601. Point in Time, Interval? This is <a href="http://www.w3.org/2011/prov/track/issues/58">ISSUE-58</a>.</div>
+
+<section>
+<h4>Temporal Events</h4>
+Four kinds of discrete events underpin the PIDM data model. They are:
+<ol>
+<li>Generation of an entity by a process execution: identifies the final instant of an entity's creation timespan, after which the characterized thing represented by an entity becomes available for use.</li>
+<li>Use of an entity by a process execution: identifies the first instant of an entity's consumption timespan.</li>
+<li>Start of a process execution: identifies the instant an activity represented by a process execution starts</li>
+<li>End of a process execution: identifies the instant an activity represented by a process execution ends</li>
+</ol>
+</section>
+
+<section>
+<h4>Event Ordering</h4>
+
+
+<p><dfn id="dfn-follows">Follows</dfn> is a partial order between events, indicating that an event occurs after another. For convenience, <dfn id="dfn-follows">precedes</dfn> is defined as the symmetric of follows. </p>
+
+<p>This specification introduces inference rules allowing such event ordering to be inferred from provenance constructs.</p>
+</section>
+
+
+</section>
+
+<section id="expression-RecipeLink">
+<h3>Recipe Link</h3>
+
+
+<p>A <dfn id="dfn-RecipeLink">recipe link</dfn> is an association between a process execution and a process specification that underpins the process execution.
+</p>
+
+<p>
+It is OPTIONAL to assert recipe links in process executions.
+</p>
+
+
+<p>
+Process specifications, as referred to by recipe links, are out of scope of this specification.
+</p>
+
+</section>
+
+<section id="expression-Role">
+<h3>Role</h3>
+
+
+<p>A <dfn id="dfn-Role">role</dfn> is a label that names the function assumed by an entity or
+an agent with respect to a specific process execution.</p>
+
+<div class='note'>It may be useful to distinguish between a role name and a role type, similarly to
+ parameter names and parameter types in a programming language procedure.
+Currently, all the constraints and definitions pertaining to roles in the
+specification should be understood as role names.</div>
+
+
+
+<p>Use, Generation, and Control assertions MUST contain a role. Roles
+are mandatory since they allow for uniform data structures. To facilitate
+the writing of these assertions when a role is unknown by the
+asserter, syntactic notations MAY allow these to be written without a role. In such a case, a default, uniquely named role from the set
+'unspecified role' will be assumed. A countable set of unique labels can be used to denote unspecified roles, as in:
+<span class="name">unspecified0</span>, <span class="name">unspecified1</span>, <span class="name">unspecified2</span>, ....
+
+<pre class="example">
+ used(pe,e) expands to used(pe,e,unspecified1)
+</pre>
+where unspecified1 is an unspecified role.
+</p>
+
+<p> The set of all Use (resp. Generation, Control) assertions that refer to a given process execution MUST contain at most one occurrence of a given role. The rationale for this requirement is that when provenance is used to replay execution, roles are used to determine which values must be associated with which input (resp. output, control channel) of a process execution.</p>
+
+<div class='resolved'>Decide the level of requirements: MUST/SHOULD and justify. This is <a href="http://www.w3.org/2011/prov/track/issues/40">ISSUE-40</a> and <a href="http://www.w3.org/2011/prov/track/issues/41">ISSUE-41</a>. MUST is confirmed. </div>
+
+
+<p>The interpretation of a role is specific to the process execution it relates
+to, which means that a same role may appear in relation to two different process executions with different interpretations.
+From this specification's viewpoint, a role's interpretation is out of
+scope.</p>
+
+
+
+
+
+</section>
+
+<section id="expression-Location">
+<h3>Location</h3>
+
+<p><dfn id="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be specified, such as by a coordinate, address, landmark, row, column, and so forth.</p>
+
+
+<p>
+Location is an OPTIONAL characteristics of
+entity, process execution, and agent.
+</p>
+
+
+
+</section>
+
+<section id="expression-OrderingOfProcesses">
+<h3>Ordering of Process Executions</h3>
+</section>
+
+
+<p>PIDM allows two forms of temporal relationships between process executions to be expressed.
+<dfn id="InformationOrdering">Information flow ordering</dfn> states that a characterized thing was generated by a process execution before it was used by another process execution.
+<dfn id="ControlOrdering">Control ordering</dfn> states that the end of
+a process execution precedes the start of another process execution,
+by a same agent.
+</p>
+
+
+<p>
+An instance of a <span class="name">wasInformedBy</span> construct, written as
+<span class="name">wasInformedBy(pe2,pe1)</span> in the Provenance Abstract Syntax Notation:
+<ul>
+<li> refers to a process execution <span class="name">pe2</span>;
+<li> refers to a process execution <span class="name">pe1</span>
+</ul>
+and expresses information flow ordering between <span class="name">pe2</span> and <span class="name">pe1</span>.
+The meaning of the <span class="name">wasInformedBy</span> construct is specified as follows.
+
+<div class='constraint' id='wasInformedBy'>Given two process executions denoted by <span class="name">pe1</span> and <span class="name">pe2</span>,
+ the construct <span class="name">wasInformedBy(pe2,pe1)</span>
+holds, <span class='conditional'>if and only if</span>
+ there is an entity denoted by <span class="name">e</span> and roles <span class="name">r1</span> and <span class="name">r2</span>,
+such that <span class="name">wasGeneratedBy(e,pe1,r1)</span> and <span class="name">used(pe2,e,r2)</span> hold.
+</div>
+
+
+
+<p>
+An instance of an <span class="name">wasScheduledAfter</span> construct, written as
+<span class="name">wasScheduledAfter(pe2,pe1)</span> in the Provenance Abstract Syntax Notation:
+<ul>
+<li> refers to a process execution <span class="name">pe2</span>;
+<li> refers to a process execution <span class="name">pe1</span>,
+</ul>
+and expresses control ordering between <span class="name">pe2</span> and <span class="name">pe1</span>.
+The meaning of the <span class="name">wasScheduledAfter</span> construct is as follows.
+
+<div class='constraint' id='wasScheduledAfter'>Given two process executions denoted by <span class="name">pe1</span> and <span class="name">pe2</span>,
+ the construct <span class="name">wasScheduledAfter(pe2,pe1)</span>
+holds, <span class='conditional'>if and only if</span>
+ there are two entities denoted by <span class="name">e1</span> and <span class="name">e2</span> and roles <span class="name">r1</span> and <span class="name">r2</span>,
+such that <span class="name">wasControlledBy(pe1,e1,r1)</span> and <span class="name">wasControlledBy(pe2,e2,r2)</span> and <span class="name">wasDerivedFrom(e2,e1)</span>.
+</div>
+
+
+
+<div class='issue'>Suggested definition for process ordering. This is <a href="http://www.w3.org/2011/prov/track/issues/50">ISSUE-50</a>.</div>
+</p>
+
+
+<section id="expression-Revision">
+<h3>Revision</h3>
+
+<p> <dfn id="dfn-Revision">Revision</dfn> represents the creation of a characterized thing considered to be a variant of another. Deciding whether something is made available as a revision of something else usually involves an agent who is responsible for declaring that the former is variant of the latter. </p>
+
+<p>An assertion wasRevisionOf, noted <span class="name">wasRevisionOf(e2,e1,ag)</span>:
+<ul>
+<li> refers to an entity <span class="name">e2</span>, denoting a newer version of a thing;
+<li> refers to an entity <span class="name">e1</span>, denoting a older version of a thing;
+<li> MAY refer to a responsible agent <span class="name">ag</span>.
+</ul>
+</p>
+
+
+<p>
+From an assertion <span class="name">wasRevisionOf(new,old,ag)</span>, one can infer that:
+<ul>
+<li> The characterized thing denoted by <span class="name">new</span> is derived from the characterized thing denoted by <span class="name">old</span>
+<li> There exists an entity <span class="name">X</span>, such that:
+<ul>
+<li> <span class="name">new</span> wasComplementOf <span class="name">X</span>;
+<li> <span class="name">old</span> wasComplementOf <span class="name">X</span>;
+<li> <span class="name">X</span> MAY have been asserted.
+</ul>
+</ul>
+</p>
+
+<p><span class="name">wasRevisionOf</span> is a strict sub-relation
+ of <span class="name">wasDerivedFrom</span> since two entities <span class="name">e2</span> and <span class="name">e1</span>
+ may satisfy <span class="name">wasDerivedFrom(e2,e1)</span> without being a variant of
+ each other.
+</p>
+
+<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='resolved'> 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>
+
+</section>
+
+<section id="expression-Participation">
+<h3>Participation</h3>
+
+<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-hadParticipant">hadParticipant</dfn>, noted <span class="name">hadParticipant(pe,e)</span>,
+<ul>
+<li> refers to a process execution <span class="name">pe</span>;
+<li> refers to an entity <span class="name">e</span>;
+</ul>
+
+<div class='constraint' id='participation'>
+<a name="PIL:0014">
+Given a process execution <span class="name">pe</span> and entity <span class="name">e</span>, <span class="name">hadParticipant(pe,e)</span> holds <span class='conditional'>if and only if</span>:
+<ul>
+<li> <span class="name">used(pe,e)</span> holds, or</li>
+<li> <span class="name">wasControlledBy(pe,e)</span> holds, or</li>
+<li> <span class="name">wasComplementOf(e1,e)</span> holds for some entities <span class="name">e1</span>, and
+ <span class="name">hadParticipant(pe,e1)</span> some process execution <span class="name">pe</span>.</li>
+</ul>
+</a> [<a
+href="../ontology/ProvenanceFormalModel.html#PIL:0014">PIL:0014</a>]
+</div>
+
+
+
+<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="expression-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>
+
+
+<p>A provenance container construct, noted <span class="name">provenanceContainer(id, constructs)</span>:
+<ul>
+<li> contains an identifier <span class="name">id</span>;</li>
+<li> contains a set of provenance constructs <span class="name">constructs</span>.</li>
+</ul>
+
+<p>How general meta-information is expressed is beyond the scope of this specification, except for a few key metatypes specified in the <a href="#expression-Account">Account</a> construct.</p>
+
+
+<div class='pending'>Asserter needs to be defined. This is <a href="http://www.w3.org/2011/prov/track/issues/51">ISSUE-51</a>.</div>
+
+</p>
+
+</section>
+
+<section id="expression-Account">
+<h3>Account</h3>
+
+<p>An <dfn id="dfn-Account">Account</dfn> is a special kind of provenance container forming a perspective on the world. </p>
+
+<p>An account has a mandatory asserter.</p>
+
+<p>An account provides a scope for some constraints associated with the constructs it wraps, such as the uniqueness of generation for a given entity.</p>
+
+
+
+<p>An account construct, noted <span class="name">account(id, asserter, constructs)</span>:
+<ul>
+<li> contains an identifier <span class="name">id</span>;</li>
+<li> refers to an agent <span class="name">asserter</span>;</li>
+<li> contains a set of provenance constructs <span class="name">constructs</span>.</li>
+</ul>
+</p>
+
+<p> The union of two accounts can be defined by forming a container
+containing the unions of their respective constructs. Accounts are not
+closed under union because the constraints may no longer be satisfied
+in the resulting union. </p>
+
+</section>
+
+<section id="expression-Collection">
+<h3>Collection</h3>
+
+<div class='note'>To be written in september.</div>
+
+This section is a placeholder for a specification of relations used to express structuring of entities into collections. That is:
+<ul>
+ <li>By introducing "entity collection" as a specialization of Entity (this will be a recursive definition: a collection is a type of Entity that contains other Entities, which may be collections). The proposal is to initially introduce nested ordered lists, possibly labelled, as a kind of collection that is grounded in a well-defined theory and is used in practice (i.e., as a model of XML documents)
+
+ <li> part-of relations to express current and past membership of Entities as part of a collection.
+
+ </ul>
+
+Specifically, the following relations are envisioned (to be made precise later):
+ <ul>
+ <li> current containment: <strong>wasMemberOf(<entity>, <collection>, <position>)</strong>
+ <li> former containment: <strong>wasRemovedFRom(<entity>, <collection>, <position>)</strong>
+ <li> new containment: <strong>wasAddedTo(<entity>, <collection>, <position>)</strong>
+ </ul>
+
+</section>
+
+
+
+ </section>
+
+ <section>
+<h2>Shortcuts and extensions</h2>
+
+<div class='issue'>There are a number of commonly used provenance relations in particular for the web that are not in the model. For practical use and uptake, it would be good to have definitions of these in the provenance model. These concepts should be defined in terms of the already existing "core" concepts. This is <a href="http://www.w3.org/2011/prov/track/issues/44">ISSUE-44</a>.</div>
+
+<section>
+<h3>Quotation</h3>
+
+Quotation represents the repeating or copying of some part of a characterized thing.
+
+<p> An assertion wasQuoteOf, noted <span class="name"> wasQuoteOf(e2,e1,ag,ag2)</span>:
+<ul>
+<li>refers to an entity <span class="name">e2</span>, denoting the quote;
+<li>refers to an entity <span class="name">e1</span>, denoting the entity being quoted;
+<li>MAY refer to an agent who is doing the quoting <span class="name">ag</span>;
+<li>MAY refer to the agent that is quoted <span class="name">ag</span>
+</ul>
+</p>
+<p>
+<span class="name">wasQuoteOf</span> is a sub-relation of <span class="name">wasRevisionOf</span>
+</p>
+
+</section>
+
+<section>
+<h3>Attribution</h3>
+
+Attribution represents that a characterized thing is ascribed to an agent.
+
+<p> An assertion wasAttributedTo, noted <span class="name"> wasAttributedTo(e1,ag)</span>:
+<ul>
+<li>refers to an entity <span class="name">e2</span>, denoting the entity;
+<li>refers to an agent who the entity is attributed to <span class="name">ag</span>.
+</ul>
+</p>
+<p>
+<span class="name">wasQuoteOf</span> is a strict sub-relation of <span class="name">wasEventuallyDerivedFrom</span>
+</p>
+
+
+</section>
+
+<section>
+<h3>Summary</h3>
+Represents a characterized thing that is a synopsis or abbreviation of another entity.
+
+<p> An assertion wasSummaryOf, noted <span class="name"> wasSummaryOf(e2,e1)</span>:
+<ul>
+<li>refers to an entity <span class="name">e2</span>, denoting the summary;
+<li>refers to an entity <span class="name">e1</span>, denoting the entity being summarized.
+</ul>
+</p>
+<p>
+<span class="name">wasSummaryOf</span> is a strict sub-relation of <span class="name">wasEventuallyDerivedFrom</span>
+</p>
+
+
+</section>
+
+<section>
+<h3>Original Source</h3>
+
+Represents a characterized thing in which another characterized thing first appeared.
+
+<p> An assertion hasOriginalSource, noted <span class="name"> hasOriginalSource(e2,e1)</span>:
+<ul>
+<li>refers to an entity <span class="name">e2</span>, denoting the entity that first appeared;
+<li>refers to an entity <span class="name">e1</span>, denoting the entity where that entity first appeared.
+</ul>
+</p>
+<p>
+<span class="name">hasOriginalSource</span> is a strict sub-relation of <span class="name">wasEventuallyDerivedFrom</span>
+</p>
+
+
+</section>
+ </section>
+
+
+<section class="appendix">
+ <h2>Illustration and Notation Conventions</h2>
+
+ <p> In this section, we summarize the conventions adopted for the graphical illustration and the abstract syntax notation appearing in this specification.
+ </p>
+
+<div class='note'>Should we formalize the graphical illustration and abstract syntax notation. Where? Should they become normative?</div>
+
+<section id='illustration-convention'>
+ <h3>Illustration Conventions</h3>
+<ul>
+<li>The graphical illustration aims to <em>illustrate</em> the provenance model. It is not intended to represent all the details of the model, and therefore, cannot be seen as a alternate notation for expressing provenance.</li>
+
+<li>The graphical illustration is a graph. </li>
+
+<li>entities, process executions and agents are represented as nodes, with oval, rectangular, and half-hexagonal shapes, respectively. </li>
+
+<li>Use, Generation, Derivation, IVPof are represented as directed edges.</li>
+
+<li>entities are layed out according to temporal order (the temporal event at which they are generated). Time SHOULD progress from left to right or from top to bottom. This means that edges for Use, Generation and Derivation typically point from right to left or from bottom to top.</li>
+
+</ul>
+
+
+</section>
+
+
+<section id='PASN-convention'>
+ <h3>Provenance Abstract Syntax Notation Conventions</h3>
+<ul>
+<li>Constructs are expressed as <span class="name">name(arg0, arg1, ...)</span>, 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> Preliminary BNF grammar for the Provenance Abstract Syntax Notation
+<pre data-include='grammar.html'></pre>
+
+<div class='grammar'>
+<span class="nonterminal">expression</span> :=
+<span class="nonterminal">node</span> <!-- better name than node?? -->
+| <span class="nonterminal">relation</span>
+| <span class="nonterminal">assertionBundle</span>
+<br/>
+<!-- -->
+<span class="nonterminal">node</span> :=
+<span class="nonterminal">entity</span>
+|<span class="nonterminal">processExecution</span>
+|<span class="nonterminal">agent</span> <br/>
+<!-- -->
+<span class="nonterminal">relation</span> :=
+<span class="nonterminal">generation</span>
+|<span class="nonterminal">use</span>
+|<span class="nonterminal">derivation</span>
+|<span class="nonterminal">control</span>
+|<span class="nonterminal">complement</span>
+|<span class="nonterminal">peOrdering</span>
+|<span class="nonterminal">revision</span>
+|<span class="nonterminal">participation</span> <br/>
+<!-- -->
+<span class="nonterminal">assertionBundles</span> :=
+|<span class="nonterminal">container</span>
+|<span class="nonterminal">account</span> <br/>
+<!-- -->
+<br/>
+<span class="nonterminal">entity</span> :=
+<span class="name">entity</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="name">[</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">]</span>
+<span class="name">)</span><br/>
+<!-- -->
+<span class="nonterminal">attribute-values</span> :=
+<span class="nonterminal">attribute-value</span>
+|<span class="nonterminal">attribute-value</span> <span class="name">,</span> <span class="nonterminal">attribute-values</span>
+<br/>
+<span class="nonterminal">attribute-value</span> :=
+<span class="nonterminal">attribute</span>
+<span class="name">:</span>
+<span class="nonterminal">Literal</span>
+<br/>
+<br/>
+
+<!-- -->
+<span class="nonterminal">generation</span> :=
+<span class="name">wasGeneratedBy</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">role</span>
+<span class="name">)</span><br/>
+<br/>
+
+<!-- -->
+<span class="nonterminal">use</span> :=
+<span class="name">used</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">role</span>
+<span class="name">)</span><br/>
+<br/>
+
+<!-- -->
+<span class="nonterminal">derivation</span> := <br/>
+<span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">processExecution</span>
+<span class="name">,</span>
+<span class="nonterminal">role</span>
+<span class="name">,</span>
+<span class="nonterminal">role</span>
+<span class="name">)</span><br/>
+| <span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">identifier</span>
+<span class="name">)</span><br/>
+| <span class="name">wasEventuallyDerivedFrom</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">identifier</span>
+<span class="name">)</span><br/>
+| <span class="name">dependedOn</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">identifier</span>
+<span class="name">)</span><br/>
+<!-- -->
+<br/>
+<span class="nonterminal">identifier</span> := <span class="nonterminal">token</span><br/>
+<span class="nonterminal">role</span> := <span class="nonterminal">token</span><br/>
+<span class="nonterminal">attribute</span> := <span class="nonterminal">token</span><br/>
+<span class="nonterminal">Literal</span> := <span class="nonterminal">string</span> <!-- to be revisited -->
+|<span class="nonterminal">number</span>
+|<span class="nonterminal">time</span><br/>
+<br/>
+</div>
+</li>
+</ul>
+</section>
+
+ </section>
+
+<section class="appendix">
+ <h2>Acknowledgements</h2>
+ <p>
+ WG membership to be listed here.
+ </p>
+ </section>
+
+ </body></html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/README.txt~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,8 @@
+Changes in version 2011-09-19:
+
+The following issues have been addressed in this version of the document
+and have been closed pending review:
+
+- ISSUE-87: section 2.2 now explains the role of PROV-ASN. Its role
+ is now more central in this document (as reflected in the new title).
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/authors.txt Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,14 @@
+Khalid
+Paul Groth
+Simon Miles
+Graham Klyne
+James Myers
+
+
+
+
+Borderline
+Stian
+Tim Lebo
+Jim Mccusker
+Stephen Cresswell
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments-from-graham.txt~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,220 @@
+With reference to:
+http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html
+Retrieved at about 17:30 on 28-Jul-2011
+
+As promised, I've taken a tilt at reviewing the model draft. I must
+say, I've found it to be really hard going - many of the notions
+described are not making sense to me, and the language used sometimes
+seems to be unnecessarily obscure.
+
+After a mammoth session going though this, I really don't have the
+time or energy to split my comments out into separate issues. I think
+many of them are purely editorial in nature, and as such could be
+cleaned up relatively easily. There are some substantive comments that
+I may separate out as formal issues later, but I'm rather hoping that
+won't be needed.
+
+My comments follow:
+
+
+3.1 Notation used is obscure. What does [...[ mean? Should be explained.
+
+For a general audience, examples based on Unix command shell commands are probably not very helpful.
+
+What is "characterized entity represented by the file". As this is an example, just say "crime statistics" - would that be a correct interpretation?
+
+
+3.2 where did 'e0' come from? - it's not mentioned in 3.1. What is it intended to denote?
+
+The "agent" statements are completely impenetrable to me.
+
+How is the notation to be interpreted. It looks a b it like some kind of deviant Prolog, but either I've forgotten some of the basic constructs, or it's not entirely clear how the deviant bits are meant to be interpreted.
+
+
+3.3 graphical representation: could be very useful, and would be much easier to follow if the illustration included a key
+
+What does it mean for an agent to be linked to a BOB as opposed to a process execution (cf. Alice and e0).
+
+
+4. About the Provenance Language
+
+Introduction of "characterized entities" - if this is something that really needs to be said, I think it needs to be clarified. I spent some time thinking about these two sentences, trying to work out if they could ever be completely correct, or just not understanding what they are intended to convey:
+[[
+Furthermore, this specification is concerned with characterized entities, that is, entities and their situation in the world, as perceived by their asserters.
+
+In the rest of the document, we are concerned with the representation of such entities; their situation in the world will be represented using sets of attributes.
+]]
+
+Why "characterized entities" as opposed to perceived entities"? What's the important distinction here?
+
+The only interpretation I've found that makes sense to me is that the document is concerning itself with entities that are characterized by the values of some bounded set of attributes. But that interpretation, if correct, is not obvious to me from the wording here.
+
+
+"PIL is a language by which representations of the world can be expressed using terms that are drawn from a controlled vocabulary. "
+I'm not sure how to interpret this. Does this "controlled vocabulary include, for example, numbers? Is this controlled vocabulary expected to be the complete set of terms used in PIL expressions?
+
+
+"These representations are relative to an asserter, and in that sense constitute assertions about the world."
+What is this trying to say? I think you might mean something like:
+"These representations are relative to the context of an asserter, and in that sense constitute perceptions about the world."
+which ties back to the earlier statement about "as perceived by their asserters".
+
+"All assertions in PIL SHOULD be interpreted as a record of what has happened, as opposed to what may or will happen."
+I feel we should find a way to strengthen this SHOULD to a MUST, but comments from earlier discussions make this tricky to get right. Maybe:
+"All assertions in PIL MUST be interpreted as a record of what has happened or been observed in some context, as opposed to what might happen or potential observations." In this, I am using the reference to a context to provide just enough wiggle-room for description in future or imagined contexts.
+
+"This specification does not prescribe the means by which assertions are made, for example on the basis of observations, inferences, or any other means."
+The phrasing "... assertions are made" here is jarring, if not confusing - I would think that assertions are made in PIL for the purposes of this spec. Suggest "... how assertions are arrived at, ..."
+
+"The language introduces a notion of "provenance container", which provides a default scope for assertions."
+The term "container" here is suggested of a physical or logical encapsulation, which I don't think is meant. How about "provenance context"?
+
+[[
+... The model may define additional scoping rules for assertions. Identifiers can safely be used within that scope. Optionally, identifiers can be exported so that they can be used outside their default scope. The language does not prescribe the mechanisms by which identifiers are generated.
+]]
+This spec is describing a data model, *not* a language. It says so at the top. As such I think it's entirely inappropriate to start defining linguistic constructs such as identifiers and scoping. Assuming the actual language used will be RDF, I'm not seeing how what you describe will be possible.
+
+"In this specification, when an assertion is defined to refer to another assertion about something, it does so by means of that thing's identifier."
+I don't understand what this is trying to say.
+
+
+5.1 BOB
+
+"A BOB represents an identifiable characterized entity."
+
+What does it mean to be "characterized" here? What does this tell us? What does it mean to not be "characterized"? If this refers to the attribute-based assertions mentioned earlier, does this mean that if there are no such assertions, an entity cannot be a "BOB"?
+
+[[
+A BOB assertion is about a characterized entity, whose situation in the world is variant. A BOB assertion is made at a particular point and is invariant, in the sense that all the attributes are assigned a value as part of that assertion.
+]]
+
+This section is, according to its heading, about "BOB". But this is defining a different concept, so shouldn't this be in a separate section?
+
+It seems to me that what we're talking about here is a "provenance assertion". I think it would be clearer to just describe that, e.g.
+[[
+A provenance assertion is about an entity, whose situation in the world is generally assumed to be variable.
+]]
+
+I either don't understand or don't agree with the second part of that description. The notion of assigning values as party of an assertion seems wrong to me (I think the notion of constraining attributes is the job of the IVP-of relation). I would expect something like:
+[[
+A provenance assertion is made at a particular point and is invariant, in the sense that the attributes it mentions do not change for the entity concerned.
+]]
+
+[[
+A BOB assertion must describe a characterized entity over a continuous time interval in the world (which may collapse into a single instant). Characterizing an entity over multiple time intervals requires multiple BOB assertions, each with its own identifier. Some attributes may retain their values across multiple assertions.
+]]
+This constraint seems rather unnecessary, and maybe counter-productive.
+
+Suppose we want to describe the collective observations of a particular telescope when pointed at a particular region of the sky. This might actually consist of a (possibly unknown) number of disjoint time-segments caused by the rotation of the earth and other factors. I can't see any clear benefit in being forced to treat these observation-sets as distinct entities.
+
+[[
+There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.
+]]
+I don't see this adding any useful information here. Remove?
+
+
+5.2 Process Execution
+
+Thinking about today's teleconference (28 July) and reading this, I'm seeing the key distinction between Entity and Process execution being like the philosophical distinction between continuants (endurant) and occurrents (perdurant) (http://en.wikipedia.org/wiki/Formal_ontology#Common_terms_in_formal_ontologies)
+
+
+5.3 Generation
+
+"characterized entitity" is clumsy - suggest just "entity" (or whatever term is selected for "BOB").
+
+If I had not previously read about OPM, I'd be completely confused by the introduction of "role" here. Following the hyperlink here does not help at all.
+
+[[
+Given an assertion isGeneratedBy(x,pe,r) or isGeneratedBy(x,pe,r,t), the activity denoted by pe and the entities used by pe dermine values of some of x's attributes.
+]]
+I've no idea what this is trying to say.
+
+
+5.4 Use
+
+Same problem with 'role' as above.
+
+[[
+A reference to a given BOB may appear in multiple use assertions that refer to a given process execution, but each of those use assertions must have a distinct role.
+]]
+In light of the above, this seems nonsensical to me.
+
+[[
+Given an assertion uses(pe,x,r) or uses(pe,x,r,t), at least one value of x's attributes is a pre-condition for the activity denoted by pe to terminate.
+]]
+As written this doesn't make sense - a value of an attribute being a precondition seems like a type error to me. I think you mean something like availability of an attribute value. But even that is hard to follow. Suggest simplifying this to just:
+[[
+Given an assertion uses(pe,x,r) or uses(pe,x,r,t), existence of x is a pre-condition for the activity denoted by pe to terminate.
+]]
+
+
+5.5 Derivation
+
+[[
+Given an assertion isDerivedFrom(B,A), one can infer that the use of characterized entity denoted by A precedes the generation of the characterized entity denoted by B.
+]]
+Where does this notion of "use" come from in the absence of some referenced activity?
+
+Concerning transitivity of derivation:
+
+Suppose:
+A has attributes a0, a1
+B having attributes b0, b1 is derived from A, with b0 being dependent on a0
+C having attributes c0, c1, is derived from B with c1 being dependent on b1
+
+So none of the attributes of C can be said to be directly or indirectly dependent on attributes of A, which by the given definition is a requirement for derivation of C from A. Thus, as defined, derivation cannot be transitive.
+
+I don't really know if derivation should or should not be transitive, but the above seems to me like a problem of spurious over-specification. My suggestion for now would be to focus on what really matters and see what logical properties fall out later.
+
+
+5.8 IVP of
+
+The revised (w.r.t. http://www.w3.org/2011/prov/wiki/F2F1ConceptDefinitions#IVP_of) treatment of IVP-of, and relabeling as "complement-of" completely overturns my understanding of what this was intended to capture. I understood the whole point of A IVP-of B was intended to capture the notion that A denotes a contextually constrained form of the entity denoted by B. I don't see what useful purpose this relation serves.
+
+From a practical perspective, given the asymmetric nature of IVP-of (as was) it is easy to express the effect of complement-of in RDF by introducing a new entity node. But I see no way of constructing the strict constraining role of IVP using complement-of.
+
+
+5.9 Time
+
+[[
+Time is defined according to [ISO8601].
+]]
+
+I don't think it is appropriate of an open standard to be normatively dependent on a standard that is available only on payment of a charge for access. In this case, we could make reference to the XML scheme datatypes, which would also require us to think about my next point...
+
+As far as I'm aware, ISO 8601 covers both points in time and time intervals. As such a bare reference to ISO 86012 is not really an adequate definition: which do we want? I suspect http://www.w3.org/TR/xmlschema-2/#dateTime.
+
+
+5.10 Recipe Link
+
+I don't see what useful purpose this serves.
+
+
+5.11 Role
+
+I can't completely follow the description given.
+
+
+5.13 Ordering of Processes
+
+This section confusingly changes the style of presentation from sections dedicated to specific concepts to a vague discussion of possible relationships between things.
+
+
+5.14 Revision
+
+This seems to be just a different form of Derivation that happens to mention an agent. I'm not sure why I'd choose one over the other.
+
+I think this may be unnecessary - would not a similar effect be achieved by having a process execution of "revision" that uses b1, generates b2 and is controlled by ag (possibly with role "revise"?).
+
+
+5.16 Provenance Container
+
+It's not clear what this is intended to be (maybe unsurprising, since
+the definition is absent). But it looks as if it's intended to a
+syntactical kind of thing, which I feel is out of place in a data
+model description (especially if we're expecting to use RDF to
+represent the data). The next version of RDF will probably formally
+define named graphs - I'm not seeing what additional definition would
+be needed here.
+
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/container1.prov~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,4 @@
+
+container([x http://x.com],[acc1,acc2]
+ account(acc1,http://x.com/asserter1,...)
+ account(acc2,http://x.com/asserter1,...))
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/container2.prov~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,82 @@
+
+; An example of container,
+; - declaring three namespaces with prefix x, viz, prov
+; - no account
+; - a set of prov assertions (hence, all considered to be part of a deafult account)
+
+; The example shows illustrations of prov attributes and application
+; specific attributes, and application specific annotations.
+
+; identifiers in this example follow the URN syntax with "demo" namespace
+
+container([x http://x.com/,
+ prov: http://w3.org/prov/,
+ viz: http://viz.com/,
+ ],
+ ,
+
+ entity(urn:demo:0, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice" ])
+ entity(urn:demo:1, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="" ])
+ entity(urn:demo:2, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London last month."])
+ entity(urn:demo:3, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London and New York last month."])
+ entity(urn:demo:4, [ ])
+ entity(urn:demo:5, [ ])
+ entity(urn:demo:6, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London and New York last month.", x:spellchecked="yes"])
+
+ processExecution(urn:demo:100,http://myapp/create-file,t,,[])
+ processExecution(urn:demo:101,http://myapp/add-crime-in-london,t+1,,[])
+ processExecution(urn:demo:102,http://myapp/email,t+2,,[])
+ processExecution(urn:demo:103,http://myapp/edit-London-New-York,t+3,,[])
+ processExecution(urn:demo:104,http://myapp/email,t+4,,[])
+ processExecution(urn:demo:105,http://myapp/spellcheck,,,[])
+
+ wasGeneratedBy(urn:demo:0, urn:demo:100, qualifier())
+ wasGeneratedBy(urn:demo:1, urn:demo:100, qualifier(x:fct="create"))
+ wasGeneratedBy(urn:demo:2, urn:demo:101, qualifier(x:fct="save"))
+ wasGeneratedBy(urn:demo:3, urn:demo:103, qualifier(x:fct="save"))
+ wasGeneratedBy(urn:demo:4, urn:demo:102, qualifier(x:port="smtp", x:section="attachment"))
+ wasGeneratedBy(urn:demo:5, urn:demo:104, qualifier(x:port="smtp", x:section="attachment"))
+ wasGeneratedBy(urn:demo:6, urn:demo:105, qualifier(x:file="stdout"))
+
+ used(urn:demo:101,urn:demo:1,qualifier(x:fct="load"))
+ used(urn:demo:103,urn:demo:2,qualifier(x:fct="load"))
+ used(urn:demo:102,urn:demo:2,qualifier(x:fct="attach"))
+ used(urn:demo:104,urn:demo:3,qualifier(x:fct="attach"))
+ used(urn:demo:105,urn:demo:3,qualifier(x:file="stdin"))
+
+ wasDerivedFrom(urn:demo:2,urn:demo:1)
+ wasDerivedFrom(urn:demo:3,urn:demo:2)
+ wasDerivedFrom(urn:demo:4,urn:demo:2,urn:demo:102,qualifier(x:port=smtp, x:section="attachment"),qualifier(x:fct="attach"))
+ wasDerivedFrom(urn:demo:5,urn:demo:3,urn:demo:104,qualifier(x:port=smtp, x:section="attachment"),qualifier(x:fct="attach"))
+
+ wasComplementOf(urn:demo:1,urn:demo:0)
+ wasComplementOf(urn:demo:2,urn:demo:0)
+ wasComplementOf(urn:demo:3,urn:demo:0)
+ wasComplementOf(urn:demo:6,urn:demo:3)
+
+
+ entity(urn:demo:201, [ prov:type="Person", x:name="Alice" ])
+ agent(urn:demo:201)
+
+ entity(urn:demo:202, [ prov:type="Person", x:name="Bob" ])
+ agent(urn:demo:202)
+
+ entity(urn:demo:203, [ prov:type="Person", x:name="Charles" ])
+ agent(urn:demo:203)
+
+ entity(urn:demo:204, [ prov:type="Person", x:name="David" ])
+ agent(urn:demo:204)
+
+ entity(urn:demo:205, [ prov:type="Person", x:name="Edith" ])
+ agent(urn:demo:205)
+
+ annotation(urn:demo:301,[viz:icon="person.png"])
+ hasAnnotation(urn:demo:201,urn:demo:301)
+ hasAnnotation(urn:demo:202,urn:demo:301)
+ hasAnnotation(urn:demo:203,urn:demo:301)
+ hasAnnotation(urn:demo:204,urn:demo:301)
+ hasAnnotation(urn:demo:205,urn:demo:301)
+
+ )
+
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/container3.prov~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,84 @@
+
+; An example of container,
+; - declaring three namespaces with prefix x, viz, prov
+; - one account
+; - a set of prov assertions (all in the single account)
+
+; The example shows illustrations of prov attributes and application
+; specific attributes, and application specific annotations.
+
+; identifiers in this example follow the URN syntax with "demo" namespace
+
+container([x http://x.com/,
+ prov: http://w3.org/prov/,
+ viz: http://viz.com/,
+ ],
+ [http://x.com/acc1]
+ ,
+ account(http://x.com/acc1,
+ http://x.com/asserter1,
+ entity(urn:demo:0, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice" ])
+ entity(urn:demo:1, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="" ])
+ entity(urn:demo:2, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London last month."])
+ entity(urn:demo:3, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London and New York last month."])
+ entity(urn:demo:4, [ ])
+ entity(urn:demo:5, [ ])
+ entity(urn:demo:6, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London and New York last month.", x:spellchecked="yes"])
+
+ processExecution(urn:demo:100,http://myapp/create-file,t,,[])
+ processExecution(urn:demo:101,http://myapp/add-crime-in-london,t+1,,[])
+ processExecution(urn:demo:102,http://myapp/email,t+2,,[])
+ processExecution(urn:demo:103,http://myapp/edit-London-New-York,t+3,,[])
+ processExecution(urn:demo:104,http://myapp/email,t+4,,[])
+ processExecution(urn:demo:105,http://myapp/spellcheck,,,[])
+
+ wasGeneratedBy(urn:demo:0, urn:demo:100, qualifier())
+ wasGeneratedBy(urn:demo:1, urn:demo:100, qualifier(x:fct="create"))
+ wasGeneratedBy(urn:demo:2, urn:demo:101, qualifier(x:fct="save"))
+ wasGeneratedBy(urn:demo:3, urn:demo:103, qualifier(x:fct="save"))
+ wasGeneratedBy(urn:demo:4, urn:demo:102, qualifier(x:port="smtp", x:section="attachment"))
+ wasGeneratedBy(urn:demo:5, urn:demo:104, qualifier(x:port="smtp", x:section="attachment"))
+ wasGeneratedBy(urn:demo:6, urn:demo:105, qualifier(x:file="stdout"))
+
+ used(urn:demo:101,urn:demo:1,qualifier(x:fct="load"))
+ used(urn:demo:103,urn:demo:2,qualifier(x:fct="load"))
+ used(urn:demo:102,urn:demo:2,qualifier(x:fct="attach"))
+ used(urn:demo:104,urn:demo:3,qualifier(x:fct="attach"))
+ used(urn:demo:105,urn:demo:3,qualifier(x:file="stdin"))
+
+ wasDerivedFrom(urn:demo:2,urn:demo:1)
+ wasDerivedFrom(urn:demo:3,urn:demo:2)
+ wasDerivedFrom(urn:demo:4,urn:demo:2,urn:demo:102,qualifier(x:port=smtp, x:section="attachment"),qualifier(x:fct="attach"))
+ wasDerivedFrom(urn:demo:5,urn:demo:3,urn:demo:104,qualifier(x:port=smtp, x:section="attachment"),qualifier(x:fct="attach"))
+
+ wasComplementOf(urn:demo:1,urn:demo:0)
+ wasComplementOf(urn:demo:2,urn:demo:0)
+ wasComplementOf(urn:demo:3,urn:demo:0)
+ wasComplementOf(urn:demo:6,urn:demo:3)
+
+
+ entity(urn:demo:201, [ prov:type="Person", x:name="Alice" ])
+ agent(urn:demo:201)
+
+ entity(urn:demo:202, [ prov:type="Person", x:name="Bob" ])
+ agent(urn:demo:202)
+
+ entity(urn:demo:203, [ prov:type="Person", x:name="Charles" ])
+ agent(urn:demo:203)
+
+ entity(urn:demo:204, [ prov:type="Person", x:name="David" ])
+ agent(urn:demo:204)
+
+ entity(urn:demo:205, [ prov:type="Person", x:name="Edith" ])
+ agent(urn:demo:205)
+
+ annotation(urn:demo:301,[viz:icon="person.png"])
+ hasAnnotation(urn:demo:201,urn:demo:301)
+ hasAnnotation(urn:demo:202,urn:demo:301)
+ hasAnnotation(urn:demo:203,urn:demo:301)
+ hasAnnotation(urn:demo:204,urn:demo:301)
+ hasAnnotation(urn:demo:205,urn:demo:301)
+
+ ))
+
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/diff.txt Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,16 @@
+diff -r 79920156d85d model/ProvenanceModel.html
+--- a/model/ProvenanceModel.html Fri Sep 16 13:11:44 2011 +0100
++++ b/model/ProvenanceModel.html Fri Sep 16 13:14:00 2011 +0100
+@@ -313,10 +313,10 @@
+
+ The model includes two additional entity types: <strong>qualifiers</strong> and <strong>annotations</strong>. These are both structured as sets of attribute-value pairs.
+ <ul><li> Qualifiers can be associated to relations, namely <strong>use</strong> and <strong>wasGeneratedBy</strong>, in order to further characterise their nature. <strong>Role</strong> is a standard qualifier.
+-<li> Annotations are used to provide additional, "free-form" information regarding <strong>any</strong> construct of the model, with no prescribed meaning. The difference between attributes and annotations is further clarified <a href="#expression-annotation">here</a>.
++<li> Annotations are used to provide additional, "free-form" information regarding <strong>any</strong> identifiable construct of the model, with no prescribed meaning. The difference between attributes and annotations is further clarified <a href="#expression-annotation">here</a>.
+ </ul>
+
+-Attributes and extensions are the main <strong>extensibility points</strong> in the model: individual interest groups are expected to extend PROV-DM by introducing new sets of attributes and annotations as needed to address applications-specific provenance modelling requirements.
++Attributes, qualifiers, and annotation are the main <strong>extensibility points</strong> in the model: individual interest groups are expected to extend PROV-DM by introducing new sets of attributes, qualifiers, and annotations as needed to address applications-specific provenance modelling requirements.
+
+
+ </section>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/entity.txt Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,79 @@
+
+
+In section 4:
+
+
+Data modelling has always relied on three elements, and it seems strange that one would have to recall this:
+- the "real world": stuff you want to model
+- a representation of the real-world: the model itself
+- a language for expressing the model
+
+
+
+In PIDM, we have the need to accommodate multiple relative views of
+the world, and thus multiple and often overlapping models (which may
+also change in time). This leads to the three elements being
+formulated as:
+
+- stuff in the real world: identifiable characterized things and activities
+- their representation: Entities (further specialized as needed), and relations amongst entities
+- assertions, which state the existence of entities and of their relationships
+
+
+
+----------------------------------------------------------------------
+
+In section 5:
+
+
+
+In PIDM, an entity construct is a representation of an identifiable characterized thing.
+
+An instance of an entity construct, expressed as entity(id, [ attr:
+val, ...]) in the Provenance Abstract Syntax Notation:
+- contains an identifier id, denoting a characterized thing
+- contains a set of attribute-value pairs [ attr: val, ...], representing
+ this characterized thing's situation in the world.
+
+The assertion of an instance of an entity construct , entity(id, [ attr: val, ...]), states, from a given asserter's viewpoint, the existence of an identifiable characterized thing, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two events in the world (which may collapse into a single instant).
+
+Example:
+... states the existence of a thing of type File and location /shared/crime.txt, and creator alice, denoted by identifier e0, during some characterization interval.
+
+
+Further properties:
+- If an asserter wishes to characterize a thing with same attribute-value pairs over several intervals, then they are required to assert multiple entity assertions, each with its own identifier.
+
+- There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.
+
+
+
+General assumption (to appear in section 4):
+ in the real world:
+ - identifiable characterized things, their situation in the world
+ - activities
+ - events
+
+
+
+
+----------------------------------------------------------------------
+
+
+An entity is an assertion about a characterized thing. Using the Provenance Abstract Syntax Notation, an entity is represented as:
+
+ entity(e,[a1:v1, a2:v2, ...])
+
+where "e" is a name that denotes the characterized thing about which provenance is expressed, and the "ai:vi" are assertions about attributes of that thing. The entity is true exactly when all of the attribute assertions are true of the named thing.
+
+For example, the entity represented by:
+
+ entity(e0, [ type: "File", location: "/shared/crime.txt", creator: "Alice" ])
+
+might be interpreted as asserting that the thing denoted by "e0" is a file whose file system location is "/shared/crime.txt", and which was created by "Alice".
+
+----------------------------------------------------------------------
+
+ Defn 2. entity(id, [ attr: val, ...]) *is* an assertion that an
+entity, identified by id, existed and was characterized by the
+attributes [ attr: val, ...].
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/entity.txt~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,3 @@
+
+
+In PIDM, an entity construct is a representation of an identifiable thing.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/example.txt~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,41 @@
+
+provenanceContainer {
+
+bob(e0, [ type: "File", location: "/shared/crime.txt", creator: "Alice" ])
+bob(e1, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "" ])
+bob(e2, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London last month."])
+bob(e3, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London and New York last month."])
+bob(e4)
+bob(e5)
+bob(e6, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London and New York last month.", disclaimer: "some text"])
+
+
+isDerivedFrom(e2,e1)
+isDerivedFrom(e3,e2)
+isDerivedFrom(e4,e2)
+isDerivedFrom(e5,e3)
+
+isGeneratedBy(e0,pe0,out)
+isGeneratedBy(e1,pe0,out)
+isGeneratedBy(e2,pe1,out)
+isGeneratedBy(e3,pe3,out)
+isGeneratedBy(e4,pe2,out)
+isGeneratedBy(e5,pe4,out)
+
+uses(pe1,e1,in)
+uses(pe3,e2,in)
+uses(pe2,e2,in)
+uses(pe4,e3,in)
+
+processExecution(pe0,create-file,t)
+processExecution(pe1,add-crime-in-london,t+1)
+processExecution(pe2,copy,t+2)
+processExecution(pe3,edit-London-New-York,t+3)
+processExecution(pe4,copy,t+4)
+
+ivpOf(e1,e0)
+ivpOf(e2,e0)
+ivpOf(e3,e0)
+ivpOf(e6,e3)
+
+}
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/intro.html Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,41 @@
+<html>
+<p>
+The term 'provenance' refers to the sources of information, such
+as people, entities, and processes, involved in producing,
+influencing, or delivering a piece of data or a thing in the world.
+In particular, 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. In an open and inclusive environment
+such as the Web, users find information that is often contradictory or
+questionable: provenance can help those users to make trust judgments.
+</p>
+
+
+<p>
+The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
+Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it, process it, and reason over it.</p>
+
+<p>A set of specifications define the various aspects
+that are necessary to achieve this vision in an inter-operable
+way:</p>
+<ul>
+<li> This document defines the PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption; </li>
+<li> A normative serialization of PROV-DM in RDF [[PROV-OWL2]], specified by means of a mapping to the OWL2 Web Ontology Language [[!OWL2-SYNTAX]];</li>
+<li> The mechanisms for accessing and querying provenance [[PROV-PAQ]].</li>
+</ul>
+
+
+<p>
+The PROV-DM data model for provenance consists of a set of core
+concepts, and a few common extensions, based on these core concepts. PROV-DM provides extensibility points allowing further domain-specific and application specific extensions to be defined.</p>
+
+<p>This specification also introduces
+PROV-ASN, an abstract syntax that is primarily aimed at human consumption. PROV-ASN allows
+serializations of PROV-DM instances to be created in a technology independent manner,
+it facilitates its mapping to concrete syntax, and it is used as the basis for a
+formal semantics.
+</p>
+
+
+</html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/intro.html~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,15 @@
+
+<p>
+The term 'provenance' refers to the sources of information, such
+as people, entities, and processes, involved in producing,
+influencing, or delivering a piece of data or a thing in the world.
+In particular, 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. In an open and inclusive environment
+such as the Web, users find information that is often contradictory or
+questionable: provenance can help those users to make trust judgments.
+</p>
+
+
+<p>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/intro.txt Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,15 @@
+
+<p>
+The term 'provenance' refers to the sources of information, such
+as people, entities, and processes, involved in producing,
+influencing, or delivering a piece of data or a thing in the world.
+In particular, 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. In an open and inclusive environment
+such as the Web, users find information that is often contradictory or
+questionable: provenance can help those users to make trust judgments.
+</p>
+
+
+<p>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/intro.txt~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,2 @@
+
+<p>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/simon-comments.txt~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,223 @@
+Luc, Paolo,
+
+Here's my comments on the current data model document, annotated with
+(T) for typo/text clarity or (C) for content comment/question. I think
+most/all comments are small enough that an issue need not be raised.
+
+Throughout:
+(T) Sections are referred to in the text by "Section Entity", "Section
+Process Execution" etc. Shouldn't these be the section numbers?
+(T) There seems to be inconsistency in symbols following the change
+from roles to qualifiers. Sometimes "q" is used in constraint
+definitions, examples etc. and sometimes "r" is used. I suggest it
+would be clearer to always use "q".
+(T) There are a few "characterised" in amongst the majority
+"characterized" spelling.
+(C) At least one standard qualifier name, "role", is used in the
+document, but it is not clear what namespace this name is in. Does it
+mean no other "role"s from domain-specific ontologies may be used in
+Prov data?
+
+Sec 2.1:
+(T) paragraph 1: "Words such thing or activity" should be "Words such
+as 'thing' or 'activity'"
+(C) paragraph 2: The first mention of "provenance" in the document
+proper is in the second paragraph of this section, and is a bit out of
+the blue ("unambiguously report provenance"). Can we add some
+intuition about what provenance is (for this data model)?
+(T) Example paragraph 1: "perspectives about a resource" should be
+"perspectives on a resource"
+(C) Example paragraph 1: "the report independent of where it is hosted
+over time" - I suggest also saying "and of its content over time", to
+distinguish this entity from the report version entity above it
+(C) paragraph 6: "punctual events"? "punctual" as most commonly used
+implies prior planning of when something should occur. I'm not sure
+what you are intending in this context.
+(C) paragraph 6: "a partial order exists between events". I assume you
+mean a temporal order? What kind of ordering do you mean?
+(C) paragraph 6: "global notion of time and Lamport's style clocks" -
+this seems like a weirdly specific level of detail for this overview
+section, especially considering that many other aspects of the model
+are not mentioned at all in the overview.
+
+Sec 2.3:
+(C) Regarding the note (not attempting to ensure consistency of an
+asserter) - this seems practical. I'm not sure how we could enforce
+consistency in any circumstance, only define what it means or say it
+is application specific.
+
+Sec 4.1:
+(T) "We denote this e1." and the same for e2 etc. It is not entirely
+clear whether "this" refers to the event or the entity.
+
+Sec 4.2:
+(C) The fact that Alice is the creator of e1 seems to be expressed
+twice, first as an attribute "creator=Alice", and secondly as the
+"creator" role of an agent in the creation process. I don't think it
+is a good idea for either clarity of use of the model or for ensuring
+interoperability for there to be multiple ways to express the same
+thing, if it can be at all avoided. Even if we cannot stop someone
+using either method, can't we say which they *should* use to aid
+interoperability?
+(T) "Generation expressions... represent the event at which a file is
+created". The surrounding text is generic rather than specific to the
+example, implying this should be "entity" rather than "file",
+Otherwise, readers may assume that all entities are files or that
+generation only applies to files.
+(T) Paragraph on wasComplementOf: in "attribute content" and
+"attribute spellchecked", fixed width font (or another font) should be
+used for the attribute names to show they are names, else the sentence
+can be read in strange ways.
+
+Sec 4.3:
+(T) Fig 1: The arrow from pe2 to a3 is a different direction to the
+other "agent" links. It is also not clear if an "agent" link is the
+same as a "wasControlledBy" link. If so, the pe2-a3 arrow direction
+makes most sense, as the others seem to be saying the agent was
+controlled by the process execution.
+
+Sec 5.1:
+(T) The last sentence, regarding a "house-keeping construct" is rather
+opaque. I'm not sure what the reader is supposed to understand from
+this.
+
+Sec 5.2.1:
+(C) First sentence: "entity expression" is given exactly the same
+definition that "entity" was in Section 4. I think having two terms
+for the same thing will cause confusion. I like addition of
+"expressions" to the model in general, though, as I think this greatly
+clarifies what is intended.
+(C) "the meaning of attribute in the context of a process execution
+expression is similar to the meaning of attribute for entity
+expression" - I think the meaning should be exactly the same, not just
+similar, else there will be confusion.
+(C) Following from the above point: "A process execution expression's
+attribute remains constant for the duration of the activity" - OK, but
+does it also characterise the process execution, e.g. is the start
+time part of what distinguishes one execution from others?
+(T) "noted processExecution" - I think you mean "denoted" (or
+"written" or "expressed")
+
+Sec 5.2.3:
+(T) "representation a characterized thing" - missing "of"
+(T) Last sentence, "On the contrary" should be "On the other hand",
+and "inferred" should be "infer"
+
+Sec 5.2.4:
+(T) Last sentence: "expectede"
+
+Sec 5.3.3.1:
+(C) I suggest that, as accounts are not introduced until later in the
+document, the generation-unicity constraint will not make sense here.
+Moreover, I think the constraint is more about accounts and what it
+means for them to be consistent than it is about generation events or
+process executions. Therefore, I suggest moving this constraint to the
+section on accounts.
+(C) Given that constraint derivation-events applies, don't we just
+have two ways of saying the same thing? Why use the long form of
+wasDerivedFrom when the same can be expressed using wasGeneratedBy and
+used? Which variety *should* be used?
+
+Sec 5.3.3.2:
+(T?) Constraint "derivation-linked-independent" seems to be a
+tautology. I guess this is a typo?
+
+Sec 5.3.3.3:
+(T) Paragraph 4: "In other word" should be "In other words"
+
+Sec 5.3.4:
+(C) This section seems to be confusingly expressed, implying that
+non-agent entities can control executions, whereas the control-agent
+constraint (in the section on agents) contradicts this. It is probably
+just a matter of clarifying the text, e.g. if you mean that a
+non-agent entity can be asserted to be controlling an execution but
+from this inferred to be an agent.
+(T) The text may be read to imply that a control link has only one
+qualifier, role, whereas I guess you mean that, like use/generate, it
+can have multiple "modalities" as part of the qualifier?
+
+Sec 5.3.5:
+(C) I can see this section causing some difficulty... While that may
+just be the nature of the topic, there seems an important thing
+missing: what has complementarity got to do with provenance? In other
+words, what value (with regards to provenance) is there in asserting
+complementarity?
+(C) The text suddenly starts talking about "properties" from the
+second paragraph. What are these, and do they have any relation to
+attributes?
+(C) Should the justification of why the complementarity relation is
+not transitive be in this document? I would expect this document to
+just state that it is not transitive and, for brevity and simplicity,
+leave justifications to another document.
+
+Sec 5.3.6:
+(C) Similarly to above, I'm not sure the justification of why
+wasInformedBy is not transitive should be in this document.
+
+Sec 5.3.8:
+(C) Constraint participation: This seems odd to me. In what
+circumstances would you not know or want to assert which of the three
+possibilities (used/controlled/complement) applied for a given entity
+and execution? Is hadParticipant as defined really useful?
+
+Sec 5.3.9:
+(C) Grammar definition: I don't understand what the
+"relationIdentification" stuff is about or what all the identifiers
+identify.
+
+Sec 5.4.1:
+(C) This appears to be yet another way to say the same thing,
+following the comment on Sec 4.2 above. If A is an "asserter" of
+expression E, then we can either (i) express E to be an entity and use
+an attribute "asserter=E"; (ii) express E to be an entity and A to be
+an agent playing "role=asserter"; or (iii) put A in the "asserter"
+slot of an "account" expression containing E. Why do we need all three
+ways? Isn't method (ii) most consistent with the rest of the model?
+
+Sec 5.4.2:
+(T) Second sentence: "return all the provenance assertions" - all the
+assertions? or just "all the assertions in the container"?
+(C) Under the definition given, you cannot have expressions in a
+container but not in an account. Does this imply that every Prov
+expression is made accessible as part of an account? I think this
+would be a good thing for clarity, but it is not explicit in the
+document (and also differs from OPM).
+
+Section 5.5.1:
+(C) I agree with the first note. If it is mandatory to say something
+but that what we say can be nothing, that means that it is not
+mandatory at all. The "mandatory" thing seems to be just saying
+something about the ASN, and so is irrelevant as the ASN is just there
+to make the model concrete and readable.
+
+Sec 5.5.4:
+(C) Second note: Wouldn't this mean that either account IDs or entity
+IDs can never be URIs, as a sequence of URIs would itself not be a
+URI? If so, that seems to make RDF serialisation difficult to achieve.
+
+Sec 5.5.6:
+(C) I don't see the connection between the section's introductory text
+and the content of the subsections.
+
+Sec 5.7.1:
+(C) I think this section needs something introductory to say why it is
+relevant to the data model, i.e. what has it to do with provenance,
+why is it useful in the context of provenance, why is it standardised
+rather than application-specific?
+(C) If my record of what occurred does not start with an empty
+container, but one with contents, how do I say that the elements are
+part of the container? Do I have to model this as a series of
+wasAddedTo links, even if I know nothing about how the elements were
+added? Or is it out of scope of the standard?
+
+Sec 5.7.2:
+(C) I don't see how wasQuoteOf is a sub-relation of wasRevisionOf, or
+wasAttributedTo a sub-relation of wasEventuallyDerivedFrom, when the
+super-relations do not contain reference to any agents but the
+sub-relations do. What does it mean?
+(T) Last sentence of 5.7.2.2: "wasQuoteOf" should be "wasAttributedTo"
+
+Thanks,
+Simon
+
+-- Dr Simon Miles Lecturer, Department of Informatics Kings College London, WC2R 2LS, UK +44 (0)20 7848 1166
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/todiscuss.txt Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,92 @@
+Hi Paolo,
+
+There are a few things to discuss between us, and I think we should
+update the document accordingly, if we are in agreement. They follow
+issues that were raised earlier.
+
+
+About derivation
+----------------
+
+One needs to link derivation to process execution.
+We should introduce a form of inference (referred to as completion by Jan vdb)
+
+
+If there isDerivedFrom(e1,e0) holds, then there exists a process execution pe, and roles r0,r1,
+such that:
+ isGeneratedBy(e1,pe,r1) and use(pe,e0,r0)
+
+
+The converse does not hold: one cannot infer derivation from the
+presence of a process execution, and use and generation.
+
+
+About time
+----------
+
+Generation time is instantaneous. If it was not, it should be
+possible to identify an attribute of the generated BOB that changes,
+... and hence, we would be dealing with several BOBs.
+
+
+By symmetry, I would suggest that use time is also instantaneous.
+It is a design decision, to ensure that "symmetry" in the various
+relations.
+
+Start and end time of process executions are also instaneous, and
+activities represented by process executions have a duration.
+
+
+About derivation time
+---------------------
+
+It is suggested that time is associated to derivation. Which is it?
+- process execution start time
+- process execution end time
+- process execution duration
+- destination use time
+- source generation time
+- a combination of the above
+- something else?
+
+About roles
+-----------
+
+Use, Generation, and Control assertions MUST contain a role.
+
+Roles are mandatory since they allow uniform data structures.
+Furthermore, this specification defines the the set of unspecified
+roles (unspecified0, unspecified1, unspecified2, ...). To facilitate
+the writing of these assertions, syntactic notations MAY allow for
+roles not to be expressed. In that case, a default role from the set
+'unspecified role' will be assumed.
+
+Example
+ use(pe,e) expands to use(pe,e,unspecified)
+where unspecified is an unspecified role.
+
+
+Derivation transitivity
+-----------------------=
+
+I think we mean for derivation to be transitive.
+
+We should say it. Of course, this brings the kind of issue we
+had in OPM.
+
+We can assert:
+ isDerivedFrom(e1,2) ... this corresponds to e1 -! r- -> e2 in paper with vdb
+
+We can infer by transitive closure
+ isDerivedFrom(e1,2) ... this corresponds to e1 -> e2 in paper with vdb
+
+Can we assert
+ isDerivedFrom(e1,2) ... this corresponds to e1 -> e2 in paper with vdb
+
+What notation do we use to distinguish those various guys.
+
+Then of course, do we have the transitive use and generation ... and why not control.
+
+If we go for that, we need to be careful about notation.
+
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/todiscuss.txt~ Mon Nov 21 16:47:40 2011 +0000
@@ -0,0 +1,20 @@
+Hi Paolo,
+
+There are a few things to discuss between us, and I think we should
+update the document accordingly, if we are in agreement. They follow
+issues that were raised earlier.
+
+About time.
+----------
+
+Generation time is instantaneous. If it was not, it should be
+possible to identify an attribute of the generated BOB that changes,
+... and hence, we would be dealing with several BOBs.
+
+
+By symmetry, I would suggest that use time is also instantaneous.
+It is a design decision, to ensure that "symmetry" in the various
+relations.
+
+Start and end time of process executions are also instaneous, and
+activities represented by process executions have a duration.