--- a/model/ProvenanceModel.html Wed Jul 20 12:26:24 2011 +0100
+++ b/model/ProvenanceModel.html Wed Jul 20 15:34:13 2011 +0100
@@ -185,10 +185,10 @@
<p>
Generation:
<pre>
-isGeneratedBy(e2,pe1)
-isGeneratedBy(e3,pe3)
-isGeneratedBy(e4,pe2)
-isGeneratedBy(e5,pe4)
+isGeneratedBy(e2,pe1,out)
+isGeneratedBy(e3,pe3,out)
+isGeneratedBy(e4,pe2,out)
+isGeneratedBy(e5,pe4,out)
</pre>
</p>
@@ -196,10 +196,10 @@
<p>
Use:
<pre>
-use(pe1,e1)
-use(pe3,e2)
-use(pe2,e2)
-use(pe4,e3)
+use(pe1,e1,in)
+use(pe3,e2,in)
+use(pe2,e2,in)
+use(pe4,e3,in)
</pre>
</p>
@@ -287,7 +287,8 @@
<p>PIL is a language by which representations of the world can be expressed using terms that are drawn from a controlled
vocabulary.
-These representations are relative to an asserter. Different asserters will normally contribute different representations, and no attempt is made to define the notion of consistency of such different sets of assertions. The lanaguage provides the means to associate attribution to assertions.
+These representations are relative to an asserter, and in that sense constitute assertions about
+ the world. Different asserters will normally contribute different representations, and no attempt is made to define the notion of consistency of such different sets of assertions. The language provides the means to associate attribution to assertions.
</p>
@@ -298,6 +299,18 @@
This specification does not prescribe the means by which assertions are made, for example on the basis of observations, inferences, or any other means.
</p>
+
+<p>The language introduces a notion of "provenance container", which
+provides a default scope for assertions. 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.</p>
+
+
+<p>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.<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>
+
</section>
@@ -307,6 +320,8 @@
<h2>Provenance Data Model</h2>
+<p>The language defines the following types of constructs.</p>
+
<section>
@@ -322,16 +337,20 @@
<p>A BOB assertion:
<ul>
-<li> MAY contain an identifier;</li>
+<li> contains an identifier;</li>
<li> contains a set of attribute-value pairs.</li>
</ul>
+<p>
+<pre class="example">
+bob(e0, [ type: "File", location: "/shared/crime.txt", creator: "Alice" ])
+</pre>
+</p>
+
<p>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.</p>
-<p>The identifier in a BOB assertion is OPTIONAL to allow for other means of identifying entities, possibly implicitly.<p>
-
<p>There is no assumption that the set of attributes is complete and
that the attributes are independent/orthogonal of each other.</p>
@@ -342,28 +361,25 @@
<section id="concept-ProcessExecution">
<h3>Process Execution</h3>
-<p>A <dfn id="dfn-ProcessExecution">process execution</dfn> represents an identifiable activity that performs a piece of work.
-
-<div class="note">" that performs a piece of work" is redundant as at the top we write that "activity" is a primitive concept to be interpreted in its "informal meaning"</div>
+<p>A <dfn id="dfn-ProcessExecution">process execution</dfn> represents an identifiable activity, which performs a piece of work.</p>
-
-<div class="note">" I am not very supportive of it, but was agreed at f2f1. </div>
-</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.</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 repsenting the activity need not mention time information, nor duration, because they may not be known.</p>
<p> A process execution assertion:
<ul>
-<li> MAY contain an identity;
-<li> MAY contain a recipe link;
- <div class="note">NB <em>recipe</em> undefined at this point</div>
+<li> contains an identifier;
+<li> MAY contain a <a href="#concept-RecipeLink">recipe link</a>;
<li> MAY contain a start time;
<li> MAY contain an end time.
</ul>
</p>
-<p>Identity in a process execution assertion is OPTIONAL to allow for
-unidentified (though still identifiable!) process executions.<p>
+<p>
+<pre class="example">
+processExecution(pe1,add-crime-in-london,t+1,t+1+epsilon)
+</pre>
+</p>
+
<p>From the assertion of a process execution, one can infer that the start precedes the end of the represented activity. </p>
@@ -377,40 +393,29 @@
<p><dfn id="dfn-Generation">Generation</dfn> represents the creation of a new characterized entity by an activity. This characterized entity did not exist before creation.</p>
-<div class="note">I think this needs to be qualified: "according to the asserter that makes a generation assertion..."</div>
-
-<div class="note">I don't think so, since preamble already says it. </div>
-
-
<p>A Generation assertion:
<ul>
<li> refers to a process execution;
-<li> refers to a BOB, which represents the characterized entity that is consumed;
- <div class="note">Consumed?? </div>
-<li> contains a role, distinguishing this generation from all other generations by the same process execution;
- <div class="note"> role? bullet item above not clear at all to me. All of a sudden we have multiple possible generations by the same process? this is going to be confusing.</div>
-
- <div class="note"> sentence was wrong. </div>
-
-<li> MAY contain a "generation time", the time at which the characterized entity was consumed.</p>
+<li> refers to a BOB, which represents the characterized entity that is created;
+<li> contains a <a href="#concept-Role">role</a>;
+<li> MAY contain a "generation time", the time at which the characterized entity was created.</p>
</ul>
</p>
+<p>
+<pre class="example">
+isGeneratedBy(e2,pe1,out)
+</pre>
+</p>
<p>A given BOB can be generated at most by one process execution.</p>
-<div class="note"> I hope we can discuss the two statements below. Suddenly we have a relational notation for Generation. For consistency with the list above, I would put pe before x.</div>
-
-<div class="note"> Order of arguments is: effect first, cause second.</div>
-
-<div class="note"> Also: characteristics -> properties?</div>
-
-<p>Given an assertion <b>Generated(x,pe,r)</b> or <b>Generated(x,pe,r,t)</b>, the
+<p>Given an assertion <b>isGeneratedBy(x,pe,r)</b> or <b>isGeneratedBy(x,pe,r,t)</b>, the
activity denoted by <b>pe</b> and the entities used by <b>pe</b> dermine values of some of <b>x</b>'s characteristics.</p>
-<p>Given an assertion <b>Generated(x,pe,r)</b> or <b>Generated(x,pe,r,t)</b>, one can
+<p>Given an assertion <b>isGeneratedBy(x,pe,r)</b> or <b>isGeneratedBy(x,pe,r,t)</b>, one can
infer that the generation of the entity denoted by <b>x</b> precedes the end
of <b>pe</b> and follows the beginning of <b>pe</b>.
</p>
@@ -426,23 +431,32 @@
<p>A Use assertion:
<ul>
-<li> contains a process execution;
-<li> contains a BOB, representing the characterized entity that is used;
-<li> contains a role, distinguishing all possible uses of a same BOB by a same process execution;
+<li> refers to a process execution;
+<li> refers to a BOB, representing the characterized entity that is used;
+<li> contains a <a href="#concept-Role">role</a>;
<li> MAY contain a "use time", the time at which the characterized entity was used.</p>
</ul>
</p>
-<p>A given process execution is allowed to use a given BOB multiple
-times, but each of those uses must have a different role.</p>
+<p>
+<pre class="example">
+use(pe1,e1,in,t)
+</pre>
+</p>
+
+
+<p>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.</p>
-<p>Given an assertion <b>Use(pe,x,r)</b> or <b>Use(pe,x,r,t)</b>, the
-activity denoted by <b>pe</b> exploits/reads the values of some of
-<b>x</b>'s characteristics.</p>
+<p>Given an assertion <b>Use(pe,x,r)</b> or <b>Use(pe,x,r,t)</b>,
+at least one value of <b>x</b>'s attributes is a pre-condition for the activity denoted by <b>pe</b> to terminate.</p>
+
+
<p>Given an assertion <b>Use(pe,x,r)</b> or <b>Use(pe,x,r,t)</b>, one can
infer that the use of the entity denoted by <b>x</b> precedes the end
@@ -461,20 +475,25 @@
<p>A Derivation assertion:
<ul>
-<li> contains a BOB, denoting the generated characterized entity;
-<li> contains a BOB, denoting the used characterized entity.
+<li> refers to a BOB, denoting the generated characterized entity;
+<li> refers to a BOB, denoting the used characterized entity.
</ul>
</p>
+<p>
+<pre class="example">
+isDerivedFrom(e5,e3)
+</pre>
+</p>
-<p>From an assertion <b>Derived(B,A)</b>, the values of some
+<p>From an assertion <b>isDerivedFrom(B,A)</b>, the values of some
characteristics of B are at least partially determined by the values
of some characteristics of A.</p>
-<p>Given an assertion <b>Derived(B,A)</b>, one can infer that the use
+<p>Given an assertion <b>isDerivedFrom(B,A)</b>, one can infer that the use
of characterized entity denoted by <b>A</b> precedes the generation of
the characterized entity denoted by <b>B</b>.
@@ -554,20 +573,21 @@
<section id="concept-Role">
<h3>Role</h3>
-<div class="note">move above first use. </div>
-<p>A <dfn id="dfn-Role">role</dfn> is the function assumed by a BOB or
+<p>A <dfn id="dfn-Role">role</dfn> is a label that names the function assumed by a BOB or
an agent with respect to a specific process execution.</p>
<p>Use, Generation, and Control assertions MUST contain a role.</p>
-<p>There is at most one occurrence of a given role for all Use, Generation and Control assertions for a given process execution.</p>
-<p>A role's meaning is specific to the process execution it relates
-to. From this specification's viewpoint, a role's meaning is out of
-scope; thus, roles are considered as syntactic attributes.</p>
-<div class="note">or: "attributes whose domain is defined by the application? </div>
+<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.</p>
+
+<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>
+