--- a/model/prov-constraints.html Fri Jun 01 10:30:35 2012 +0100
+++ b/model/prov-constraints.html Fri Jun 01 10:43:26 2012 +0100
@@ -1974,8 +1974,7 @@
<h2>Account Constraints</h2>
<div class="note">
-Work on accounts has been deferred until after the next working draft,
-so this section is very unstable
+This section does not talk about accounts.
</div>
<p>PROV-DM allows for multiple descriptions of entities (and in general any identifiable object) to be expressed. </p>
@@ -2014,7 +2013,7 @@
<p>In some cases, there may be a requirement for two different
- statements concerning the same entity to be included in the same account. To satisfy the constraint <a class="rule-text" href="#entity-unique"><span>entity-unique</span></a>, we can adopt a different identifier for one of them, and relate the two statements with the <span class="name">alternateOf</span> relation. </p>
+ statements concerning the same entity to be included in the same provenance instance. To satisfy the constraint <a class="rule-text" href="#entity-unique"><span>entity-unique</span></a>, we can adopt a different identifier for one of them, and relate the two statements with the <span class="name">alternateOf</span> relation. </p>
<div class="anexample" id="merge-with-rename">
<p>We now reconsider the same two statements of a same entity, but we change the identifier for one of them:</p>
@@ -2443,65 +2442,6 @@
</section>
-
- <section id="account-section">
- <h3>Account</h3>
-
-<div class="note">
- Some of this discussion may belong in the account constraint section
- as motivation, or as formal constraints/inferences. In particular,
- the MUST, MAY, SHOULD statements should be clarified and put into
- the normative section.
- </div>
-
-<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>
-
-<div class="note">
- See ISSUE-343.
- </div>
-<p>
- <span class="glossary" id="glossary-account">
-An <dfn>account</dfn> is an entity that contains an instance, or set
- of PROV statements.
-</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 is a bundle of provenance descriptions whose content MAY change over time.</li>
-<li>If an account's set of statements changes over time, it SHOULD increase 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'>
-The last point is important. It indicates that within an account:
-<ul>
-<li>It is always possible to add new provenance statements, e.g. stating that a given entity was used by an activity, or derived from another. 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 statement describing
- an entity, which is a "copy" of the original statement 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 bundles of
-statements. Instead, it is assumed that some mechanism, outside
-PROV-DM can create them. However, from a provenance viewpoint, such
-accounts are things whose provenance we may want to describe. 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 <span class="name">Account</span>.
-</p>
-
- </section>
</section>
@@ -2509,6 +2449,7 @@
+
<section class="appendix">
<h2>Acknowledgements</h2>
<p>