--- a/model/working-copy/prov-dm-constraints.html Tue Feb 14 09:25:09 2012 +0000
+++ b/model/working-copy/prov-dm-constraints.html Tue Feb 14 10:10:08 2012 +0000
@@ -253,7 +253,7 @@
<section id='preliminaries'>
<h2>Data Model Refinement</h2>
-<p>Underpinning the PROV-DM data model is a notion of event, marking transitions in the world (when entities are generated, used, or destroyed, or activities started or ended). This notion of event is not first-class in the data model, but underpins many of its concepts and its semantics. Thus, using this notion of event, we can refine the data model, and hereby allowing creators of provenance assertions to make their assertions more robust. </p>
+<p>Underpinning the PROV-DM data model is a notion of event, marking transitions in the world (when entities are generated, used, or destroyed, or activities started or ended). This notion of event is not first-class in the data model, but underpins many of its concepts and its semantics [[PROV-SEM]]. Thus, using this notion of event, we can provide an interpretation for the data model, which in turn can allow creators of provenance assertions to make their assertions more robust. </p>
<section id='section-time-event'>
@@ -361,7 +361,7 @@
<section id='section-attributes'>
-<h4>Entities and Attributes</h4>
+<h4>Attributes in Entities and Beyond </h4>
<p>When we talk about things in the world in natural language and even when we assign identifiers, we are often imprecise in ways that make it difficult to clearly and unambiguously report
provenance: a resource with a URL may be understood as referring to a report available at that URL, the version of the report available there today, the report independent of where it is
@@ -382,18 +382,13 @@
may be different.</p>
- <section id='section-entity-activity-agent'>
-<h4>Entity, Activity, Agent</h4>
-
<div class="anexample" id="a-report-example">
Different users may take different perspectives on a resource with
-a URL. These perspectives in this conceptualization of the world are
-referred to as entities. Three such entities may be
-expressed:
+a URL. For each perspective, an entity may be expressed:
<ul>
<li>a report available at a URL: fixes the nature of the thing, i.e. a document, and its location; </li>
<li>the version of the report available there today: fixes its version number, contents, and its date;</li>
@@ -407,57 +402,44 @@
</ul>
</div>
-<p>We do not assume that any characterization is more important than any other, and in fact, it is possible to describe the processing that occurred for the report to be commissioned, for
-individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity that characterizes the report appropriately.</p>
-
-
-</section>
+<p>We do not assume that any entity is more important than any other; in fact, it is possible to describe the processing that occurred for the report to be commissioned, for
+individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity with attribute-value pairs that fix some aspect of the report appropriately.</p>
+
+<p>Attributes are not restricted to entities, but they belong to a variety of PROV-DM objects, including activities, activity associations, responsibility chains, generations, usages, derivations, and alternates. Each object has its duration interval, and attribute-value pairs for a given object, are expected to be unchanged for the object's duration.</p>
</section>
<section id="representation-record-assertion-inference">
-<h3>Representation, Record, Assertion, and Inference</h3>
+<h3>Description, Assertion, and Inference</h3>
<p>
-PROV-DM is a provenance data model designed to express <em>representations</em> of the world. Such representations are structured according to a set of <em>records</em>.
+PROV-DM is a provenance data model designed to express <em>descriptions</em> of the world.
</p>
<div class="anexample">
-A file at some point during its lifecycle, which includes multiple edits by multiple people, can be represented by its location in the file system, a creator, and content.
-</div>
-
-
-<p>
-These records are relative to an asserter, and in that sense constitute assertions stating properties of the world, as represented by an asserter. Different asserters will normally
-contribute different records expressive different representations of the world.
-This specification does not define a notion of consistency between different sets of records (whether by the same asserter or different asserters).
-The data model provides the means to associate attribution to assertions.
-</p>
-
-<div class="anexample">
-An alternative representation of the above file is a set of blocks in a hard disk.
+A file at some point during its lifecycle, which includes multiple edits by multiple people, can be described by its type, its location in the file system, a creator, and content.
</div>
<p>The data model is designed to capture activities that happened in the past, as opposed to activities
that may or will happen.
However, this distinction is not formally enforced.
-Therefore, all PROV-DM records SHOULD be interpreted as a description of what has happened, as opposed to what may or will happen.</p>
+Therefore, all PROV-DM descriptions SHOULD be interpreted as what has happened, as opposed to what may or will happen.</p>
<p>
-This specification does not prescribe the means by which an asserter arrives at records; for example, records can be composed on the basis of observations, reasoning, or any other means.
+This specification does not prescribe the means by which descriptions can be arrived at; for example, descriptions can be composed on the basis of observations, reasoning, or any other means.
</p>
<p>
-Sometimes, inferences about the world can be made from records
+Sometimes, inferences about the world can be made from descriptoins
conformant to the PROV-DM data model. When this is the case, this
-specification defines such inferences, allowing new provenance records
-to be inferred from existing ones. Hence, representations of the world
-can result either from direct assertions of records by asserters or from inference of new records
+specification defines such inferences, allowing new descriptions
+to be inferred from existing ones. Hence, descriptions of the world
+can result either from direct assertion or from inference
by application of inference rules defined by this specification.
</p>
@@ -468,14 +450,226 @@
</section>
+
+
+ <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="record-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-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"])
+ 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>
+
+
-
+<section id="data-model-constraints">
+<h2>PROV-DM Constraints</h2>
+
+<p>The previous two sections??? have introduced a data model for provenance, without introducing any constraint that this data model has to satisfy. In this section, we explore the constraints
+that this data model has to satisfy. </p>
+
+<p> Discuss the kind of constraints</p>
+<ul>
+<li>Definitional constraints</li>
+<li>Event ordering constraints</li>
+<li>Account-related constraints</li>
+</ul>
+
+</section>
<section id="data-model-concepts">
-<h2>Definitional Constraints and Inferences in PROV-DM</h2>
-
-<p>This section contains the normative specification of PROV-DM core, the core of the PROV data model.</p>
+<h2>PROV-DM Definitional Constraints and Inferences</h2>
+
+<p>In this section, we revisit terms and relations of PROV-DM, and examine </p>
@@ -1253,212 +1447,13 @@
</section>
- <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="record-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-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"])
- 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>
-
-
-
- <section id="constraints">
-<h2>PROV-DM Constraints</h2>
-
-<p>The previous two sections have introduced a data model for provenance, without introducing any constraint that this data model has to satisfy. In this section, we explore the constraints
-that this data model has to satisfy. </p>
+
+
+
+
<section id="interpretation">
-<h3>PROV-DM Interpretation</h3>
+<h3>PROV-DM Ordering Constraints</h3>
<p>Section <a href="#section-time-event">section-time-event</a>
introduces a notion of <a title="event">instantaneous event</a>
@@ -1931,7 +1926,6 @@
</ul>
</section>
-</section>
<section id="resource-section">
@@ -2033,28 +2027,6 @@
-->
-<section class="appendix">
- <h2>Changes Since Second Public Working Draft</h2>
-<ul>
-<li>01/19/11: Replaced wasComplementOf with alternateOf and specializationOf</li>
-<li>01/16/12: updated derivation, simplified derivation record, prov:strep can be single/any. </li>
-<li>01/02/12: revision of collections </li>
-<li>01/02/12: definition alternate and specialization </li>
-<li>12/21/11: updated example with new relations. </li>
-<li>12/21/11: definition alternate and specialization (5.3.3.3). </li>
-<li>12/21/11: Specified permitted occurrences of prov attributes. </li>
-<li>12/21/11: Introduced the attribute occurrence validity property. </li>
-<li>12/21/11: Clarified the issues with identifier in entity record. </li>
-<li>12/21/11: Explained overloading of wasStartedBy. </li>
-<li>12/21/11: Moved Collections from 6.1 to 6.8. </li>
-<li>12/20/11: Created a section on structural constraints. </li>
-<li>12/19/11: Made plan entity and added extra parameter to wasAssociatedWith. </li>
-<li>12/17/11: Replaced wasComplementOf with viewOf and [foobar] </li>
-<li>12/13/11: Introduced hadPlan as a specialization of wasAssociatedWith. </li>
-<li>12/12/11: Section 7 on interpretation. </li>
-<li>12/08/11: Restructuring of Constraints. </li>
-</ul>
- </section>
<section class="appendix">
<h2>Acknowledgements</h2>