--- a/model/working-copy/prov-dm-constraints.html Mon Feb 13 12:34:44 2012 +0000
+++ b/model/working-copy/prov-dm-constraints.html Mon Feb 13 13:04:45 2012 +0000
@@ -234,19 +234,6 @@
</section>
-<section id="prov-dm-namespace">
- <h3>PROV-DM Namespace</h3>
-
-
-<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
-
-<p> All the elements, relations, reserved names and attributes introduced in this specification belong to the PROV-DM namespace.</p>
-
-<div class="issue">
-There is a desire to use a single namespace that all specifications of the PROV family can share to refer to common provenance terms. This is <a href="http://www.w3.org/2011/prov/track/issues/224">ISSUE-224</a>.
-</div>
-
-</section>
<section id="conventions">
@@ -270,6 +257,9 @@
<h3>A Conceptualization of the World</h3>
+ <section id='section-attributes'>
+<h4>Attributes</h4>
+</section>
<section id='section-entity-activity-agent'>
<h4>Entity, Activity, Agent</h4>
@@ -441,42 +431,6 @@
</section>
- <section id="prov-asn-intro">
-<h3>PROV-ASN: The Provenance Abstract Syntax Notation</h3>
-
-<p>This specification defines PROV-DM, a data model for provenance, consisting of records describing how people, entities, and activities, were involved in producing,
-influencing, or delivering a piece of data or a thing in the world.</p>
-
-<p>This specification also relies on a language, PROV-ASN, the Provenance Abstract Syntax Notation, to express
-<em>instances</em> of that data model.
-For each construct of PROV-DM, a corresponding ASN expression is introduced, by way of a production in the ASN grammar. </p>
-
-
-
-
-
-<p>PROV-ASN is an abstract syntax, whose goals are:
-<ul>
-<li>to allow serializations of PROV-DM instances in a technology independent manner, which makes it more readable for human consumption;
-<li>to facilitate the mapping of PROV-DM to concrete syntax;
-<li>to provide the basis for a formal semantics.
-</ul>
-
-<p>This specification provides a grammar for PROV-ASN. Each record of the PROV-DM data model is explained
-in terms of the production of this grammar.</p>
-
-
-
-<p>The formal semantics of PROV-DM is defined at
-[[PROV-SEM]] and its encoding in the OWL2 Web Ontology Language at [[!PROV-O]].
-</p>
-
-
-
-
-
-
- </section>
<section id="representation-record-assertion-inference">
<h3>Representation, Record, Assertion, and Inference</h3>
@@ -526,45 +480,6 @@
</section>
- <section id="grammar-notation">
-<h3>Grammar Notation</h3>
-
-<p>This specification includes a grammar for PROV-ASN expressed using the Extended Backus-Naur Form (EBNF) notation.</p>
-
-<div class="grammar">
-<p> Each production rule (or <dfn>production</dfn>, for short) in the grammar defines one non-terminal symbol, in the form:</p>
-<p>
-<span class="nonterminal">E</span> ::= <em>expression</em>
-</p>
-
-
-Within the expression on the right-hand side of a rule, the following expressions are used to match strings of one or more characters:
-<ul>
-<li>
-<span class="nonterminal">E</span>: matches term satisfying rule for symbol E.
-</li>
-
-<li>
-<span class="name">abc</span>: matches the literal string inside the single quotes.
-</li>
-
-
-<li>
-<span class="optional"><em>expression</em></span>: matches <em>expression</em> or nothing; optional <em>expression</em>.
-</li>
-
-<li>
-<span class="plus"><em>expression</em></span>: matches one or more occurrences of <em>expression</em>.
-</li>
-
-<li>
-<span class="star"><em>expression</em></span>: matches zero or more occurrences of <em>expression</em>.
-</li>
-
-</ul>
-</div>
-
-</section>
</section>
@@ -576,87 +491,8 @@
<p>This section contains the normative specification of PROV-DM core, the core of the PROV data model.</p>
- <section id="PROV-DM-record">
-
-<h3>Record</h3>
-
-<p>This specification introduced <a>provenance</a> as a set of records
-describing the people, institutions, entities, and activities,
-involved in producing, influencing, or delivering a piece of data or a
-thing in the world. PROV-DM is a data model defining the structure and
-meaning of such records.</p>
-
-
-<p>Concretely, PROV-DM consists of a set of constructs to formulate representations of the world and constraints that must be satisfied by them.
-A PROV-DN <dfn id="dfn-Record">record</dfn> is a body of information about something which is of interest from a provenance viewpoint. PROV-DM records may be asserted directly or may be
-inferred from others.
-</p>
-
-<p>
-PROV-DM records are typed and can be among the following types, introduced one by one in this section:
-<a>entity record</a>,
-<a>activity record</a>,
-<a>agent record</a>,
-<a>note record</a>,
-<a>generation record</a>,
-<a>usage record</a>,
-<a>derivation record</a>,
-<a>activity association record</a>,
-<a>responsibility record</a>,
-<a>start record</a>,
-<a>end record</a>,
-<a>alternate record</a>,
-<a>specialization record</a>,
-<a>annotation record</a>, and
-<a>account record</a>.
-</p>
-
-
-<p>
-Furthermore, PROV-DM includes a "house-keeping construct", a record container,
- used to wrap PROV-DM records and facilitate their interchange.
-Hence, by creating a set of PROV-DM records and packaging them into a record container,
-one forms a provenance record. </p>
-
-<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>
-
-
-<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/>
-<span class="nonterminal">elementRecord</span> ::=
-<span class="nonterminal">entityRecord</span>
-| <span class="nonterminal">activityRecord</span>
-| <span class="nonterminal">agentRecord</span>
-| <span class="nonterminal">noteRecord</span> <br/>
-<!-- -->
-<br/>
-<span class="nonterminal">relationRecord</span> ::=
-<span class="nonterminal">generationRecord</span>
-| <span class="nonterminal">usageRecord</span>
-| <span class="nonterminal">derivationRecord</span>
-| <span class="nonterminal">activityAssociationRecord</span>
-| <span class="nonterminal">responsibilityRecord</span>
-| <span class="nonterminal">startRecord</span>
-| <span class="nonterminal">endRecord</span>
-| <span class="nonterminal">alternateRecord</span>
-| <span class="nonterminal">specializationRecord</span>
-| <span class="nonterminal">annotationRecord</span>
-</div>
-
-
-<p>In PROV-ASN, a record container is compliant with the production <span class="nonterminal">recordContainer</span> (see section <a href="#RecordContainer">Record Container</a>). </p>
-
-</section>
+
+
<section id="record-element">
<h3>Element</h3>
@@ -958,47 +794,6 @@
<h4>Note Record</h4>
-<p>As provenance records are exchanged between systems, it may be useful to add extra-information about such records. For instance, a "trust service" may add value-judgements about the
-trustworthiness of some of the assertions made. Likewise, an interactive visualization component may want to enrich a set of provenance records with information helping reproduce their
-visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing any identifiable record to be associated with notes.</p>
-
-<p>A <dfn id="dfn-note">note record</dfn> is a set of attribute-value pairs, whose meaning is application specific. It may or may not be a representation of something in the world.</p>
-
-<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
-</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">noteRecord</span> ::=
-<span class="name">note</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">attribute-values</span>
-<span class="name">)</span><br/>
-<!-- -->
-</div>
-
-<p>A separate PROV-DM record is used to associate a note with an identifiable record (see <a href="#record-annotation">Section on annotation</a>). A given note may be associated with
-multiple records.
-</p>
-
-
-<div class="anexample">
-<p>
-The following note record consists of a set of application-specific attribute-value pairs, intended
-to help the rendering of the record it is associated with, by
-specifying its color and its position on the screen.</p>
-<pre class="codeexample">
-note(ann1,[ex:color="blue", ex:screenX=20, ex:screenY=30])
-hasAnnotation(g1,n1)
-</pre>
-<p>The note record is associated with a record <span class="name">g1</span> previously introduced (<a title="annotation record">hasAnnotation</a> is
-discussed in Section <a href="#record-annotation">Annotation Record</a>). In this example,
-the attribute-value pairs do not constitute a representation of something
-in the world; they are just used to help render provenance.
-</p>
-</div>
<p>
Attribute-value pairs occurring in notes differ from attribute-value pairs occurring in entity records and activity records. In entity and activity records, attribute-value pairs MUST be a
@@ -1952,648 +1747,15 @@
-<!--
-<section>
-<h4>Transitive Derivation Record</h4>
-
-
-<p>
-If <span class="name">wasDerivedFrom(e2,e1)</span> holds because attribute <span class="name">a2.1</span> of <span class="name">e2</span> is determined by attribute <span
-class="name">a1.1</span> of <span class="name">e1</span>,
-and if <span class="name">wasDerivedFrom(e3,e2)</span> holds because attribute <span class="name">a3.1</span>of <span class="name">e3</span> is determined by attribute <span
-class="name">a2.2</span> of <span class="name">e1</span>, it is not necessarily the case that an attribute of <span class="name">e3</span> is determined by an attribute of <span
-class="name">e1</span>; so, an asserter may not be able to assert <span class="name">wasDerivedFrom(e3,e1)</span>, since it would fail to satisfy constraint <a
-href="#derivation-attributes">derivation-attributes</a>. Hence, the constraint on attributes as expressed in <a href="#derivation-attributes">derivation-attributes</a> invalidates
-transitivity in the general case.
-</p>
-
-<p>However, there is sense that <span class="name">e3</span> still depends on <span class="name">e1</span>, since <span class="name">e3</span> could not be generated without <span
-class="name">e1</span> existing. Hence, we introduce a weaker notion of derivation record, which is transitive.</p>
-
-A transitive derivation record, written <span class="name">dependedOn(e2, e1)</span> in PROV-ASN:
-<ul>
-<li> contains an identifier <span class="name">e2</span>, denoting an entity record, which represents the entity that is the result of the derivation;
-<li> contains an identifier <span class="name">e1</span>, denoting an entity record, which represents the entity that the derivation relies upon.
-</ul>
-<p>The record <span class="name">dependedOn</span> can only be inferred; in other words, it cannot be asserted. It is
-transitive by definition and relies on the previously defined derivation assertions for its
-base case.</p>
-
-<div class='constraint' id='transitive-derivation'>
-<ul>
-<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> or <span class="name">wasDerivedFrom(e2,e1,pe,attrs2,attrs1)</span> holds, <span
-class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
-<li><span class='conditional'>If</span> <span class="name">wasEventuallyDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span>
-holds.</li>
-<li><span class='conditional'>If</span> <span class="name">dependedOn(e3,e2)</span> and <span class="name">dependedOn(e2,e1)</span> hold, <span class='conditional'>then</span> <span
-class="name">dependedOn(e3,e1)</span> holds.</li>
-</ul>
-</div>
-
-</section>
--->
-
-
-
-
-
-
-
-<section id="record-annotation">
-<h4>Annotation Record</h4>
-
-
-<p>An <dfn id="dfn-annotation">annotation record</dfn> establishes a link between an identifiable PROV-DM record and a note record referred to by its identifier. Multiple note records can
-be associated with a given PROV-DM record; symmetrically, multiple PROV-DM records can be associated with a given note record. Since note records have identifiers, they can also be
-annotated. The annotation mechanism (with note record and the annotation record) forms a key aspect of the extensibility mechanism of PROV-DM (see <a
-href="#extensibility-section">extensibility section</a>).</p>
-
-<p>An annotation record, written <span class="name">hasAnnotation(r,n,attrs)</span> in PROV-ASN, has the following constituents:</p>
-<ul>
-<li><em>record</em>: an identifier <span class="name">r</span> of the record being annnotated;</li>
-<li><em>note</em>: an identifier <span class="name">n</span> of a note record;</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, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class='grammar'>
-<span class="nonterminal">annotationRecord</span> ::=
-<span class="name">hasAnnotation</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">nIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<p>The interpretation of notes is application-specific. See Section <a href="#record-note">Note</a> for a discussion of the difference between note attributes and other records attributes.
-We also note the present tense in this term to indicate that it may not denote something in the past.</p>
-
-<div class="anexample">
-<p>
-The following records</p>
-<pre class="codexample">
-entity(e1,[prov:type="document"])
-entity(e2,[prov:type="document"])
-activity(a,t1,t2)
-used(u1,a,e1,[ex:file="stdin"])
-wasGeneratedBy(e2, a, [ex:file="stdout"])
-
-note(n1,[ex:icon="doc.png"])
-hasAnnotation(e1,n1)
-hasAnnotation(e2,n1)
-
-note(n2,[ex:style="dotted"])
-hasAnnotation(u1,n2)
-</pre>
-<p>assert the existence of two documents in the world (attribute-value pair: <span class="name">prov:type="document"</span>) identified by <span class="name">e1</span> and <span
-class="name">e2</span>, and annotate these records with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also
-asserts an activity, its usage of the first entity, and its generation of the second entity. The <span class="name">usage</span> record is annotated with a style (an application specific way
-of rendering this edge graphically). To be able to express this annotation, the usage record was provided with an identifier <span class="name">u1</span>, which was then referred to in <span
-class="name">hasAnnotation(u1,n2)</span>.
-</p>
-</div>
-
-
-</section>
-</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 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
-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 id="RecordContainer">
-<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
-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>
-
-
-<p>A record container, written <span class="name">container decls recs endContainer</span> in PROV-ASN, contains:
-<ul>
-<li><em>namespaceDeclarations</em>: a set <span class="name">decls</span> of namespace declarations, declaring namespaces and associated prefixes, which can be used in <a
-title="attribute">attributes</a> and <a title="identifier">identifiers</a> occurring inside <span class="name">recs</span>;</li>
-<li><em>records</em>: a non-empty set of records <span class="name">recs</span>.</li>
-</ul>
-<p>All the records in <span class="name">recs</span> are implictly wrapped in a default account, scoping all the record identifiers they declare directly, and constituting a toplevel
-account, in the hierarchy of accounts. Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a
-container's default account.</p>
-
-<p>In PROV-ASN, a record container's text matches the <span class="nonterminal">recordContainer</span> production of the grammar defined in this specification document.</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">recordContainer</span> ::=
-<span class="name">container</span>
-<span class="nonterminal">namespaceDeclarations</span>
-<span class="plus"> <span class="nonterminal">record</span> </span>
-<span class="name">endContainer</span>
-</div>
-
-
-<div class="anexample">
-<p>
-The following container contains records related to the provenance of entity
-<span class="name">e2</span>.
-</p>
-<pre class="codeexample">
-container
- prefix ex: http://example.org/,
- entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice",
- ex:content="There was a lot of crime in London last month."])
- activity(a1, 2011-11-16T16:05:00,,[prov:type="edit"])
- wasGeneratedBy(e2, a1, [ex:fct="save"])
- wasAssociatedWith(a1, ag2, [prov:role="author"])
- 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
-wrapped in a default account. In the absence of an explicit account, such provenance records remain unattributed.
-</p>
-</div>
-
-<div class="anexample">
-<p>
-The following container </p>
-<pre class="codeexample">
-container
- prefix ex: http://example.org/,
-
- account(ex:acc1,http://example.org/asserter1,...)
- account(ex:acc2,http://example.org/asserter1,...)
-endContainer
-</pre>
-<p> illustrates how two accounts with identifiers <span class="name">ex:acc1</span> and <span class="name">ex:acc2</span> can be returned in a PROV-ASN serialization of the provenance of
-something.
-</p>
-</div>
-
-
-<div class='issue'>
-Clarify what records are. This is <a href="http://www.w3.org/2011/prov/track/issues/208">ISSUE-208</a>. </div>
-</section>
-</section>
-
-
-<section id="sub-record">
-<h3>Further Terms in Records</h3>
-
-This section further terms in PROV-DM records.
-
-
-
-<section id="record-attribute">
-<h4>Attribute</h4>
-
-<p>An <dfn id="dfn-attribute">attribute</dfn> is a <em>qualified name</em>.
-An <dfn id="dfn-qualified-name">qualified name</dfn> is a name subject to namespace interpretation. It consists of namespace, denoted by an optional prefix, and a local name. The namespace
-is denoted by an IRI [[!IRI]].</p>
-
-
-<p>PROV-DM stipulates that a qualified name can be mapped into an IRI
- by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a
-href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
-
-<p>A qualified name's prefix is OPTIONAL. If a prefix occurs in a
- qualified name, it refers to a <a>namespace</a> declared in the
- record container. In the absence of prefix, the qualified name
- refers to the default namespace declared in the container.</p>
-
-<p>In PROV-ASN, an attribute's text matches the <span class="nonterminal">attribute</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">attribute</span> ::= <span class="nonterminal">qualifiedName</span><br/>
-<span class="nonterminal">qualifiedName</span> ::= <span class="nonterminal">prefixedName</span> | <span class="nonterminal">unprefixedName</span><br/>
-<span class="nonterminal">prefixedName</span> ::= <span class="nonterminal">prefix</span> <span class="name">:</span> <span class="nonterminal">localPart</span><br/>
-<span class="nonterminal">unprefixedName</span> ::= <span class="nonterminal">localPart</span><br/>
-<span class="nonterminal">prefix</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production
-[[!XML-NAMES]]</em><br/>
-<span class="nonterminal">localPart</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production
-[[!XML-NAMES]]</em>
-</div>
-
-
-<div class="note">Note that XML NC_NAME don't allow local identifiers to start with a number. Instead, should we use the productions used in SPARQL or TURTLE?</div>
-
-
-<p>
-For each attribute in a record, its namespace also declares the number of occurrences it
-may have in a list of attributes. The
-property <dfn>attribute occurrence validity</dfn> holds for a record
-if the actual number of occurrences of each attribute in this record is compatible with
-this attribute's declaration it its namespace. How to handle records
-that do not satisfy the <a>attribute occurrence validity</a> property
-is beyond the scope of this specification.</p>
-
-
-<p>From this specification's viewpoint, the interpretation of an attribute declared in a namespace other than prov-dm is out of
-scope.</p>
-
-<p>The PROV data model introduces a fixed set of attributes in the <a href="#prov-dm-namespace">PROV-DM namespace</a>:</p>
-<ul>
-<li> The attribute <dfn id="dfn-role"><span class="name">prov:role</span></dfn> denotes the function of an entity with respect to an activity, in the context of a usage, generation,
-activity association, start, end record. The attribute <span class="name">prov:role</span> is allowed to occur multiple times in such records. The value associated with a <span
-class="name">prov:role</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>.
-<div class="anexample">
-<p>The following start record describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
-<pre class="codeexample">
- wasStartedBy(a,ag, [prov:role="program-operator"])
-</pre>
-</div>
- </li>
-
-<li> The attribute <dfn id="dfn-type"><span class="name">prov:type</span></dfn> provides further typing information for the element or relation asserted in the record. PROV-DM liberally
-defines a type as a category of things having common characteristics. PROV-DM is agnostic about the representation of types, and only states that
-the value associated with a <span class="name">prov:type</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>. The attribute <span class="name">prov:type</span>
-is allowed to occur multiple times in a record.
-
-<div class="anexample">
-<p>The following record declares an agent of type software agent</p>
-<pre class="codeexample">
- agent(ag, [prov:type="prov:SoftwareAgent" %% xsd:QName])
-</pre>
-</div>
-</li>
-
-<li> The attribute <dfn id="dfn-steps"><span class="name">prov:steps</span></dfn> defines the level of precision associated with a derivation record. The value associated with a <span
-class="name">prov:steps</span> attribute MUST be <span class="name">"single"</span> or <span class="name">"any"</span>. The attribute <span class="name">prov:step</span> occurs at most
-once in a derivation record. A derivation record without attribute <span class="name">prov:step</span> is considered to be equivalent to the same record extended with an extra attribute
-<span class="name">prov:step</span> and associated value <span class="name">"any"</span>.
-
-<div class="anexample">
-<p>The following record declares an imprecise-1 derivation, which is known to involve one activity, though its identity, usage details of <span class="name">ex:e1</span>, and generation
-details of <span class="name">ex:e2</span> are not asserted.</p>
-<pre class="codeexample">
- wasDerivedFrom(ex:e2, ex:e1, [prov:steps="single"])
-</pre>
-</div>
- </li>
-
-<li> The attribute <dfn id="dfn-label"><span class="name">prov:label</span></dfn> provides a human-readable representation of a PROV-DM element or relation.
-
-<div class='issue'>
- This is <a href="http://www.w3.org/2011/prov/track/issues/219">ISSUE-219</a>. </div>
-</li>
-
-</ul>
-</section>
-
-
-
-<section id="record-identifier">
-<h4>Identifier</h4>
-
-
-<p>An <dfn id="dfn-identifier">identifier</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
- by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a
-href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
-
-<div class='grammar'>
-<span class="nonterminal">identifier</span> ::= <span class="nonterminal">qualifiedName</span><br/>
-<span class="nonterminal">eIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an entity record)</em><br/>
-<span class="nonterminal">aIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an activity record)</em><br/>
-<span class="nonterminal">agIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an agent record)</em><br/>
-<span class="nonterminal">gIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a generation record)</em><br/>
-<span class="nonterminal">uIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a usage record)</em><br/>
-<span class="nonterminal">nIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a note record)</em><br/>
-<span class="nonterminal">accIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote an account record)</em>
-</div>
-
-
-</section>
-
-<section id="record-literal">
-<h4>Literal</h4>
-
-<p>
-A PROV-DM Literal represents a data value such as a particular string
-or number. A PROV-DM Literal represents a value whose interpretation is outside the scope of PROV-DM.
-</p>
-
-<p>In PROV-ASN, a Literal's text matches the <span class="nonterminal">Literal</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">Literal</span> ::= <span class="nonterminal">typedLiteral</span> | <span class="nonterminal">convenienceNotation</span> <br/>
-<span class="nonterminal">typedLiteral</span> ::= <span class="nonterminal">quotedString</span> <span class="name">%%</span> <span class="nonterminal">datatype</span><br/>
-<span class="nonterminal">datatype</span> ::= <span class="nonterminal">qualifiedName</span><br/>
-<span class="nonterminal">convenienceNotation</span> ::= <span class="nonterminal">stringLiteral</span> | <span class="nonterminal">intLiteral</span><br/>
-<span class="nonterminal">stringLiteral</span> ::= <span class="nonterminal">quotedString</span><br/>
-<span class="nonterminal">quotedString</span> ::= <em>a finite sequence of characters in which " (U+22) and \ (U+5C) occur only in pairs of the form \" (U+5C, U+22) and \\ (U+5C,
-U+5C), enclosed in a pair of " (U+22) characters</em><br/>
-<span class="nonterminal">intLiteral</span> ::= <em>a finite-length sequence of decimal digits (#x30-#x39) with an optional leading negative sign (-)</em>
-</div>
-
-<p>The non terminals <span class="nonterminal">stringLiteral</span> and
-<span class="nonterminal">intLiteral</span>
-are syntactic sugar for quoted strings with datatype <span class="name">xsd:string</span> and <span class="name">xsd:int</span>, respectively.
-</p>
-
-<p> In particular, a PROV-DM Literal may be an IRI-typed string (with datatype <span class="name">xsd:anyURI</span>); such IRI has no specific interpretation in the context of PROV-DM.</p>
-
-
-<div class="anexample">
-<p>
-The following examples respectively are the string "abc" (expressed using the convenience notation), the string "abc", the integer number 1, the integer number 1 (expressed using the
-convenience notation) and the IRI "http://example.org/foo".
-<pre class="codeexample">
- "abc"
- "abc" %% xsd:string
- "1" %% xsd:int
- 1
- "http://example.org/foo" %% xsd:anyURI
-</pre>
-The following example shows a literal of type <span class="name">xsd:QName</span> (see
-<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#QName">QName</a> [[!XMLSCHEMA-2]]).
-The prefix <span class="name">ex</span> MUST be bound to a <a>namespace</a> declared in the
- record container.
-<pre class="codeexample">
- "ex:value" %% xsd:QName
-</pre>
-</div>
-
-
-
-<div class='note'>Should we define structural equivalence of literals as in OWL2? [[!OWL2-SYNTAX]]
-(see section <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Literals">Literals</a>).
-</div>
-
-</section>
-
-
-
-
-<section id="record-Time">
-<h4>Time</h4>
-
-<p><dfn id="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [[!XMLSCHEMA-2]].</p>
-
-
-
-<p>It is OPTIONAL to assert time in usage, generation, and activity records.</p>
+
+
+
</section>
-<section id="record-Asserter">
-<h3>Asserter</h3>
-
-<p>An <dfn id="dfn-asserter">asserter</dfn> is a creator of PROV-DM records. An asserter is denoted by an IRI. Such IRI has no specific interpretation in the context of PROV-DM.</p>
-
-<div class='grammar'>
-<span class="nonterminal">asserter</span> ::= <span class="nonterminal">IRI</span><br/>
-<span class="nonterminal">IRI</span> ::= <em>an IRI compatible with production IRI in [[!IRI]], enclosed in a pair of < (U+3C) and > (U+3E) characters </em>
-</div>
-
-<div class='issue'>
-Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance
-of PROV-DM. 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>
-
-</section>
-
-<section id="record-NamespaceDeclaration">
-<h3>Namespace Declaration</h3>
-
-<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [[!IRI]]. In PROV-DM, attributes, identifiers, and literals of with datatype <span
-class="name">xsd:QName</span> can be placed in a namespace using the mechanisms described in this specification. </p>
-
-
-<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this
-declaration refers to this namespace.
-A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration
-refers to this namespace.</p>
-
-<div class='grammar'>
-<span class="nonterminal">namespaceDeclarations</span> ::=
- | <span class="group"><span class="nonterminal">defaultNamespaceDeclaration</span> | <span class="nonterminal">namespaceDeclaration</span></span> <span class="star"> <span
-class="nonterminal">namespaceDeclaration</span></span><br>
-<span class="nonterminal">namespaceDeclaration</span> ::=
-<span class="name">prefix</span> <span class="nonterminal">prefix</span> <span class="nonterminal">IRI</span><br/>
-<span class="nonterminal">defaultNamespaceDeclaration</span> ::=
- <span class="name">default</span> <span class="nonterminal">IRI</span> <br/>
-</div>
-</section>
-
-
-
-
-
-
-<section id="record-Location">
-<h3>Location</h3>
-
-<p><dfn id="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate,
-address, landmark, row, column, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations in assertions. </p>
-
-
-<p>
-Location is an OPTIONAL attribute of entity records and activity records. The value associated with a attribute <span class="name">location</span> MUST be a <span
-class="nonterminal">Literal</span>, expected to denote a location.
-</p>
-
-
-
-
-</section>
-
-</section>
</section>
@@ -2601,54 +1763,15 @@
<section id="common-relations">
<h2>PROV-DM Common Relations</h2>
-<p>This section contains the normative specification of common relations of PROV-DM.</p>
-
-
-
-
-<p>The following figure summarizes the additional relations described in subsections 6.1 to 6.7.</p>
-
-<div style="text-align: center;">
-<figure>
-<img src="sec6-summary.png" alt="common relations"/>
-<figcaption>PROV-DM Common Relations</figcaption>
-</figure>
-</div>
+<p>This section contains constraints associated with PROV-DM common relations.</p>
+
+
+
+
<section id="record-traceability">
<h3>Traceability Record</h3>
-<p> It is common that we may want to know who or what may have some influence, whether direct or indirect, on a given entity, or who may, directly or not, have some responsibility for a
-given outcome. Hence, we may want to infer such a notion from an existing set of PROV-DM records. Vice-versa, we may have knowledge of this influence and responsibility, but without
-knowing its actual details. Thus, we may also want to assert such a notion. </p>
-
-<p> A <dfn id="dfn-Traceability">traceability record</dfn> states the existence of a "dependency path" between two entities, indicating that one entity can be shown to be in the lineage of
-another, and may have influenced it, or may bear some responsibility for it, in some way. The traceability relation subsumes derivation, activity association, and responsibility, and is
-defined to be transitive. </p>
-
-<p> A traceability record, written <span class="name">tracedTo(id,e2,e1,attrs)</span> in PROV-ASN, contains the following components:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the traceability record;</li>
-<li><em>entity</em>: an identifier <span class="name">e2</span> identifying an entity;
-<li><em>ancestor</em>: an identifier <span class="name">e1</span> identifying an ancestor entity in the lineage of <span class="name">e2</span>;
-<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, a traceability record's text matches the <span class="nonterminal">traceabilityRecord</span> production of the grammar defined in this specification document.</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">traceabilityRecord</span> ::=
-<span class="name">tracedTo</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>
-<span class="name">,</span></span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
<p>A traceability record can be inferred from existing records, or can be asserted stating that such a dependency path exists without the asserter knowing its individual steps, as expressed
by the following inference and constraint, respectively.
@@ -2709,58 +1832,6 @@
-<p>PROV-DM allows dependencies amongst activities to be expressed.
-An <dfn id="InformationFlowOrdering">information flow ordering record</dfn> is a representation that an entity was generated by an activity, before it was used by another activity.
-A <dfn id="ControlOrdering">control ordering record</dfn> is a representation that an activity was initiated by another activity.
-</p>
-
-<p>In PROV-ASN, an activity ordering record's text matches the <span class="nonterminal">activityOrderingRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class='grammar'>
-<span class="nonterminal">activityOrderingRecord</span> ::=
-<span class="nonterminal">informationFlowOrderingRecord</span> |
-<span class="nonterminal">controlOrderingRecord</span>
-<br/>
-
-<span class="nonterminal">informationFlowOrderingRecord</span> ::=
-<span class="name">wasInformedBy</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>
-<span class="name">,</span>
-</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-<br/>
-
-<span class="nonterminal">controlOrderingRecord</span> ::=
-<span class="name">wasStartedBy</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>
-<span class="name">,</span>
-</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-<br/>
-</div>
-
-
-<p>
-An information flow ordering record, written as
-<span class="name">wasInformedBy(id,a2,a1,attrs)</span> in PROV-ASN, contains:
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the record;</li>
-<li><em>informed</em>: the identifier <span class="name">a2</span> of an activity record representing the informed activity;
-<li><em>informant</em>: the identifier <span class="name">a1</span> of an activity record representing the informant activity;
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
<p> An information flow ordering record is formally defined as follows.</p>
<div class='constraint' id='wasInformedBy-Definition'>Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
@@ -2801,20 +1872,11 @@
<div style="text-align: center;">
<figure>
-<img src="informedByNonTransitive.png" alt="non transitivity of wasInformedBy" />
+<img src="../informedByNonTransitive.png" alt="non transitivity of wasInformedBy" />
<figcaption>Counter-example for transitivity of wasInformedBy</figcaption>
</figure>
</div>
-<p>
-A control ordering record, written as
-<span class="name">wasStartedBy(a2,a1, attrs)</span> in PROV-ASN, contains: </p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span>;</li>
-<li><em>started</em>: refers to an activity record identified by <span class="name">a2</span>, representing the started activity;
-<li><em>starter</em>: refers to an activity record identified by <span class="name">a1</span>, representing the activity that started <span class="name">a1</span>;</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>Such a record states control ordering between <span class="name">a2</span> and <span class="name">a1</span>, specified as follows.</p>
<div class='constraint' id='wasStartedBy'>Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
@@ -2832,26 +1894,6 @@
class="name">wasStartedBy</span> has a range formed by the union of agents and activities.</p>
-<div class="anexample">
-<p>
-In the following assertions, we find two activity records, identified by <span class="name">a1</span> and <span class="name">a2</span>, representing two activities, which took place on two
-separate hosts. The third record indicates that the latter activity was started by the former.</p>
-<pre class="codeexample">
-activity(a1,t1,t2,[ex:host="server1.example.org",prov:type="workflow"])
-activity(a2,t3,t4,[ex:host="server2.example.org",prov:type="subworkflow"])
-wasStartedBy(a2,a1)
-</pre>
-
-<p>Alternatively, we could have asserted the existence of an entity, representing a request to create a sub-workflow. This request, issued by <span class="name">a1</span>, triggered the
-start of <span class="name">a2</span>.
-</p>
-<pre class="codeexample">
-entity(e,[prov:type="creation-request"])
-wasGeneratedBy(e,a1)
-wasStartedBy(a2,e)
-</pre>
-</div>
-
<div class="interpretation-forward">
For the interpretation of a control flow ordering record, see <a href="#wasStartedBy-ordering">wasStartedBy-ordering</a>.
@@ -2863,36 +1905,6 @@
<section id="record-Revision">
<h3>Revision Record</h3>
-<p> A <dfn id="dfn-Revision">revision record</dfn> is a representation of the creation of an entity considered to be a variant of another. Deciding whether something is made available as a
-revision of something else usually involves an agent who represents someone in the world who takes responsibility for approving that the former is a due variant of the latter. </p>
-
-<p> A revision record, written <span class="name">wasRevisionOf(e2,e1,ag,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>newer</em>: an identifier <span class="name">e2</span> identifying an entity that represents a newer version of an entity;
-<li><em>older</em>: an identifier <span class="name">e1</span> identifying an entity that represents an older version of an entity;
-<li><em>responsibility</em>: an OPTIONAL identifier <span class="name">ag</span> for the agent who approved that <span class="name">e2</span> is a variant of <span class="name">e1</span>;
-<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, a revision record's text matches the <span class="nonterminal">revisionRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class='grammar'>
-<span class="nonterminal">revisionRecord</span> ::=
-<span class="name">wasRevisionOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="optional"><span class="name">,</span>
-<span class="nonterminal">agIdentifier</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-
<p>A revision record needs to satisfy the following constraint, linking the two entity records by a derivation, and stating them to be a complement of a third entity record.</p>
@@ -2917,21 +1929,6 @@
each other.
</p>
-<div class="anexample">
-<p>
-The following revision assertion</p>
-<pre class="codeexample">
-agent(ag,[prov:type="QualityController"])
-entity(e1,[prov:type="document"])
-entity(e2,[prov:type="document"])
-wasRevisionOf(e2,e1,ag)
-</pre>
-<p>states that the document represented by entity record identified by <span class="name">e2</span> is a revision of document represented by entity record identified by <span
-class="name">e1</span>; agent denoted by <span class="name">ag</span> is responsible for this new versioning of the document.
-</p>
-</div>
-
-
</section>
@@ -2939,18 +1936,6 @@
<section id="recod-attribution">
<h3>Attribution Record</h3>
-<p>An <dfn>attribution record</dfn> represents that an entity is ascribed to an agent.</p>
-
-
-<p> An attribution record, written <span class="name"> wasAttributedTo(e,ag,attr)</span> in PROV-ASN, contains the following components:</p>
-<ul>
-<li><em>entity</em>: an identifier <span class="name">e</span> of an entity record;</li>
-<li><em>agent</em>: an identifier <span class="name">ag</span> of an agent whom the entity is attributed to;</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>Attribution models the notion of an activity generating an entity identified by <span class="name">e</span> being associated with an agent <span class="name">ag</span>, which takes
-responsibility for generating <span class="name">e</span>. Formally, this is expressed as the following necessary condition.</p>
-
<div class='inference' id='attribution-implication'>
<span class='conditional'>If</span>
@@ -2965,19 +1950,6 @@
for some sets of attribute-value pairs <span class="name">attr1</span> and <span class="name">attr2</span>, time <span class="name">t1</span>, and <span class="name">t2</span>.
</div>
-<p>In PROV-ASN, an attribution record's text matches the <span class="nonterminal">attributionRecord</span> production of the grammar.</p>
-
-<div class='grammar'>
-<span class="nonterminal">attributionRecord</span> ::=
-<span class="name">wasAttributedTo</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
</section>
@@ -2985,38 +1957,6 @@
<h3>Quotation Record</h3>
-<p> A <dfn>quotation record</dfn> is a representation of the repeating or copying of some part of an entity.</p>
-
-
-<p> A quotation record, written <span class="name"> wasQuotedFrom(e2,e1,ag2,ag1,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>quote</em>: an identifier <span class="name">e2</span>, identifying an entity record that represents the quote;
-<li><em>quoted</em>: an identifier <span class="name">e1</span>, identifying an entity record representing what is being quoted;
-<li><em>quoterAgent</em>: an OPTIONAL identifier <span class="name">ag2</span> of the agent who is doing the quoting;
-<li><em>quotedAgent</em>: an OPTIONAL identifier <span class="name">ag1</span> of the agent that is quoted;
-<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, a quotation record's text matches the <span class="nonterminal">quotationRecord</span> production of the grammar.</p>
-
-<div class='grammar'>
-<span class="nonterminal">quotationRecord</span> ::=
-<span class="name">wasQuotedFrom</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-
<div class='inference' id='quotation-implication'>
<span class='conditional'>If</span>
<span class="name">wasQuotedFrom(e2,e1,ag2,ag1,attrs)</span> holds for some identifiers
@@ -3034,34 +1974,6 @@
<section id="record-summary">
<h3>Summary Record</h3>
-<p>A <dfn>summary record</dfn> represents that an entity (expected to be a document) is a synopsis or abbreviation of another entity (also expected to be a document). </p>
-
-
-
-<p> A summary record, written <span class="name"> wasSummaryOf(e2,e1,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>summarizedEntity</em>: an identifier <span class="name">e2</span> for the entity record that represents the summary;
-<li><em>fullEntity</em>: an identifier <span class="name">e1</span> for the entity record that represents what is being summarized;
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p>
-<span class="name">wasSummaryOf</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
-</p>
-
-
-<p>In PROV-ASN, a summary record's text matches the <span class="nonterminal">summaryRecord</span> production of the grammar.</p>
-
-<div class='grammar'>
-<span class="nonterminal">summaryRecord</span> ::=
-<span class="name">wasSummaryOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
<div class='issue'>Drop this relation <a href="http://www.w3.org/2011/prov/track/issues/220">ISSUE-220</a>.</div>
@@ -3072,33 +1984,7 @@
<section id="record-orignal-source">
<h3>Original Source Record</h3>
-<p>An <dfn>original source record</dfn> represents an entity in
-which another entity first appeared. </p>
-
-
-<p> An assertion hadOriginalSource, written <span class="name"> hadOriginalSource(e2,e1,attrs)</span>, contains:</p>
-<ul>
-<li><em>entity</em>: an identifier <span class="name">e1</span> for the entity record representing the original entity; </li>
-<li><em>source</em>: an identifier <span class="name">e2</span> for an entity record, representing an entity that had appeared previously;</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>
- <span class="name">hasOriginalSource</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
-</p>
-
-<p>In PROV-ASN, an original source record's text matches the <span class="nonterminal">originalSourceRecord</span> production of the grammar.</p>
-
-<div class='grammar'>
-<span class="nonterminal">originalSourceRecord</span> ::=
-<span class="name">hadOriginalSource</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
+<p>Nothing specific.</p>
</section>
@@ -3308,6 +2194,204 @@
</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 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
+ 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>