--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/working-copy/wd5-prov-dm-constraints.html Thu Mar 15 22:59:06 2012 +0000
@@ -0,0 +1,1851 @@
+<!DOCTYPE html>
+
+<html><head>
+ <title>PROV-DM Part II: Constraints of the Provenance Data Model</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+<!-- PM -->
+ <style type="text/css">
+ .note { font-size:small; margin-left:50px }
+ </style>
+
+ <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
+ <script src="http://www.w3.org/2007/OWL/toggles.js" class="remove"></script>
+
+ <script class="remove">
+ var addExtraReferences = function() {
+ for (var k in extraReferences)
+ berjon.biblio[k] = extraReferences[k];
+ };
+ var extraReferences = {
+ "CLOCK":
+ "Lamport, L. "+
+ "<a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\"><cite>Time, clocks, and the ordering of events in a distributed system</cite></a>."+
+ "Communications of the ACM 21 (7): 558–565. 1978. "+
+ "URL: <a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\">http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf</a> " +
+ "DOI: doi:10.1145/359545.359563.",
+ "CSP":
+ "Hoare, C. A. R. "+
+ "<a href=\"http://www.usingcsp.com/cspbook.pdf\"><cite>Communicating Sequential Processes</cite></a>."+
+ "Prentice-Hall. 1985"+
+ "URL: <a href=\"http://www.usingcsp.com/cspbook.pdf\">http://www.usingcsp.com/cspbook.pdf</a>",
+ "Logic":
+ "W. E. Johnson"+
+ "<a href=\"http://www.ditext.com/johnson/intro-3.html\"><cite>Logic: Part III</cite></a>."+
+ "1924. "+
+ "URL: <a href=\"http://www.ditext.com/johnson/intro-3.html\">http://www.ditext.com/johnson/intro-3.html</a>",
+ "PROV-SEM":
+ "James Cheney "+
+ "<a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\"><cite>Formal Semantics Strawman</cite></a>. "+
+ "2011, Work in progress. "+
+ "URL: <a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\">http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman</a>",
+
+ "PROV-PRIMER":
+ "Yolanda Gil and Simon Miles (eds.) Khalid Belhajjame, Helena Deus, Daniel Garijo, Graham Klyne, Paolo Missier, Stian Soiland-Reyes, and Stephan Zednik "+
+ "<a href=\"http://www.w3.org/TR/prov-primer/\"><cite>Prov Model Primer</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-primer/\">http://www.w3.org/TR/prov-primer/</a>",
+
+
+ "PROV-DM":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-dm/\"><cite>PART 1: PROV-DM ...</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-dm/\">http://www.w3.org/TR/prov-dm/</a>",
+
+ "PROV-N":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-n/\"><cite>PROV-N ....</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-n/\">http://www.w3.org/TR/prov-n/</a>",
+
+
+ "PROV-O":
+ "Satya Sahoo and Deborah McGuinness (eds.) Khalid Belhajjame, James Cheney, Daniel Garijo, Timothy Lebo, Stian Soiland-Reyes, and Stephan Zednik "+
+ "<a href=\"http://www.w3.org/TR/prov-o/\"><cite>Provenance Formal Model</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-o/\">http://www.w3.org/TR/prov-o/</a>",
+
+ "PROV-AQ":
+ "Graham Klyne and Paul Groth (eds.) Luc Moreau, Olaf Hartig, Yogesh Simmhan, James Meyers, Timothy Lebo, Khalid Belhajjame, and Simon Miles "+
+ "<a href=\"http://www.w3.org/TR/prov-aq/\"><cite>Provenance Access and Query</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-aq/\">http://www.w3.org/TR/prov-aq/</a>",
+ };
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "prov-dm-constraints",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ subtitle : "Initial document for discussion, WD5",
+
+ // if you wish the publication date to be other than today, set this
+ //publishDate: "2012-02-01",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ copyrightStart: "2011",
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ //previousPublishDate: "2012-02-02",
+ //previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm-constraints.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css", "./extra.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Luc Moreau", url: "http://www.ecs.soton.ac.uk/~lavm/",
+ company: "University of Southampton" },
+ { name: "Paolo Missier", url: "http://www.cs.ncl.ac.uk/people/Paolo.Missier",
+ company: "Newcastle University" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: ,
+ authors: [
+ { name: "TBD" },
+ ],
+
+ // name of the WG
+ wg: "Provenance Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2011/prov/",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-prov-wg",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/46974/status",
+
+ // Add extraReferences to bibliography database
+ preProcess: [addExtraReferences],
+ };
+ </script>
+ </head>
+ <body>
+
+ <section id="abstract">
+<p>
+PROV-DM is a data model for provenance that describes
+the entities, people and activities involved in
+producing a piece of data or thing in the world. PROV-DM is
+domain-agnostic, but is equipped with extensibility points allowing
+further domain-specific and application-specific extensions to be
+defined. PROV-DM is accompanied by PROV-N, a technology-independent
+notation, which allows serializations of PROV-DM
+instances to be created for human consumption, which facilitates the
+mapping of PROV-DM to concrete syntax, and which is used as the basis for a
+formal semantics of PROV-DM. This document introduces
+ further set of concepts underpinning the PROV-DM data model and defines constraints that well-structured provenance descriptions should follow and that provide an interpretation for these descriptions.
+</p>
+ </section>
+
+<section id="sotd">
+<b>This document is released internally by the Provenance Working Group.</b>
+<section id="prov-family">
+<!-- <h3>Prov Family of Specifications</h3>-->
+This document is part of the PROV family of specifications, a set of specifications aiming to define the various aspects that are necessary to achieve the vision of inter-operable
+interchange of provenance information in heterogeneous environments such as the Web. This document defines the PROV-DM data model for provenance, accompanied with a notation to express
+instances of that data model for human consumption. Other documents are:
+<ul>
+<li> PROV-DM-CONSTRAINTS, a set of constraints applying to the PROV-DM data model,</li>
+<li> PROV-N, a notation for provenance aimed at human consumption,</li>
+<li> PROV-O, the provenance ontology: by means of a mapping of PROV-DM to the OWL2 Web Ontology Language, this specification provides a normative serialization of PROV-DM in RDF</li>
+<li> PROV-AQ, provenance access and query: the mechanisms for accessing and querying provenance; </li>
+<li> PROV-PRIMER: a primer for the PROV-DM provenance data model,</li>
+<li> PROV-SEM: a formal semantics for the PROV-DM provenance data model.</li>
+</ul>
+</section>
+</section>
+
+
+<!--
+<div class="buttonpanel">
+<form action="#"><p>
+<input id="hide-bnf" onclick="set_display_by_class('div','grammar','none'); set_display_by_id('hide-bnf','none'); set_display_by_id('show-bnf','');" type="button" value="Hide Grammar" />
+<input id="show-bnf" onclick="set_display_by_class('div','grammar',''); set_display_by_id('hide-bnf',''); set_display_by_id('show-bnf','none');" style="display: none" type="button"
+value="Show Grammar" />
+<input id="hide-examples" onclick="set_display_by_class('div','anexample','none'); set_display_by_id('hide-examples','none'); set_display_by_id('show-examples','');" type="button"
+value="Hide Examples" />
+<input id="show-examples" onclick="set_display_by_class('div','anexample',''); set_display_by_id('hide-examples',''); set_display_by_id('show-examples','none');" style="display: none"
+type="button" value="Show Examples" />
+</p>
+</form>
+</div>
+-->
+
+ <section id="introduction">
+ <h2>Introduction<br>
+</h2>
+
+<p> Provenance is defined as a record that describes the people,
+institutions, entities, and activities, involved in producing,
+influencing, or delivering a piece of data or a thing in the world. A
+companion specification [[PROV-DM]] defines PROV-DM, a data model for
+provenance, allowing such descriptions to be expressed.
+</p>
+
+
+<p>PROV-DM has essentially be defined without any constraints [[PROV-DM]]. This document introduces a further set of concepts underpinning this data model and defines constraints that well-structured provenance descriptions should follow and that provide an interpretation for these descriptions. </p>
+
+
+<p>This specification is one of several specifications, referred to as the PROV family of specifications, defining the various aspects
+that are necessary to achieve the vision of inter-operable exchange of provenance:</p>
+<ul>
+<li>A data model for provenance, which is presented in three documents:
+<ul>
+<li> PROV-DM (part I): the provenance data model itself, expressed in natural language [[PROV-DM]];
+<li> PROV-DM-CONSTRAINTS (part II): constraints underpinning the data model (this document);
+<li> PROV-N (part III): a notation to express instances of that data model for human consumption [[PROV-N]];
+</ul>
+</li>
+
+<li>PROV-O: a normative serialization of PROV-DM in RDF [[!PROV-O]], specified by means of a mapping to the OWL2 Web Ontology Language [[!OWL2-SYNTAX]];</li>
+<li>PROV-AQ: the mechanisms for accessing and querying provenance [[PROV-AQ]];</li>
+<li>PROV-PRIMER: a primer for the PROV approach [[PROV-PRIMER]];</li>
+<li>PROV-SEM: semantics of the PROV-DM data model [[PROV-SEM]];</li>
+</ul>
+
+
+ <section id="structure-of-this-document">
+<h3>Structure of this Document</h3>
+
+<div class='note'>TODO</div>
+
+<p>In <a href="#prov-dm-refinement">section 2</a>, further concepts underpinning PROV-DM are introduced.</p>
+
+<p><a href="#data-model-constraints">Section 3</a></p>
+
+
+<p><a href="#definitional-constraints">Section 4</a></p>
+
+<p><a href="#account-constraints">Section 5</a>
+</p>
+
+<p><a href="#interpretation">Section 6</a></p>
+<p><a href="#structural-constraints">Section 7</a></p>
+<p><a href="#collection-constraints">Section 8</a></p>
+<p><a href="#refining-provenance-descriptions">Section 9</a> successively review refined provenance descriptions, and examine their meaning, in light of the constraints introduced in previous sections. </p>
+
+
+
+ </section>
+
+
+
+ <section id="conventions">
+<h3>Conventions</h3>
+
+
+
+<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [[!RFC2119]].</p>
+ </section>
+
+</section>
+
+
+<section id='prov-dm-refinement'>
+<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 [[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'>
+<h4>Time and Event</h4>
+
+<p>Time is critical in the context of provenance, since it can help corroborate provenance claims. For instance, if an entity is claimed to be obtained by transforming another, then the
+latter must have existed before the former. If it is not the case, then there is something wrong with such a provenance claim. </p>
+
+<p> Although time is critical, we should also recognize that provenance can be used in many different contexts: in a single system, across the Web, or in spatial data management, to name a
+few. Hence, it is a design objective of PROV-DM to minimize the assumptions about time, so that PROV-DM can be used in varied contexts. </p>
+
+
+<p>Furthermore, consider two activities that started at the same time
+instant. Just by referring to that instant, we cannot distinguish
+which activity start we refer to. This is particularly relevant if we
+try to explain that the start of these activities had different
+reasons. We need to be able to refer to the start of an activity as a
+first class concept, so that we can talk about it and about its
+relation with respect to other similar starts. </p>
+
+
+<p>Hence, in our conceptualization of the world, an <em>instantaneous event</em>, or <dfn id="dfn-event">event</dfn> for short, happens in the world and marks a change in the world, in its
+activities and in its entities.
+The term "event" is commonly used in process algebra with a similar meaning. For instance, in CSP [[CSP]], events represent communications or interactions; they are assumed to be atomic and
+instantaneous.</p>
+
+
+
+
+<section id="types-of-events">
+<h4>Types of Events</h4>
+
+<p>Four kinds of <a title="event">instantaneous events</a> underpin the PROV-DM data model. The <strong>activity start</strong> and <strong>activity end</strong> events demarcate the
+beginning and the end of activities, respectively. The <strong>entity generation</strong> and <strong>entity usage</strong> events demarcate the characterization interval for entities. More
+specifically:
+
+</p>
+
+<p>An <dfn id="dfn-generation-event">entity generation event</dfn> is the <a title="event">instantaneous event</a> that marks the final instant of an entity's creation timespan, after which
+it is no longer available for use.</p>
+
+<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a title="event">instantaneous event</a> that marks the first instant of an entity's consumption timespan by an activity.</p>
+
+<p>An <dfn id="dfn-destruction-event">entity destruction event</dfn> is the <a title="event">instantaneous event</a> that marks the initial instant of an entity's destruction timespan, after which
+it no longer becomes available for use.</p>
+
+<div class='note'>Tentative definition of destruction!</div>
+
+
+<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a title="event">instantaneous event</a> that marks the instant an activity starts.</p>
+
+<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a title="event">instantaneous event</a> that marks the instant an activity ends.</p>
+
+</section>
+
+<section id="event-ordering">
+<h4>Event Ordering</h4>
+
+<p>To allow for minimalistic clock assumptions, like Lamport
+[[CLOCK]], PROV-DM relies on a notion of relative ordering of <a title="event">instantaneous events</a>,
+without using physical clocks. This specification assumes that a partial order exists between <a title="event">instantaneous events</a>.
+</p>
+
+
+<p>Specifically, <dfn id="dfn-follows">follows</dfn> is a partial
+order between <a title="event">instantaneous events</a>, indicating that an <a title="event">instantaneous event</a> occurs at the same time as or after another.
+For symmetry, <dfn id="dfn-precedes">precedes</dfn> is defined as
+the inverse of follows. (Hence, these relations are reflexive and transitive.)</p>
+
+
+<p> How such partial order is realized in practice is beyond the scope
+of this specification. This specification only assumes that
+each <a title="event">instantaneous event</a> can be mapped to an instant in some form of
+timeline. The actual mapping is not in scope of this
+specification. Likewise, whether this timeline is formed of a single
+global timeline or whether it consists of multiple Lamport's style
+clocks is also beyond this specification. It is anticipated
+that <a>follows</a> and <a>precedes</a> correspond to some ordering
+over this timeline.
+</p>
+
+
+<p>This specification introduces a set of "temporal interpretation"
+rules allowing the derivation of <a title="event">instantaneous event</a> ordering constraints from
+provenance descriptions. According to such temporal interpretation,
+descriptions MUST satisfy such constraints. We note that the
+actual verification of such ordering constraints is outside the
+scope of this specification. </p>
+
+<p>PROV-DM also allows for time observations to be inserted in specific
+descriptions, for each recognized <a title="event">instantaneous event</a> introduced
+in this specification. The presence of a time observation for a
+given <a title="event">instantaneous event</a> fixes the mapping of this <a title="event">instantaneous event</a> to the
+timeline. It can also help with the verification of associated
+ordering constraints (though, again, this verification is outside the
+scope of this specification).
+</p>
+
+
+
+</section>
+
+ </section>
+
+
+
+ <section id='section-attributes'>
+<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
+hosted over time, etc.</p>
+
+<p>From a provenance viewpoint, it is important to identify a "<em>partial state</em>" of something, i.e. something with some aspects that have been fixed, so that it becomes possible to express its provenance, and what causes that thing, with these specific aspects to be as such. </p>
+
+<p>It is the purpose of attributes in PROV-DM to help fix some aspect of entities.
+Indeed, we previously defined
+entities as things in the world one wants to provide provenance for;
+we refine this definition as follows, using attribute-values to describe entities' "partial states", and linking them to the very existence of entities.</p>
+
+<p>
+An <dfn>entity</dfn> is a thing in the world one wants to provide provenance for and whose situation in the world is described by some attribute-value pairs; an entity's description (formed of attribute-value pairs) holds (i.e. describes the thing's situation) during a period comprised between its <a title="entity generation event">generation event</a> and its <a title="entity destruction event">destruction event</a>.</p>
+
+<p>An entity fixes some aspects of a thing and its situation in the
+world. An alternative entity may fix other aspects, and its provenance
+may be different.</p>
+
+
+
+
+
+
+<div class="anexample" id="a-report-example">
+Different users may take different perspectives on a resource with
+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>
+<li>the report independent of where it is hosted and of its content over time: fixes the nature of the thing as a conceptual artifact.</li></ul>
+The provenance of these three entities may differ, and may be along the following lines:
+<ul>
+<li>the provenance of a report available at a URL may include: the act of publishing it and making it available at a given location, possibly under some license and access control;</li>
+<li>the provenance of the version of the report available there today may include: the authorship of the specific content, and reference to imported content;</li>
+<li>the provenance of the report independent of where it is hosted over time may include: the motivation for writing the report, the overall methodology for producing it, and the broad team
+involved in it.</li>
+</ul>
+</div>
+
+<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-term-assertion-inference">
+<h3>Description, Assertion, and Inference</h3>
+
+<p>
+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 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 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 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 descriptions
+conformant to the PROV-DM data model. When this is the case, this
+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>
+
+
+
+</section>
+<div class='issue'> We need to refine the definition of entity and activity, and all the concepts in general. This is <a href="http://www.w3.org/2011/prov/track/issues/223">ISSUE-223</a>.</div>
+
+
+
+
+ <section id="account-and-accountEntity">
+ <h3>Account and AccountEntity</h3>
+
+
+<p>It is common for multiple provenance records to co-exist. For
+instance, when emailing a file, there could be a provenance record
+kept by the mail client, and another by the mail server. Such
+provenance records may provide different explanations about something
+happening in the world, because they are created by different parties
+or observed by different witnesses. A given party could also create
+multiple provenance records about an execution, to capture different
+levels of details, targeted at different end-users: the programmer of
+an experiment may be interested in a detailed log of execution, while
+the scientists may focus more on the scientific-level description.
+Given that multiple provenance records can co-exist, it is important
+to have details about their origin, who they are attributed to, how
+they were generated, etc. In other words, an important requirement is
+to be able to express the provenance of provenance. </p>
+
+<p>
+ <span class="glossary" id="glossary-account">
+An <dfn>account</dfn> is a named bundle of provenance descriptions.
+</span> PROV-DM does not provide an actual mechanism for creating accounts, i.e. for bundling up provenance descriptions and naming them. Accounts MUST satisfy some properties:
+<ul>
+<li>An account can be seen as a container of provenance descriptions, hence its content MAY change over time.</li>
+<li>If an account's set of descriptions changes over time, it increases monotonically with time. </li>
+<li>A given description of e.g. an entity in a given account, in terms of its identifier and attribute-value pairs, does not change over time. </li>
+</ul>
+
+<div class='note'>
+The last point is important and needs to be discussed by the Working Group.
+It indicates that within an account:
+<ul>
+<li>It is always possible to add new provenance descriptions, e.g. stating that a given entity was used by an activity. This is very much an open world assumption.
+<li>It is not permitted to add new attributes to a given entity (a form of closed world assumption from the attributes point of view), though it is always permitted to create a new description for an entity, which is a "copy" of the original description extended with novel attributes (cf Example <a href="#merge-with-rename">merge-with-rename</a>).
+</ul>
+</div>
+
+<p>
+There is no construct in PROV-DM to create such named bundles. Instead, it is assumed that some mechanism, outside PROV-DM can create them. However, from a provenance viewpoint, such accounts are things we may want to describe the provenance of. In order to be able to do so, we need to see accounts as entities, whose origin can be described using PROV-DM vocabulary. Thus, PROV-DM introduces the reserved type AccountEntity, defined as follows:
+<span class="glossary" id="glossary-entity">
+ <dfn id="concept-accountEntity">AccountEntity</dfn> is the category of entities that are accounts, i.e. named bundles of provenance descriptions.
+</span>
+</p>
+
+ </section>
+</section>
+
+
+
+<section id="data-model-constraints">
+<h2>Constraints Applicable to PROV-DM </h2>
+
+<p>In [[PROV-DM]], a data model for provenance has been defined without introducing any constraint that this data model has to satisfy. In <a href="#prov-dm-refinement">Section 2</a>, various notions have been introduced, attributes, event, entity interval, activity interval, accounts, which underpin the PROV-DM data model. Using these notion, we explore the constraints
+that the PROV-DM data model has to satisfy. </p>
+
+<div class='note'>
+<p> Overview the kind of constraints</p>
+<ul>
+<li>Definitional constraints (<a href="#definitional-constraints">Section 4</a>)</li>
+<li>Account constraints (<a href="#account-constraints">Section 5</a>)</li>
+<li>Event ordering constraints (<a href="#interpretation">Section 6</a>)</li>
+<li>Structural constraints (<a href="#structural-constraints">Section 7</a>)</li>
+<li>Collection constraints (<a href="#collection-constraints">Section 8</a>)</li>
+</ul>
+</div>
+
+</section>
+
+<section id="definitional-constraints">
+
+<h2>PROV-DM Definitional Constraints and Inferences</h2>
+
+<p>In this section, we revisit elements and relations of PROV-DM, and examine and examine the constraints associated with their definitions. </p>
+
+
+<div class='note'>
+Proposing to remove the subsections in this section, since some have no constraints.
+</div>
+
+
+ <section id="term-element">
+<h3>Element</h3>
+
+ <section id="term-Entity">
+
+<h4>Entity</h4>
+
+
+<p>
+An <dfn>entity</dfn> is a thing in the world one wants to provide provenance for and whose situation in the world is represented by some attribute-value pairs; an entity's attribute-value pairs remain unchanged during an entity's characterization interval,
+ i.e. a continuous interval between two <a title="event">instantaneous events</a> in the world, namely its <a title="entity generation event">generation event</a> and its <a title="entity destruction event">destruction event</a>.</p>
+
+
+Further considerations:
+<ul>
+<li>In order to describe something over several intervals, it is required to create multiple entities (either by direct
+assertion or by inference), each with its own identifier (so as to allow potential dependencies between the various entity records).
+
+
+</li>
+
+<li>There is no assumption that the set of attributes is complete and that the attributes are independent or orthogonal of each other.</li>
+
+<li>A characterization interval may collapse into a single instant.</li>
+
+
+
+</ul>
+
+
+
+<div class='issue'>The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define alternateOf and specializationOf more precisely.
+Beginning and end of characterization interval could be expressed by attributes (similarly to activities).
+How do we define the end of an entity? This is <a href="http://www.w3.org/2011/prov/track/issues/204">ISSUE-204</a>.
+</div>
+
+
+
+
+ </section>
+
+ <section id="term-Activity">
+
+<h3>Activity</h3>
+
+
+
+<p>An activity is anything that involves entities. An activity is delimited by its <a title="activity start event">start</a> and its <a title="activity end event">end</a> events; hence, it occurs over
+an interval delimited by two <a title="event">instantaneous events</a>. However, an activity need not mention time information, nor duration, because they may not be known.
+An activity's attribute-value pairs remain unchanged during an activity's interval, i.e. an interval between two instantaneous events in the world, namely its <a title="activity start event">start</a> event and its <a title="activity end event">end</a> event.
+</p>
+
+<div class="interpretation-forward">
+For the interpretation of an activity, see <a href="#start-precedes-end">start-precedes-end</a>.
+</div>
+
+<p>Further considerations:</p>
+<ul>
+<li>An activity is not an entity.
+Indeed, an entity exists in full at
+any point in its lifetime, persists during this
+interval, and preserves the characteristics that makes it
+identifiable. In contrast, an activity is something that happens,
+unfolds or develops through time, but is typically not identifiable by
+the characteristics it exhibits at any point during its duration.
+This distinction is similar to the distinction between
+'continuant' and 'occurrent' in logic [[Logic]].</li>
+</ul>
+
+
+</section>
+
+<section id="term-Agent">
+<h3>Agent</h3>
+
+
+
+
+<div class='issue'> Shouldn't we allow for entities (not agent) to be associated with an activity? Should we drop the inference association-agent? <a
+href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.
+
+<p>One can assert an agent record or alternatively, one can infer an agent record
+by its association with an activity. </p>
+
+<div class='inference' id='association-agent'>
+<span class='conditional'>If</span> the records <span class="name">entity(e,attrs)</span>
+and
+<span class="name">wasAssociatedWith(a,e)</span> hold for some identifiers
+<span class="name">a</span>, <span class="name">e</span>, and attribute-values <span class="name">attrs</span>, then
+the record <span class="name">agent(e,attrs)</span> also holds.
+</div>
+
+</div>
+
+</section>
+
+ <section id="term-note">
+
+<h4>Note</h4>
+
+<p>Attribute-value pairs occurring in notes are application specific. Thus, their interpretation is outside the scope of this document, and they are not subject to any of the constraints listed in this document. </p>
+
+
+
+ </section>
+
+</section>
+
+
+<section id="term-relation">
+<h3>PROV-DM Relations</h3>
+
+
+
+<section id="term-Generation">
+<h4>Generation</h4>
+
+
+<p>A <dfn id="dfn-Generation">generation</dfn> is an instantaneous world <a title="entity generation event">event</a>, the completed creation of a new
+entity by an activity. This entity become available for usage after this <a title="event">instantaneous
+event</a>. This entity did not exist before creation.
+ This <a title="event">instantaneous event</a> encompasses a description of the modalities of generation of this entity by this activity, by means of key-value pairs.</p>
+
+
+
+<p>
+A generation's id is OPTIONAL. It MUST be used when annotating generations (see Section <a href="#term-annotation">Annotation</a>) or when defining precise
+derivations (see <a href="#Derivation-Relation">Derivation</a>).
+</p>
+
+
+<div class="interpretation-forward">
+For the interpretation of a generation, see <a href="#generation-within-activity">generation-within-activity</a>.
+</div>
+
+
+
+<p></p>
+<div class="structural-forward">
+See <a href="#generation-uniqueness">generation-uniqueness</a> for a structural constraint on generations.
+</div>
+
+
+
+</section>
+
+
+<section id="term-Usage">
+<h3>Usage</h3>
+
+
+
+<p>A <dfn id="dfn-Use">usage</dfn> is an instantaneous world <a title="entity usage event">event</a>: an activity beginning to consume an entity.
+Before this event, the activity had not begun to consume or use to this entity.
+ The description includes the modalities of usage of this entity by this activity.</p>
+
+
+
+
+<p>
+A usage id is OPTIONAL. It MUST be present when annotating usages (see Section <a href="#term-annotation">Annotation</a>) or when defining precise derivations (see
+<a href="#Derivation-Relation">Derivation</a>).</p>
+
+<p>
+A reference to a given entity MAY appear in multiple usages for a given activity identifier.
+</p>
+
+
+<div class="interpretation-forward">
+For the interpretation of a usage, see <a href="#generation-precedes-usage">generation-precedes-usage</a> and <a href="#usage-within-activity">usage-within-activity</a>.
+</div>
+
+
+
+</section>
+
+
+
+
+
+
+<section id="term-ActivityAssociation">
+<h4>Activity Association</h4>
+
+<div class="interpretation-forward">
+For the interpretation of an activity association, see <a href="#wasAssociatedWith-ordering">wasAssociatedWith-ordering</a>.
+</div>
+
+
+<div class='issue'> The activity association record does not allow for a plan to be asserted without an agent.
+This seems over-restrictive. Discussed in the context of <a href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
+
+
+<div class='issue'> Agents should not be inferred. WasAssociatedWith should also work with entities.
+This is <a href="http://www.w3.org/2011/prov/track/issues/206">ISSUE-206</a>.</div>
+
+
+</section>
+
+<section id="term-Start-End">
+<h4>Start and Ends</h4>
+
+
+<div class='issue'>
+Should we define start/end records as representation of activity start/end events.
+Should time be associated with these events rather than with activities. This will be similar to what
+we do for entities. This is issue <a href="http://www.w3.org/2011/prov/track/issues/207">ISSUE-207</a>.</div>
+
+
+</section>
+
+
+
+
+
+
+
+<section id="term-responsibility">
+
+<h4>Responsibility Chain</h4>
+
+
+Nothing here.
+
+</section>
+
+<section id="Derivation-Relation">
+<h4>Derivation</h4>
+
+<p>A derivation is more informative if it contains a reference to an activity, generation, and usage. Hence, the following implication
+holds.</p>
+<div class='inference' id='derivation-implication'>
+Given two entities denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the assertion <span class="name">wasDerivedFrom(e2,
+e1, a, g2, u1, attrs)</span>
+ holds for some generation <span class="name">g2</span>, usage <span class="name">u1</span>, and set of attribute-value pairs <span class="name">attrs</span>, then <span
+class="name">wasDerivedFrom(e2,e1, attrs)</span> also holds.<br>
+ </div>
+
+<div class="interpretation-forward">
+For the interpretation of a derivation, see <a href="#derivation-usage-generation-ordering">derivation-usage-generation-ordering</a> and <a
+href="#derivation-generation-generation-ordering">derivation-generation-generation-ordering</a>
+</div>
+
+
+<p>
+Note that inferring derivation from usage and generation does not hold
+in general. Indeed, when a generation <span class="name">wasGeneratedBy(g, e2, a, attrs2)</span>
+<a>precedes</a> <span class="name">used(u, a, e1, attrs1)</span>, for
+some <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">attrs1</span>, <span class="name">attrs2</span>, and <span class="name">a</span>, one
+cannot infer derivation <span class="name">wasDerivedFrom(e2, e1, a, g, u)</span>
+or <span class="name">wasDerivedFrom(e2,e1)</span> since
+of <span class="name">e2</span> cannot possibly be derived from
+ <span class="name">e1</span>, given the creation of <span class="name">e2</span> <a>precedes</a> the use
+of <span class="name">e1</span>.
+</p>
+
+
+<p></p>
+<div class="structural-forward">
+See <a href="#derivation-use">derivation-use</a> for a structural constraint on derivations.
+</div>
+
+
+
+
+
+
+<div class='issue'> Emphasize the notion of 'affected by' <a href="http://www.w3.org/2011/prov/track/issues/133">ISSUE-133</a>.</div>
+
+
+
+
+</section>
+
+
+<section id="term-alternate-specialization">
+
+<h4>Alternate and Specializations</h4>
+
+<p>Nothing to add here</p>
+
+ <div class="note">
+In order to further convey the intended meaning, the following properties are associated to these two relations.
+
+ <ul>
+ <li><span class="name">specializationOf(e2,e1)</span> is <strong>transitive</strong>: <span class="name">specializationOf(e3,e2)</span> and <span
+class="name">specializationOf(e2,e1)</span> implies <span class="name">specializationOf(e3,e1)</span>.
+
+ <li><span class="name">specializationOf(e2,e1)</span> is <strong>anti-symmetric</strong>: <span class="name">specializationOf(e2,e1)</span> implies that <span
+class="name">specializationOf(e1,e2)</span> does not hold.
+ <li><span class="name">alternateOf(e2,e1)</span> is <strong>symmetric</strong>: <span class="name">alternateOf(e2,e1)</span> implies <span class="name">alternateOf(e1,e2)</span>.
+ </ul>
+
+There are proposals to make alternateOf a transitive property. This is still under discussion and the default is for alternateOf <strong>not</strong> to be transitive, and this is what the current text reflects.</div>
+
+
+<div class='issue'>A discussion on alternative definition of these relations has not reached a satisfactory conclusion yet. This is <a
+href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a>. Also <a href="http://www.w3.org/2011/prov/track/issues/96">ISSUE-96</a>.</div>
+
+
+</section>
+
+
+
+
+
+
+
+
+
+
+</section>
+
+
+
+
+ <section id="common-relations">
+<h2>PROV-DM Common Relations</h2>
+
+<p>This section contains constraints associated with PROV-DM common relations.</p>
+
+
+
+
+
+<section id="term-traceability">
+<h3>Traceability</h3>
+
+
+<p>Traceability can be inferred from existing descriptions, or can be asserted stating that a dependency path exists without its individual steps being expressed. This is captured
+by the following inference and constraint, respectively.
+
+<div class='inference' id='traceability-inference'>
+Given two identifiers <span class="name">e2</span> and <span class="name">e1</span> for entities,
+the following statements hold:
+
+<ol>
+<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span
+class="name">u1</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also
+holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr) and wasAssociatedWith(a,e1)</span> hold, for some <span class="name">a</span> and <span
+class="name">gAttr</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span
+class="name">actedOnBehalfOf(e,e1)</span> hold, for some <span class="name">a</span>, <span class="name">e</span>, and <span class="name">gAttr</span>, <span
+class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr) and wasStartedBy(a,e1,sAttr)</span> hold, for some <span class="name">a</span>, <span
+class="name">e</span>, and <span class="name">gAttr</span>, and <span class="name">sAttr</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also
+holds.</li>
+<li><span class='conditional'>If</span> <span class="name">tracedTo(e2,e)</span> and <span class="name">tracedTo(e,e1)</span> hold for some <span class="name">e</span>, <span
+class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+</ol>
+</div>
+
+<p>We note that the inference rule <a href="#traceability-inference">traceability-inference</a> does not allow us to infer attributes, which are application specific. </p>
+
+<div class='constraint' id='traceability-assertion'>
+<span class='conditional'>If</span> <span class="name">tracedTo(r2,r1,attrs)</span> holds for two identifiers <span class="name">r2</span> and <span class="name">r1</span>
+identifying entities, and attribute-value pairs <span class="name">attrs</span>,
+ <span class='conditional'>then</span> there exist
+<span class="name">e<sup>0</sup></span>, <span class="name">e<sup>1</sup></span>, ..., <span class="name">e<sup>n</sup></span> for <span class="name">n≥1</span>, with <span
+class="name">e<sup>0</sup></span>=<span class="name">r2</span> and <span class="name">e<sup>n</sup></span>=<span class="name">r1</span>, and
+for any i such that <span class="name">0≤i≤n-1</span>, at least of the following statements holds:
+<ul>
+<li> <span class="name">wasDerivedFrom(e<sup>i</sup>,e<sup>i+1</sup>,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span class="name">u1</span>,
+or</li>
+<li> <span class="name">wasDerivedFrom(e<sup>i</sup>,e<sup>i+1</sup>)</span> holds, or</li>
+<li> <span class="name">wasBasedOn(e<sup>i</sup>,e<sup>i+1</sup>)</span> holds, or</li>
+<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasAssociatedWith(a,e<sup>i+1</sup>)</span> hold, for some <span class="name">a</span> and <span
+class="name">gAttr</span>, or</li>
+<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span class="name">actedOnBehalfOf(e,e<sup>i+1</sup>)</span> hold,
+for some <span class="name">a</span>, <span class="name">e</span> and <span class="name">gAttr</span>, or</li>
+<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasStartedBy(a,e<sup>i+1</sup>,sAttr)</span> hold, for some <span class="name">a</span>, <span class="name">e</span>, and
+<span class="name">gAttr</span>, and <span class="name">sAttr</span>.</li>
+</ul>
+</div>
+
+<p>We note that the previous constraint is not really an inference <em>rule</em>, since there is nothing that we can actually infer. Instead, this constraint should simply be seen as part
+of the definition of the traceability relation. </p>
+
+
+</section>
+
+<section id="term-OrderingOfActivities">
+<h3>Activity Ordering</h3>
+
+
+
+<p> An information flow ordering relation is formally defined as follows.</p>
+
+<div class='constraint' id='wasInformedBy-Definition'>Given two activities identified by <span class="name">a1</span> and <span class="name">a2</span>,
+ <span class="name">wasInformedBy(a2,a1)</span>
+holds, <span class='conditional'>if and only if</span>
+ there is an entity with some identifier <span class="name">e</span> and some sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
+such that <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">used(a2,e,attrs2)</span> hold.
+</div>
+
+
+<div class="interpretation-forward">
+For the interpretation of an information flow ordering, see <a href="#wasInformedBy-ordering">wasInformedBy-ordering</a>.
+</div>
+
+
+<p>The relationship <span class="name">wasInformedBy</span> is not transitive. Indeed, consider the following fragment.</p>
+<pre class="codeexample">
+wasInformedBy(a2,a1)
+wasInformedBy(a3,a2)
+</pre>
+<p> We cannot infer <span class="name">wasInformedBy(a3,a1)</span> from these expressions. Indeed,
+from
+<span class="name">wasInformedBy(a2,a1)</span>, we know that there exists <span class="name">e1</span> such that <span class="name">e1</span> was generated by <span class="name">a1</span>
+and used by <span class="name">a2</span>. Likewise, from <span class="name">wasInformedBy(a3,a2)</span>, we know that there exists <span class="name">e2</span> such that <span
+class="name">e2</span> was generated by <span class="name">a2</span> and used by <span class="name">a3</span>. The following illustration shows a case for which transitivity cannot hold. The
+horizontal axis represents the event line. We see that <span class="name">e1</span> was generated after <span class="name">e2</span> was used. Furthermore, the illustration also shows that
+<span class="name">a3</span> completes before <span class="name">a1</span>. So it is impossible for <span class="name">a3</span> to have used an entity generated by <span
+class="name">a1</span>.</p>
+
+<div style="text-align: center;">
+<figure>
+<img src="images/informedByNonTransitive.png" alt="non transitivity of wasInformedBy" />
+<figcaption>Counter-example for transitivity of wasInformedBy</figcaption>
+</figure>
+</div>
+
+<p>Control ordering between two activities denoted by <span class="name">a2</span> and <span class="name">a1</span> is specified as follows.</p>
+
+<div class='constraint' id='wasStartedBy'>Given two activities with identifiers <span class="name">a1</span> and <span class="name">a2</span>,
+ <span class="name">wasStartedBy(a2,a1)</span>
+holds <span class='conditional'>if and only if</span>
+ there exist an entity with some identifier <span class="name">e</span>
+and some attributes <span class="name">gAttr</span> and <span class="name">sAttr</span>,
+such that
+ <span class="name">wasGeneratedBy(e,a1,gAttr)</span>
+ and <span class="name">wasStartedBy(a2,e,sAttr)</span> hold.
+</div>
+
+<p>We note that an activity start associates an activity with an agent, and is denoted by the name <span class="name">wasStartedBy</span>. A <a>control ordering</a> relation associates an
+activity with another activity, also denoted by the name <span class="name">wasStartedBy</span>. Effectively, by considering both relation types, the relation <span
+class="name">wasStartedBy</span> has a range formed by the union of agents and activities.</p>
+
+
+
+<div class="interpretation-forward">
+For the interpretation of a control flow ordering, see <a href="#wasStartedBy-ordering">wasStartedBy-ordering</a>.
+</div>
+
+
+</section>
+
+<section id="term-Revision">
+<h3>Revision</h3>
+
+
+
+<p>A revision needs to satisfy the following constraint, linking the two entities by a derivation, and stating them to be a specialization of a third entity.</p>
+
+<div class='inference' id='wasRevision'>
+Given two identifiers <span class="name">old</span> and <span class="name">new</span> identifying two entities, and an identifier <span class="name">ag</span> identifying an agent,
+<span class='conditional'>if</span> <span class="name">wasRevisionOf(new,old,ag)</span> holds, <span class='conditional'>then</span>
+there exists an entity with some identifier <span class="name">e</span> and some attribute-values <span class="name">eAttrs</span>, <span class="name">dAttrs</span>, such that the following
+hold:
+<ul>
+<li> <span class="name">wasDerivedFrom(new,old,dAttrs)</span>;
+<li> <span class="name">entity(e,eAttrs)</span>;
+<li> <span class="name">specializationOf(new,e)</span>;
+<li> <span class="name">specializationOf(old,e)</span>.
+</ul>
+</div>
+
+<p><span class="name">wasRevisionOf</span> is a strict sub-relation
+ of <span class="name">wasDerivedFrom</span> since two entities <span class="name">e2</span> and <span class="name">e1</span>
+ may satisfy <span class="name">wasDerivedFrom(e2,e1)</span> without being a variant of
+ each other.
+</p>
+
+
+</section>
+
+
+<section id="recod-attribution">
+<h3>Attribution</h3>
+
+
+<div class='inference' id='attribution-implication'>
+<span class='conditional'>If</span>
+<span class="name">wasAttributedTo(e,ag)</span> holds for some identifiers
+<span class="name">e</span> and <span class="name">ag</span>,
+<span class='conditional'>then</span>, there exists an activity with some identifier <span class="name">a</span> such that the following statements hold:
+<pre>
+activity(a,t1,t2,attr1)
+wasGenerateBy(e,a)
+wasAssociatedWith(a,ag,attr2)
+</pre>
+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>
+
+</section>
+
+
+<section id="term-quotation">
+<h3>Quotation</h3>
+
+
+<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
+<span class="name">e2</span>, <span class="name">e1</span>, <span class="name">ag2</span>, <span class="name">ag1</span>,
+<span class='conditional'>then</span> the following hold:
+<pre>
+wasDerivedFrom(e2,e1)
+wasAttributedTo(e2,ag2)
+wasAttributedTo(e1,ag1)
+</pre>
+</div>
+
+</section>
+
+
+
+<section id="term-orignal-source">
+<h3>Original Source</h3>
+
+<p>Nothing specific.</p>
+
+</section>
+
+
+
+<section id="term-Collection">
+<h3>Collections</h3>
+
+<p>Nothing specific, here, everything in Collection constraint section</p>
+
+</section>
+
+ </section>
+
+</section>
+
+
+
+<section id="account-constraints">
+<h3>PROV-DM Account Constraints</h3>
+
+
+<p>PROV-DM allows for multiple descriptions of entities (and in general any identifiable object) to be expressed. </p>
+
+<div class="anexample" id="example-two-entities-one-id">
+<p>Let us consider two descriptions of a same entity, which we have taken from two different contexts (see example). A working draft published by the <span class="name">w3:Consortium</span>:</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+</pre>
+The second version of a document edited by some authors:
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
+</pre>
+<p>Both descriptions are about the same entity identified by
+<span class="name">tr:WD-prov-dm-20111215</span>, but they contain different attributes, reflecting the context in which they occur.
+</p>
+</div>
+
+
+
+<p>Two different descriptions of a same entity cannot co-exist in a same account
+ as formalized in <a href="#unique-description-in-account">unique-description-in-account</a>.</p>
+
+<div class='constraint' id='unique-description-in-account'>
+<p>Given an entity identifier <span class="name">e</span>, there is at most one description
+<span class="name">entity(e,av)</span> occurring in a given account, where <span class="name">av</span> is some set of attribute-values. Other descriptions of the same entity can exist in different accounts.</p>
+
+<p>This constraint similarly applies to all other types of identifiable entities and relations.</p>
+</div>
+
+<p>
+ <div class="structural-forward">
+ See Section <a href="#structural-constraints">structural-constraints</a> for a structural constraint on accounts
+ </div>
+
+
+<p>In some cases, there may be a requirement for the two descriptions to be included in a same account. To satisfy the constraint <a href="#unique-description-in-account">unique-description-in-account</a>, we can adopt a different identifier for one of them, and relate the two descriptions with the <span class="name">alternateOf</span> relation. </p>
+
+<div class="anexample" id="merge-with-rename">
+<p>We now reconsider the same two descriptions of a same entity, but we change the identifier for one of them:</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+entity(ex:alternate-20111215, [ prov:type="document", ex:version="2" ])
+alternateOf(tr:WD-prov-dm-20111215,ex:alternate-20111215)
+alternateOf(ex:alternate-20111215,tr:WD-prov-dm-20111215)
+</pre>
+</div>
+
+
+</section>
+
+
+ <section id="interpretation">
+<h3>PROV-DM Event Ordering Constraints</h3>
+
+<p>Section <a href="#section-time-event">section-time-event</a>
+introduces a notion of <a title="event">instantaneous event</a>
+marking changes in the world, in its activities and entities. PROV-DM
+identifies five kinds of <a title="event">instantaneous events</a>, namely <a>entity generation
+event</a>, <a>entity usage event</a>, <a>entity destruction event</a>, <a>activity start event</a>
+and <a>activity end event</a>. PROV-DM adopts Lamport's clock
+assumptions [[CLOCK]] in the form of a reflexive, transitive partial order <a>follows</a>
+(and its inverse <a>precedes</a>) between <a title="event">instantaneous events</a>. Furthermore,
+PROV-DM assumes the existence of a mapping from <a title="event">instantaneous events</a> to time clocks,
+though the actual mapping is not in scope of this specification.</p>
+
+<p>Given that provenance consists of a description of past entities
+and activities, to be meaningful provenance descriptions MUST
+satisfy <em>instantaneous event ordering constraints</em>, which we introduce in
+this section. For instance, an entity can only be used after it was
+generated; hence, we say that an entity's <a title="entity generation
+event">generation event</a> precedes any of this
+entity's <a title="entity usage event">usage event</a>. Should this
+ordering constraint be proven invalid, the associated generation and
+usage could not be credible. The rest of this section defines
+the <dfn>temporal interpretation</dfn> of provenance descriptions as a
+set of instantaneous event ordering constraints. </p>
+
+
+<p>PROV-DM also allows for time observations to be inserted in
+specific provenance descriptions, for each of the four kinds
+of <a title="event">instantaneous events</a> introduced in this specification. The
+presence of a time observation for a given <a>instantaneous event</a> fixes the
+mapping of this <a>instantaneous event</a> to the timeline. The presence of time
+information in a provenance description instantiates the ordering constraint with
+that time information. It is expected that such instantiated
+constraint can help corroborate provenance information. We anticipate
+that verification algorithms could be developedm, though this
+verification is outside the scope of this specification.
+</p>
+
+<p>The following figure summarizes the ordering constraints in a
+graphical manner. For each subfigure, an event time line points to the
+right. Activities are represented by rectangles, whereas entities are
+represented by circles. Usage, generation and derivation are
+represented by the corresponding edges between entities and
+activities. The four kind of <a title="event">instantaneous events</a> are represented by vertical
+dotted lines (adjacent to the vertical sides of an activity's
+rectangle, or intersecting usage and generation edges). The ordering
+constraints are represented by triangles: an occurrence of a triangle between two <a title="event">instantaneous event</a> vertical dotted lines represents that the event denoted by the left
+line precedes the event denoted by the right line.</p>
+
+<div style="text-align: center;">
+<figure>
+<img src="images/constraints.png" alt="constraints between events" />
+<figcaption id="constraint-summary">Summary of <a title="event">instantaneous event</a> ordering constraints</figcaption>
+</figure>
+</div>
+
+
+<p>The mere existence of an activity entails some <a>event</a> ordering in the world, since an <a>activity start event</a> always <a>precedes</a> the corresponding <a>activity end
+event</a>. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (a) and expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
+
+<div class='interpretation' id='start-precedes-end'> The following ordering constraint holds for any activity: the
+<a title="activity start event">start event</a> <a>precedes</a> the <a title="activity end event">end event</a>.</div>
+
+<p> A usage and a generation for a given entity implies ordering of <a title="event">events</a> in the world, since the <a title="entity generation
+event">generation event</a> had to precede the <a title="entity usage event">usage event</a>. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (b) and expressed by constraint <a href="#generation-precedes-usage">generation-precedes-usage</a>.</p>
+
+<div class='interpretation' id='generation-precedes-usage'>For any entity, the following ordering constraint holds: the <a title="entity generation event">generation</a> of an entity always
+<a>precedes</a> any of its <a title="entity usage event">usages</a>.
+</div>
+
+<p>A usage implies ordering of <a title="event">events</a> in the world, since the <a title="entity usage event">usage event</a> had to occur during the associated activity. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (c) and expressed by constraint <a href="#usage-within-activity">usage-within-activity</a>.</p>
+
+<div class='interpretation' id='usage-within-activity'>Given an activity with identifier <span class="name">a</span>, an entity with identifier <span class="name">e</span>, a set
+of attribute-value pairs <span class="name">attrs</span>, and optional time <span class="name">t</span>, <span class='conditional'>if</span>
+ assertion <span class="name">used(a,e,attrs)</span> or <span class="name">used(a,e,attrs,t)</span> holds, <span class='conditional'>then</span> the following ordering constraint holds:
+ the <a title="entity usage event">usage</a> of the entity denoted by <span class="name">e</span> <a>precedes</a> the <a title="activity end event">end</a> of
+activity denoted by <span class="name">a</span> and <a>follows</a> its <a title="activity start event">start</a>.
+</div>
+
+
+
+<p>A generation implies ordering of <a title="event">events</a> in the world, since the <a title="entity generation event">generation event</a> had to occur during the associated activity. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (d) and expressed by constraint <a href="#generation-within-activity">generation-within-activity</a>.</p>
+
+<div class='interpretation' id='generation-within-activity'>Given an activity with identifier <span class="name">a</span>, an entity with identifier <span class="name">e</span>, a set
+of attribute-value pairs <span class="name">attrs</span>, and optional time <span class="name">t</span>, <span class='conditional'>if</span> <span class="name">wasGeneratedBy(e,a,attrs)</span> or <span
+class="name">wasGeneratedBy(e,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following ordering constraint also holds: the <a title="entity generation
+event">generation</a> of the entity denoted by <span class="name">e</span> <a>precedes</a> the <a title="activity end event">end</a>
+of activity <span class="name">a</span> and <a>follows</a> the <a title="activity start event">start</a> of <span class="name">a</span>.
+</div>
+
+
+
+
+<p>If there is a derivation between <span class="name">e2</span> and <span class="name">e1</span>, then
+this means that the entity <span class="name">e1</span> had some form of influence on the entity <span class="name">e2</span>; for this to be possible, some event ordering must be satisfied.
+First, we consider derivations, where the activity and usage are known. In that case, the <a title="entity usage event">usage</a> of <span class="name">e1</span> has to precede the <a title="entity generation
+event">generation</a> of <span class="name">e2</span>.
+This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (e) and expressed by constraint <a
+href="#derivation-usage-generation-ordering">derivation-usage-generation-ordering</a>.</p>
+
+
+<div class='interpretation' id='derivation-usage-generation-ordering'>Given an activity with identifier <span class="name">a</span>, entities with identifier <span
+class="name">e1</span> and <span class="name">e2</span>, a generation identified by <span class="name">g2</span>, and a usage identified by <span class="name">u1</span>, <span
+class='conditional'>if</span> <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
+ holds, <span class='conditional'>then</span>
+the following ordering constraint holds:
+the <a title="entity usage event">usage</a>
+of entity denoted by <span class="name">e1</span> <a>precedes</a> the <a title="entity generation event">generation</a> of
+the entity denoted by <span class="name">e2</span>.
+</div>
+
+<p>When the usage is unknown, a similar constraint exists, except that the constraint refers to its
+generation event, as
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (f) and expressed by constraint <a
+href="#derivation-generation-generation-ordering">derivation-generation-generation-ordering</a>.</p>
+
+<div class='interpretation' id='derivation-generation-generation-ordering'>
+Given two entities denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> <span
+class="name">wasDerivedFrom(e2,e1, attrs)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraint holds:
+the <a title="entity generation event">generation event</a> of the entity denoted by <span class="name">e1</span> <a>precedes</a> the <a title="entity generation event">generation event</a>
+of
+the entity denoted by <span class="name">e2</span>.
+ </div>
+
+<p>Note that event ordering is between generations of <span class="name">e1</span>
+and <span class="name">e2</span>, as opposed to derivation where usage is known,
+which implies ordering ordering between the usage of <span class="name">e1</span> and
+generation of <span class="name">e2</span>. </p>
+
+<p> Information flow ordering between two activities <span class="name">a1</span> and <span class="name">a2</span> also implies ordering of <a
+title="event">events</a> in the world, since some entity must have been generated by the former and used by the later, which implies that the start event of <span class="name">a1</span>
+cannot follow the end event of <span class="name">a2</span>. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (g) and expressed by constraint <a href="#wasInformedBy-ordering">wasInformedBy-ordering</a>.</p>
+
+<div class='interpretation' id='wasInformedBy-ordering'>
+Given two activities denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> <span
+class="name">wasInformedBy(a2,a1)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraint holds:
+the <a title="activity start event">start event</a> of the activity denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity end event">end event</a> of
+the activity denoted by <span class="name">a2</span>.
+</div>
+
+<p>Control flow ordering between two activities <span class="name">a1</span> and <span class="name">a2</span> also implies ordering of <a
+title="event">events</a> in the world, since <span class="name">a1</span> must have been active before <span class="name">a2</span> started. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (h) and expressed by constraint <a href="#wasStartedBy-ordering">wasStartedBy-ordering</a>.</p>
+
+
+<div class='interpretation' id='wasStartedBy-ordering'>
+Given two activities denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> <span
+class="name">wasStartedBy(a2,a1)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraint holds: the
+<a title="activity start event">start</a> event of the activity denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity start event">start event</a> of
+the activity denoted by <span class="name">a2</span>.
+</div>
+
+<div class='issue'>In the following, we assume that we can talk about the end of an entity (or agent)
+For this, we use the term 'destruction' This is <a href="http://www.w3.org/2011/prov/track/issues/204">ISSUE-204</a>.
+</div>
+
+
+<p>Further constraints appear in Figure <a href="#constraint-summary2">constraint-summary2</a> and are discussed below.</p>
+
+<div style="text-align: center;">
+<figure>
+<img src="images/constraints2.png" alt="further constraints between events" />
+<figcaption id="constraint-summary2">Summary of <a title="event">instantaneous event</a> ordering constraints (continued)</figcaption>
+</figure>
+</div>
+
+
+<p>An agent that started an activity must exist when the activity starts.
+This is
+illustrated by Subfigure <a href="#constraint-summary2">constraint-summary2</a> (a) and expressed by constraint <a href="#wasStartedByAgent-ordering">wasStartedByAgent-ordering</a>.</p>
+
+
+<div class='interpretation' id='wasStartedByAgent-ordering'>
+Given an activity denoted by <span class="name">a</span> and an agent denoted by <span class="name">ag</span>, <span class='conditional'>if</span> <span
+class="name">wasStartedBy(a,ag)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraints hold: the
+<a title="activity start event">start</a> event of the activity denoted by <span class="name">a</span> <a>follows</a> the <a title="entity generation event">generation event</a> for agent denoted by <span class="name">ag</span>, and
+<a>precedes</a> the destruction event of
+the same agent.
+</div>
+
+
+<p>An activity that was associated with an agent must have some overlap with the agent. The agent may be generated, or may only become associated with the activity, after its start: so, the agent is required to exist before the activity end. Likewise, the agent may be destructed, or may terminate its association with the activity, before the activity end: hence, the agent destruction is required to happen after the activity start.
+This is
+illustrated by Subfigure <a href="#constraint-summary2">constraint-summary2</a> (b) and expressed by constraint <a href="#wasAssociatedWith-ordering">wasAssociatedWith-ordering</a>.</p>
+
+
+<div class='interpretation' id='wasAssociatedWith-ordering'>
+Given an activity denoted by <span class="name">a</span> and an agent denoted by <span class="name">ag</span>, <span class='conditional'>if</span> <span
+class="name">wasAssociatedWith(a,ag)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraints hold: the
+<a title="activity start event">start</a> event of the activity denoted by <span class="name">a</span>
+precedes the destruction event of
+the agent denoted by <span class="name">ag</span>, and
+ the <a title="entity generation event">generation event</a> for agent denoted by <span class="name">ag</span>
+<a>precedes</a> the activity <a title="activity end event">end</a> event.
+</div>
+
+
+<div class="issue">
+For completeness, we should define ordering constraint for wasAssociatedWith and actedOnBehalfOf.
+For wasAssociatedWith(a,ag), it feels that ag must have some overlap with a.
+For actedOnBehalfOf(ag1,ag2,a), it seem that ag2 should have existed before the overlap between ag1 and a. This is <a href="http://www.w3.org/2011/prov/track/issues/221">ISSUE-221</a>.
+</div>
+
+
+<div class="issue">
+It is suggested that a stronger name for wasAssociatedWith should be adopted.
+This is <a href="http://www.w3.org/2011/prov/track/issues/182">ISSUE-182</a>.
+</div>
+
+</section>
+
+<section id="structural-constraints">
+<h3>PROV-DM Structural Constraints</h3>
+
+<p><a href="#definitional-constraints">Section 4</a> provides definitional constraints for data model concepts.
+<a href="#account-constraints">Section 5</a> introduces constraints on descriptions occurring in accounts.
+<a href="#interpretation">Section 6</a> defines an interpretation of this data model, in terms of event ordering
+constraints.
+This section introduces further constraints on the structure of PROV-DM descriptions. Descriptions that satisfy these constraints are said to be <dfn>structurally well-formed</dfn>. A
+benefit of structurally well-formed provenance descriptions is that further inferences can be made, because descriptions are more precise, and therefore, richer. </p>
+
+<p>According to the definition of a <a>generation</a>, an entity becomes available after this entity's generation event, and does not exist before this event. From this definition,
+we conclude that PROV-DM does not allow for an entity to have two generations occurring at two different instants.
+The rationale for this constraint is as follows.
+ Two distinct <a title="entity generation event">generation events</a> (by a same activity or by two distinct activities), occurring one after the other, necessarily create two distinct
+entities; otherwise, the second <a title="entity generation event">generation event</a> would have resulted in an entity that existed before its creation, which contradicts the definition of
+<a>generation</a>.</p>
+
+<p>So, PROV-DM allows for two distinct <a>generations</a> <span class="name">g1</span> and <span class="name">g2</span> referencing a same entity provided they occur
+<em>simultaneously</em>.
+<!-- (This means that <span class="name">g1</span> <a>precedes</a> <span class="name">g2</span> and <span class="name">g2</span> <a>precedes</a> <span class="name">g1</span>.) -->
+ In practice, for such a simultaneous generation to occur, the generation event has to be unique and caused by a <em>single world activity</em>, though provenance may contain
+several descriptions for the <em>same</em> world activity.
+</p>
+
+<div class="anexample">
+<p>
+In the following assertions, a workflow execution <span class="name">a0</span> consists of two sub-workflow executions <span class="name">a1</span> and <span class="name">a2</span>.
+Sub-workflow execution <span class="name">a2</span> generates entity <span class="name">e</span>, so does <span class="name">a0</span>.</p>
+<pre class="codeexample">
+activity(a0,,,[prov:type="workflow execution"])
+activity(a1,,,[prov:type="workflow execution"])
+activity(a2,,,[prov:type="workflow execution"])
+wasInformedBy(a2,a1)
+
+wasGeneratedBy(e,a0)
+wasGeneratedBy(e,a2)
+</pre>
+<p>So, we have two different <a title="generation">generations</a> for entity <span class="name">e</span>. Such an example is permitted in PROV-DM if the two activities denoted by <span class="name">a0</span> and <span class="name">a2</span> are a single thing happening in the world
+but described from different perspectives.</p>
+</div>
+
+<p>While this example is permitted in PROV-DM, it does not make the inter-relation between activities explicit, and it mixes descriptions expressed from different perspectives together.
+While this may acceptable in some specific applications, it becomes challenging for inter-operability. Indeed, PROV-DM does not offer any relation describing the structure of activities.
+ Such descriptions are said not be structurally well-formed.</p>
+
+<p>Structurally well-formed provenance can be obtained by partitioning the generations into different accounts. This makes it clear that these generations provide alternative
+descriptions of the same real-world generation event, rather than describing two distinct generation events for the same entity. When accounts are used, the example can be encoded as follows.</p>
+
+
+<div class="anexample">
+<p>
+The same example is now revisited, with the following assertions that are structurally well-formed. Two accounts are introduced, and there is a single generation for entity <span
+class="name">e</span> per account.</p>
+
+<p>In a first account, entitled "summary", we find:</p>
+<pre class="codeexample">
+ activity(a0,t1,t2,[prov:type="workflow execution"])
+ wasGeneratedBy(e,a0)
+</pre>
+<p>In a second account, entitled "detail", we find:</p>
+<pre class="codeexample">
+ activity(a1,t1,t3,[prov:type="workflow execution"])
+ activity(a2,t3,t2,[prov:type="workflow execution"])
+ wasInformedBy(a2,a1)
+ wasGeneratedBy(e,a2)
+</pre>
+</div>
+
+
+
+<p>Structurally well-formed provenance satisfies some constraints, which force the structure of descriptions to be exposed by means of accounts. With these constraints satisfied, further
+inferences can be made about structurally well-formed descriptons.
+The uniqueness of generations in accounts is formulated as follows.
+</p>
+
+<div class='constraint' id='generation-uniqueness'>Given an entity denoted by <span class="name">e</span>, two activities denoted by <span class="name">a1</span> and <span
+class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
+<span class='conditional'>if</span> <span class="name">wasGeneratedBy(id1,e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(id2,e,a2,attrs2)</span> exist in the scope of a given
+account,
+<span class='conditional'>then</span> <span class="name">id1</span>=<span class="name">id2</span>, <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
+</div>
+
+
+
+
+
+
+<p>A further inference is permitted from derivations with an explicit activity and no usage: </p>
+<div class='inference' id='derivation-use'>
+<p>Given an activity <span class="name">a</span>, entities denoted by <span class="name">e1</span> and <span class="name">e2</span>, and sets of attribute-value
+pairs <span class="name">dAttrs</span>, <span class="name">gAttrs</span>,
+<span class='conditional'>if</span> <span class="name">wasDerivedFrom(e2,e1, a, dAttrs)</span> and <span class="name">wasGeneratedBy(e2,a,gAttrs)</span> hold, <span
+class='conditional'>then</span> <span class="name">used(a,e1,uAttrs)</span> also holds
+for some set of attribute-value pairs <span class="name">uAttrs</span>.
+</div>
+<p>This inference is justified by the fact that the entity denoted by <span class="name">e2</span> is generated by at most one activity in a given account
+(see <a href="#generation-uniqueness">generation-uniqueness</a>). Hence, this activity is also the one referred to by the usage of <span class="name">e1</span>.
+</p>
+
+
+<p>We note that the converse inference, does not hold.
+From <span class="name">wasDerivedFrom(e2,e1)</span> and <span class="name">used(a,e1)</span>, one cannot
+derive <span class="name">wasGeneratedBy(e2,a,attrs2)</span> because identifier <span class="name">e1</span> may occur in usages performed by many activities, which may have not generated the entity denoted by <span class="name">e2</span>.</p>
+
+
+<p>
+An account is said to be structurally well-formed if
+it satisfies the constraint <a href="#generation-uniqueness">generation-uniqueness</a>. If an account is structurally well-formed, it support the inference <a
+href="#derivation-use">derivation-use</a>.</p>
+
+<p> Taking the union of two accounts is another account,
+formed by the union of the descriptions they respectively contain. We note that the resulting union may or may not invalidate some constraints:
+<ul>
+<li> Two entity descriptions with a same identifier but different sets of attributes exist in each original account may invalidate <a href="#unique-description-in-account">unique-description-in-account</a> in the union, unless some form of description merging or renaming (as per <a href="#merge-with-rename">Example</a>) occurs.
+<li> Structurally 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. </li>
+</ul>
+<p>How to reconcile such accounts is beyond the scope of this specification.</p>
+
+<!--
+Indeed, let us reconsider example <a href="#account-example-1">account-example-1</a>, and let us define another account record as follows.</p>
+
+<div class="anexample">
+<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>
+-->
+
+<div class="note">
+Can the semantics characterize better what can be achieved with structurally well-formed accounts?
+</div>
+
+
+<div class="note" id="note-related-to-issue-105">
+Satya discussed the example of a sculpture, whose hand and leg are sculpted independently by two different sculptors. He suggested that the sculpture is generated by two distinct activities.
+This section explains that it is not the case. The example can be formulated as follows.
+
+<p><a href="examples/sculpture.pn">Sculpture example in PROV-N</a></p>
+
+<p><a href="examples/sculpture.png">Sculpture example image</a></p>
+
+<p>
+We see that ex:s_3 (the sculpture in its final state) was derived from ex:l_2 (containment) which was generated by ex:a2. However, ex:s_3 is not directly generated by ex:a2. We may want to
+consider an abbreviation for this: wasGeneratedBy*(ex:s_3,ex:a2).</p>
+</div>
+
+</section>
+
+
+
+
+
+<section id="collection-constraints">
+<h3>PROV-DM Collection Constraints</h3>
+
+<div class='note'>
+Edited by PM --- TBC
+</div>
+
+
+<div class='constraint' id='collection-parallel-insertions'>
+<p>One can have multiple assertions regarding the state of a collection following a <em>set</em> of insertions, for example:</p>
+<pre class="codeexample">
+CollectionAfterInsertion(c2, c1, k1, v1)
+CollectionAfterInsertion(c2, c1, k2, v2)
+...
+</pre>
+<p>This is interpreted as <em>" <span class="name">c2</span> is the state that results from inserting <span class="name">(k1, v1)</span>, <span class="name">(k2, v2)</span> etc. into <span class="name">c1</span>"</em></p>
+</div>
+
+<div class='note'>
+Shouldn't we have the same for deletion, and combination of insertion and deletion?
+</div>
+
+
+<div class='constraint' id='collection-branching-derivations'>
+It is possible to have multiple derivations from a single root collection, as shown in the following example.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="EmptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+ entity(v3)
+ entity(c1, [prov:type="Collection"])
+ entity(c2, [prov:type="Collection"])
+ entity(c3, [prov:type="Collection"])
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 = { (k1,v1) }
+ CollectionAfterInsertion(c2, c, k2, v2) // c2 = { (k2 v2) }
+ CollectionAfterInsertion(c3, c1, k3,v3) // c3 = { (k1,v1), (k3,v3) }
+</pre>
+</div>
+</div>
+
+
+
+
+
+
+<div class='constraint' id='collection-unique-ancestor'>
+Given the pair of assertions:
+<pre class="codeexample">
+CollectionAfterInsertion(c, c1, k1, v1)
+CollectionAfterInsertion(c, c2, k2, v2)
+</pre>
+it follows that <span class="name">c1==c2</span>.
+</div>
+
+<div class='note'>
+Original text stated it follows that <span class="name">c1==c2, k1==k2, v1==v2</span>, because one cannot have two different derivations for the same final collection state. This is incompatible with parallel insertion constraint.
+</div>
+
+
+<div class='note'>
+Shouldn't we have the same for deletion, and combination of insertion and deletion?
+</div>
+
+
+
+
+<div class='constraint' id='collection-unique-value-for-key'>
+Given the following set of insertions:
+<pre class="codeexample">
+CollectionAfterInsertion(c1, c, k, v1)
+CollectionAfterInsertion(c1, c, k, v2)
+</pre>
+it follows that <span class="name">v1==v2</span>.
+</div>
+
+
+<p>The state of a collection is only known to the extent that a chain of derivations starting from an empty collection can be found. Since a set of assertions regarding a collection's evolution may be incomplete, so is the reconstructed state obtained by querying those assertions. In general, all assertions reflect the asserter's partial knowledge of a sequence of data transformation events. In the particular case of collection evolution, in which the asserter <em>knows</em> that some of the state changes may have been missed, then the more generic <a href="#Derivation-Relation">derivation</a> relation should be used to signal that some updates may have occurred, which cannot be precisely asserted as insertions or removals. The following two examples illustrate this.</p>
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="collection"]) // e is a collection, possibly not empty
+ entity(v1)
+ entity(v2, [prov:type="collection"]) // v2 is a collection
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 <em>includes</em> { (k1,v1) } but may contain additional unknown pairs
+ CollectionAfterInsertion(c2, c1, k2, v2) // c2 includes { (k1,v1), (k2 v2) } where v2 is a collection with unknown state
+</pre>
+</div>
+ In the example, the state of <span class="name">c2</span> is only partially known because the collection is constructed from partially known other collections.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="emptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 = { (k1,v1) }
+ wasDerivedFrom(c2, c1) // the asserted knows that c2 is somehow derived from c1, but cannot assert the precise sequence of updates
+ CollectionAfterInsertion(c3, c2, k2, v2)
+</pre>
+
+<p>Here <span class="name">c3</span> includes <span class="name">{ (k2 v2) }</span> but the earlier "gap" leaves uncertainty regarding <span class="name">(k1,v1)</span> (it may have been removed) or any other pair that may have been added as part of the derivation activities.</p>
+</div>
+
+</section>
+
+
+<!--
+<section id="resource-section">
+<h2>Resources, URIs, Entities, Identifiers, and Scope</h2>
+
+<p>This specification introduces the notion of an identifiable entity in the world. In PROV-DM, an entity record is a representation of such an identifiable entity. An entity record
+includes an identifier identifying this entity. Identifiers are qualified names, which can be mapped to IRIs. </p>
+
+<p>The term 'resource' is used in a general sense
+ for whatever might be identified by a URI [[!RFC3986]]. On the Web, a URI denotes a resource, without any expectation that the resource is accessed. </p>
+
+<p>The purpose of this section is to clarify the relationship between resource and the notions of entity and entity record. </p>
+
+<p>In the context of PROV-DM, a resource is just a thing in the world. One may take multiple perspectives on such a thing and its situation in the world, fixing some its aspects.</p>
+
+<p> We refer to the <a href="#a-report-example">example</a> of section <a href="#conceptualization">2.1</a> for a resource (at some URL) and three different perspectives, referred to as
+entities. Three different entity records can be expressed for this report, which in the PROV-N sample below, are expressed within a same account.
+</p>
+
+<pre>
+container
+prefix app http://example.org/app/
+prefix cr http://example.org/crime/
+
+ account(acc1,
+ http://example.org/asserter1,
+
+ entity(app:0, [ prov:type="Document", cr:path="http://example.org/crime.txt" ])
+ entity(app:1, [ prov:type="Document", cr:path="http://example.org/crime.txt", cr:version="2.1", cr:content="...", cr:date="2011-10-07" ])
+ entity(app:2, [ prov:type="Document", cr:author="John" ])
+ ...)
+endContainer
+</pre>
+
+<p>Each entity record contains an identifier that is unique in
+account <span class="name">acc1</span>, and therefore locally
+identifies the entity record it is contained in. In this example,
+three identifiers were minted.</p>
+
+<p>Given that the report is a resource denoted by the URI <span class="name">http://example.org/crime.txt</span>, we could simply use this URI as the identifier of an entity. This would
+avoid us minting new URIs. Hence, the report URI would play a double role: as a URI it denotes a resource accessible at that URI, and as an identifier in a PROV-DM record, it helps identify
+a specific characterization of this report. A given identifier occurring in an entity record must be unique within the scope of an account. Hence, below, all entities records have been given
+the same identifier but appear in the scope of different accounts, so as to satisfy <a href="#identifiable-term-in-account">identifiable-term-in-account</a>.</p>
+
+<pre>
+container
+prefix app http://example.org/
+prefix cr http://example.org/crime/
+
+ account(acc2,
+ http://example.org/asserter1,
+
+ entity(app:crime.txt, [ prov:type="Document", cr:path="http://example.org/crime.txt" ])
+ ...)
+
+ account(acc3,
+ http://example.org/asserter1,
+
+ entity(app:crime.txt, [ prov:type="Document", cr:path="http://example.org/crime.txt", cr:version="2.1", cr:content="...", cr:date="2011-10-07" ])
+ ...)
+
+ account(acc4,
+ http://example.org/asserter1,
+ entity(app:crime.txt, [ prov:type="Document", cr:author="John" ])
+ ...)
+endContainer
+</pre>
+
+<p>In this case, the qualified name <span class="name">app:crime.txt</span> maps to URI <span class="name">http://example.org/crime.txt</span> still denotes the same resource; however, the
+perspectives we take about that resource are expressed by multiple entity records, happening to all contain the same identifier but in different accounts. </p>
+
+<p> Alternatively, if we need to assert the existence of two different perspectives on the report within the same account, then alternate identifiers MUST be used, one of them being allowed
+to be the resource URI.</p>
+
+<pre>
+container
+ prefix app http://example.org/
+ prefix app2 http://example.org/app/
+ prefix cr http://example.org/crime/
+
+ account(acc5,
+ http://example.org/asserter1,
+
+ entity(app:crime.txt, [ prov:type="Document", cr:path="http://example.org/crime.txt" ])
+ entity(app2:1, [ prov:type="Document", cr:path="http://example.org/crime.txt", cr:version="2.1", cr:content="...", cr:date="2011-10-07" ])
+
+ ...)
+endContainer
+
+</pre>
+
+
+</section>
+
+-->
+
+<!--
+<li>For use, generation, and derivation event, the first argument is the 'effect' (i.e. most recent item) and the second argument is the 'cause' (i.e. least recent item). This order is
+compatible with the temporal layout of the graphical notation.
+-->
+
+<section id="refining-provenance-descriptions">
+<h3>Refining Provenance Descriptions</h3>
+
+<div class='note'>Purely tentative</div>
+
+<p>In this section, we successively review refined provenance descriptions, and examine their meaning, in light of the constraints introduced in this specification. </p>
+
+
+<ol>
+<li>First, let us consider a small set of three descriptions, including an entity, an agent, and an attribution relation.
+<pre>
+entity(tr:prov-dm)
+agent(w3:Consortium)
+wasAttributedTo(tr:prov-dm,w3:Consortium)
+</pre>
+<p>The entity denoted by <span class="name">tr:prov-dm</span> does not contain any attribute besides its identifier. Without any further detail, this entity is simply the resource denoted by <span class="name">tr:prov-dm</span>, whatever its state over time. This resource has multiple versions including <span class="name">tr:WD-prov-dm-20111215</span> and <span class="name">tr:WD-prov-dm-20111018</span>.
+Likewise, the second line simply is a description for a resource denoted by <span class="name">w3:Consortium</span>, nothing less, nothing more.</p>
+<p>The third description should be interpreted as: whatever changes entity <span class="name">tr:prov-dm</span> may have gone through, it is always attributed to the <span class="name">w3:Consortium</span> agent.</p>
+</li>
+
+
+<li>Second, the descriptions are bundled up as an account with name <span class="name">ex:acc1</span>:
+<pre>
+entity(tr:prov-dm)
+agent(ex:Simon)
+wasAttributedTo(tr:prov-dm,ex:Simon)
+</pre>
+and provenance details are available for <span class="name">ex:acc1</span>, namely the generation time for the provenance.
+<pre>
+entity(ex:acc1, [prov:type="AccountEntity"])
+wasGeneratedBy(ex:acc1,,2011-12-15T12:00:00)
+</pre>
+<div class='note'>
+What is the meaning here? Is it any different? Are stating anything about newer version of tr:prov-dm that occur after 2011-12-15T12:00:00?
+</div>
+
+<li> A generation event for <span class="name">tr:prov-dm</span> is provided.
+<pre>
+entity(tr:prov-dm)
+agent(ex:Simon)
+wasGeneratedBy(tr:prov-dm,,2011-12-15T12:00:00)
+wasAttributedTo(tr:prov-dm,ex:Simon)
+</pre>
+<div class='note'>
+What is the meaning here? that only the version that was created by this event is attributed to ex:Simon, but not previous ones. This means that it is not specfied whether he was an author in anterior versions.
+</div>
+
+</li>
+
+
+<li> A destruction event for <span class="name">tr:prov-dm</span> is provided.
+<pre>
+entity(tr:prov-dm)
+agent(ex:Simon)
+wasGeneratedBy(tr:prov-dm,,2011-12-15T12:00:00)
+wasDestroyedBy(tr:prov-dm,,2012-02-02T12:00:00)
+wasAttributedTo(tr:prov-dm,ex:Simon)
+</pre>
+<div class='note'>
+Speculative, since we have not defined the destruction event (yet?.
+What is the meaning here? that only the versions that existed during this characterization interval were attributed to ex:Simon.
+</div>
+</li>
+
+</ol>
+
+</section>
+
+<!--
+<section>
+<h3>Stuff to Keep, Maybe?</h3>
+
+
+
+
+<li id='attribute-occurrence-in-entity-record'>The attributes
+occurring in an entity record MUST be declared in the namespace
+referred to by their prefix according to
+<a href="#term-attribute">Section term-attribute</a>. Furthermore,
+for each attribute, a namespace also declares the number of
+occurrences it may have in a list of attributes. An entity record is
+valid if the number of occurrences of any of its attributes is
+compatible with this attribute's declaration it its namespace. This
+property applies to all types of records, and is referred to
+as <a>attribute occurrence validity</a>.</li>
+
+
+</section>
+-->
+
+<section class="appendix">
+ <h2>Acknowledgements</h2>
+ <p>
+ WG membership to be listed here.
+ </p>
+ </section>
+
+ </body></html>