--- a/model/ProvenanceModel.html Tue Nov 29 21:29:09 2011 +0000
+++ b/model/ProvenanceModel.html Tue Nov 29 21:54:29 2011 +0000
@@ -2077,9 +2077,9 @@
<p>In this section, two constructs are introduced to group
PROV-DM records. The first
-one, <span class="nonterminal">accountRecord</span> is itself a
+one, <a>account record</a> is itself a
record, whereas the second
-one <span class="nonterminal">container</span> is not.
+one <a>record container</a> is not.
</p>
@@ -2094,6 +2094,14 @@
</ul>
+
+<p>An account record, written <span class="name">account(id, assertIRI, recs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> that identifies this account globally;</li>
+<li><em>asserter</em>: an IRI, denoted by <span class="name">assertIRI</span>, to identify an asserter; such IRI has no specific interpretation in the context of PROV-DM;</li>
+<li><em>records</em>: a set <span class="name">recs</span> of provenance records.</li>
+</ul>
+
<p>In PROV-ASN, an account record's text matches the <span class="nonterminal">accountRecord</span> production of the grammar defined in this specification document.</p>
<div class='grammar'>
@@ -2109,22 +2117,14 @@
<span class="name">)</span>
</div>
-<p>An account record, written <span class="name">account(id, uri, exprs)</span> in PROV-ASN:</p>
-<ul>
-<li> contains an identifier <span class="name">id</span> to identify this account;</li>
-<li> contains an asserter identified by URI denoted by <span class="name">uri</span>;</li>
-<li> contains a <em>set</em> of provenance records denoted by <span class="name">exprs</span>.</li>
-</ul>
-
-
<div class='note'>
-Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI. 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>
+Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI and its interpretation is outside PROV-DM. 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="codeexample">
-account(acc0,
+account(ex:acc0,
http://example.org/asserter,
entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
...
@@ -2136,14 +2136,14 @@
...
wasAssociatedWith(a4, ag5, [prov:role="communicator"]) )
</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>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">ex: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>
+<p>Account records constitue a scope for record identifiers. A record 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>
<div class='constraint' id='identified-entity-in-account'>
-Given an identifier <span class="name">e</span>, two sets of attribute-values denoted by <span class="name">av1</span> and <span class="name">av2</span>,
+Given an entity record identifier <span class="name">e</span>, two sets of attribute-values denoted by <span class="name">av1</span> and <span class="name">av2</span>,
two entity records <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account are equivalent to the entity record <span class="name">entity(e,av)</span> where <span class="name">av</span> is the set of attribute-value pairs formed by the union of <span class="name">av1</span> and <span class="name">av2</span>.
</div>
@@ -2153,13 +2153,13 @@
<p>
In the following account record, we find two entity records with a same identifier <span class="name">e</span>.</p>
<pre class="codeexample">
-account(acc1,
+account(ex:acc1,
http://example.org/id,
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>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 and outside the scope of this specification.
</p></div>
<p>Account records can be nested since an account record can occur among the records being wrapped by another account. </p>
@@ -2181,7 +2181,7 @@
<p>
Indeed, let us consider another account record</p>
<pre class="codeexample">
-account(acc2,
+account(ex:acc2,
http://example.org/asserter2,
entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
...
@@ -2190,32 +2190,32 @@
wasGeneratedBy(e0,a1,[ex:fct="create"])
... )
</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">a1</span> instead of <span class="name">a0</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>
+<p>with identifier <span class="name">ex: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">a1</span> instead of <span class="name">a0</span> in the previous account <span class="name">ex:acc0</span>. If accounts <span class="name">ex:acc0</span> and <span class="name">ex: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>
+<p>Account records constitute a scope for record identifiers. Since accounts can be nested, scopes can also be nested; thus, the scope of record 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>
+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">ex:acc3</span>, declares entity record with identifier <span class="name">e0</span>, which is being referred to in the nested account <span class="name">ex:acc4</span>. The scope of identifier <span class="name">e0</span> is account <span class="name">ex:acc3</span>, including subaccount <span class="name">ex:acc4</span>.</p>
<pre class="codeexample">
-account(acc3,
+account(ex:acc3,
http://example.org/asserter1,
entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
activity(a0,create-file,t)
wasGeneratedBy(e0,a0,[])
- account(acc4,
- http://example.org/asserter2,
- entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
- activity(a0,copy-file,t)
- wasGeneratedBy(e1,a0,[ex:fct="create"])
- wasComplementOf(e1,e0)))
+ account(ex:acc4,
+ http://example.org/asserter2,
+ entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
+ activity(a0,copy-file,t)
+ wasGeneratedBy(e1,a0,[ex:fct="create"])
+ wasComplementOf(e1,e0)))
</pre>
<p>Alternatively, an activity record identified by <span class="name">a0</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>
+<p>The account record is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. The annotation mechanism can be used for this purpose, but how general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>
<div class='note'>We are going to introduce a disambiguation mechanism by which we can qualify identifiers by the account in which they occur (or the sequence of nested accounts in which they occur). This mechanism allows two entity records, asserted separately in two different accounts but with the same identifier, to be uniquely referred to.
</div>
@@ -3163,7 +3163,7 @@
</pre>
-</section>
+</section>
<!--