merging with main branch
authorGraham Klyne
Thu, 04 Aug 2011 15:58:51 +0100
changeset 110 a055a7987aa7
parent 109 70d2851b9179 (current diff)
parent 108 f7ff3e10b799 (diff)
child 111 0068a01361c0
merging with main branch
--- a/model/ProvenanceModel.html	Thu Aug 04 15:57:43 2011 +0100
+++ b/model/ProvenanceModel.html	Thu Aug 04 15:58:51 2011 +0100
@@ -20,7 +20,7 @@
           specStatus:           "ED",
           
           // the specification's short name, as in http://www.w3.org/TR/short-name/
-          shortName:            "PIL-Model",
+          shortName:            "PIDM-Model",
  
           // if your specification has a subtitle that goes below the main
           // formal title, define it here
@@ -121,58 +121,52 @@
 
 
 <p>This scenario is concerned with the evolution of a crime statistics
-file (e0) stored on a shared file system and which journalists Alice,
-Bob, Charles, David, and Edith can share and edit. We now consider
-different events in the evolution of file (e0).</p>
+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 now consider various events in the evolution of file (e0);
+events follow each other, unless specified otherwise.</p>
 
 
 
 <p>
-Event evt1: Alice creates an empty file in /share/crime.txt.  We denote this e1.
+Event evt1: Alice creates (pe0) an empty file in /share/crime.txt.  We denote this e1.
 </p>
 
 <p>
-Event evt2: Bob appends the following line to /share/crime.txt:
+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 the contents of /share/crime.txt
-<pre>
-cat /share/crime.txt | sendmail ...
-</pre>
-We denote this e4.
+<p>Event evt3: Charles emails (pe2) the contents of /share/crime.txt, as an
+attachment, which refer to as e4.
 </p>
 
 <p>
-Event evt4: David edits file /share/crime.txt as follows.
+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 the contents of /share/crime.txt
-<pre>
-cat /share/crime.txt | sendmail ...
-</pre>
-We denote this e5.
+<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 on the file /share/crime.txt.
+<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 in PIL</h3>
+<h3>Encoding using Abstract Syntax Notation</h3>
 
-In this section, the example is encoded using PIL constructs (specified in section <a href="\data-model-concepts">concepts</a>), expressed in the Abstract Syntax Notation. Details about the Abstract Syntax Notation can be found in <a href="'#ASN-convention'">appendix</a>.
+In this section, the example is encoded according to the Provenance data model (specified in section <a href="\data-model-concepts">concepts</a>), expressed in the Abstract Syntax Notation. Details about the Abstract Syntax Notation can be found in <a href="'#ASN-convention'">appendix</a>.
 <p>
-Entities (construct described at <a href="#concept-Entity">entity</a>):
+Entities (construct described in <a href="#concept-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: "" ])
@@ -185,20 +179,23 @@
 </p>
 
 
-<p>
+<p>The entities, as characterized, hold during intervals delimited by events. The following table lists all events and their corresponding validity events, where evt5 is considered to be the most recent event.
+<blockquote>
 <table>
-<tr><td>e0:</td><td> holds in interval [t,t+4[</td></tr>
-<tr><td>e1:</td><td> holds in interval [t,t+1[</td></tr>
-<tr><td>e2:</td><td> holds in interval [t+1,t+3[</td></tr>
-<tr><td>e3:</td><td> holds in interval [t+3,t+4[</td></tr>
-<tr><td>e4:</td><td> the information piped to sendmail at t+2 (that's a copy of e2's content)</td></tr>
-<tr><td>e5:</td><td> the information piped to sendmail at t+4 (that's a copy of e3's content)</td></tr>
-<tr><td>e6:</td><td> holds in interval [t+3,t+4[; a different view of the characterized thing represented by e3. </td></tr>
+<tr><td>Entity</td><td>Interval</td></tr>
+<tr><td>e0</td><td>evt1 - evt5</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 - evt3</td></tr>
+<tr><td>e4</td><td>evt3 - evt5</td></tr>
+<tr><td>e5</td><td>evt3 - evt5</td></tr>
+<tr><td>e6</td><td>evt6 - evt5 </td></tr>
 </table>
+</blockquote>
 </p>
 
 <p>
-Derivations (construct described at <a href="#concept-Derivation">derivation</a>):
+Derivations (construct described in <a href="#concept-Derivation">Section Derivation</a>): derivations express that an entity is derived from another.
 <pre>
 isDerivedFrom(e2,e1)
 isDerivedFrom(e3,e2)
@@ -208,54 +205,57 @@
 </p>
 
 <p>
-Generations (construct described at <a href="#concept-Generation">generation</a>):
+Process Executions (construct described in <a href="#concept-ProcessExecution">Section Process Execution</a>): process execution represents an activity in the scenario.
 <pre>
-isGeneratedBy(e0,pe0,out)     
-isGeneratedBy(e1,pe0,out)     
+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="#concept-Generation">Section Generation</a>): generation is the event at which a file is created in a specific form. To distinguish the various entities generated by a given process execution, a role  (construct described in <a href="#concept-Role">Section Role</a>) is introduced.  Illustrations of such roles are outFile, outContent, out, attachment.
+<pre>
+isGeneratedBy(e0,pe0,outFile)     
+isGeneratedBy(e1,pe0,outContent)     
 isGeneratedBy(e2,pe1,out)     
 isGeneratedBy(e3,pe3,out)     
-isGeneratedBy(e4,pe2,out)     
-isGeneratedBy(e5,pe4,out)     
+isGeneratedBy(e4,pe2,attachment)     
+isGeneratedBy(e5,pe4,attachment)     
+isGeneratedBy(e6,pe5,out)     
 </pre>
 </p>
 
 
 <p>
-Uses (construct described at <a href="#concept-Use">use</a>):
+Uses (construct described in <a href="#concept-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="#concept-Role">Section Role</a>) is introduced.  Illustrations of such roles are in and fileIn.
 <pre>
 uses(pe1,e1,in)
 uses(pe3,e2,in)
 uses(pe2,e2,in)
 uses(pe4,e3,in)
+uses(pe5,e3,fileIn)
 </pre>
 </p>
 
+
+
 <p>
-Process Executions (construct described at <a href="#concept-ProcessExecution">process execution</a>):
+isComplementOf:   (this relation is described in <a href="#concept-IVP-of">Section isComplementOf</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>
-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)
+isComplementOf(e1,e0)
+isComplementOf(e2,e0)
+isComplementOf(e3,e0)
+isComplementOf(e6,e3) 
 </pre>
 </p>
 
 
 <p>
-IVP of:   (this relation is described at <a href="#concept-IVP-of">IVP-of</a>)
-<pre>
-ivpOf(e1,e0)
-ivpOf(e2,e0)
-ivpOf(e3,e0)
-ivpOf(e6,e3) 
-</pre>
-Note that e6 strictly contains all of e3's attributes, and it has an extra one, "disclaimer", and is therefore an ivpOf e3. Note that no other assertions (i.e., on generation) is available for this entity.
-</p>
-
-
-<p>
-Agents (construct described at <a href="#concept-Agent">agent</a>):
+Agents (construct described at <a href="#concept-Agent">Section Agent</a>): in the provenance model, the various users are represented as agents, themselves being a type of entity.
 <pre>
 entity(e7, [ type: "Person", name: "Alice" ])
 agent(e7)
@@ -276,13 +276,13 @@
 
 
 <p>
-Control (construct described at <a href="#concept-Control">control</a>):
+Control (construct described in <a href="#concept-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="#concept-Role">Section Role</a>).  Illustrations of such roles are creator, author and communicator.
 <pre>
-isControlledBy(pe0,e7,"creator")
-isControlledBy(pe1,e8,"author")
-isControlledBy(pe2,e9, "communicator")
-isControlledBy(pe3,e10,"author")
-isControlledBy(pe4,e11, "communicator")
+isControlledBy(pe0,e7, creator)
+isControlledBy(pe1,e8, author)
+isControlledBy(pe2,e9, communicator)
+isControlledBy(pe3,e10, author)
+isControlledBy(pe4,e11, communicator)
 </pre>
 </p>
 </section> 
@@ -453,7 +453,7 @@
 </p>
 
 <p>A process execution is not an entity, because ... </p>
-<div class='note'>Formulate justification. We shouldn't adopt FRBR definitions. </div>
+<div class='note'>Formulate justification.  Should we or or not adopt FRBR definitions? </div>
 
 
 
@@ -487,13 +487,18 @@
 </pre>
 </p>
 
-<p>A given entity can be generated at most by one process execution.</p>
+<p>A given entity can be generated at most by one process execution.
+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>
 
 <p>Given a process execution <b>pe</b>, entity <b>e</b>, role <b>r</b>, and optional time <b>t</b>,
 if the assertion <b>isGeneratedBy(e,pe,r)</b>
-or <b>isGeneratedBy(e,pe,r,t)</b> holds, the values of some of <b>e</b>'s
+or <b>isGeneratedBy(e,pe,r,t)</b> holds, the values of <em>some</em> of <b>e</b>'s
 attributes are determined by the activity denoted by <b>pe</b> and the
-entities used by <b>pe</b>.</p>
+entities used by <b>pe</b>.
+Only some of the attributes values may be determined since, in an open world, not all used entities may have been asserted.
+</p>
 
 <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 thing denoted by <b>x</b> precedes the end
@@ -503,7 +508,12 @@
 
 <div class='pending'>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='issue'> Comments on generation <a href="http://www.w3.org/2011/prov/track/issues/59">ISSUE-59</a>.</div>
+<div class='pending'> Comments on generation <a href="http://www.w3.org/2011/prov/track/issues/59">ISSUE-59</a>.</div>
+
+<div class='pending'> Added justification for generation by a single process <a href="http://www.w3.org/2011/prov/track/issues/67">ISSUE-67</a>.</div>
+
+
+
 
 </section>
 
@@ -939,7 +949,7 @@
 <h3>Provenance Container</h3>
 
 
-<p>A <dfn id="dfn-ProvenanceContainer">Provenance Container</dfn> is an identifiable wrapper for a set of PIL constructs, including other containers, which allows for additional meta-information pertaining to these constructs to be expressed.</p> 
+<p>A <dfn id="dfn-ProvenanceContainer">Provenance Container</dfn> is an identifiable wrapper for a set of PIDM constructs, including other containers, which allows for additional meta-information pertaining to these constructs to be expressed.</p> 
 
 <p>Such meta-information may be authorship, date of creation, justification for assertions, and cryptographic signature. </p>