--- a/model/working-copy/prov-dm-constraints.html Wed Feb 15 06:19:32 2012 +0000
+++ b/model/working-copy/prov-dm-constraints.html Wed Feb 15 07:16:17 2012 +0000
@@ -338,13 +338,13 @@
<p>This specification introduces a set of "temporal interpretation"
rules allowing the derivation of <a title="event">instantaneous event</a> ordering constraints from
-provenance records. According to such temporal interpretation,
-provenance records MUST satisfy such constraints. We note that the
+provenance descriptions. According to such temporal interpretation,
+descriptions MUST satisfy such constraints. We note that the
actual verification of such ordering constraints is outside the
scope of this specification. </p>
<p>PROV-DM also allows for time observations to be inserted in specific
-provenance records, for each recognized <a title="event">instantaneous event</a> introduced
+descriptions, for each recognized <a title="event">instantaneous event</a> introduced
in this specification. The presence of a time observation for a
given <a title="event">instantaneous event</a> fixes the mapping of this <a title="event">instantaneous event</a> to the
timeline. It can also help with the verification of associated
@@ -455,196 +455,15 @@
<section id="bundle">
<h3>Bundle</h3>
- <p>In this section, two constructs are introduced to group
- PROV-DM records. The first
- one, <a>account record</a> is itself a
- record, whereas the second
- one <a>record container</a> is not.
- </p>
-
-
- <section id="term-Account">
- <h3>Account</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 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>
-
- <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 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-term-in-account">identifiable-term-in-account</a>.</p>
-
- <div class='constraint' id='identifiable-term-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-term-in-account">identifiable-term-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>
+ 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="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-term-in-account">identifiable-term-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-term-in-account">identifiable-term-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"])
- specializationOf(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>
-
-
- </section>
</section>
@@ -1342,8 +1161,59 @@
+<section id="account-constraints">
+<h3>PROV-DM Account Constraints</h3>
+<p>PROV-DM allows for multiple descriptions of entities (and in general any identifiable object) to be expressed. </p>
+
+<div class="anexample">
+<p>Let us consider two descriptions of a same entity, which we have taken from two different contexts (see example). A working draft published by the <span class="name">w3:Consortium</span>:</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+</pre>
+The second version of a document edited by some authors:
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
+</pre>
+<p>Both descriptions are about the same entity identified by
+<span class="name">tr:WD-prov-dm-20111215</span>, but they contain different attributes, reflecting the context in which they occur.
+</p>
+</div>
+
+
+
+<p>Two different descriptions of a same entity cannot co-exist in a same account
+ as formalized in <a href="#unique-description-in-account">unique-description-in-account</a>.</p>
+
+<div class='constraint' id='unique-description-in-account'>
+<p>Given an entity identifier <span class="name">e</span>, there is at most one description
+<span class="name">entity(e,av)</span> occurring in a given account, where <span class="name">av</span> is some set of attribute-values. Other descriptions of the same entity can exist in different accounts.</p>
+
+<p>This constraint similarly applies to all other types of identifiable entities and relations.</p>
+</div>
+
+<p>
+ <div class="structural-forward">
+ See Section <a href="#structural-constraints">structural-constraints</a> for a structural constraint on account records.
+ </div>
+</p>
+
+<p>In some cases, there may be a requirement for the two descriptions to be included in a same account. To satisfy the constraint <a href="#unique-description-in-account">unique-description-in-account</a>, we can adopt a different identifier for one of them, and relate the two descriptions with the <span class="name">alternateOf</span> relation. </p>
+
+<div class="anexample">
+<p>We now reconsider the same two descriptions of a same entity, but we change the identifier for one of them:</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+entity(ex:alternate-20111215, [ prov:type="document", ex:version="2" ])
+alternateOf(tr:WD-prov-dm-20111215,ex:alternate-20111215)
+alternateOf(ex:alternate-20111215,tr:WD-prov-dm-20111215)
+</pre>
+</div>
+
+
+</section>
+
<section id="interpretation">
<h3>PROV-DM Ordering Constraints</h3>
@@ -1574,7 +1444,7 @@
<h3>PROV-DM Structural Constraints</h3>
<section>
-<h3>Stuff</h3>
+<h3>Stuff to Edit</h3>
<li>
The entity identifier <span class="name">id</span> contained in an entity record is expected to be unique among all the identifiers contained in the current account's records.
This constraint is elaborated upon in <a href="#identifiable-term-in-account">identifiable-term-in-account</a>. It means that the current account does not contain any other record for