--- a/model/working-copy/towards-wd4.html Sun Feb 05 20:55:25 2012 +0000
+++ b/model/working-copy/towards-wd4.html Sun Feb 05 20:56:31 2012 +0000
@@ -378,8 +378,7 @@
<a>end record</a>,
<a>alternate record</a>,
<a>specialization record</a>,
-<a>annotation record</a>, and
-<a>account record</a>.
+<a>annotation record</a>.
</a>
<div class="note">Account again?</div>
@@ -395,15 +394,13 @@
<p>In PROV-ASN, such representations of the world MUST be conformant with the toplevel <a>production</a> <span class="nonterminal">record</span> of the grammar. These <span
class="nonterminal">record</span>s are grouped in three categories:
<span class="nonterminal">elementRecord</span> (see section <a href="#record-element">Element</a>),
-<span class="nonterminal">relationRecord</span> (see section <a href="#record-relation">Relation</a>), and
-<span class="nonterminal">accountRecord</span> (see section <a href="#record-Account">Account</a>).</p>
+<span class="nonterminal">relationRecord</span> (see section <a href="#record-relation">Relation</a>).</p>
<div class='grammar'>
<span class="nonterminal">record</span> ::=
<span class="nonterminal">elementRecord</span>
| <span class="nonterminal">relationRecord</span>
-| <span class="nonterminal">accountRecord</span>
<br/>
<!-- -->
<br/>
@@ -905,16 +902,6 @@
</p>
-<!--
-<p>The assertion of a generation record implies ordering of <a title="event">events</a> in the world.</p>
-
-
-<div class='interpretation' id='generation-within-activity'><span class='conditional'>If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span
-class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following temporal constraint also holds: the <a title="entity generation
-event">generation</a> of the entity denoted by <span class="name">x</span> <a>precedes</a> the <a title="activity end event">end</a>
-of <span class="name">a</span> and <a>follows</a> the <a title="activity start event">start</a> of <span class="name">a</span>.
-</div>
--->
<p>
<div class="structural-forward">
@@ -922,22 +909,7 @@
</div>
</p>
-<!--
-<p>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
-The rationale for this constraint is as follows.
-If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct
-entities. Alternatively, for two activities 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 activity. This uniqueness constraint is formalized as follows.
-
-<div class='constraint' id='generation-uniqueness'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span
-class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
-<span class='conditional'>if</span> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given
-account,
-<span class='conditional'>then</span> <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
-</div>
-
-<div class='note'>TODO: Introduce the well-formed-ness constraint in a entirely separate section.</div>
--->
+
<div class='pending'> We may want to assert the time at which an entity is created. The placeholder for such time information is a generation record. But a generation mandates the presence of an activity identifier. But it may not be known.
@@ -1866,6 +1838,8 @@
<section id="record-Account">
<h3>Account Record</h3>
+
+
<p>It is common for multiple provenance records to co-exist. For instance, when emailing
a file, there could be a provenance record kept by the mail client,
and another by the mail server. Such provenance records may provide different explanations about something happening in the world, because they are created by different parties or observed
@@ -1873,178 +1847,8 @@
programmer of an experiment may be interested in a detailed log of execution, while the scientists may focus more on the scientific-level description. Given that multiple provenance
records can co-exist, it is important to know who asserted these records. </p>
-<p>In PROV-DM, an <dfn id="dfn-Account">account record</dfn> is a wrapper of records with the following purposes: </p>
-<ul>
-<li> It is the mechanism by which attribution of provenance can be assserted; it allows asserters to bundle up their assertions, and assert suitable attribution;</li>
-<li> It provides a scoping mechanism for the uniqueness of identifiers (of elements and relations of PROV-DM);</li>
-<li> It provides a scoping mechanism for structural contraints (such as
- <a href="#generation-uniqueness">generation-uniqueness</a> and <a href="#derivation-use">derivation-use</a> discussed in Section <a
-href="#structural-constraints">structural-constraints</a>).</li>
-</ul>
-
-
-
-<p>An account record, written <span class="name">account(id, assertIRI, recs, attrs)</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>
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-</div>
-<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'>
-<span class="nonterminal">accountRecord</span> ::=
-<span class="name">account</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">asserter</span>
-<span class="name">,</span>
-<span class="plus">
-<span class="nonterminal">record</span> </span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-</div>
-
-<div class='issue'>
-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.
-We seek inputs on how to resolve this issue. This is <a href="http://www.w3.org/2011/prov/track/issues/217">ISSUE-217</a>. </div>
-
-<div class="anexample" id="account-example-1">
-<p>
-The following account record</p>
-<pre class="codeexample">
-account(ex:acc0,
- http://example.org/asserter,
- entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
- ...
- wasDerivedFrom(e2,e1)
- ...
- activity(a0,t,,[prov:type="createFile"])
- ...
- wasGeneratedBy(e0,a0)
- ...
- 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">ex:acc0</span>.
-</p>
-</div>
-
-<p> An identifier in a record 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="#identifiable-record-in-account">identifiable-record-in-account</a>.</p>
-
-<div class='constraint' id='identifiable-record-in-account'>
-<p>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>.</p>
-
-<p>This constraint similarly applies to all other types of records. As a result, the identifier that occurs in a record is unique and acts as a local identifier for that record in that
-account.</p>
-</div>
-
-
-<p>Whilst constraint <a href="#identifiable-record-in-account">identifiable-record-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 satisfies the <a>attribute occurrence validity</a> property, 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="codeexample">
-account(ex:acc1,
- http://example.org/id,
- entity(e,[prov:type="person", ex:age=20])
- entity(e,[prov:type="person", ex:weight=50, ex:age=30])
- ...)
-</pre>
-
-<p>Application of <a href="#identifiable-record-in-account">identifiable-record-in-account</a> results in an entity record containing the attribute-value pairs <span class="name">age=20</span>, <span class="name">weight=50</span>, and <span class="name">age=30</span>. The namespace referred to by prefix <span class="name">ex</span> declares the number of occurrences that are permitted for each attribute. The resulting entity record may or may not satisfy the <a>attribute occurrence validity</a>, depending on this namespace. For instance, if the namespace referred to by <span class="name">ex</span> declares that <span class="name">age</span> must have at most one occurrence, then the resulting entity record does not satisfy the <a>attribute occurrence validity</a> property. This document does not specify how to handle such an entity record.
-</p></div>
-
-<p>Account records can be nested since an account record can occur among the records being wrapped by another account. </p>
-
-
-
-<!--
-<p>
-An account is said to be well-formed if
-it satisfies the constraints <a href="#generation-uniqueness">generation-uniqueness</a> and <a href="#derivation-use">derivation-use</a>.</p>
-
-<p> The union of two accounts is another account,
-containing the unions of their respective records, where
- records with a same identifier should be understood according to constraint <a href="#identifiable-record-in-account">identifiable-record-in-account</a>. Well-formed
-accounts are not
-closed under union because the
-constraint <a href="#generation-uniqueness">generation-uniqueness</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="codeexample">
-account(ex:acc2,
- http://example.org/asserter2,
- entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
- ...
- activity(a1,t1,,[prov:type="createFile"])
- ...
- wasGeneratedBy(e0,a1,[ex:fct="create"])
- ... )
-</pre>
-<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-uniqueness">generation-uniqueness</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are
-distinct.</p>
-</div>
-
--->
-
-<p>Account records constitute a scope for identifier uniqueness. Since accounts can be nested, scopes can also be nested; thus, the requirement on uniqueness 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">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>. Identifier <span
-class="name">e0</span> is uniquely identify a record in account <span class="name">ex:acc3</span>, including subaccount <span class="name">ex:acc4</span>.</p>
-<pre class="codeexample">
-account(ex:acc3,
- http://example.org/asserter1,
- entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
- activity(a0,t,,[prov:type="createFile"])
- wasGeneratedBy(e0,a0,[])
- account(ex:acc4,
- http://example.org/asserter2,
- entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
- activity(a0,t,,[prov:type="copyFile"])
- 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 identifier of an account record is expected to be globally unique, whereas identifiers for other records are expected to be unique within the scope of the account in which their
-record occurs. </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="structural-forward">
-See Section <a href="#structural-constraints">structural-constraints</a> for a structural constraint on account records.
-</div>
-
+
+<p><em>All the rest removed</em></p>
</section>
@@ -2052,7 +1856,7 @@
<h4>Record Container</h4>
<p>A <dfn id="dfn-RecordContainer">record container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM <a title="record">records</a>. A record container is the
-root of a provenance record and can be exploited to package up PROV-DM <a title="record">records</a> in response to a request for the provenance of something ([[!PROV-AQ]]). Given that a
+root of a provenance record and can be exploited to package up PROV-DM <a title="record">records</a> in response to a request for the provenance of something ([[PROV-AQ]]). Given that a
record container is the root of a provenance record, it is not defined as a PROV-DM record (production <span class="nonterminal">record</span>), since otherwise it could appear arbitrarily
nested inside accounts.</p>
@@ -2095,7 +1899,7 @@
agent(ag2, [ prov:type="prov:Person" %% xsd:QName, ex:name="Bob" ])
endContainer
</pre>
-<p>This container could for instance be returned by querying a provenance store for the provenance of entity <span class="name">e2</span> [[!PROV-AQ]]. All these assertions are implicitly
+<p>This container could for instance be returned by querying a provenance store for the provenance of entity <span class="name">e2</span> [[PROV-AQ]]. All these assertions are implicitly
wrapped in a default account. In the absence of an explicit account, such provenance records remain unattributed.
</p>
</div>