--- a/model/working-copy/prov-dm-constraints.html	Wed Feb 15 22:41:52 2012 +0000
+++ b/model/working-copy/prov-dm-constraints.html	Thu Feb 16 10:03:07 2012 +0000
@@ -450,17 +450,47 @@
       <h3>Account and AccountEntity</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
-	  by different witnesses. A given party could also create multiple provenance records about an execution, to capture different levels of details, targeted at different end-users: the
-	  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 have details about their origin, who they are attributed to, how they were generated, etc.  In other words, an important requirement is to be able to express the provenance of provenance. </p>
+<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 by different witnesses. A given party could also create
+multiple provenance records about an execution, to capture different
+levels of details, targeted at different end-users: the 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 have details about their origin, who they are attributed to, how
+they were generated, etc.  In other words, an important requirement is
+to be able to express the provenance of provenance. </p>
+
+<p>
+  <span  class="glossary" id="glossary-entity">
+An <dfn>account</dfn> is a named bundle of provenance descriptions.
+</span>  PROV-DM does not provide an actual mechanism for creating accounts, i.e. for bundling up provenance descriptions and naming them.  Accounts MUST satisfy some properties:
+<ul>
+<li>An account can be seen as a container of provenance descriptions, hence its content MAY change over time.</li>
+<li>If an account's  set of descriptions changes over time, it increases monotonically with time. </li>
+<li>A given description of e.g. an entity in a given account, in terms of its identifier and attribute-value pairs, does not change over time. </li>
+</ul>
 
 <div class='note'>
-TODO: expand on account, distinguish from accoutnEntity.
+The last point is important and needs to be discussed by the Working Group.
+It indicates that within an account:
+<ul>
+<li>It is always possible to add new provenance descriptions, e.g. stating that a given entity was used by an activity.  This is very much an open world assumption.
+<li>It is not permitted to add new attributes to a given entity (a form of closed world assumption from the attributes point of view), though it is always permitted to create a new description for an entity, which is a "copy" of the original description extended with novel attributes  (cf Example <a href="#merge-with-rename">merge-with-rename</a>).
+</ul>
 </div>
 
+<p>
+There is no construct in PROV-DM to create such named bundles. Instead, it is assumed that some mechanism, outside PROV-DM can create them.  However, from a provenance viewpoint, such accounts are things we may want to describe the provenance of. In order to be able to do so, we need to see accounts as entities, whose origin can be described using PROV-DM vocabulary. Thus, PROV-DM introduces the reserved type AccountEntity, defined as follows:
+<span  class="glossary" id="glossary-entity">
+ <dfn id="concept-accountEntity">AccountEntity</dfn> is the category of entities that are accounts, i.e. named bundles of provenance descriptions.
+</span>
+</p>
+
     </section>
 </section>
 

--- a/model/working-copy/towards-wd4.html	Wed Feb 15 22:41:52 2012 +0000
+++ b/model/working-copy/towards-wd4.html	Thu Feb 16 10:03:07 2012 +0000
@@ -2223,11 +2223,11 @@
 
 <li>The existence of some mechanism(s)  by which a set of provenance descriptions can be bundled up and named is assumed.  No such mechanism is considered as mature for standardization, and therefore such mechanisms remain outside the scope of PROV-DM.   Various ways of achieving this functionality exist, for instance, by:
 <ul>
-<li> packaging up a set of descriptions and exposing them as a Web resource;</li>
+<li> bundling up a set of descriptions in a file and exposing it as a Web resource;</li>
 <li> relying on specific serializations to name bundles of descriptions;</li>
 <li> using the idea of a service that is capable of associating provenance descriptions to whom they are attributed to.</li>
 </ul>
-<p>Even though a mechanism for packaging up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named bundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-accountEntity">AccountEntity</a> so that its provenance can be expressed.   The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as constraint that  <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
+<p>Even though a mechanism for blundling up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named bundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-accountEntity">AccountEntity</a> so that its provenance can be expressed.   The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as constraint that  <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
 </li>