--- a/model/ProvenanceModel.html Wed Nov 16 17:14:30 2011 -0500
+++ b/model/ProvenanceModel.html Wed Nov 16 22:46:55 2011 +0000
@@ -81,7 +81,7 @@
// 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"],
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css", "./extra.css", "http://www.w3.org/2007/OWL/toggles.js"],
// editors, add as many as you like
// only "name" is required
@@ -159,7 +159,25 @@
This document is part of a set of specifications aiming to define the various aspects that are necessary to achieve the visition on inter-operable interchange of provenance information in heterogeneous environments such as the Web. This document defines the PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption. Two other documents, to be released shortly, are: 1) a normative serialization of PROV-DM in RDF, specified by means of a mapping to the OWL2 Web Ontology Language; 2)
the mechanisms for accessing and querying provenance.
</section>
-
+
+<!-- DOESN@T WORK
+<div class="buttonpanel">
+<form action=""><p>
+<input id="show-sd" onclick="set_display_by_class('div','image','none'); set_display_by_id('hide-sd',''); set_display_by_id('show-sd','none');" type="button" value="Hide Diagrams" />
+<input id="hide-sd" onclick="set_display_by_class('div','image',''); set_display_by_id('hide-sd','none'); set_display_by_id('show-sd','');" style="display: none" type="button" value="Show Diagrams" />
+<input id="hide-bnf" onclick="set_display_by_class('div','grammar','none'); set_display_by_id('hide-bnf','none'); set_display_by_id('show-bnf','');" type="button" value="Hide Grammar" />
+<input id="show-bnf" onclick="set_display_by_class('div','grammar',''); set_display_by_id('hide-bnf',''); set_display_by_id('show-bnf','none');" style="display: none" type="button" value="Show Grammar" />
+<input id="hide-examples" onclick="set_display_by_class('div','anexample','none'); set_display_by_id('hide-examples','none'); set_display_by_id('show-examples','');" type="button" value="Hide Examples" />
+<input id="show-examples" onclick="set_display_by_class('div','anexample',''); set_display_by_id('hide-examples',''); set_display_by_id('show-examples','none');" style="display: none" type="button" value="Show Examples" />
+<input id="hide-fss" onclick="show_syntaxes(false,bRDFVisible); set_display_by_id('hide-fss','none'); set_display_by_id('show-fss','');" type="button" value="Hide FSS in Examples" />
+<input id="show-fss" onclick="show_syntaxes(true,bRDFVisible); set_display_by_id('hide-fss',''); set_display_by_id('show-fss','none');" style="display: none" type="button" value="Show FSS in Examples" />
+<input id="hide-rdf" onclick="show_syntaxes(bFSSVisible,false); set_display_by_id('hide-rdf','none'); set_display_by_id('show-rdf','');" style="display: none" type="button" value="Hide RDF in Examples" />
+<input id="show-rdf" onclick="show_syntaxes(bFSSVisible,true); set_display_by_id('hide-rdf',''); set_display_by_id('show-rdf','none');" type="button" value="Show RDF in Examples" />
+</p>
+</form>
+</div>
+-->
+
<section>
<h2>Introduction<br>
</h2>
@@ -269,7 +287,7 @@
<p>Hence, to accommodate different perspectives on things and their situation in the world as perceived by us, we introduce the idea of a characterized thing, which refers to a thing and its situation in the world, as characterized by someone. We then define an <dfn id="concept-entity">entity</dfn> as an identifiable characterized thing. An entity <em>fixes some aspects</em> of a thing and its situation in the world, so that it becomes possible to express its provenance, and what causes these specific aspects to be as such. An alternative entity may fix other aspects, and its provenance may be different.</p>
-<div class="xmpl">
+<div class="anexample">
Different users may take different perspectives on a resource with
a URL. These perspectives in this conceptualization of the world are
referred to as entities. Three such entities may be
@@ -353,7 +371,7 @@
PROV-DM is a provenance data model designed to express <em>representations</em> of the world.
</p>
-<div class="xmpl">
+<div class="anexample">
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>
@@ -367,7 +385,7 @@
<div class="note">Suggestion: add "should not attempt to define or ensure the
consistency of the assertions made by the same asserter."</div>
-<div class="xmpl">
+<div class="anexample">
An alternative representation of the above file is a set of blocks in a hard disk.
</div>
@@ -496,13 +514,13 @@
<p>
Entity Records (described in <a href="#record-Entity">Section Entity</a>). The file in its various forms and its copies are modelled as entity records, corresponding to multiple characterizations, as per scenario. The entity records are identified by <span class="name">e0</span>, ..., <span class="name">e6</span>.</p>
<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(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", content="" ])
+entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", content="There was a lot of crime in London last month."])
+entity(e3, [ prov:type="File", ex:path="/shared/crime.txt", ex: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"])
+entity(e6, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", content="There was a lot of crime in London and New York last month.", spellchecked="yes"])
</pre>
@@ -589,19 +607,19 @@
<p>
Agent Records (described at <a href="#record-Agent">Section Agent</a>): the various users are represented as agents, themselves being a type of entity.</p>
<pre>
-entity(a1, [ type="Person", name="Alice" ])
+entity(a1, [ prov:type="Person", name="Alice" ])
agent(a1)
-entity(a2, [ type="Person", name="Bob" ])
+entity(a2, [ prov:type="Person", name="Bob" ])
agent(a2)
-entity(a3, [ type="Person", name="Charles" ])
+entity(a3, [ prov:type="Person", name="Charles" ])
agent(a3)
-entity(a4, [ type="Person", name="David" ])
+entity(a4, [ prov:type="Person", name="David" ])
agent(a4)
-entity(a5, [ type="Person", name="Edith" ])
+entity(a5, [ prov:type="Person", name="Edith" ])
agent(a5)
</pre>
@@ -701,6 +719,20 @@
<p>In PROV-DM, an <dfn id="dfn-entity" title="entity">entity record</dfn> is a representation of an entity.</p>
+
+
+
+<p>An entity record, noted <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> identifying an entity;</li>
+<li><em>attributes</em>: contains a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this entity's situation in the world.</li>
+</ul>
+
+
+<p>
+The assertion of an entity record, <span class="name">entity(id, [ attr1=val1, ...])</span>, states, from a given asserter's viewpoint, the existence of an entity, 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>
In PROV-ASN, an entity record's text matches the <span class="nonterminal">entityRecord</span> production of the grammar defined in this specification document.
</p>
@@ -727,28 +759,14 @@
<br/>
</div>
-
-
-<p>An entity record, noted <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN:</p>
-<ul>
-<li> contains an identifier <span class="name">id</span> identifying an entity;</li>
-<li> contains a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this entity's situation in the world.</li>
-</ul>
-
-
-<p>
-The assertion of an entity record, <span class="name">entity(id, [ attr1=val1, ...])</span>, states, from a given asserter's viewpoint, the existence of an entity, 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>
-
-
-
+<div class="anexample">
<p>
The following entity record,</p>
-<pre class="example">
-entity(e0, [ type="File", location="/shared/crime.txt", creator="Alice" ])
+<pre class="codeexample">
+entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
</pre>
-states the existence of an entity of type File and location /shared/crime.txt, and creator alice, denoted by identifier e0, during some characterization interval.
-
+states the existence of an entity of type File and path <span class="name">/shared/crime.txt</span> in the file system, and creator alice, denoted by identifier e0, during some characterization interval. The attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span class="name">type</span> is reserved in the PROV-DM namespace.
+</div>
Further considerations:
<ul>
@@ -790,6 +808,20 @@
<h3>Activity Record</h3>
<p>In PROV-DM, an <dfn id="dfn-activity">activity record</dfn> is a representation of an identifiable activity, which performs a piece of work.</p>
+
+<p>An activity, represented by an activity record, is delimited by its start and its end events; hence, it occurs over an interval delimited by two events. However, an activity record need not mention time information, nor duration, because they may not be known.</p>
+
+<p>Such start and end times constitute <em>attributes</em> of an activity, where the interpretation of attribute in the context of an activity record is the same as the interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the world can be represented by other attribute-value pairs, which MUST also remain unchanged during the activity duration.</p>
+
+<p> An activity record, written <span class="name">activity(id, rl, st, et, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span>;</li>
+<li><em>recipeLink</em>: an OPTIONAL <a href="#record-RecipeLink">recipe link</a> <span class="name">rl</span>, which consists of a domain specific description of the activity;</li>
+<li><em>startTime</em>: an OPTIONAL time <span class="name">st</span> indicating the start of the activity;</li>
+<li><em>startTime</em>: an OPTIONAL time <span class="name">et</span> indicating the end of the activity;</li>
+<li><em>attributes</em>: a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole duration.</li>
+</ul>
+
<p>In PROV-ASN, an activity record's text matches the <span class='nonterminal'>activityRecord</span> production of the grammar defined in this specification document.</p>
@@ -811,27 +843,14 @@
<span class="nonterminal">other-attribute-values</span> := <span class="nonterminal">attribute-values</span>
</div>
-<p>An activity, represented by an activity record, is delimited by its start and its end events; hence, it occurs over an interval delimited by two events. However, an activity record need not mention time information, nor duration, because they may not be known.</p>
-
-<p>Such start and end times constitute <em>attributes</em> of an activity, where the interpretation of attribute in the context of an activity record is the same as the interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the world can be represented by other attribute-value pairs, which MUST also remain unchanged during the activity duration.</p>
-
-<p> An activity record, written <span class="name">activity(id, rl, st, et, [ attr1=val1, ...])</span> in PROV-ASN:</p>
-<ul>
-<li> contains an identifier <span class="name">id</span>;</li>
-<li> MAY contain a <a href="#record-RecipeLink">recipe link</a> <span class="name">rl</span>, which consists of a domain specific description of the activity;</li>
-<li> MAY contain a start time <span class="name">st</span>;</li>
-<li> MAY contain an end time <span class="name">et</span>;</li>
-<li> contains a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole duration.</li>
-</ul>
-
-
+<div class="anexample">
<p>
The following activity assertion</p>
-<pre class="example">
-activity(pe1,add-crime-in-london,t+1,t+1+epsilon,[host="server.example.org",type="app:edit"])
+<pre class="codeexample">
+activity(pe1,add-crime-in-london,t+1,t+1+epsilon,[ex:host="server.example.org",prov:type="app:edit"])
</pre>
-<p>identified by identifier <span class="name">id</span>, states the existence of an activity with recipe link <span class="name">add-crime-in-london</span>, start time <span class="name">t+1</span>, and end time <span class="name">t+1+epsilon</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix <span class="name">app</span>). The attribute <span class="name">host</span> is application specific, but MUST hold for the duration of activity. The attribute <span class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.
-</p>
+<p>identified by identifier <span class="name">id</span>, states the existence of an activity with recipe link <span class="name">add-crime-in-london</span>, start time <span class="name">t+1</span>, and end time <span class="name">t+1+epsilon</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix <span class="name">app</span>). The attribute <span class="name">host</span> is application specific, but MUST hold for the duration of activity. The attribute <span class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
+</div>
<p>The mere existence of an activity assertion entails some event ordering in the world, since the start event precedes the end event. This is expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
@@ -882,16 +901,15 @@
-<p>
-With the following assertions,</p>
-
-<pre class="example">
-entity(e1, [employee="1234", name="Alice"]) and agent(e1)
+<div class="anexample">
+<p>With the following assertions,</p>
+<pre class="codeexample">
+entity(e1, [ex:employee="1234", ex:name="Alice"]) and agent(e1)
entity(e2) and wasControlledBy(pe,e2,[prov:role="author"])
</pre>
-<p>the entity record identified by <span class="name">e1</span> is accompanied by an explicit assertion of an agent record, and this assertion holds irrespective of activities it may be involved in. On the other hand, from the entity record identified by <span class="name">e2</span>, one can infer an agent record, as per the following inference.
-</p>
+<p>the entity record identified by <span class="name">e1</span> is accompanied by an explicit assertion of an agent record, and this assertion holds irrespective of activities it may be involved in. On the other hand, from the entity record identified by <span class="name">e2</span>, one can infer an agent record, as per the following inference.</p>
+</div>
<div class='constraint' id='control-agent'>
<span class='conditional'>If</span> the records
@@ -928,10 +946,11 @@
</p>
+<div class="anexample">
<p>
The following annotation record</p>
-<pre class="example">
-annotation(ann1,[ex:color="blue", ex:screenX=20, ex:screenY=30])
+<pre class="codeexample">
+annotation(ann1,[ex:color="blue", ex:screenX="20" %% xsd:integer, ex:screenY="30" %% xsd:integer])
</pre>
<p>consists of a set of application-specific attribute-value pairs, intended
to help the rendering of the record it is associated with, by
@@ -939,6 +958,7 @@
these attribute-value pairs do not constitute a representation of something
in the world; they are just used to help render provenance.
</p>
+</div>
<p>
Attribute-value pairs occurring in annotations differ from attribute-value pairs occurring in entity records and activity records. In entity and activity records, attribute-value pairs MUST be a representation of something in the world, which remain constant for the duration of the characterization interval (for entity record) or the activity duration (for activity records). In annotation records, it is OPTIONAL for attribute-value pairs to be representations of something in the world. If they are a representation of something in the world, then it MAY change value for the corresponding duration. If attribute-value pairs of an annotation record are a representation of something in the world that does not change, they are not regarded as determining characteristics of an entity or activity, for the purpose of provenance.
@@ -953,9 +973,13 @@
<section id="record-relation">
<h3>Relation</h3>
-<p>This section describes all the PROV-DM records creating associations between the elements introduced in section <a href="#record-element">Section element</a>. While these relations are not binary, they all involve two primary elements. They can be summarized as follows. </p>
-
-
+<p>This section describes all the PROV-DM records creating associations between the elements introduced in <a href="#record-element">Section element</a>. While these relations are not binary, they all involve two primary elements. They can be summarized as follows. </p>
+
+<style type="text/css">
+table { text-align: center; margin: 5em 0 0 0; vertical-align: middle }
+</style>
+
+<div class="table">
<table border="1" align="center">
<tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Annotation</td></tr>
<tr><td>Entity</td><td>wasComplementOf</td><td>wasGeneratedBy</td><td>-</td><td>hasAnnotation</td></tr>
@@ -964,7 +988,7 @@
<tr><td>Annotation</td><td>-</td><td>-</td><td>-</td><td>hasAnnotation</td></tr>
<caption>PROV-DM Relation Summary</caption>
</table>
-
+</div>
<p>In PROV-ASN, all these relation records are conformant to the <span class='nonterminal'>relationRecord</span> production of the grammar.</p>
@@ -980,7 +1004,7 @@
The representation of this event encompasses a description of the modalities of generation of this entity by this activity.</p>
-<p>A generation record, written <span class="name">wasGeneratedBy(e,a,attrs,t)</span> in PROV-ASN, has the following components:</p>
+<p>A generation record, written <span class="name">wasGeneratedBy(id,e,a,attrs,t)</span> in PROV-ASN, has the following components:</p>
<ul>
<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the generation record;</li>
<li><em>entity</em>: an identifier <span class="name">e</span> identifying an entity record that represents the entity that is created; </li>
@@ -1210,9 +1234,9 @@
</ul>
-
+<div class="anexample">
<p>The following derivation assertions</p>
-<pre class="example">
+<pre class="codeexample">
wasDerivedFrom(e5,e3,pe4,[ex:channel="out"),[ex:channel="in"])
wasDerivedFrom(e3,e2)
</pre>
@@ -1224,6 +1248,7 @@
entity denoted by <span class="name">e5</span> and generated it on
channel <span class="name">out</span>. The second is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity record and associated attributes implicit. The meaning of "channel" is application specific.
</p>
+</div>
<p>If a derivation record holds for <span class="name">e2</span> and <span class="name">e1</span>, then it means that the entity represented by the entity record identified by <span class="name">e1</span> has an influence on the entity represented by the entity record identified 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>
@@ -1544,10 +1569,10 @@
</div>
-
+<div class="anexample">
<p>A complementarity record is written <span class="name">wasComplementOf(e2,e1)</span>, where <span class="name">e1</span> and <span class="name">e2</span> are two identifiers denoting entity records.</p>
-<pre class="example">
+<pre class="codeexample">
entity(rs,[created="1870"])
entity(rs_l1,[location="loc2"])
@@ -1568,6 +1593,7 @@
wasComplementOf(rs_l1, rs)
wasComplementOf(rs_l2, rs)
</pre>
+</div>
<div class='constraint' id='wasComplementOf-necessary-cond'>
@@ -1644,25 +1670,26 @@
<p>The interpretation of annotations is application-specific. See Section <a href="#record-annotation">Annotation</a> for a discussion of the difference between attributes and annotations. </p>
+<div class="anexample">
<p>
The following records</p>
-<pre class="example">
-entity(e1,[type="document"])
-entity(e2,[type="document"])
-activity(pe,transform,t1,t2,[])
-used(pe,e1,[prov:file="stdin"])
-wasGeneratedBy(e2, pe, [prov:file="stdout"])
-
-annotation(ann1,[icon="doc.png"])
+<pre class="codexample">
+entity(e1,[prov:type="document"])
+entity(e2,[prov:type="document"])
+activity(a,transform,t1,t2,[])
+used(a,e1,[ex:file="stdin"])
+wasGeneratedBy(e2, a, [ex:file="stdout"])
+
+annotation(ann1,[ex:icon="doc.png"])
hasAnnotation(e1,ann1)
hasAnnotation(e2,ann1)
-annotation(ann2,[style="dotted"])
-hasAnnotation(relation(pe,e1,[prov:file="stdin"]),ann2)
+annotation(ann2,[ex:style="dotted"])
+hasAnnotation(relation(a,e1,[ex:file="stdin"]),ann2)
</pre>
-<p>assert the existence of two documents in the world (attribute-value pair: <span class="name">type="document"</span>) represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these records with an annotation indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also asserts an activity, its use of the first entity, and its generation of the second entity. The <span class="name">used</span> relation is annotated with a style (an application specific way of rendering this edge graphically).
+<p>assert the existence of two documents in the world (attribute-value pair: <span class="name">prov:type="document"</span>) represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these records with an annotation indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also asserts an activity, its use of the first entity, and its generation of the second entity. The <span class="name">used</span> relation is annotated with a style (an application specific way of rendering this edge graphically).
</p>
-
+</div>
</section>
@@ -1715,12 +1742,13 @@
<div class='note'>
Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as URI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM assertions. The editors seek inputs on how to resolve this issue. </div>
+<div class="anexample">
<p>
The following account record</p>
-<pre class="example">
+<pre class="codeexample">
account(acc0,
http://example.org/asserter,
- entity(e0, [ type="File", location="/shared/crime.txt", creator="Alice" ])
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
...
wasDerivedFrom(e2,e1)
...
@@ -1732,6 +1760,7 @@
</pre>
<p>contains the set of provenance records of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span class="name">http://example.org/asserter</span>, and is identified by identifier <span class="name">acc0</span>.
</p>
+</div>
<p>Account records constitue a scope for identifiers. An identifier within the scope of an account is intended to denote a single record. However, nothing prevents an asserter from asserting an account containing, for example, multiple entity records with a same identifier but different attribute-values. In that case, they should be understood as a single entity record with this identifier and the union of all attributes values, as formalized in <a href="#identified-entity-in-account">identified-entity-in-account</a>.</p>
@@ -1742,17 +1771,18 @@
<p>Whilst constraint <a href="#identified-entity-in-account">identified-entity-in-account</a> specifies how to understand multiple entity records with a same identifier within a given account, it does not guarantee that the entity record formed with the union of all attribute-value pairs is consistent. Indeed, a given attribute may be assigned multiple values, resulting in an inconsistent entity record, as illustrated by the following example.</p>
+<div class="anexample">
<p>
In the following account record, we find two entity records with a same identifier <span class="name">e</span>.</p>
-<pre class="example">
+<pre class="codeexample">
account(acc1,
http://example.org/id,
- entity(e,[type="person",age=20])
- entity(e,[type="person",age=30])
+ entity(e,[prov:type="person", ex:age="20" %% xsd:integer])
+ entity(e,[prov:type="person", ex:age="30" %% xsd:integer])
...)
</pre>
<p>Application of <a href="#identified-entity-in-account">identified-entity-in-account</a> results in an entity record containing the attribute-value pairs <span class="name">age=20</span> and <span class="name">age=30</span>. This results in an inconsistent characterization of a person. We note that deciding whether a set of attribute-values is consistent or not is application specific.
-</p>
+</p></div>
<p>Account records can be nested since an account record can occur among the records being wrapped by another account. </p>
@@ -1769,13 +1799,13 @@
constraint <a href="#generation-unicity">generation-unicity</a> may no
longer be satisfied in the resulting union. </p>
-
+<div class="anexample">
<p>
Indeed, let us consider another account record</p>
-<pre class="example">
+<pre class="codeexample">
account(acc2,
http://example.org/asserter2,
- entity(e0, [ type="File", location="/shared/crime.txt", creator="Alice" ])
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
...
activity(pe1,create-file,t1)
...
@@ -1783,26 +1813,29 @@
... )
</pre>
<p>with identifier <span class="name">acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">pe1</span> instead of <span class="name">pe0</span> in the previous account <span class="name">acc0</span>. If accounts <span class="name">acc0</span> and <span class="name">acc2</span> are merged together, the resulting set of records violates <a href="#generation-unicity">generation-unicity</a>.</p>
+</div>
<p>Account records constitute a scope for identifiers. Since accounts can be nested, their scope can also be nested; thus, the scope of identifiers should be understood in the context of such nested scopes. When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur. </p>
+<div class="anexample">
<p>
The following account record is inspired from section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>. This account, identified by <span class="name">acc3</span>, declares entity record identified by <span class="name">e0</span>, which is being referred to in the nested account <span class="name">acc4</span>. The scope of identifier <span class="name">e0</span> is account <span class="name">acc3</span>, including subaccount <span class="name">acc4</span>.</p>
-<pre class="example">
+<pre class="codeexample">
account(acc3,
http://example.org/asserter1,
- entity(e0, [ type="File", location="/shared/crime.txt", creator="Alice" ])
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
activity(pe0,create-file,t)
wasGeneratedBy(e0,pe0,[])
account(acc4,
http://example.org/asserter2,
- entity(e1, [ type="File", location="/shared/crime.txt", creator="Alice", content="" ])
+ entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", content="" ])
activity(pe0,copy-file,t)
wasGeneratedBy(e1,pe0,[ex:fct="create"])
isComplement(e1,e0)))
</pre>
<p>Alternatively, an activity record identified by <span class="name">pe0</span> occurs in each of the two accounts. Therefore, each activity record is asserted in a separate scope, and therefore may represent different activities in the world.
</p>
+</div>
<p>The account record is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. How general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>
@@ -1840,15 +1873,17 @@
</ul>
<p>All the records in <span class="name">exprs</span> are implictly wrapped in a default account, scoping all the identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts. Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a container's default account.</p>
+<div class="anexample">
<p>
The following container </p>
-<pre class="example">
+<pre class="codeexample">
container([x http://example.org/], [acc1,acc2]
account(acc1,http://example.org/asserter1,...)
account(acc2,http://example.org/asserter1,...))
</pre>
<p> illustrates how two accounts with identifiers <span class="name">acc1</span> and <span class="name">acc2</span> can be returned in a PROV-ASN serialization of the provenance of something.
</p>
+</div>
<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>
@@ -1975,16 +2010,17 @@
<p> In particular, a PROV-DM Literal may be a URI-typed string (with datatype <span class="name">xsd:anyURI</span>), or URI-denoted resource (with datatype <span class="name">rdf:Resource</span>); in either case; such URI has no specific interpretation in the context of PROV-DM.</p>
+<div class="anexample">
<p>
-The following examples respectively are the string "abc", the string "abc" with language english, the string "abc", the integer number "1", the URI "http://example.org/foo", and the resource denoted by "http://example.org/foo"
-<pre class="example">
+The following examples respectively are the string "abc", the string "abc" with language english, the string "abc", the integer number "1", and the URI "http://example.org/foo".
+<pre class="codeexample">
"abc"
"abc"@en
- "abc"^^xsd:string
- "1"^^xsd:int
- "http://example.org/foo"^^xsd:anyURI
- "http://example.org/foo"^^rdf:Resource
+ "abc" %% xsd:string
+ "1" %% xsd:int
+ "http://example.org/foo" %% xsd:anyURI
</pre>
+</div>
@@ -2309,8 +2345,8 @@
<pre class="example">
activity(pe1,long-workflow,t1,t2,[host="server1.example.org"])
activity(pe2,long-workflow,t3,t4,[host="server2.example.org"])
-entity(e1,[type="scheduler",state=1])
-entity(e2,[type="scheduler",state=2])
+entity(e1,[prov:type="scheduler",state=1])
+entity(e2,[prov:type="scheduler",state=2])
wasControlledBy(pe1,e1,[prov:role="end"])
wasControlledBy(pe2,e2,[prov:role="start"])
wasDerivedFrom(e2,e1)
@@ -2672,6 +2708,8 @@
<section class="appendix">
<h2>Changes Since Previous Version</h2>
<ul>
+<li>11/16/11: Introduced class anexample.</li>
+<li>11/16/11: Change presentation of entity and activity.</li>
<li>11/16/11: Updated examples for usage and generation record.</li>
<li>11/16/11: Renamed use record into usage record.</li>
<li>11/16/11: Removed constraint generation-affects-attributes.</li>