--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/WD-prov-dm-20111215/ProvenanceModel.html Fri Dec 09 09:01:11 2011 +0000
@@ -0,0 +1,3328 @@
+<!DOCTYPE html>
+
+<html><head>
+ <title>The PROV Data Model and Abstract Syntax Notation</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-SEMANTICS":
+ "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 "+
+ "<a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html\"><cite>Prov Model Primer</cite></a>. "+
+ "2011, Work in progress. "+
+ "URL: <a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html\">http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html</a>",
+
+ "PROV-O":
+ "Satya Sahoo and Deborah McGuinness "+
+ "<a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html\"><cite>Provenance Formal Model</cite></a>. "+
+ "2011, Work in progress. "+
+ "URL: <a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html\">http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html</a>",
+
+ "PROV-PAQ":
+ "Graham Klyne and Paul Groth "+
+ "<a href=\"http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html\"><cite>Provenance Access and Query</cite></a>. "+
+ "2011, Work in progress. "+
+ "URL: <a href=\"http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html\">http://dvcs.w3.org/hg/prov/tip/paq/provenance-access.html</a>",
+ };
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "WD",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "prov-dm",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "Initial draft for internal discussion",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2011-10-18",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ previousPublishDate: "2011-10-18",
+ previousMaturity: "FPWD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.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: [
+ { name: "Khalid Belhajjame", url: "http://semanticweb.org/wiki/Khalid_Belhajjame",
+ company: "University of Manchester" },
+ { name: "Stephen Cresswell",
+ company: "legislation.gov.uk"},
+ { name: "Yolanda Gil",
+ company: "Invited Expert", url:"http://www.isi.edu/~gil/"},
+ { name: "Ryan Golden",
+ company: "Oracle Corporation" },
+ { name: "Paul Groth", url: "http://www.few.vu.nl/~pgroth/",
+ company: "VU University of Amsterdam" },
+ { name: "Graham Klyne",
+ company: "University of Oxford" },
+ { name: "Jim McCusker", url: "http://tw.rpi.edu/web/person/JamesMcCusker",
+ company: "Rensselaer Polytechnic Institute" },
+ { name: "Simon Miles",
+ company: "Invited Expert", url:"http://www.inf.kcl.ac.uk/staff/simonm/" },
+ { name: "James Myers", url:"http://www.rpi.edu/research/ccni/",
+ company: "Rensselaer Polytechnic Institute"},
+ { name: "Satya Sahoo", url:"http://cci.case.edu/cci/index.php/Satya_Sahoo",
+ company: "Case Western Reserve University" },
+ ],
+
+ // 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 for building
+representations of the entities, people and activities involved in
+producing a piece of data or thing in the world. PROV-DM is
+domain-agnotisc, but with well-defined extensibility points allowing
+further domain-specific and application-specific extensions to be
+defined. It is accompanied by PROV-ASN, a technology-independent
+abstract syntax notation, which allows serializations of PROV-DM
+instances to be created for human consumption, which facilitates its
+mapping to concrete syntax, and which is used as the basis for a
+formal semantics.
+</p>
+ </section>
+
+<section id="sotd">
+<em>TODO: update this section for next publication.</em>
+This document is part of a set of specifications aiming to define the various aspects that are necessary to achieve the visition on 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. Three other documents are: 1) a normative serialization of PROV-DM in RDF, specified by means of a mapping to the OWL2 Web Ontology Language; 2)
+the mechanisms for accessing and querying provenance; 3) a primer for the provenance data model.
+</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>
+ <h2>Introduction<br>
+</h2>
+
+<p>
+For the purpose of this specification, 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.
+In particular, the provenance of information is crucial in deciding
+whether information is to be trusted, how it should be integrated with
+other diverse information sources, and how to give credit to its
+originators when reusing it. In an open and inclusive environment
+such as the Web, users find information that is often contradictory or
+questionable: provenance can help those users to make trust judgments.
+</p>
+
+
+<p>
+The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
+Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it, process it, and reason over it.</p>
+
+<p>Thus, the vision is that different provenance-aware systems natively adopt their own model for representing their provenance, but a core provenance data model can be readily adopted as a provenance <em>interchange</em> model across such systems.</p>
+
+<p>A set of specifications define the various aspects
+that are necessary to achieve this vision in an inter-operable
+way, the first of which is contained in this document:</p>
+<ul>
+<li> The PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption; </li>
+<li> 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> The mechanisms for accessing and querying provenance [[PROV-PAQ]];</li>
+<li> A Primer for the PROV approach [[PROV-PRIMER]].</li>
+</ul>
+
+
+<p>
+The PROV-DM data model for provenance consists of a set of core
+concepts, and a few common relations, based on these core concepts. PROV-DM is a domain-agnotisc model, but with well-defined extensibility points allowing further domain-specific and application-specific extensions to be defined.</p>
+
+<p>This specification also introduces
+PROV-ASN, an abstract syntax that is primarily aimed at human consumption. PROV-ASN allows
+serializations of PROV-DM instances to be written in a technology independent manner,
+it facilitates its mapping to concrete syntax, and it is used as the basis for a
+formal semantics. This specification uses instances of provenance written in PROV-ASN
+to illustrate the data model.
+</p>
+
+ <section>
+<h3>Structure of this Document</h3>
+
+<p>In <a href="#preliminaries">section 2</a>, a set of preliminaries are introduced, including concepts that underpin PROV-DM and motivations for the PROV-ASN notation.</p>
+
+<p><a href="#prov-dm-overview">Section 3</a> provides an overview of PROV-DM listing its core types and their relations.</p>
+
+<p>In <a href="#prov-dm-example">section 4</a>, PROV-DM is
+applied to a short scenario, encoded in PROV-ASN, and illustrated
+graphically.</p>
+
+<p><a href="#data-model-concepts">Section 5</a> provides the normative definition of PROV-DM and the notation PROV-ASN.</p>
+
+<p><a href="#common-relations">Section 6</a> introduces common relations used in PROV-DM, including relations for data collections and common domain-independent common relations.</p>
+
+<p><a href="#extensibility-section">Section 7</a> summarizes PROV-DM extensibility points.</p>
+
+<p><a href="#resource-section">Section 8</a> discusses how PROV-DM can be applied to the notion of resource.</p>
+
+
+ </section>
+
+<section id="prov-dm-namespace">
+ <h3>PROV-DM Namespace</h3>
+
+
+<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
+
+<p> All the elements, relations, reserved names and attributes introduced in this specification belong to the PROV-DM namespace.</p>
+
+<div class="note">
+There is a desire to use a single namespace that all specs can share to refer to common provenance terms.
+</div>
+
+</section>
+
+
+ <section>
+<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='preliminaries'>
+<h2>Preliminaries</h2>
+
+ <section id='conceptualization'>
+<h3>A Conceptualization of the World</h3>
+
+
+
+ <section id='section-entity-activity-agent'>
+<h4>Entity, Activity, Agent</h4>
+
+
+
+
+<p>This specification is based on a conceptualization of the world
+that is described in this section. In the world (whether real or not),
+there are things, which can be physical, digital, conceptual, or
+otherwise, and activities involving things. </p>
+
+<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>Hence, to accommodate different perspectives on things and their situation in the world as perceived by us, we introduce the idea of a characterized thing, which refers to a thing and its situation in the world, as characterized by someone. We then define an <dfn id="concept-entity">entity</dfn> as an identifiable characterized thing. An entity <em>fixes some aspects</em> of a thing and its situation in the world, so that it becomes possible to express its provenance, and what causes these specific aspects to be as such. An alternative entity may fix other aspects, and its provenance may be different.</p>
+
+<div class="anexample">
+Different users may take different perspectives on a resource with
+a URL. These perspectives in this conceptualization of the world are
+referred to as entities. Three such entities may be
+expressed:
+<ul>
+<li>a report available at 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 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>
+
+<!--
+<div class='paolo'>can we follow through from the example. thare three perspectives, possibly by just one observer or multiple ones. but <strong>why is it so important for reporting provenance</strong> that this distinction is made? I feel we need to connect this approach to provenance recording strongly and right away</div>
+-->
+
+<p>We do not assume that any characterization is more important than any other, and in fact, it is possible to describe the processing that occurred for the report to be commissioned, for individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity that characterizes the report appropriately.</p>
+
+<p>In the world, <dfn id="concept-activity">activities</dfn> involve
+entities in multiple ways: they consume them, they process them, they
+transform them, they modify them, they change them, they relocate
+them, they use them, they generate them, they are controlled by them,
+etc.</p>
+
+
+<p>An <dfn id="concept-agent">agent</dfn> is a type of entity that takes an active role in an activity such that it can be assigned some degree of responsibility for the activity taking place.
+This definition intentionally stays away from using concepts such as enabling, causing, initiating, affecting, etc, because any entities also enable, cause, initiate, and affect in some way the activities. So the notion of having some degree of responsibility is really what makes an agent. </p>
+
+<p> Even software agents can be assigned some responsibility for the effects they have in the world, so for example if one is using a Text Editor and one's laptop crashes, then one would say that the Text Editor was responsible for crashing the laptop. If one invokes a service to buy a book, that service can be considered responsible for drawing funds from one's bank to make the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well). So when someone models software as an agent for an activity in our model, they mean the agent has some responsibility for that activity.
+</p>
+<p> In this specification, the qualifier 'identifiable' is implicit whenever a reference is made to an activity, agent, or an entity.</p>
+
+</section>
+
+
+ <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 in 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 instantaneous event, 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>
+<h4>Types of Events</h4>
+
+<p>Four kinds of events 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>event</a> that marks the final instant of an entity's creation timespan, after which it becomes available for use.</p>
+
+<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a>event</a> that marks the first instant of an entity's consumption timespan by an activity.</p>
+
+<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a>event</a> that marks the instant an activity starts.</p>
+
+<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a>event</a> that marks the instant an activity ends.</p>
+
+</section>
+
+<section>
+<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">events</a>,
+without using physical clocks. This specification assumes that a partial order exists between <a title="event">events</a>.
+</p>
+
+
+<p>Specifically, <dfn id="dfn-follows">follows</dfn> is a partial
+order between <a title="event">events</a>, indicating that an <a>event</a> occurs after another.
+For symmetry, <dfn id="dfn-precedes">precedes</dfn> is defined as
+the inverse of follows. </p>
+
+
+<p> How such partial order is realized in practice is beyond the scope
+of this specification. This specification only assumes that
+each <a>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 to derive <a>event</a> ordering constraints from
+provenance records. According to such temporal interpretation,
+provenance records MUST satisfy such constraints. We note that the
+actual verification of such temporal constraints is also outside the
+scope of this specification. </p>
+
+<p>PROV-DM also allows for time observations to be inserted in specific
+provenance records, for each recognized <a>event</a> introduced
+in this specification. The presence of a time observation for a
+given <a>event</a> fixes the mapping of this <a>event</a> to the
+timeline. It can also help with the verification of associated
+temporal constraints (though, again, this verification is outside the
+scope of this specfication).
+
+</p>
+
+
+
+</section>
+
+ </section>
+
+ </section>
+
+ <section>
+<h3>PROV-ASN: The Provenance Abstract Syntax Notation</h3>
+
+<p>This specification defines PROV-DM, a data model for provenance, consisting of records describing how people, entities, and activities, were involved in producing,
+influencing, or delivering a piece of data or a thing in the world.</p>
+
+<p>This specification also relies on a language, PROV-ASN, the Provenance Abstract Syntax Notation, to express
+<em>instances</em> of that data model.
+For each construct of PROV-DM, a corresponding ASN expression is introduced, by way of a production in the ASN grammar. </p>
+
+
+
+
+
+<p>PROV-ASN is an abstract syntax, whose goals are:
+<ul>
+<li>to allow serializations of PROV-DM instances in a technology independent manner, which makes it more readable for human consumption;
+<li>to facilitate the mapping of PROV-DM to concrete syntax;
+<li>to provide the basis for a formal semantics.
+</ul>
+
+<p>This specification provides a grammar for PROV-ASN. Each record of the PROV-DM data model is explained
+in terms of the production of this grammar.</p>
+
+
+
+<p>The formal semantics of PROV-DM is defined at
+[[PROV-SEMANTICS]] and its encoding in the OWL2 Web Ontology Language at [[PROV-O]].
+</p>
+
+
+
+
+
+
+ </section>
+
+ <section>
+<h3>Representation, Assertion, and Inference</h3>
+
+<p>
+PROV-DM is a provenance data model designed to express <em>representations</em> of the world.
+</p>
+
+<div class="anexample">
+A file at some point during its lifecycle, which includes multiple edits by multiple people, can be represented by its location in the file system, a creator, and content.
+</div>
+
+
+<p>
+These representations are relative to an asserter, and in that sense constitute assertions stating properties of the world, as represented by an asserter. Different asserters will normally contribute different representations.
+This specification does not define a notion of consistency between different sets of assertions (whether by the same asserter or different asserters).
+The data model provides the means to associate attribution to assertions.
+</p>
+
+<div class="anexample">
+An alternative representation of the above file is a set of blocks in a hard disk.
+</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 assertions SHOULD be interpreted as a record of what has happened, as opposed to what may or will happen.</p>
+
+
+
+<p>
+This specification does not prescribe the means by which an asserter arrives at assertions; for example, assertions can be composed on the basis of observations, reasoning, or any other means.
+</p>
+
+
+<p>
+Sometimes, inferences about the world can be made from representations
+conformant to the PROV-DM data model. When this is the case, this
+specification defines such inferences, allowing new provenance records
+to be inferred from existing ones. Hence, representations of the world
+can result either from direct assertions by asserters or from
+application of inferences defined by this specification.
+</p>
+
+
+
+</section>
+ <section>
+<h3>Grammar Notation</h3>
+
+<p>This specification includes a grammar for PROV-ASN expressed using the Extended Backus-Naur Form (EBNF) notation.</p>
+
+<div class="grammar">
+<p> Each rule in the grammar defines one symbol, in the form:</p>
+<p>
+<span class="nonterminal">E</span> ::= <em>expression</em>
+</p>
+
+
+Within the expression on the right-hand side ofa rule, the follwoing expressions are used to match strings of one or more characters:
+<ul>
+<li>
+<span class="nonterminal">E</span>: matches term satisfying rule for symbol E.
+</li>
+
+<li>
+<span class="name">abc</span>: matches the literal string inside the single quotes.
+</li>
+
+
+<li>
+<span class="optional"><em>expression</em></span>: matches <em>expression</em> or nothing; optional <em>expression</em>.
+</li>
+
+<li>
+<span class="plus"><em>expression</em></span>: matches one or more occurrences of <em>expression</em>.
+</li>
+
+<li>
+<span class="star"><em>expression</em></span>: matches zero or more occurrences of <em>expression</em>.
+</li>
+
+</ul>
+</div>
+
+</section>
+</section>
+
+ <section id="prov-dm-overview">
+<h2>PROV-DM: An Overview </h2>
+
+<p>
+The following ER diagram provides a high level overview of the <strong>structure of PROV-DM records</strong>. Examples of provenance assertions that conform to this schema are provided in the next section.</p>
+
+<div style="text-align: center;">
+ <img src="overview.png" alt="PROV-DM overview"/>
+</div>
+
+<div class="note"> Overview diagram does not represent the sub-relations -- proposal to use a UML notation instead of ER.</div>
+
+
+<p>The model includes the following elements:</p>
+<ul>
+ <li>An <a title="entity record">Entity Record</a> (noted <samp>entity</samp> in the diagram, to reflect the term used in the ASN) is a representation of an <em>entity</em>.
+
+ <li>An <a title="activity record">Activity Record</a>(noted <samp>activity</samp> in the diagram) represents an activity that has an effect on entities, namely it either <em>generates</em> or <em>uses</em> one or more entities. Usage and generation are modelled by means of the <a title="usage record">used</a> and the <a title="generation record">wasGeneratedBy</a> relationships. Activities may include not only computations, but also any other type of activity that can be described in terms of their effect on <samp>entities</samp>.
+Note that multiple <samp>activities</samp> may <em>use</em> the same <samp>entity</samp>, and each activity may use multiple <samp>entities</samp>. Finally, entities can be derived from other entities, and this is specified using the <a title="derivation record">wasDerivedFrom</a> relation.</li>
+
+ <li>An <a title="agent record">Agent Record</a> represents a particular <samp>entity</samp> that can be associated to activities, meaning that it can be assigned some degree of responsibility for an <samp>activity</samp> taking place.
+ Agents have a rather generic connotation: their association with an activity is represented by the <a title="activity association record">wasAssociatedWith</a> relationship, which can take up various meanings (attribution, responsibility, supervision, management, etc.), which are not individually specified in the model. Relations <a title="start record">wasStartedBy</a> and <a title="end record">wasEndedBy</a> are specializations of <a title="activity association record">wasAssociatedWith</a> that can optionally be used to carry additional meaning. Furthermore, it is recognized that agents can act on behalf of others: hence, the relation <a title="responsibility record">actedOnBehalfOf</a> allows for chains of responsibility to be stated.
+</li>
+
+
+
+</ul>
+
+<p> A set of attribute-value pairs can be associated to elements and relations of the PROV model in order to further characterize
+their nature.
+The <a title="complementarity record">wasComplementOf</a> relationship is used to denote that two <samp>entities</samp> <em>complement</em> each other, in the sense that they each represent a partial, but mutually compatible characterization of the same thing.
+The attributes <a title="prov:role">role</a> and <a title="prov:type">type</a> are pre-defined.
+</p>
+
+
+<p>The set of relations presented here forms a core, which is further extended with additional relations, defined in Section <a href="#common-relations">Common Relations</a>.</p>
+
+
+<p>
+The model includes a further additional element: <a title="note record">notes</a>. These are also structured as sets of attribute-value pairs. Notes are used to provide additional, "free-form" information regarding <em>any</em> identifiable construct of the model, with no prescribed meaning. Notes are described in detail <a href="#record-note">here</a>.
+</p>
+
+<p>
+Attributes and notes are the main <em>extensibility points</em> in the model: individual interest groups are expected to extend PROV-DM by introducing new attributes and notes as needed to address applications-specific provenance modelling requirements. </p>
+
+</section>
+
+
+ <section class="informative" id="prov-dm-example">
+<h2>Example</h2>
+
+<div class='issue'> There is a suggestion that a better example should be adopted for this document. Possibly, several shorter examples. This is <a href="http://www.w3.org/2011/prov/track/issues/132">ISSUE-132</a></div>
+
+
+To illustrate PROV-DM, this section presents an example encoded according to PROV-ASN. For more detailed explanations of how PROV-DM should be used, and for more examples, we refer the reader to the Provenance Primer [[PROV-PRIMER]].
+
+
+
+
+
+<div class='pending'>Comments on section 3.2. This is <a href="http://www.w3.org/2011/prov/track/issues/71">ISSUE-71</a></div>
+
+ <section>
+<h3>A File Scenario</h3>
+
+
+<p>This scenario is concerned with the evolution of a crime statistics
+file (referred to as e0) stored on a shared file system and which
+journalists Alice, Bob, Charles, David, and Edith can share and
+edit. We consider various <a title="event">events</a> in the evolution of file e0;
+<a title="event">events</a> listed below follow each other, unless otherwise specified.</p>
+
+
+
+<p>
+<a>Event</a> evt1: Alice creates (a0) an empty file in /share/crime.txt. We denote this file e1.
+</p>
+
+<p>
+<a>Event</a> evt2: Bob appends (a1) the following line to /share/crime.txt:</p>
+<pre>
+There was a lot of crime in London last month.
+</pre>
+<p>We denote the revised file e2.</p>
+
+<p><a>Event</a> evt3: Charles emails (a2) the contents of /share/crime.txt, as an
+attachment, which we refer to as e4. (We specifically refer to a copy of the file that is uploaded on the mail server.)
+</p>
+
+<p>
+<a>Event</a> evt4: David edits (a3) file /share/crime.txt as follows.</p>
+<pre>
+There was a lot of crime in London and New-York last month.
+</pre>
+<p>
+We denote the revised file e3.
+</p>
+
+<p><a>Event</a> evt5: Edith emails (a4) the contents of /share/crime.txt as an attachment, referred to as e5.
+</p>
+
+<p><a>Event</a> evt6: between <a title="event">events</a> evt4 and evt5, someone (unspecified) runs a spell checker (a5) on the file /share/crime.txt.
+ The file after spell checking is referred to as e6.
+</p>
+
+</section>
+
+ <section id="example-prov-asn-encoding">
+<h3>Encoding using PROV-ASN</h3>
+
+In this section, the example is encoded according to the provenance data model (specified in section <a href="#data-model-concepts">PROV-DM: The Provenance Data Model</a>) and expressed in PROV-ASN.
+<p>
+Entity Records (described in <a href="#record-Entity">Section Entity</a>). The file in its various forms and its copies are modelled as entity records, corresponding to multiple characterizations, as per scenario. The entity records are identified by <span class="name">e0</span>, ..., <span class="name">e6</span>.</p>
+<pre>
+entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
+entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London last month."])
+entity(e3, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month."])
+entity(e4)
+entity(e5)
+entity(e6, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month.", ex:spellchecked="yes"])
+</pre>
+
+
+
+<p>These entity records list attributes that have been given values during intervals delimited by <a title="event">events</a>; such intervals are referred to as <em>characterization intervals</em>. The following table lists all entity identifiers and their corresponding characterization intervals. When the end of the characterization interval is not delimited by an <a>event</a> described in this scenario, it is marked by "...".</p>
+<blockquote>
+<table>
+<tr><td>Entity</td><td>Characterization Interval</td></tr>
+<tr><td>e0</td><td>evt1 - ...</td></tr>
+<tr><td>e1</td><td>evt1 - evt2</td></tr>
+<tr><td>e2</td><td>evt2 - evt4</td></tr>
+<tr><td>e3</td><td>evt4 - ...</td></tr>
+<tr><td>e4</td><td>evt3 - ...</td></tr>
+<tr><td>e5</td><td>evt5 - ...</td></tr>
+<tr><td>e6</td><td>evt6 - ... </td></tr>
+</table>
+</blockquote>
+
+
+
+<p>
+Activity Records (described in <a href="#record-Activity">Section Activity</a>) represent activities in the scenario.</p>
+<pre>
+activity(a0, create-file, 2011-11-16T16:00:00,)
+activity(a1, add-crime-in-london, 2011-11-16T16:05:00,)
+activity(a2, email, 2011-11-16T17:00:00,)
+activity(a3, edit-London-New-York, 2011-11-17T09:00:00,)
+activity(a4, email, 2011-11-17T09:30:00,)
+activity(a5, spellcheck,,)
+</pre>
+
+
+<p>
+Generation Records (described in <a href="#record-Generation">Section Generation</a>) represent the <a>event</a> at which a file is created in a specific form. Attributes are used to describe the modalities according to which a given entity is generated by a given activity. The interpretation of attributes is application specific. Illustrations of such attributes for the scenario are: no attribute is provided for <span class="name">e0</span>;
+<span class="name">e2</span> was generated by the editor's save function; <span class="name">e4</span> can be found on the smtp port, in the attachment section of the mail message; <span class="name">e6</span> was produced on the standard output of <span class="name">a5</span>. Two identifiers <span class="name">g1</span> and <span class="name">g2</span> identify the generation records referenced in derivations introduced below.</p>
+<pre>
+wasGeneratedBy(e0, a0)
+wasGeneratedBy(e1, a0, [ex:fct="create"])
+wasGeneratedBy(e2, a1, [ex:fct="save"])
+wasGeneratedBy(e3, a3, [ex:fct="save"])
+wasGeneratedBy(g1, e4, a2, [ex:port="smtp", ex:section="attachment"])
+wasGeneratedBy(g2, e5, a4, [ex:port="smtp", ex:section="attachment"])
+wasGeneratedBy(e6, a5, [ex:file="stdout"])
+</pre>
+
+
+
+<p>
+Usage Records (described in <a href="#record-Usage">Section Usage</a>) represent the <a>event</a> by which a file is read by an activity.
+
+Likewise, attributes describe the modalities according to which the various entities are used by activities. Illustrations of such attributes are:
+<span class="name">e1</span> is used in the context of <span class="name">a1</span>'s <span class="name">load</span> functionality; <span class="name">e2</span> is used by <span class="name">a2</span> in the context of its attach functionality; <span class="name">e3</span> is used on the standard input by <span class="name">a5</span>. Two identifiers <span class="name">u1</span> and <span class="name">u2</span> identify the Usage records referenced in derivations introduced below.</p>
+<pre>
+used(a1,e1,[ex:fct="load"])
+used(a3,e2,[ex:fct="load"])
+used(u1,a2,e2,[ex:fct="attach"])
+used(u2,a4,e3,[ex:fct="attach"])
+used(a5,e3,[ex:file="stdin"])
+</pre>
+
+
+<p>
+Derivation Records (described in <a href="#Derivation-Relation">Section Derivation Relation</a>) express that an entity is derived from another. The first two are expressed in their compact version, whereas the following two are expressed in their full version, including the activity underpinning the derivation, and associated usage (<span class="name">u1</span>, <span class="name">u2</span>) and generation (<span class="name">g1</span>, <span class="name">g2</span>) records.</p>
+<pre>
+wasDerivedFrom(e2,e1)
+wasDerivedFrom(e3,e2)
+wasDerivedFrom(e4,e2,a2,g1,u1)
+wasDerivedFrom(e5,e3,a4,g2,u2)
+</pre>
+
+
+
+<p>
+wasComplementOf: (this relation is described in <a href="#record-complement-of">Section wasComplementOf</a>). The crime statistics file (<span class="name">e0</span>) has various contents over its existence (<span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span>); the entity records identified by <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span> complement <span class="name">e0</span> with an attribute <span class="name">content</span>. Likewise, the one denoted by <span class="name">e6</span> complements the record denoted by <span class="name">e3</span> with an attribute <span class="name">spellchecked</span>.</p>
+<pre>
+wasComplementOf(e1,e0)
+wasComplementOf(e2,e0)
+wasComplementOf(e3,e0)
+wasComplementOf(e6,e3)
+</pre>
+
+
+
+<p>
+Agent Records (described at <a href="#record-Agent">Section Agent</a>): the various users are represented as agents, themselves being a type of entity.</p>
+<pre>
+agent(ag1, [ prov:type="prov:Person" %% xsd:QName, ex:name="Alice" ])
+
+agent(ag2, [ prov:type="prov:Person" %% xsd:QName, ex:name="Bob" ])
+
+agent(ag3, [ prov:type="prov:Person" %% xsd:QName, ex:name="Charles" ])
+
+agent(ag4, [ prov:type="prov:Person" %% xsd:QName, ex:name="David" ])
+
+agent(ag5, [ prov:type="prov:Person" %% xsd:QName, ex:name="Edith" ])
+</pre>
+
+
+
+<p>
+Activity Assocation Records (described in <a href="#record-ActivityAssociation">Section Activity Association</a>): the association of an agent with an activity is expressed with , and the nature of this association is described by attributes. Illustrations of such attributes include the role of the participating agent, as creator, author and communicator (role is a reserved attribute in PROV-DM).</p>
+<pre>
+wasAssociatedWith(a0, ag1, [prov:role="creator"])
+wasAssociatedWith(a1, ag2, [prov:role="author"])
+wasAssociatedWith(a2, ag3, [prov:role="communicator"])
+wasAssociatedWith(a3, ag4, [prov:role="author"])
+wasAssociatedWith(a4, ag5, [prov:role="communicator"])
+</pre>
+</section>
+
+
+ <section>
+<h3>Graphical Illustration</h3>
+
+
+<p>
+Provenance assertions can be <em>illustrated</em> graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of provenance assertions. Therefore, it cannot be seen as an alternate notation for expressing provenance.</p>
+
+<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and half-hexagonal shapes, respectively. Usage, Generation, Derivation, Activity Association, and Complementarity are represented as directed edges.</p>
+
+<p>Entities are layed out according to the ordering of their generation event. We endeavor to show time progressing from left to right. This means that edges for Usage, Generation and Derivation typically point from right to left.</p>
+
+
+<div style="text-align: center;">
+<img src="example-graphical.png" alt="example"/>
+</div>
+<br/>
+<div style="text-align: center;">
+<img src="timeline.png" alt="example"/>
+</div>
+</section>
+
+</section>
+
+
+
+<section id="data-model-concepts">
+
+<h2>PROV-DM Core</h2>
+
+<p>This section contains the normative specification of PROV-DM core, the core of the PROV data model.</p>
+
+<div class="note">
+In a next iteration of this document, it is proposed to reorganize
+section 5 as follows. First, the presentation of the data model
+alone. Second, its temporal interpretation. Third, the constraints and
+inferences associated with well-formed accounts.
+</div>
+
+ <section id="PROV-DM-record">
+
+<h3>Record</h3>
+
+<p>PROV-DM consists of a set of constructs, referred to as <em>records</em>, to formulate representations of the world and constraints that must be satisfied by them.</p>
+
+<p>
+Furthermore, PROV-DM includes a "house-keeping construct", a record container,
+ used to wrap PROV-DM records and facilitate their interchange.</p>
+
+<p>In PROV-ASN, such representations of the world MUST be conformant with the toplevel production <span class="nonterminal">record</span> of the grammar. These <span class="nonterminal">record</span>s are grouped in three categories:
+<span class="nonterminal">elementRecord</span> (see section <a href="#record-element">Element</a>),
+<span class="nonterminal">relationRecord</span> (see section <a href="#record-relation">Relation</a>), and
+<span class="nonterminal">accountRecord</span> (see section <a href="#record-Account">Account</a>).</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">record</span> ::=
+<span class="nonterminal">elementRecord</span>
+| <span class="nonterminal">relationRecord</span>
+| <span class="nonterminal">accountRecord</span>
+<br/>
+<!-- -->
+<br/>
+<span class="nonterminal">elementRecord</span> ::=
+<span class="nonterminal">entityRecord</span>
+| <span class="nonterminal">activityRecord</span>
+| <span class="nonterminal">agentRecord</span>
+| <span class="nonterminal">noteRecord</span> <br/>
+<!-- -->
+<br/>
+<span class="nonterminal">relationRecord</span> ::=
+<span class="nonterminal">generationRecord</span>
+| <span class="nonterminal">usageRecord</span>
+| <span class="nonterminal">derivationRecord</span>
+| <span class="nonterminal">activityAssociationRecord</span>
+| <span class="nonterminal">responsibilityRecord</span>
+| <span class="nonterminal">startRecord</span>
+| <span class="nonterminal">endRecord</span>
+| <span class="nonterminal">complementRecord</span>
+| <span class="nonterminal">annotationRecord</span>
+</div>
+
+
+<p>In PROV-ASN, a record container is compliant with the production <span class="nonterminal">recordContainer</span> (see section <a href="#RecordContainer">Record Container</a>). </p>
+
+</section>
+
+ <section id="record-element">
+<h3>Element</h3>
+
+<p>This section describes all the PROV-DM records referred to as element records. (They are conformant to the <span class='nonterminal'>elementRecord</span> production of the grammar.)</p>
+
+
+
+ <section id="record-Entity">
+
+<h4>Entity Record</h4>
+
+<p>In PROV-DM, an <dfn id="dfn-entity">entity record</dfn> is a representation of an entity.</p>
+
+
+<p>Examples of entities include a linked data set, a sparse-matrix matrix of floating-point numbers, a document in a directory, the same document published on the Web, and meta-data embedded in a document.</p>
+
+<p>An entity record, noted <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> identifying an entity; the identifier of the entity record is defined to be the same as the identifier of the entity; </li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this entity's situation in the world.</li>
+</ul>
+
+
+<p>
+The assertion of an entity record, <span class="name">entity(id, [ attr1=val1, ...])</span>, states, from a given asserter's viewpoint, the existence of an entity, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two <a title="event">events</a> in the world.
+</p>
+
+<p>
+In PROV-ASN, an entity record's text matches the <span class="nonterminal">entityRecord</span> production of the grammar defined in this specification document.
+</p>
+
+<div class='grammar'>
+<span class="nonterminal">entityRecord</span> ::=
+<span class="name">entity</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/><br/>
+<!-- -->
+<span class="nonterminal">optional-attribute-values</span> ::=
+<span class="optional"><span class="name">,</span>
+<span class="name">[</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">]</span>
+</span><br/>
+<span class="nonterminal">attribute-values</span> ::=
+<span class="nonterminal">attribute-value</span>
+| <span class="nonterminal">attribute-value</span> <span class="name">,</span> <span class="nonterminal">attribute-values</span>
+<br/>
+<span class="nonterminal">attribute-value</span> ::=
+<span class="nonterminal">attribute</span>
+<span class="name">=</span>
+<span class="nonterminal">Literal</span>
+<br/>
+</div>
+
+<div class="anexample">
+<p>
+The following entity record,</p>
+<pre class="codeexample">
+entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+</pre>
+states the existence of an entity, denoted by identifier <span class="name">e0</span>, with type <span class="name">File</span> and path <span class="name">/shared/crime.txt</span> in the file system, and creator alice The attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span class="name">type</span> is reserved in the PROV-DM namespace.
+</div>
+
+Further considerations:
+<ul>
+<li>If an asserter wishes to characterize an entity with the same attribute-value pairs over several intervals, then they are required to assert multiple entity records, each with its own identifier (so as to allow potential dependencies between the various entity records to be expressed). </li>
+
+<li>There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.</li>
+
+<li>A characterization interval may collapse into a single instant.</li>
+
+<li>An entity assertion
+ is about a thing, whose situation in the world may be variant.
+ An entity record is asserted at a particular point and is invariant, in the sense that
+its attributes are given a value as part of that assertion.
+</li>
+
+<li>Activities are not represented by entity records, but instead by activity records, as explained below.</li>
+</ul>
+
+
+
+
+
+
+<div class='note'>The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define wasComplementOf more precisely. It would also allow us to address
+<a href="http://www.w3.org/2011/prov/track/issues/108">ISSUE-108</a>.
+Beginning and end of characterization interval could be expressed by attributes (similarly to activities). </div>
+
+
+
+
+ </section>
+
+ <section id="record-Activity">
+
+<h3>Activity Record</h3>
+<p>In PROV-DM, an <dfn id="dfn-activity">activity record</dfn> is a representation of an identifiable activity, which performs a piece of work.</p>
+
+
+<p>An activity, represented by an activity record, 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">events</a>. However, an activity record need not mention time information, nor duration, because they may not be known.</p>
+
+<p>Such start and end times constitute <em>attributes</em> of an activity, where the interpretation of attribute in the context of an activity record is the same as the interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the world can be represented by other attribute-value pairs, which MUST also remain unchanged during the activity duration.</p>
+
+<p>
+Examples of activities include assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a sparql query over a triple store, editing a file, and publishing a web page. </p>
+
+<p> An activity record, written <span class="name">activity(id, rl, st, et, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> identifying an activity; the identifier of the activity record is defined to be the same as the identifier of the activity;</li>
+<li><em>recipeLink</em>: an OPTIONAL <a href="#record-RecipeLink">recipe link</a> <span class="name">rl</span>, which consists of a domain specific specification of the activity;</li>
+<li><em>startTime</em>: an OPTIONAL time <span class="name">st</span> indicating the start of the activity;</li>
+<li><em>endTime</em>: an OPTIONAL time <span class="name">et</span> indicating the end of the activity;</li>
+<li><em>attributes</em>: a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole duration.</li>
+</ul>
+
+<p>In PROV-ASN, an activity record's text matches the <span class='nonterminal'>activityRecord</span> production of the grammar defined in this specification document.</p>
+
+
+
+<div class='grammar'>
+<span class="nonterminal">activityRecord</span> ::=
+<span class="name">activity</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="optional"><span class="name">,</span>
+<span class="nonterminal">recipeLink</span> </span>
+<span class="name">,</span>
+<span class="optional"><span class="nonterminal">time</span></span>
+<span class="name">,</span>
+<span class="optional"><span class="nonterminal">time</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/>
+</div>
+
+<div class="anexample">
+<p>
+The following activity assertion</p>
+<pre class="codeexample">
+activity(a1,add-crime-in-london,2011-11-16T16:05:00,2011-11-16T16:06:00,[ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
+</pre>
+<p>identified by identifier <span class="name">a1</span>, states the existence of an activity with recipe link <span class="name">add-crime-in-london</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix <span class="name">ex</span>). The attribute <span class="name">host</span> is application specific, but MUST hold for the duration of activity. The attribute <span class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
+</div>
+
+<p>The mere existence of an activity assertion 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 expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
+
+<div class='interpretation' id='start-precedes-end'> The following temporal constraint holds for any activity record: the
+<a title="activity start event">start event</a> <a>precedes</a> the <a title="activity end event">end event</a>.</div>
+
+<p>An activity record is not an entity record.
+Indeed, an entity record represents an entity that exists in full at
+any point in its characterization interval, persists during this
+interval, and preserves the characteristics that makes it
+identifiable. Alternatively, an activity in 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]].</p>
+
+
+</section>
+
+<section id="record-Agent">
+<h3>Agent Record</h3>
+
+
+
+<p>An <dfn id="dfn-Agent">agent record</dfn> is a representation of an agent, which is an entity that can be assigned some degree of responsibility for an activity taking place.</p>
+
+<p>Many agents can have an association with a given activity. An agent may do the ordering of the activity, another agent may do its design, another agent may push the button to start it, another agent may run it, etc.
+As many agents as one wishes to mention can occur in the provenance record, if it is important to indicate that they were associated with the activity. </p>
+
+<p>
+From an inter-operability perspective, it is useful to define some basic categories of agents since
+it will improve the use of provenance records by applications.
+There should be very few of these basic categories to keep the model simple and accessible.
+There are three types of agents in the model:
+<ul>
+<li><span class="name">Person</span>: agents of type Person are people. (This type is equivalent to a "foaf:person" [[FOAF]])</li>
+<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc. (This type is equivalent to a "foaf:organization" [[FOAF]])</li>
+<li><span class="name">SoftwareAgent</span>: a software agent is a piece of software. </li>
+</ul>
+<p>These types are mutually exclusive, though they do not cover all kinds of agent. </p>
+
+<p>An agent record, noted <span class="name">agent(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> identifying an agent; the identifier of the agent record is defined to be the same as the identifier of the agent;</li>
+<li><em>attributes</em>: contains a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this agent's situation in the world.</li>
+</ul>
+
+<p>In PROV-ASN, an agent record's text matches the <span class="nonterminal">agentRecord</span> production of the grammar defined in this specification document.
+</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">agentRecord</span> ::=
+<span class="name">agent</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+
+
+<div class="anexample">
+<p>With the following assertions,</p>
+<pre class="codeexample">
+agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Person" %% xsd:QName])
+
+entity(e2) and wasStartedBy(a1,e2,[prov:role="author"])
+
+entity(e3) and wasAssociatedWith(a1,e3,[prov:role="sponsor"])
+</pre>
+<p>the agent record identified by <span class="name">e1</span> is an explicit agent assertion that holds irrespective of activities it may be associated with. On the other hand, from the entity records identified by <span class="name">e2</span> and <span class="name">e3</span>, one can infer agent records, as per the following inference.</p>
+</div>
+
+<p>One can assert an agent record or alternatively, one can infer an agent record
+by its association with an activity. </p>
+
+<div class='constraint' 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>
+
+</section>
+
+ <section id="record-note">
+
+<h4>Note Record</h4>
+
+<p>As provenance records are exchanged between systems, it may be useful to add extra-information about such records. For instance, a "trust service" may add value-judgements about the trustworthiness of some of the assertions made. Likewise, an interactive visualization component may want to enrich a set of provenance records with information helping reproduce their visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing any identifiable record to be associated with notes.</p>
+
+<p>An <dfn id="dfn-note">note record</dfn> is a set of attribute-value pairs, whose meaning is application specific. It may or may not be a representation of something in the world.</p>
+
+<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
+</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">noteRecord</span> ::=
+<span class="name">note</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">)</span><br/>
+<!-- -->
+</div>
+
+<p>A separate PROV-DM record is used to associate a note with an identifiable record (see <a href="#record-annotation">Section on annotation</a>). A given note may be associated with multiple records.
+</p>
+
+
+<div class="anexample">
+<p>
+The following note record</p>
+<pre class="codeexample">
+note(ann1,[ex:color="blue", ex:screenX=20, ex:screenY=30])
+</pre>
+<p>consists of a set of application-specific attribute-value pairs, intended
+to help the rendering of the record it is associated with, by
+specifying its color and its position on the screen. In this example,
+these attribute-value pairs do not constitute a representation of something
+in the world; they are just used to help render provenance.
+</p>
+</div>
+
+<p>
+Attribute-value pairs occurring in notes differ from attribute-value pairs occurring in entity records and activity records. In entity and activity records, attribute-value pairs MUST be a representation of something in the world, which remain constant for the duration of the characterization interval (for entity record) or the activity duration (for activity records). In note records, it is OPTIONAL for attribute-value pairs to be representations of something in the world. If they are a representation of something in the world, then it MAY change value for the corresponding duration. If attribute-value pairs of a note record are a representation of something in the world that does not change, they are not regarded as determining characteristics of an entity or activity, for the purpose of provenance.
+</p>
+
+
+ </section>
+
+</section>
+
+
+<section id="record-relation">
+<h3>Relation</h3>
+
+<p>This section describes all the PROV-DM records representing relations between the elements introduced in <a href="#record-element">Section Element</a>. While these relations are not binary, they all involve two primary elements. They can be summarized as follows. </p>
+
+
+<div style="text-align: center;">
+<table border="1" style="margin-left: auto; margin-right: auto;">
+<caption>PROV-DM Core Relation Summary</caption>
+<tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Note</td></tr>
+<tr><td>Entity</td><td><a title="derivation record">wasDerivedFrom</a><br><a title="complementarity record">wasComplementOf</a></td><td><a title="generation record">wasGeneratedBy</a></td><td>-</td><td><a title="annotation record">hasAnnotation</a></td></tr>
+<tr><td>Activity</td><td><a title="usage record">used</a></td><td>-</td><td><a title="start record">wasStartedBy</a><br><a title="end record">wasEndedBy</a><br><a title="activity association record">wasAssociatedWith</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
+<tr><td>Agent</td><td>-</td><td>-</td><td><a title="responsibility record">actedOnBehalfOf</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
+<tr><td>Note</td><td>-</td><td>-</td><td>-</td><td><a title="annotation record">hasAnnotation</a></td></tr>
+</table>
+</div>
+
+
+<p>In PROV-ASN, all these relation records are conformant to the <span class='nonterminal'>relationRecord</span> production of the grammar.</p>
+
+<section id="activity-entity-relation">
+<h3>Activity-Entity Relation</h3>
+
+<section id="record-Generation">
+<h4>Generation Record</h4>
+
+
+<p>In PROV-DM, a <dfn id="dfn-Generation">generation record</dfn> is a representation of a world <a title="entity generation event">event</a>, the creation of a new entity by an activity. This entity did not exist before creation.
+The representation of this <a>event</a> encompasses a description of the modalities of generation of this entity by this activity.</p>
+
+<p>A <a title="entity generation event">generation event</a> may be, for example, the creation of a file by a program, the creation of a linked data set, the production of a new version of a document, and the sending of a value on a communication channel.</p>
+
+<p>A generation record, written <span class="name">wasGeneratedBy(id,e,a,attrs,t)</span> in PROV-ASN, has the following components:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the generation record;</li>
+<li><em>entity</em>: an identifier <span class="name">e</span> identifying an entity record that represents the entity that is created; </li>
+<li><em>activity</em>: an identifier <span class="name">a</span> identifying an activity record that represents the activity that creates the entity;</li>
+
+<li><em>time</em>: an OPTIONAL "generation time" <span class="name">t</span>, the time at which the entity was created;</li>
+
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describes the modalities of generation of this entity by this activity.</li>
+
+</ul>
+
+<p>In PROV-ASN, a generation record's text matches the <span class='nonterminal'>generationRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class='grammar'>
+<span class="nonterminal">generationRecord</span> ::=
+<span class="name">wasGeneratedBy</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>
+<span class="name">,</span> </span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="optional"><span class="name">,</span>
+<span class="nonterminal">time</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/>
+</div>
+
+
+<p>
+A generation record's id is OPTIONAL. It MUST be used when annotating generation records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).
+</p>
+
+
+<div class='anexample'>
+<p>
+The following generation assertions</p>
+<pre class="codeexample">
+ wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1", ex:order=1])
+ wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p1", ex:order=2])
+</pre>
+<p>state the existence of two <a title="event">events</a> in the world (with respective times <span class="name">2001-10-26T21:32:52</span> and <span class="name">2001-10-26T10:00:00</span>), at which new entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an activity, itself represented by an activity record identified by <span class="name">a1</span>.
+The first one is available as the first value on port p1, whereas the other is the second value on port p1. The semantics of <span class="name">port</span> and <span class="name">order</span> in these records are application specific.
+</p>
+</div>
+
+
+
+<p>The assertion of a generation record implies ordering of <a title="event">events</a> in the world.</p>
+
+
+<div class='interpretation' id='generation-activity-ordering'><span class='conditional'>If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following temporal constraint also holds: the <a title="entity generation event">generation</a> of the entity denoted by <span class="name">x</span> <a>precedes</a> the <a title="activity end event">end</a>
+of <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>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
+The rationale for this constraint is as follows.
+If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct entities. Alternatively, for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This unicity constraint is formalized as follows.
+
+<div class='constraint' id='generation-unicity'>Given an entity record denoted by <span class="name">e</span>, two activity records 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> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given account,
+<span class='conditional'>then</span> <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
+</div>
+
+<div class='note'>TODO: Introduce the well-formed-ness constraint in a entirely separate section.</div>
+
+
+</section>
+
+
+<section id="record-Usage">
+<h3>Usage Record</h3>
+
+
+
+<p>In PROV-DM, a <dfn id="dfn-Use">usage record</dfn> is a representation of a world <a title="entity usage event">event</a>: the consumption of an entity by an activity. The representation includes a description of the modalities of usage of this entity by this activity.</p>
+
+<p>
+A <a title="entity usage event">usage event</a> may be the consumption of a parameter by a procedure, the reading of a value on a port by a service, the reading of a configuration file by a program, or the adding of an ingredient, such as eggs, in a baking activity. Usage may entirely consume an entity (e.g. eggs are not longer available after being added to the mix), or leave it as such, ready for further uses (e.g. a file on a file system can be read indefinitely).</p>
+
+
+<p>A usage record, written <span class="name">used(id,a,e,attrs,t)</span> in PROV-ASN, has the following constituent:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the usage record;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record, which represents the consuming activity;</li>
+<li><em>entity</em>: an identifier <span class="name">e</span> for an entity record, which represents the entity that is consumed;</li>
+<li><em>time</em>: an OPTIONAL "usage time" <span class="name">t</span>, the time at which the entity was used;</li>
+<li><em>attributes</em>: an OPTIONIAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of usage of this entity by this activity;</li>
+</ul>
+
+<p>In PROV-ASN, a usage record's text matches the <span class='nonterminal'>usageRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class='grammar'>
+<span class="nonterminal">usageRecord</span> ::=
+<span class="name">used</span>
+<span class="name">(</span>
+<span class="optional">
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="optional">
+<span class="name">,</span>
+ <span class="nonterminal">time</span>
+</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/>
+</div>
+
+
+<p>
+A usage record's id is OPTIONAL, but comes handy when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining derivations.
+</p>
+
+
+<div class='anexample'>
+<p>The following usage records</p>
+<pre class="codeexample">
+ used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"])
+ used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])
+</pre>
+<p>state that the activity, represented by the activity record identified by <span class="name">a1</span>, consumed two entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, at times <span class="name">2011-11-16T16:00:00</span> and <span class="name">2011-11-16T16:00:01</span>, respectively; the first one was found as the value of parameter <span class="name">p1</span>, whereas the second was found as value of parameter <span class="name">p2</span>. The semantics of <span class="name">parameter</span> in these records is application specific.</p>
+</div>
+
+
+
+
+
+<p>
+A usage record's id is OPTIONAL. It MUST be present when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).</p>
+
+<p>
+A reference to a given entity record MAY appear in multiple usage records that share
+ a given activity record identifier.
+</p>
+
+
+
+
+
+<div class='interpretation' id='usage-generation-ordering'>For any entity, the following temporal 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>
+
+
+<div class='interpretation' id='usage-activity-ordering'>Given an activity record identified by <span class="name">a</span>, an entity record identified by <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 temporal constraint holds:
+ the <a title="entity usage event">usage</a> of the entity represented by entity record identified by <span class="name">e</span> <a>precedes</a> the <a title="activity end event">end</a> of activity represented by record identified by <span class="name">a</span> and <a>follows</a> its <a title="activity start event">start</a>.
+</div>
+
+
+
+
+<div class='issue'>Should we define a taxonomy of use? This is <a href="http://www.w3.org/2011/prov/track/issues/23">ISSUE-23</a>.</div>
+
+</section>
+</section>
+
+
+
+
+
+<section id="activity-agent-relation">
+<h3>Activity-Agent Relation</h3>
+
+<section id="record-ActivityAssociation">
+<h4>Activity Association Record</h4>
+
+<p>The key purpose of agents in PROV-DM is to assign responsibility
+for activities. It is important to reflect that there is a degree in
+the responsibility of agents, and that is a major reason for
+distinguishing among all the agents that have some association with an
+activity and determine which ones are really the originators of the
+entity. For example, a programmer and a researcher could both be
+associated with running a workflow, but it may not matter what
+programmer clicked the button to start the workflow while it would
+matter a lot what researcher told the programmer to do so. Another
+example: a student publishing a web page describing an academic
+department could result in both the student and the department being
+agents associated with the activity, and it may not matter what
+student published a web page but it matters a lot that the department
+told the student to put up the web page. So there is some notion of
+responsibility that needs to be captured. </p>
+
+<p>To this end, PROV-DM offers two kinds of records. The first, introduced in this section, represents an association between an agent and an activity; the second, introduced in <a href="#record-responsibility">Section Responsibility record</a>, represents the fact that an agent was acting on behalf of another, in the context of an activity. </p>
+
+<p>Examples of activity association include designing, participation, initiation and termination, timetabling or sponsoring. </p>
+
+<p>An <dfn id="dfn-activity-association">activity association record</dfn>, written <span class="name">wasAssociatedWith(a,ag2,attrs)</span> in PROV-ASN, has the following constituents:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the activity association record;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of association of this activity with this agent;</li>
+<li><em>agent</em>: an identifier <span class="name">ag2</span> for an agent record, which represents the agent associated with the activity.</li>
+
+</ul>
+
+<p>In PROV-ASN, an activity association record's text matches the <span class="nonterminal">activityAssociationRecord</span> productions of the grammar defined in this specification document.</p>
+
+<div class='grammar'>
+<span class="nonterminal">activityAssociationRecord</span> ::=
+<span class="name">wasAssociatedWith</span>
+<span class="name">(</span>
+<span class="optional"><span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">aIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<div class="anexample">
+In the following example, a programmer and a researcher agents are asserted to be associated with an activity.
+<pre class="codeexample">
+activity(a,[prov:type="workflow"])
+agent(ag1,[prov:type="programmer"])
+agent(ag2,[prov:type="researcher"])
+wasAssociatedWith(a,ag1,[prov:role="loggedInUser", ex:how="webapp"])
+wasAssociatedWith(a,ag2,[prov:role="designer", ex:context="phd"])
+</pre>
+</div>
+
+
+
+</section>
+
+<section id="record-Start-End">
+<h4>Start and End Records</h4>
+
+<p> A <dfn id="dfn-Start">start record</dfn> is a representation of an agent starting an activity.
+ An <dfn id="dfn-End">end record</dfn> is a representation of an agent ending an activity. Both relations are specialized forms of <span class="name">wasAssociatedWith</span>. They contain attributes describing the modalities of acting/ending activities.</p>
+
+
+
+<p>A start record, written <span class="name">wasStartedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the start record;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the started activity;
+<li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the starting agent;
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent started the activity.
+</ul>
+
+<p>An end record, written <span class="name">wasEndedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the end record;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the ended activity;
+<li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the ending agent;
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent ended the activity.
+</ul>
+
+<p>In PROV-ASN, start and end record's texts match the <span class="nonterminal">startRecord</span> and <span class="nonterminal">endRecord</span> productions of the grammar defined in this specification document.
+</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">startRecord</span> ::=
+<span class="name">wasStartedBy</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">aIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/>
+<span class="nonterminal">endRecord</span> ::=
+<span class="name">wasEndedBy</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">aIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+<div class="anexample">
+<p>
+The following assertions</p>
+<pre class="codeexample">
+wasStartedBy(a,ag,[ex:mode="manual"])
+wasEndedby(a,ag,[ex:mode="manual"])
+</pre>
+<p>state that the activity, represented by the activity record denoted by <span class="name">a</span>
+was started and ended by an agent, represented by record denoted by <span class="name">ah</span>, in "manual" mode, an application specific characterization of these relations.
+</p>
+</div>
+</section>
+
+<div class="note">Temporal constraints for these relations remain to be
+written. The temporal constraints should ensure that the agent started
+its existence before the effect it may have on the activity. </div>
+
+
+
+<!--
+
+<section id="record-Participation">
+<h4>Participation Record</h4>
+
+<p>A <dfn id="dfn-Participation">participation record</dfn> is a representation of the involvement of an entity in an activity. A participation record can be asserted or inferred.</p>
+
+
+<p>In PROV-ASN, a participation record's text matches the <span class="nonterminal">participationRecord</span> production of the grammar defined in this specification document.</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">participationRecord</span> ::=
+<span class="name">hadParticipant</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">identifier</span>
+<span class="name">)</span>
+</div>
+
+
+
+<p> A participation record,
+written <span class="name">hadParticipant(pe,e)</span> in PROV-ASN:
+<ul>
+<li> contains to identifier <span class="name">pe</span> identifying an activity record representing an activity;
+<li> contains an identifier <span class="name">e</span> identifying an entity record, which is
+a representation of an entity involved in this activity.
+</ul>
+
+<p>An entity's participation in an activity can be by direct usage or direct control. But also, if an entity and situation are characterized in two complementary manners (and are represented by two entity records related by <span class="name">isComplementOf</span>), if one of them participates in an activity, so does the other. The following captures the definition of participation.</p>
+
+<div class='constraint' id='participation'>
+Given two identifiers <span class="name">pe</span> and <span class="name">e</span>, respectively identifying an activity record and an entity record, the record <span class="name">hadParticipant(pe,e)</span> holds <span class='conditional'>if and only if</span>:
+<ul>
+<li> <span class="name">used(pe,e)</span> holds, or</li>
+<li> <span class="name">wasControlledBy(pe,e)</span> holds, or</li>
+<li> <span class="name">wasComplementOf(e1,e)</span> holds for some entity record identified by <span class="name">e1</span>, and
+ <span class="name">hadParticipant(pe,e1)</span> holds some activity record identified by <span class="name">pe</span>.</li>
+</ul>
+</div>
+
+
+<div class='pending'>Suggested definition for participation. This is <a href="http://www.w3.org/2011/prov/track/issues/49">ISSUE-49</a>.</div>
+
+</section>
+
+-->
+
+</section>
+
+<section id="entity-entity-agent-agent-relation">
+<h4>Entity-Entity or Agent-Agent Relation</h4>
+
+<section id="record-responsibility">
+
+<h4>Responsibility Record</h4>
+
+<p>To promote take-up, PROV-DM offers a mild version of responsibility
+in the form of a relation to represent when an agent acted on another
+agent's behalf. So in the example of someone running a mail program,
+the program is an agent of that activity and the person is also an
+agent of the activity, but we would also add that the mail software
+agent is running on the person's behalf. In the other example, the
+student acted on behalf of his supervisor, who acted on behalf of the
+department chair, who acts on behalf of the university, and all those
+agents are responsible in some way for the activity to take place but
+we don't say explicitly who bears responsibility and to what
+degree. </p>
+
+<p>We could also say that an agent can act on behalf of several other
+agents (a group of agents). This would also make possible to
+indirectly reflect chains of responsibility. This also indirectly
+reflects control without requiring that control is explicitly
+indicated. In some contexts there will be a need to represent
+responsibility explicitly, for example to indicate legal
+responsibility, and that could be added as an extension to this core
+model. Similarly with control, since in particular contexts there
+might be a need to define specific aspects of control that various
+agents exert over a given activity.</p>
+
+<p>Given an activity association record <span class="name">wasAssociatedWith(a,ag2,attrs)</span>,
+a <dfn id="dfn-responsibility">responsibility record</dfn>, written <span class="name">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-ASN, has the following constituents:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the responsibility record;</li>
+<li><em>subordinate</em>: an identifier <span class="name">ag2</span> for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible agent;</li>
+<li><em>responsible</em>: an identifier <span class="name">ag1</span> for an agent record, which represents the agent on behalf of which the subordinate agent <span class="name">ag2</span> acts;</li>
+<li><em>activity</em>: an OPTIONAL identifier <span class="name">a</span> of an activity record for which the responsibility record holds;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this relation.</li>
+</ul>
+
+
+<div class='grammar'>
+<span class="nonterminal">responsibilityRecord</span> ::=
+<span class="name">actedOnBehalfOf</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">agIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>,
+<span class="optional"><span class="nonterminal">aIdentifier</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<div class="anexample">
+In the following example, a programmer, a researcher and a funder agents are asserted. The porgrammer and researcher are associated with a workflow activity. The programmer acts on behalf of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher.
+<pre class="codeexample">
+activity(a,[prov:type="workflow"])
+agent(ag1,[prov:type="programmer"])
+agent(ag2,[prov:type="researcher"])
+agent(ag3,[prov:type="funder"])
+wasAssociatedWith(a,ag1,[prov:role="loggedInUser"])
+wasAssociatedWith(a,ag2)
+actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])
+actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
+</pre>
+</div>
+
+
+</section>
+
+<section id="Derivation-Relation">
+<h4>Derivation Record</h4>
+
+<p>In PROV-DM, a <dfn id="dfn-Derivation">derivation record</dfn> is a representation that some entity is transformed from, created from, or affected by another entity in the world. </p>
+
+
+<p>Examples of derivation include the transformation of a canvas into a painting, the transportation of a person from London to New-York, the transformation of a relational table into a linked data set, and the melting of ice into water.</p>
+
+
+<p>According to <a href="#conceptualization">Section Conceptualization</a>, for an entity to be transformed from, created from, or affected by another in some way, there must be some underpinning activities performing the necessary actions resulting in such a derivation.
+However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or less precise records of derivation to be asserted. Hence, PROV-DM uses the terms <em>precise</em> and <em>imprecise</em> to characterize the different kinds of derivation record. We note that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation record, that may be imprecise. </p>
+
+<p>The lack of precision may come from two sources:</p>
+<ul>
+<li> the number of activities that underpin a derivation is not asserted or known, or</li>
+<li> any of the other details that are involved in the derivation is not asserted or known; these include activity identities, generation and usage records, and their attributes.</li>
+</ul>
+
+
+<!--
+Furthermore, assuming that an asserter has full knowledge of an activity underpinning a derivation, the same activity can generally be modelled in terms of sub-activities, composed in a such a way as to deliver the same behavior. Hence, since activities can be modelled at arbitrary levels of granularity, there is a distinguished case in which a derivation between two entities <span class="name">e2</span> and <span class="name">e1</span> corresponds <em>exactly</em> to <em>one</em> activity that used <span class="name">e1</span> and generated <span class="name">e2</span>. This is to be contrasted to the case where one derivation corresponds to n activities, where n can be any number greater than 1.
+Hence, PROV-DM uses the terms <em>one-activity</em> and <em>n-activities</em> to distinguish these two cases.</p>
+-->
+
+
+<p>Hence, given a precision axis, with values <em>precise</em> and <em>imprecise</em>, and an activity axis, with values <em>one activity</em> and <em>n activities</em>, we can then form a matrix of possible derivations, precise or imprecise, or corresponding to one activity or n activities.
+Out of the four possibilities, PROV-DM offers three forms of derivation, while the fourth one is not meaningful. The following table summarises names for the three kinds of derivation, which we then explain.</p>
+
+<div style="text-align: center;">
+<table border="1" style="margin-left: auto; margin-right: auto;">
+<caption>PROV-DM Derivation Type Summary</caption>
+<tr><td colspan=2 rowspan=2></td><td colspan=2>precision axis</td></tr>
+<tr><td>precise</td><td>imprecise</td></tr>
+<tr><td rowspan=2>activity<br>axis</td><td>one activity</td><td><a>precise-1 derivation record</a></td><td><a>imprecise-1 derivation record</a></td></tr>
+<tr><td>n activities</td><td>---</td><td><a>imprecise-n derivation record</a></td></tr>
+</table>
+</div>
+
+<ul>
+<li> The asserter asserts that derivation is due to exactly one activity, and all the details are asserted. We call this a precise-1 derivation record.</li>
+<li> The asserter asserts that derivation is due to exactly one activity, but other details, whether known or unknown, are not asserted. We call this an imprecise-1 derivation record.</li>
+<li> The asserter does not know how many activities are involved in the derivation, and other details, whether known or unknown, are also not asserted. We call this an imprecise-n derivation record.</li>
+</ul>
+
+<p> We note that the fourth theoretical case of a precise derivation, where the number of activities is not known or asserted cannot occur. </p>
+
+
+<p>The three kinds of derivation records are successively introduced. To minimize the number of relation types in PROV-DM, we introduce a PROV-DM reserved attribute <span class="name">steps</span>, which allows us to distinguish the various derivation types. </p>
+
+<p>A <dfn>precise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
+<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
+<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> of an activity record, which is a representation of the activity using and generating the above entities;</li>
+<li><em>generation</em>: an identifier <span class="name">g2</span> of the generation record pertaining to <span class="name">e2</span> and <span class="name">a</span>;</li>
+<li><em>usage</em>: an identifier <span class="name">u1</span> of the usage record pertaining to <span class="name">e1</span> and <span class="name">a</span>.</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation, optionally including the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
+</ul>
+<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in a precise-1 derivation since the record already refers to the one and only one activity underpinning the derivation.</p>
+
+
+<p>An <dfn>imprecise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2,e1, attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
+<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
+<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
+<li><em>attributes</em>: a set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it MUST include the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
+</ul>
+<p>An imprecise-1 derivation MUST include the attribute <span class="name">prov:steps</span>, since it is the only means to distinguish this record from an imprecise-n derivation record.</p>
+
+
+<p>An <dfn>imprecise-n derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
+<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
+<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it optionally includes the attribute-value pair <span class="name">prov:steps="n"</span>.</li>
+</ul>
+<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in an imprecise-n derivation record. It defaults to <span class="name">prov:steps="n"</span>.</p>
+
+
+<p>None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property holds.</p>
+
+
+<p>In PROV-ASN, a derivation record's text matches the <span class='nonterminal'>derivationRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class='grammar'>
+<span class="nonterminal">derivationRecord</span> ::=
+<span class="nonterminal">precise-1-derivationRecord</span>
+| <span class="nonterminal">imprecise-1-derivationRecord</span>
+| <span class="nonterminal">imprecise-n-derivationRecord</span><br/>
+<br/>
+<span class="nonterminal">precise-1-derivationRecord</span> ::=
+<span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">gIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">uIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/>
+<span class="nonterminal">imprecise-1-derivationRecord</span>::=
+<span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">)</span>
+<br/>
+<span class="nonterminal">imprecise-n-derivationRecord</span>::=
+<span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+<div class="note">
+The grammar should make it clear that attribute <span class="name">prov:steps="1"</span> is required for imprecise-1-derivationRecord.<br/>
+ PM: suggestion -- remove the distinction between imprecise-1 and imprecise-n in the grammar and instead explain that the qualification (1 vs n) is through attribute prov:steps.
+</div>
+
+<div class="anexample">
+<p>The following assertions state the existence of derivations.</p>
+<pre class="codeexample">
+wasDerivedFrom(e5,e3,a4,g2,u2,[])
+wasDerivedFrom(e5,e3,a4,g2,u2,[prov:steps="1"])
+
+wasDerivedFrom(e3,e2,[prov:steps="1"])
+
+wasDerivedFrom(e2,e1,[])
+wasDerivedFrom(e2,e1,[prov:steps="n"])
+</pre>
+<p>
+The first two are precise-1 derivation records expressing that the activity represented by the activity <span class="name">a4</span>, by
+using the entity denoted by <span class="name">e3</span> according to usage record <span class="name">u2</span>
+ derived the
+entity denoted by <span class="name">e5</span> and generated it according to generation record
+ <span class="name">g2</span>.
+
+The third record is an imprecise-1 derivation, which is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity record and associated attributes implicit. The fourth and fifth records are imprecise-n derivation records between <span class="name">e2</span> and <span class="name">e1</span>, but no information is provided as to the number and identity of activities underpinning the derivation.
+</p>
+</div>
+
+
+<p>An precise-1 derivation record is richer than an imprecise-1 derivation record, itself, being more informative that an imprecise-n derivation record. Hence, the following implications hold.</p>
+<div class='constraint' id='derivation-implications'>
+Given two entity records 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 record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, then <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> also holds.<br>
+
+Given two entity records 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, [prov:steps="1"] ∪ attrs)</span>
+ holds, then <span class="name">wasDerivedFrom(e2,e1,attrs)</span> also holds.<br>
+ </div>
+
+
+
+<p>
+<p>If a derivation record holds for <span class="name">e2</span> and <span class="name">e1</span>, then
+this means that the entity represented by entity record identified by <span class="name">e1</span> has an influence on the entity represented entity record identified by <span class="name">e2</span>,
+ which at the minimum implies temporal ordering, specified as follows.
+First, we consider one-activity derivations.</p>
+
+<div class='interpretation' id='derivation-usage-generation-ordering'>Given an activity record identified by <span class="name">a</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, <span class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
+or <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> holds, <span class='conditional'>then</span>
+the following temporal 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>Then, imprecise-n derivations.</p>
+
+<div class='interpretation' id='derivation-generation-generation-ordering'>
+Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,[prov:steps="n"] ∪ attrs)</span>
+ holds, <span class='conditional'>then</span> the following temporal 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 temporal ordering is between generations of <span class="name">e1</span>
+and <span class="name">e2</span>, as opposed to precise-1 derivation,
+which implies temporal ordering between the usage of <span class="name">e1</span> and
+generation of <span class="name">e2</span>. Indeed, in the case of
+imprecise-n derivation, nothing is known about the usage of <span class="name">e1</span>,
+since there is no associated activity.</p>
+
+
+
+
+<p>The imprecise-1 derivation has the same meaning as the precise-1
+ derivation, except that an activity
+ is known to exist, though it does not need to be
+asserted. This is formalized by the following inference rule,
+referred to as <em>activity introduction</em>:</p>
+<div class='constraint' id="activity-introduction">
+<span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> there exist an activity record identified by <span class="name">a</span>, a usage record identified by <span class="name">u</span>, and a generation record identified by <span class="name">g</span>
+such that:
+<pre class="codeexample">
+activity(a,aAttrs)
+wasGeneratedBy(g,e2,a,gAttrs)
+used(u,a,e1,uAttrs)
+</pre>
+for sets of attribute-value pairs <span class="name">gAttrs</span>, <span class="name">uAttrs</span>, and <span class="name">aAttrs</span>.
+</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 determined by
+of <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>
+
+<div class="note">The following property holds for account where
+generation-unicity applies. Move it to separate section with all
+related material. </div>
+
+<p>A further inference is permitted from the imprecise-1 derivation record: </p>
+<div class='constraint' id='derivation-use'>
+<p>Given an activity record identified by <span class="name">pe</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and set of attribute-value pairs <span class="name">attrs2</span>,
+<span class='conditional'>if</span> <span class="name">wasDerivedFrom(e2,e1, [prov:steps="1"])</span> and <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> hold, <span class='conditional'>then</span> <span class="name">used(pe,e1,attrs1)</span> also holds
+for some set of attribute-value pairs <span class="name">attrs1</span>.
+</div>
+<p>This inference is justified by the fact that the entity represented by entity record identified by <span class="name">e2</span> is generated by at most one activity in a given account (see <a href="#generation-unicity">generation-unicity</a>). Hence, this activity record is also the one referred to in the usage record 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(pe,e1)</span>, one cannot
+derive <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> because identifier <span class="name">e1</span> may occur in usage records referring to
+many activity records, but they may not be referred to in generation records containing identifier <span class="name">e2</span>.</p>
+
+
+
+
+<div class='issue'>Should derivation have a time? Which time? This is <a href="http://www.w3.org/2011/prov/track/issues/43">ISSUE-43</a>.</div>
+
+</section>
+
+
+<section id="record-complement-of">
+
+<h4>Complementarity Record</h4>
+
+<div class="note">While the working group recognizes the importance of the complementarity record concept, its name and its exact semantics are still being discussed.
+</div>
+
+
+<p>A <dfn id="complementOf">complementarity record</dfn> is a relationship between two entities stated to have compatible characterization over some continuous interval between two events.</p>
+
+<!-- PAOLO, which event do you refer to? <a>event</a>?? -->
+
+
+<p>
+The rationale for introducing this relationship is that in general, at any given time, for an entity in the world, there may be multiple ways of characterizing it, and hence multiple representations can be asserted by different asserters. In the example that follows, suppose thing "Royal Society" is represented by two asserters, each using a different set of attributes. If the asserters agree that both representations refer to "The Royal Society", the question of whether any correspondence can be established between the two representations arises naturally. This is particularly relevant when (a) the sets of attributes used by the two representations overlap partially, or (b) when one set is subsumed by the other. In both these cases, we have a situation where each of the two asserters has a partial view of "The Royal Society", and establishing a correspondence between them on the shared attributes is beneficial, as in case (a) each of the two representation <em>complements</em> the other, and in case (b) one of the two (that with the additional attributes) complements the other.</p>
+
+<p>This intuition is made more precise by considering the entities that form the representations of entities at a certain point in time.
+
+An entity record represents, by means of attribute-value pairs, a thing and its situation in the world, which remain constant over a characterization interval.
+As soon as the thing's situation changes, this marks the end of the characterization interval for the entity record representing it. The thing's novel situation is represented by an attribute with a new value, or an entirely different set of attribute-value pairs, embodied in another entity record, with a new characterization interval. Thus, if we overlap the timelines (or, more generally, the sequences of value-changing events) for the two entities, we can hope to establish correspondences amongst the entity records that represent them at various points along that events line. The figure below illustrates this intuition.</p>
+
+<div style="text-align: center;">
+<img src="complement-of.png" alt="illustration complementOf"/>
+</div>
+
+<p>
+Relation <em>complement-of</em> between two entity records is intended to capture these correspondences, as follows. Suppose entity records A and B share a set P of attributes, and each of them has other attributes in addition to P. If the values assigned to each attribute in P are <em>compatible</em> between A and B, then we say that <em>A is-complement-of B</em>, and <em>B is-complement-of A</em>, in a symmetrical fashion. In the particular case where the set P of attributes of B is a strict superset of A's attributes, then we say that <em>B is-complement-of A</em>, but in this case the opposite does not hold. In this case, the relation is not symmetric. (as a special case, A and B may not share any attributes at all, and yet the asserters may still stipulate that they are representing the same thing "Royal Society". The symmetric relation may hold trivially in this case).</p>
+
+<p>The term <em>compatible</em> used above means that a mapping can be established amongst the values of attributes in P and found in the two entity expession. This generalizes to the case where attribute sets P1 and P2 of A, and B, respectively, are not identical but they can be mapped to one another. The simplest case is the identity mapping, in which A and B share attribute set P, and furthermore the values assigned to attributes in P match exactly.</p>
+
+<p>It is important to note that the relation holds only for the characterization intervals of the entity expessions involved As soon as one attribute changes value in one of them, new correspondences need to be found amongst the new entities. Thus, the relation has a validity span that can be expressed in terms of the event lines of the entity.</p>
+
+<!--
+The "IVP of" relationship is designed to represent pairs of entities that correspond to each other. By their own nature, an entity remains valid only as long as all of its attributes do not change their value. It follows that the correspondence "B IVP of A" is only valid within the time interval during which such invariance attribute holds for both A and B. When any of the attribute values change in either A or B, those entities are replaced by new ones, and a new correspondence may be established. Thus, "IVP of" is defined relative to the intersection of the temporal intervals for which A and B are valid.
+-->
+
+
+
+<p>A complementarity record is written <span class="name">wasComplementOf(e2,e1)</span>, where <span class="name">e1</span> and <span class="name">e2</span> are two identifiers denoting entity records.</p>
+
+
+<div class="anexample">
+<p>The following example illustrates the entity "Royal Society"and its perspectives at various points in time.</p>
+<pre class="codeexample">
+entity(rs,[ex:created=1870])
+
+entity(rs_l1,[prov:location="loc2"])
+entity(rs_l2,[prov:location="The Mall"])
+
+entity(rs_m1,[ex:membership=250, ex:year=1900])
+entity(rs_m2,[ex:membership=300, ex:year=1945])
+entity(rs_m3,[ex:membership=270, ex:year=2010])
+
+wasComplementOf(rs_m3, rs_l2)
+wasComplementOf(rs_m2, rs_l1)
+wasComplementOf(rs_m2, rs_l2)
+wasComplementOf(rs_m1, rs_l1)
+
+wasComplementOf(rs_m3, rs)
+wasComplementOf(rs_m2, rs)
+wasComplementOf(rs_m1, rs)
+wasComplementOf(rs_l1, rs)
+wasComplementOf(rs_l2, rs)
+</pre>
+</div>
+
+
+
+<div class='constraint' id='wasComplementOf-necessary-cond'>
+An assertion "wasComplementOf(B,A)" holds over the temporal intersection of A and B, <span class='conditional'>only if</span>:
+<ol>
+<li> if a mapping can be established from an attribute X of entity record identified by B to an attribute Y of entity record identified by A, then the values of A and B must be consistent with that mapping;</li>
+<li>entity record identified by B has some attribute that entity record identified by A does not have.</li>
+</ol>
+ </div>
+
+<p>The complementarity relation is not transitive. Let us consider identifiers <span class="name">e1</span>, <span class="name">e2</span>, and <span class="name">e3</span> identifying three entity records such that
+ <span class="name">wasComplementOf(e3,e2)</span> and <span class="name">wasComplementOf(e2,e1)</span> hold. The record <span class="name">wasComplementOf(e3,e1)</span> may not hold because the characterization intervals of the denoted entity records may not overlap.</p>
+
+
+<p>In PROV-ASN, a complementarity record's text matches the <span class="nonterminal">complementarityRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class='grammar'>
+<span class="nonterminal">complementarityRecord</span> ::=
+<span class="name">wasComplementOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span> <br/>
+|
+<span class="name">wasComplementOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">accIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">accIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+<p>
+An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to link two entity record identifiers that are appear in different accounts. (In particular, the entity record identifiers in two different account are allowed to be the same.). When account identifiers are not available, then the linking of entity records through complementarity can only take place within the scope of a single account.
+</p>
+
+
+<div class="anexample">
+<p>In the following example, the same description of the Royal Society is structured according to two different accounts. In the second account, we find a complementarity record linking <span class="name">rs_m1</span> in account <span class="name">ex:acc2</span> to
+<span class="name">rs</span> in account <span class="name">ex:acc1</span>.
+<pre class="codeexample">
+account(ex:acc1,
+ http://example.org/asserter1,
+
+ ...
+ entity(rs,[ex:created=1870])
+ ...
+ )
+
+
+account(ex:acc2,
+ http://example.org/asserter2,
+
+ ...
+ entity(rs_m1,[ex:membership=250, ex:year=1900])
+ ...
+ wasComplementOf(rs_m1, ex:acc2, rs, ex:acc1)
+
+)
+</pre>
+</div>
+
+
+
+<div class='note'>It is suggested that the name 'wasComplementOf' does not capture the meaning of this relation adequately. No concrete suggestion has been made so far.
+Furthermore, there is a suggestion that an alternative relation that is transitive may also be useful.
+This is raised in the following <a href="http://lists.w3.org/Archives/Public/public-prov-wg/2011Sep/0315.html">email</a>.</div>
+
+
+
+<div class='issue'>A discussion on alternative definition of wasComplementOf has not reached a satisfactory conclusion yet. This is <a href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a></div>
+
+
+
+<div class='pending'> Comments on ivpof in <a href="http://www.w3.org/2011/prov/track/issues/57">ISSUE-57</a>.</div>
+
+
+</section>
+</section>
+
+
+<!--
+<section>
+<h4>Transitive Derivation Record</h4>
+
+
+<p>
+If <span class="name">wasDerivedFrom(e2,e1)</span> holds because attribute <span class="name">a2.1</span> of <span class="name">e2</span> is determined by attribute <span class="name">a1.1</span> of <span class="name">e1</span>,
+and if <span class="name">wasDerivedFrom(e3,e2)</span> holds because attribute <span class="name">a3.1</span>of <span class="name">e3</span> is determined by attribute <span class="name">a2.2</span> of <span class="name">e1</span>, it is not necessarily the case that an attribute of <span class="name">e3</span> is determined by an attribute of <span class="name">e1</span>; so, an asserter may not be able to assert <span class="name">wasDerivedFrom(e3,e1)</span>, since it would fail to satisfy constraint <a href="#derivation-attributes">derivation-attributes</a>. Hence, the constraint on attributes as expressed in <a href="#derivation-attributes">derivation-attributes</a> invalidates transitivity in the general case.
+</p>
+
+<p>However, there is sense that <span class="name">e3</span> still depends on <span class="name">e1</span>, since <span class="name">e3</span> could not be generated without <span class="name">e1</span> existing. Hence, we introduce a weaker notion of derivation record, which is transitive.</p>
+
+A transitive derivation record, written <span class="name">dependedOn(e2, e1)</span> in PROV-ASN:
+<ul>
+<li> contains an identifier <span class="name">e2</span>, denoting an entity record, which represents the entity that is the result of the derivation;
+<li> contains an identifier <span class="name">e1</span>, denoting an entity record, which represents the entity that the derivation relies upon.
+</ul>
+<p>The record <span class="name">dependedOn</span> can only be inferred; in other words, it cannot be asserted. It is
+transitive by definition and relies on the previously defined derivation assertions for its
+base case.</p>
+
+<div class='constraint' id='transitive-derivation'>
+<ul>
+<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> or <span class="name">wasDerivedFrom(e2,e1,pe,attrs2,attrs1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasEventuallyDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
+<li><span class='conditional'>If</span> <span class="name">dependedOn(e3,e2)</span> and <span class="name">dependedOn(e2,e1)</span> hold, <span class='conditional'>then</span> <span class="name">dependedOn(e3,e1)</span> holds.</li>
+</ul>
+</div>
+
+</section>
+-->
+
+
+
+
+
+
+
+<section id="record-annotation">
+<h4>Annotation Record</h4>
+
+
+<p>An <dfn id="dfn-annotation">annotation record</dfn> establishes a link between an identifiable PROV-DM record and a note record referred to by its identifier. Multiple note records can be associated with a given PROV-DM record; symmetrically, multiple PROV-DM records can be associated with a given note record. Since note records have identifiers, they can also be annotated. The annotation mechanism (with note record and the annotation record) forms a key aspect of the extensibility mechanism of PROV-DM (see <a href="#extensibility-section">extensibility section</a>).</p>
+
+<p>An annotation record, written <span class="name">hasAnnotation(r,n,attrs)</span> in PROV-ASN, has the following constituents:</p>
+<ul>
+<li><em>record</em>: an identifier <span class="name">r</span> of the record being annnotated;</li>
+<li><em>note</em>: an identifier <span class="name">n</span> of a note record;</li>
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+
+<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
+</p>
+
+<div class='grammar'>
+<span class="nonterminal">annotationRecord</span> ::=
+<span class="name">hasAnnotation</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">nIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<p>The interpretation of notes is application-specific. See Section <a href="#record-note">Note</a> for a discussion of the difference between note attributes and other records attributes. We also note the present tense in this term to indicate that it may not denote something in the past.</p>
+
+<div class="anexample">
+<p>
+The following records</p>
+<pre class="codexample">
+entity(e1,[prov:type="document"])
+entity(e2,[prov:type="document"])
+activity(a,transform,t1,t2,[])
+used(u1,a,e1,[ex:file="stdin"])
+wasGeneratedBy(e2, a, [ex:file="stdout"])
+
+note(n1,[ex:icon="doc.png"])
+hasAnnotation(e1,n1)
+hasAnnotation(e2,n1)
+
+note(n2,[ex:style="dotted"])
+hasAnnotation(u1,n2)
+</pre>
+<p>assert the existence of two documents in the world (attribute-value pair: <span class="name">prov:type="document"</span>) represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these records with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also asserts an activity, its usage of the first entity, and its generation of the second entity. The <span class="name">usage</span> record is annotated with a style (an application specific way of rendering this edge graphically). To be able to express this annotation, the usage record was provided with an identifier <span class="name">u1</span>, which was then referred to in <span class="name">hasAnnotation(u1,n2)</span>.
+</p>
+</div>
+
+
+</section>
+</section>
+
+<section id="bundle">
+<h3>Bundle</h3>
+
+<p>In this section, two constructs are introduced to group
+PROV-DM records. The first
+one, <a>account record</a> is itself a
+record, whereas the second
+one <a>record container</a> is not.
+</p>
+
+
+<section id="record-Account">
+<h3>Account Record</h3>
+
+<p>In PROV-DM, an <dfn id="dfn-Account">account record</dfn> is a wrapper of records with a dual purpose: </p>
+<ul>
+<li> It is the mechanism by which attribution of provenance can be assserted; it allows asserters to bundle up their assertions, and assert suitable attribution;
+<li> It provides a scoping mechanism for record identifiers and for some contraints (such as
+ <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>).
+</ul>
+
+
+
+<p>An account record, written <span class="name">account(id, assertIRI, recs, attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> that identifies this account globally;</li>
+<li><em>asserter</em>: an IRI, denoted by <span class="name">assertIRI</span>, to identify an asserter; such IRI has no specific interpretation in the context of PROV-DM;</li>
+<li><em>records</em>: a set <span class="name">recs</span> of provenance records;</li>
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p>In PROV-ASN, an account record's text matches the <span class="nonterminal">accountRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class='grammar'>
+<span class="nonterminal">accountRecord</span> ::=
+<span class="name">account</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">asserter</span>
+<span class="name">,</span>
+<span class="plus">
+<span class="nonterminal">record</span> </span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<div class='note'>
+Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI and its interpretation is outside PROV-DM. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM assertions. The editors seek inputs on how to resolve this issue. </div>
+
+<div class="anexample">
+<p>
+The following account record</p>
+<pre class="codeexample">
+account(ex:acc0,
+ http://example.org/asserter,
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+ ...
+ wasDerivedFrom(e2,e1)
+ ...
+ activity(a0,create-file,t)
+ ...
+ wasGeneratedBy(e0,a0,[])
+ ...
+ wasAssociatedWith(a4, ag5, [prov:role="communicator"]) )
+</pre>
+<p>contains the set of provenance records of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span class="name">http://example.org/asserter</span>, and is identified by identifier <span class="name">ex:acc0</span>.
+</p>
+</div>
+
+<p>Account records constitue a scope for record identifiers. A record identifier within the scope of an account is intended to denote a single record. However, nothing prevents an asserter from asserting an account containing, for example, multiple entity records with a same identifier but different attribute-values. In that case, they should be understood as a single entity record with this identifier and the union of all attributes values, as formalized in <a href="#identified-entity-in-account">identified-entity-in-account</a>.</p>
+
+<div class='constraint' id='identified-entity-in-account'>
+Given an entity record identifier <span class="name">e</span>, two sets of attribute-values denoted by <span class="name">av1</span> and <span class="name">av2</span>,
+ two entity records <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account are equivalent to the entity record <span class="name">entity(e,av)</span> where <span class="name">av</span> is the set of attribute-value pairs formed by the union of <span class="name">av1</span> and <span class="name">av2</span>.
+</div>
+
+<p>Whilst constraint <a href="#identified-entity-in-account">identified-entity-in-account</a> specifies how to understand multiple entity records with a same identifier within a given account, it does not guarantee that the entity record formed with the union of all attribute-value pairs is consistent. Indeed, a given attribute may be assigned multiple values, resulting in an inconsistent entity record, as illustrated by the following example.</p>
+
+<div class="anexample">
+<p>
+In the following account record, we find two entity records with a same identifier <span class="name">e</span>.</p>
+<pre class="codeexample">
+account(ex:acc1,
+ http://example.org/id,
+ entity(e,[prov:type="person", ex:age=20])
+ entity(e,[prov:type="person", ex:age=30])
+ ...)
+</pre>
+<p>Application of <a href="#identified-entity-in-account">identified-entity-in-account</a> results in an entity record containing the attribute-value pairs <span class="name">age=20</span> and <span class="name">age=30</span>. This results in an inconsistent characterization of a person. We note that deciding whether a set of attribute-values is consistent or not is application specific and outside the scope of this specification.
+</p></div>
+
+<p>Account records can be nested since an account record can occur among the records being wrapped by another account. </p>
+
+
+<p>
+An account is said to be well-formed if
+it satisfies the constraints <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>.</p>
+
+<p> The union of two accounts is another account,
+containing the unions of their respective records, where
+ records with a same identifier should be understood according to constraint <a href="#identified-entity-in-account">identified-entity-in-account</a>. Well-formed
+accounts are not
+closed under union because the
+constraint <a href="#generation-unicity">generation-unicity</a> may no
+longer be satisfied in the resulting union. </p>
+
+<div class="anexample">
+<p>
+Indeed, let us consider another account record</p>
+<pre class="codeexample">
+account(ex:acc2,
+ http://example.org/asserter2,
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+ ...
+ activity(a1,create-file,t1)
+ ...
+ 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-unicity">generation-unicity</a>.</p>
+</div>
+
+<p>Account records constitute a scope for record identifiers. Since accounts can be nested, scopes can also be nested; thus, the scope of record identifiers should be understood in the context of such nested scopes. When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur. </p>
+
+<div class="anexample">
+<p>
+The following account record is inspired from section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>. This account, identified by <span class="name">ex:acc3</span>, declares entity record with identifier <span class="name">e0</span>, which is being referred to in the nested account <span class="name">ex:acc4</span>. The scope of identifier <span class="name">e0</span> is account <span class="name">ex:acc3</span>, including subaccount <span class="name">ex:acc4</span>.</p>
+<pre class="codeexample">
+account(ex:acc3,
+ http://example.org/asserter1,
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+ activity(a0,create-file,t)
+ wasGeneratedBy(e0,a0,[])
+ account(ex:acc4,
+ http://example.org/asserter2,
+ entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
+ activity(a0,copy-file,t)
+ wasGeneratedBy(e1,a0,[ex:fct="create"])
+ wasComplementOf(e1,e0)))
+</pre>
+<p>Alternatively, an activity record identified by <span class="name">a0</span> occurs in each of the two accounts. Therefore, each activity record is asserted in a separate scope, and therefore may represent different activities in the world.
+</p>
+</div>
+
+<p>The account record is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. The annotation mechanism can be used for this purpose, but how general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>
+
+
+</section>
+
+<section id="RecordContainer">
+<h4>Record Container</h4>
+
+<p>A <dfn id="dfn-RecordContainer">record container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM records. A record container is not a record, but can be exploited to return assertions in response to a request for the provenance of something ([[PROV-PAQ]]). </p>
+
+<p>
+
+
+<p>A record container, written <span class="name">container decls recs endContainer</span> in PROV-ASN, contains:
+<ul>
+<li><em>namespaceDeclarations</em>: a set <span class="name">decls</span> of namespace declarations, declaring namespaces and associated prefixes, which can be used in <a title="attribute">attributes</a> and <a title="identifier">identifiers</a> occurring inside <span class="name">recs</span>;</li>
+<li><em>records</em>: a non-empty set of records <span class="name">recs</span>.</li>
+</ul>
+<p>All the records in <span class="name">recs</span> are implictly wrapped in a default account, scoping all the record identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts. Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a container's default account.</p>
+
+<p>In PROV-ASN, a record container's text matches the <span class="nonterminal">recordContainer</span> production of the grammar defined in this specification document.</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">recordContainer</span> ::=
+<span class="name">container</span>
+<span class="nonterminal">namespaceDeclarations</span>
+<span class="plus"> <span class="nonterminal">record</span> </span>
+<span class="name">endContainer</span>
+</div>
+
+
+<div class="anexample">
+<p>
+The following container </p>
+<pre class="codeexample">
+container
+ prefix ex: http://example.org/,
+
+ account(ex:acc1,http://example.org/asserter1,...)
+ account(ex:acc2,http://example.org/asserter1,...)
+endContainer
+</pre>
+<p> illustrates how two accounts with identifiers <span class="name">ex:acc1</span> and <span class="name">ex:acc2</span> can be returned in a PROV-ASN serialization of the provenance of something.
+</p>
+</div>
+
+
+<div class='pending'>Asserter needs to be defined. This is <a href="http://www.w3.org/2011/prov/track/issues/51">ISSUE-51</a>.</div>
+
+
+<div class='pending'>Scope and Identifiers. This is <a href="http://www.w3.org/2011/prov/track/issues/81">ISSUE-81</a>.</div>
+
+
+</section>
+</section>
+
+
+<section id="sub-record">
+<h3>Further Terms in Records</h3>
+
+This section further terms in PROV-DM records.
+
+
+
+<section id="record-attribute">
+<h4>Attribute</h4>
+
+<p>An <dfn id="dfn-attribute">attribute</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
+ by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
+
+<div class='grammar'>
+<span class="nonterminal">attribute</span> ::= <span class="nonterminal">qualifiedName</span><br/>
+<span class="nonterminal">qualifiedName</span> ::= <span class="nonterminal">prefixedName</span> | <span class="nonterminal">unprefixedName</span><br/>
+<span class="nonterminal">prefixedName</span> ::= <span class="nonterminal">prefix</span> <span class="name">:</span> <span class="nonterminal">localPart</span><br/>
+<span class="nonterminal">unprefixedName</span> ::= <span class="nonterminal">localPart</span><br/>
+<span class="nonterminal">prefix</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [[!XML-NAMES]]</em><br/>
+<span class="nonterminal">localPart</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [[!XML-NAMES]]</em>
+</div>
+
+<p>A qualified name's prefix is OPTIONAL. If a prefix occurs in a
+ qualified name, it refers to a <a>namespace</a> declared in the
+ record container. In the absence of prefix, the qualified name
+ refers to the default namespace declared in the container.</p>
+
+<div class="note">Note that XML NC_NAME don't allow local identifiers to start with a number. Instead, should we use the productions used in SPARQL or TURTLE?</div>
+
+<p>From this specification's viewpoint, the interpretation of an attribute declared in a namespace other than prov-dm is out of
+scope.</p>
+
+<p>The PROV data model introduces a fixed set of attributes in the <a href="#prov-dm-namespace">PROV-DM namespace</a>:</p>
+<ul>
+<li> The attribute <dfn id="dfn-role"><span class="name">prov:role</span></dfn> denotes the function of an entity with respect to an activity, in the context of a usage, generation, activity association, start, end record. The value associated with a <span class="name">prov:role</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>.
+
+<div class="anexample">
+<p>The following start record describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
+<pre class="codeexample">
+ wasStartedBy(a,ag, [prov:role="program-operator"])
+</pre>
+</div>
+ </li>
+
+<li> The attribute <dfn id="dfn-type"><span class="name">prov:type</span></dfn> provides further typing information for the element or relation asserted in the record. The value associated with a <span class="name">prov:type</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>.
+
+<div class="anexample">
+<p>The following record declares an agent of type software agent</p>
+<pre class="codeexample">
+ agent(ag, [prov:type="prov:SoftwareAgent" %% xsd:QName])
+</pre>
+</div>
+
+
+<li> The attribute <dfn id="dfn-steps"><span class="name">prov:steps</span></dfn> defines the level of precision associated with a derivation record. The value associated with a <span class="name">prov:steps</span> attribute MUST be <span class="name">"1"</span> or <span class="name">"n"</span>. </li>
+
+</ul>
+</section>
+
+
+
+<section id="record-identifier">
+<h4>Identifier</h4>
+
+
+<p>An <dfn id="dfn-identifier">identifier</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
+ by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
+
+<div class='grammar'>
+<span class="nonterminal">identifier</span> ::= <span class="nonterminal">qualifiedName</span><br/>
+<span class="nonterminal">eIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an entity record)</em><br/>
+<span class="nonterminal">aIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an activity record)</em><br/>
+<span class="nonterminal">agIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an agent record)</em><br/>
+<span class="nonterminal">gIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a generation record)</em><br/>
+<span class="nonterminal">uIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a usage record)</em><br/>
+<span class="nonterminal">nIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a note record)</em><br/>
+<span class="nonterminal">accIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote an account record)</em>
+</div>
+
+
+</section>
+
+<section id="record-literal">
+<h4>Literal</h4>
+
+<p>
+A PROV-DM Literal represents a data value such as a particular string
+or number. A PROV-DM Literal represents a value whose interpretation is outside the scope of PROV-DM.
+</p>
+
+<p>In PROV-ASN, a Literal's text matches the <span class="nonterminal">Literal</span> production of the grammar defined in this specification document.</p>
+
+<div class='grammar'>
+<span class="nonterminal">Literal</span> ::= <span class="nonterminal">typedLiteral</span> | <span class="nonterminal">convenienceNotation</span> <br/>
+<span class="nonterminal">typedLiteral</span> ::= <span class="nonterminal">quotedString</span> <span class="name">%%</span> <span class="nonterminal">datatype</span><br/>
+<span class="nonterminal">datatype</span> ::= <span class="nonterminal">qualifiedName</span><br/>
+<span class="nonterminal">convenienceNotation</span> ::= <span class="nonterminal">stringLiteral</span> | <span class="nonterminal">intLiteral</span><br/>
+<span class="nonterminal">stringLiteral</span> ::= <span class="nonterminal">quotedString</span><br/>
+<span class="nonterminal">quotedString</span> ::= <em>a finite sequence of characters in which " (U+22) and \ (U+5C) occur only in pairs of the form \" (U+5C, U+22) and \\ (U+5C, U+5C), enclosed in a pair of " (U+22) characters</em><br/>
+<span class="nonterminal">intLiteral</span> ::= <em>a finite-length sequence of decimal digits (#x30-#x39) with an optional leading negative sign (-)</em>
+</div>
+
+<p>The non terminals <span class="nonterminal">stringLiteral</span> and
+<span class="nonterminal">intLiteral</span>
+are syntactic sugar for quoted strings with datatype <span class="name">xsd:string</span> and <span class="name">xsd:int</span>, respectively.
+</p>
+
+<p> In particular, a PROV-DM Literal may be an IRI-typed string (with datatype <span class="name">xsd:anyURI</span>); such IRI has no specific interpretation in the context of PROV-DM.</p>
+
+
+<div class="anexample">
+<p>
+The following examples respectively are the string "abc" (expressed using the convenience notation), the string "abc", the integer number 1, the integer number 1 (expressed using the convenience notation) and the IRI "http://example.org/foo".
+<pre class="codeexample">
+ "abc"
+ "abc" %% xsd:string
+ "1" %% xsd:int
+ 1
+ "http://example.org/foo" %% xsd:anyURI
+</pre>
+The following example shows a literal of type <span class="name">xsd:QName</span> (see
+<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#QName">QName</a> [[!XMLSCHEMA-2]]).
+The prefix <span class="name">ex</span> MUST be bound to a <a>namespace</a> declared in the
+ record container.
+<pre class="codeexample">
+ "ex:value" %% xsd:QName
+</pre>
+</div>
+
+
+
+<div class='note'>Should we define structural equivalence of literals as in OWL2? [[!OWL2-SYNTAX]]
+(see section <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Literals">Literals</a>).
+</div>
+
+</section>
+
+
+
+
+<section id="record-Time">
+<h4>Time</h4>
+
+<p><dfn id="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [[!XMLSCHEMA-2]].</p>
+
+
+
+<p>It is OPTIONAL to assert time in usage, generation, and activity records.</p>
+
+
+
+
+</section>
+
+<section id="record-Asserter">
+<h3>Asserter</h3>
+
+<p>An <dfn id="dfn-asserter">asserter</dfn> is a creator of PROV-DM records. An asserter is denoted by an IRI. Such IRI has no specific interpretation in the context of PROV-DM.</p>
+
+<div class='grammar'>
+<span class="nonterminal">asserter</span> ::= <span class="nonterminal">IRI</span><br/>
+<span class="nonterminal">IRI</span> ::= <em>an IRI compatible with production IRI in [[!IRI]], enclosed in a pair of < (U+3C) and > (U+3E) characters </em>
+</div>
+
+<div class='note'>
+Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM. We seek inputs on how to resolve this issue. </div>
+
+</section>
+
+<section id="record-NamespaceDeclaration">
+<h3>Namespace Declaration</h3>
+
+<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [[!IRI]]. In PROV-DM, attributes, identifiers, and literals of with datatype <span class="name">xsd:QName</span> can be placed in a namespace using the mechanisms described in this specification. </p>
+
+
+<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this declaration refers to this namespace.
+A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration refers to this namespace.</p>
+
+<div class='grammar'>
+<span class="nonterminal">namespaceDeclarations</span> ::=
+ | <span class="group"><span class="nonterminal">defaultNamespaceDeclaration</span> | <span class="nonterminal">namespaceDeclaration</span></span> <span class="star"> <span class="nonterminal">namespaceDeclaration</span></span><br>
+<span class="nonterminal">namespaceDeclaration</span> ::=
+<span class="name">prefix</span> <span class="nonterminal">prefix</span> <span class="nonterminal">IRI</span><br/>
+<span class="nonterminal">defaultNamespaceDeclaration</span> ::=
+ <span class="name">default</span> <span class="nonterminal">IRI</span> <br/>
+</div>
+</section>
+
+
+<section id="record-RecipeLink">
+<h3>Recipe Link</h3>
+
+
+<p>A <dfn id="dfn-RecipeLink">recipe link</dfn> is an association between an activity record and a process specification that underpins the represented activity. Such IRI has no specific interpretation in the context of PROV-DM.
+</p>
+
+<div class='grammar'>
+<span class="nonterminal">recipeLink</span> ::= <span class="nonterminal">IRI</span>
+</div>
+
+<p>
+It is OPTIONAL to assert recipe links in activities.
+</p>
+
+
+<p>
+Process specifications, as referred to by recipe links, are out of scope of this specification.
+</p>
+
+<div class="note">
+By defining a recipe link as an IRI whose interpretation is out of
+scope of PROV-DM, we don't allow it to refer to an entity (in an
+inter-operable manner). Is this what we intend?
+</div>
+
+<div class='issue'> Simplify the references to recipe link. This is <a href="http://www.w3.org/2011/prov/track/issues/131">ISSUE-131</a></div>
+
+</section>
+
+
+
+
+
+<section id="record-Location">
+<h3>Location</h3>
+
+<p><dfn id="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, row, column, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations in assertions. </p>
+
+
+<p>
+Location is an OPTIONAL attribute of entity records and activity records. The value associated with a attribute <span class="name">location</span> MUST be a <span class="nonterminal">Literal</span>, expected to denote a location.
+</p>
+
+
+
+
+</section>
+
+</section>
+
+</section>
+
+
+ <section id="common-relations">
+<h2>PROV-DM Common Relations</h2>
+
+<p>This section contains the normative specification of common relations of PROV-DM.</p>
+
+
+<div class='issue'>We have defined a set of common relation, in response to <a href="http://www.w3.org/2011/prov/track/issues/44">ISSUE-44</a>. Is this set complete?</div>
+
+
+<div class='note'>The types of these relations need to be made explicit.</div>
+
+<p>The following figure summarizes the additional relations described in subsections 6.2 onwards.</p>
+
+<div style="text-align: center;">
+<img src="sec6-summary.png" alt="common relations"/>
+</div>
+
+
+<section id="record-Collection">
+<h3>Collections</h3>
+
+The purpose of this section is to enable modelling of part-of relationships amongst entities. In particular, a form of <strong>collection</strong> entity type is introduced, consisting of a set of key-value pairs. Key-value pairs provide a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more.<br/>
+
+The relations introduced here are all specializations of the <a href="#record-Derivation"><strong>wasDerivedFrom</strong></a> relation, specifically precise-1 or imprecise-1. They are designed to model:
+
+<ul>
+ <li><strong>insertion</strong>: a collection entity c' is obtained from collection entity c, by adding entity e having key k to c;
+ <li><strong>removal</strong>: a collection entity c' is obtained from collection entity c, by removing entity e having key k from c;
+ <li><strong>selection</strong>: an entity e was selected from collection c using key k.
+ </ul>
+
+ A collection record is defined as follows.
+<div class='grammar'>
+ <span class="nonterminal">collectionRecord</span> ::=
+<span class="nonterminal">collectionDerivationRecord</span>
+| <span class="nonterminal">keyDerivationRecord</span>
+| <span class="nonterminal">entityMembershipRecord</span>
+<br/>
+
+ <span class="nonterminal">collectionDerivationRecord</span> ::=
+<span class="name">wasAddedTo_Coll</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+ |
+<span class="name">wasRemovedFrom_Coll</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+<br/>
+
+ <span class="nonterminal">keyDerivationRecord</span> ::=
+<span class="name">wasAddedTo_Key</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+|
+<span class="name">wasRemovedFrom_Key</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+ <br/>
+
+ <span class="nonterminal">entityMembershipRecord</span> ::=
+<span class="name">wasAddedTo_Entity</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+<br/>
+ </div>
+
+<p> Record: <span class="name">wasAddedTo_Coll(c2,c1)</span> (resp. <span class="name">wasRemovedFrom_Coll(c2,c1)</span>) denotes that collection <span class="name">c2</span> is an updated version of collection <span class="name">c1</span>, following an insertion (resp. deletion) operation.</p>
+
+<p> Record: <span class="name">wasAddedTo_Key(c,k)</span> (resp. <span class="name">wasRemovedFrom_Key(c,k)</span>) denotes that collection <span class="name">c</span> had
+ a new value with key <span class="name">k</span> added to (resp. removed from) it.</p>
+
+<p> Record: <span class="name">wasAddedTo_Entity(c,e)</span> denotes that collection <span class="name">c</span> had entity
+ <span class="name">e</span> added to it.
+</p>
+
+
+<div class="anexample">
+<p>Consider the following assertions:</p>
+<pre class="codeexample">
+
+
+ <span class="name">wasAddedTo_Coll(c2,c1)</span>
+ <span class="name">wasAddedTo_Key(c2,k1)</span>
+ <span class="name">wasAddedTo_Entity(c2,e1)</span>
+
+ <span class="name">wasAddedTo_Coll(c3,c2)</span>
+ <span class="name">wasAddedTo_Key(c3,k2)</span>
+ <span class="name">wasAddedTo_Entity(c3,e2)</span>
+
+ <span class="name">wasRemovedFrom_Coll(c4,c3)</span>
+ <span class="name">wasRemovedFrom_Key(c4,k1)</span>
+</pre>
+<p>The corresponding graphical representation is shown below.</p>
+
+<div style="text-align: center;">
+<img src="collections.png" alt="collections"/>
+</div>
+
+
+<p> With these assertions:</p>
+ <ul>
+ <li><span class="name">c2</span> is known to contain the key-value pair <span class="name">(k1,e1)</span>
+ <li><span class="name">c3</span> is known to contain pairs <span class="name">(k1,e1)</span> and <span class="name">(k2,e2)</span>.
+ <li><span class="name">c4</span> is known <em>not</em> to contain pair <span class="name">(k1,e1)</span> and to contain pair <span class="name">(k2,e2)</span>.
+ </ul>
+</div>
+
+ </section>
+
+<section id="record-traceability">
+<h3>Traceability Record</h3>
+
+<p> A <dfn id="dfn-Traceability">traceability record</dfn> states the existence of a "dependency path" between two entities, indicating that one entity can be shown to be in the lineage of another, and may have influenced it in some way. This relation is transitive. </p>
+
+<p> A traceability record, written <span class="name">tracedTo(id,e2,e1,attrs)</span> in PROV-ASN:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the traceability record;</li>
+<li><em>entity</em>: an identifier <span class="name">e2</span> identifying an entity;
+<li><em>ancestor</em>: an identifier <span class="name">e1</span> identifying an ancestor entity in the lineage of <span class="name">e2</span>;
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p>In PROV-ASN, a traceability record's text matches the <span class="nonterminal">traceabilityRecord</span> production of the grammar defined in this specification document.</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">traceabilityRecord</span> ::=
+<span class="name">tracedTo</span>
+<span class="name">(</span>
+<span class="optional"><span class="nonterminal">identifier</span>
+<span class="name">,</span></span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<p>A traceability record can be inferred from existing relations, or can be asserted stating that such a dependency path exists without the asserter knowing its individual steps, as expressed by the following constraints.
+
+<div class='constraint' id='traceability-inference'>
+Given two identifiers <span class="name">e2</span> and <span class="name">e1</span> identifying entity records,
+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>
+
+<div class='constraint' id='traceability-assertion'>
+<span class='conditional'>If</span> the record <span class="name">tracedTo(r2,r1)</span> holds
+for two identifiers <span class="name">r2</span> and <span class="name">r1</span> identifying entity records,
+ <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 record. </p>
+
+
+</section>
+
+<section id="record-OrderingOfActivities">
+<h3>Activity Ordering Record</h3>
+
+
+
+<p>PROV-DM allows dependencies amongst activities to be expressed.
+An <dfn id="InformationFlowOrdering">information flow ordering record</dfn> is a representation that an entity was generated by an activity, before it was used by another activity.
+A <dfn id="ControlOrdering">control ordering record</dfn> is a representation that an activity was initiated by another activity.
+</p>
+
+<p>In PROV-ASN, an activity ordering record's text matches the <span class="nonterminal">activityOrderingRecord</span> production of the grammar defined in this specification document.
+</p>
+
+<div class='grammar'>
+<span class="nonterminal">activityOrderingRecord</span> ::=
+<span class="nonterminal">informationFlowOrderingRecord</span> |
+<span class="nonterminal">controlOrderingRecord</span>
+<br/>
+
+<span class="nonterminal">informationFlowOrderingRecord</span> ::=
+<span class="name">wasInformedBy</span>
+<span class="name">(</span>
+<span class="optional"><span class="nonterminal">identifier</span>
+<span class="name">,</span>
+</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+<br/>
+
+<span class="nonterminal">controlOrderingRecord</span> ::=
+<span class="name">wasStartedBy</span>
+<span class="name">(</span>
+<span class="optional"><span class="nonterminal">identifier</span>
+<span class="name">,</span>
+</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+<br/>
+</div>
+
+
+<p>
+An information flow ordering record, written as
+<span class="name">wasInformedBy(id,a2,a1,attrs)</span> in PROV-ASN, contains:
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the record;</li>
+<li><em>informed</em>: the identifier <span class="name">a2</span> of an activity record representing the informed activity;
+<li><em>informant</em>: the identifier <span class="name">a1</span> of an activity record representing the informant activity;
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p> An information flow ordering record is formally defined as follows.</p>
+
+<div class='constraint' id='wasInformedBy-Definition'>Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
+ the record <span class="name">wasInformedBy(a2,a1)</span>
+holds, <span class='conditional'>if and only if</span>
+ there is an entity record identified by <span class="name">e</span> and 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' id='wasInformedBy-ordering'>
+Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span class="name">wasInformedBy(a2,a1)</span>
+ holds, <span class='conditional'>then</span> the following temporal constraint holds:
+the <a title="activity start event">start event</a> of the activity record denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity end event">end event</a> of
+the activity record denoted by <span class="name">a2</span>.
+</div>
+
+
+<p>The relationship <span class="name">wasInformedBy</span> is not transitive. Indeed, consider the following records.</p>
+<pre class="codeexample">
+wasInformedBy(a2,a1)
+wasInformedBy(a3,a2)
+</pre>
+<p> We cannot infer <span class="name">wasInformedBy(a3,a1)</span> from them. 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 where transitivity cannot hold. The horizontal axis represents time. 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;">
+<img src="informedByNonTransitive.png" alt="non transitivity of wasInformedBy" />
+</div>
+
+<div class="note">
+The relation wasScheduledAfter was dropped, and replaced by a simplier relation wasStartedBy(a2,a1). It is intentional that the name wasStartedBy is overloaded.
+</div>
+
+<p>
+A control ordering record, written as
+<span class="name">wasStartedBy(a2,a1)</span> in PROV-ASN, contains: </p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span>;</li>
+<li><em>started</em>: refers to an activity record identified by <span class="name">a2</span>, representing the started activity;
+<li><em>starter</em>: refers to an activity record identified by <span class="name">a1</span>, representing the activity that started <span class="name">a1</span>;</li>
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+<p>Such a record states control ordering between <span class="name">a2</span> and <span class="name">a1</span>, specified as follows.</p>
+
+<div class='constraint' id='wasStartedBy'>Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
+ the record <span class="name">wasStartedBy(a2,a1)</span>
+holds <span class='conditional'>if and only if</span>
+ there exist an entity record identified by <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>
+
+
+<div class="anexample">
+<p>
+In the following assertions, we find two activity records, identified by <span class="name">a1</span> and <span class="name">a2</span>, representing two activities, which took place on two separate hosts. The third record indicates that the latter activity was started by the former.</p>
+<pre class="codeexample">
+activity(a1,workflow,t1,t2,[ex:host="server1.example.org"])
+activity(a2,sub-workflow,t3,t4,[ex:host="server2.example.org"])
+wasStartedBy(a2,a1)
+</pre>
+
+<p>Alternatively, we could have asserted the existence of an entity, representing a request to create a sub-workflow. This request, issued by <span class="name">a1</span>, triggered the start of <span class="name">a2</span>.
+</p>
+<pre class="codeexample">
+entity(e,[prov:type="creation-request"])
+wasGeneratedBy(e,a1)
+wasStartedBy(a2,e)
+</pre>
+</div>
+
+<div class='interpretation' id='wasStartedBy-ordering'>
+Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span class="name">wasStartedBy(a2,a1)</span>
+ holds, <span class='conditional'>then</span> the following temporal constraint holds: the
+<a title="activity start event">start</a> event of the activity record denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity start event">start event</a> of
+the activity record denoted by <span class="name">a2</span>.
+</div>
+
+
+
+<div class='pending'>Suggested definition for process ordering. This is <a href="http://www.w3.org/2011/prov/track/issues/50">ISSUE-50</a>.</div>
+
+</section>
+
+<section id="record-Revision">
+<h3>Revision Record</h3>
+
+<p> A <dfn id="dfn-Revision">revision record</dfn> is a representation of the creation of an entity considered to be a variant of another. Deciding whether something is made available as a revision of something else usually involves an agent who represents someone in the world who takes responsibility for approving that the former is a due variant of the latter. </p>
+
+<p> A revision record, written <span class="name">wasRevisionOf(e2,e1,ag,attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>newer</em>: an identifier <span class="name">e2</span> identifying an entity that represents a newer version of an entity;
+<li><em>older</em>: an identifier <span class="name">e1</span> identifying an entity that represents an older version of an entity;
+<li><em>responsibility</em>: an OPTIONAL identifier <span class="name">ag</span> for the agent who approved that <span class="name">e2</span> is a variant of <span class="name">e1</span>;
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+
+<p>In PROV-ASN, a revision record's text matches the <span class="nonterminal">revisionRecord</span> production of the grammar defined in this specification document.
+</p>
+
+<div class='grammar'>
+<span class="nonterminal">revisionRecord</span> ::=
+<span class="name">wasRevisionOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="optional"><span class="name">,</span>
+<span class="nonterminal">agIdentifier</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+
+
+
+<p>A revision record needs to satisfy the following constraint, linking the two entity records by a derivation, and stating them to be a complement of a third entity record.</p>
+
+<div class='constraint' 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> a record <span class="name">wasRevisionOf(new,old,ag)</span> is asserted, <span class='conditional'>then</span>
+there exists an entity record identifier <span class="name">e</span> and attribute-values <span class="name">eAttrs</span>, <span class="name">dAttrs</span>, such that the following records hold:
+<ul>
+<li> <span class="name">wasDerivedFrom(new,old,dAttrs)</span>;
+<li> <span class="name">entity(e,eAttrs)</span>;
+<li> <span class="name">wasComplementOf(new,e)</span>;
+<li> <span class="name">wasComplementOf(old,e)</span>.
+</ul>
+The derivation record may be imprecise-1 or imprecise-n.
+</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>
+
+<div class="anexample">
+<p>
+The following revision assertion</p>
+<pre class="codeexample">
+agent(ag,[prov:type="QualityController"])
+entity(e1,[prov:type="document"])
+entity(e2,[prov:type="document"])
+wasRevisionOf(e2,e1,ag)
+</pre>
+<p>states that the document represented by entity record identified by <span class="name">e2</span> is a revision of document represented by entity record identified by <span class="name">e1</span>; agent denoted by <span class="name">ag</span> is responsible for this new versioning of the document.
+</p>
+</div>
+
+
+<div class='pending'>Revision should be a class not a property. This is <a href="http://www.w3.org/2011/prov/track/issues/48">ISSUE-48</a>.</div>
+
+
+</section>
+
+
+<section>
+<h3>Attribution Record</h3>
+
+<p>An attribution record represents that an entity is ascribed to an agent and is compliant with the <span class="nonterminal">attributionRecord</span> production.</p>
+
+
+<p> An attribution record, written <span class="name"> wasAttributedTo(e,ag,attr)</span>, contains the following components:</p>
+<ul>
+<li><em>entity</em>: an identifier <span class="name">e</span> of an entity record;</li>
+<li><em>agent</em>: an identifier <span class="name">ag</span> of an agent whom the entity is attributed to;</li>
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+<p>Attribution models the notion of an activity generating an entity identified by <span class="name">e</span> being controlled by an agent <span class="name">ag</span>, which takes responsibility for generating <span class="name">e</span>. Formally, this is expressed as the following necessary condition.</p>
+
+<p>In PROV-ASN, an attribution record's text matches the <span class="nonterminal">attributionRecord</span> production of the grammar.</p>
+
+<div class='grammar'>
+<span class="nonterminal">attributionRecord</span> ::=
+<span class="name">wasAttributedTo</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<div class='constraint' 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 identified by <span class="name">pe</span> such that the following statements hold:
+<pre>
+activity(pe,recipe,t1,t2,attr1)
+wasGenerateBy(e,pe)
+wasAssociatedWith(pe,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>
+<h3>Quotation Record</h3>
+
+
+<p> A quotation record is a representation of the repeating or copying of some part of an entity, compatible with
+the <span class="nonterminal">quotationRecord</span> production.</p>
+
+
+<p> A quotation record, written <span class="name"> wasQuotedFrom(e2,e1,ag2,ag1,attrs)</span>, contains:</p>
+<ul>
+<li><em>quote</em>: an identifier <span class="name">e2</span>, identifying an entity record that represents the quote;
+<li><em>quoted</em>: an identifier <span class="name">e1</span>, identifying an entity record representing what is being quoted;
+<li><em>quoterAgent</em>: an OPTIONAL identifier <span class="name">ag2</span> of the agent who is doing the quoting;
+<li><em>quotedAgent</em>: an OPTIONAL identifier <span class="name">ag1</span> of the agent that is quoted;
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+
+</ul>
+
+<p>In PROV-ASN, a quotation record's text matches the <span class="nonterminal">quotationRecord</span> production of the grammar.</p>
+
+<div class='grammar'>
+<span class="nonterminal">quotationRecord</span> ::=
+<span class="name">wasQuotedFrom</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">agIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+
+<div class='constraint' id='quotation-implication'>
+<span class='conditional'>If</span>
+<span class="name">wasQuotedFrom(e2,e1,ag2,ag1)</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 records hold:
+<pre>
+wasDerivedFrom(e2,e1)
+wasAttributedTo(e2,ag2)
+wasAttributedTo(e1,ag1)
+</pre>
+</div>
+
+</section>
+
+
+<section>
+<h3>Summary Record</h3>
+<p>A <dfn>summary record</dfn> represents that an entity is a synopsis or abbreviation of another entity. A summary record is compliant with the
+<span class="nonterminal">summaryRecord</span> production.</p>
+
+
+
+<p> An assertion wasSummaryOf, written <span class="name"> wasSummaryOf(e2,e1,attrs)</span>, contains:</p>
+<ul>
+<li><em>summarizedEntity</em>: an identifier <span class="name">e2</span> for the entity record that represents the summary;
+<li><em>fullEntity</em>: an identifier <span class="name">e1</span> for the entity record that represents what is being summarized;
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p>In PROV-ASN, a summary record's text matches the <span class="nonterminal">summaryRecord</span> production of the grammar.</p>
+
+<div class='grammar'>
+<span class="nonterminal">summaryRecord</span> ::=
+<span class="name">wasSummaryOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<p>
+<span class="name">wasSummaryOf</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
+</p>
+
+
+</section>
+
+<section>
+<h3>Original Source Record</h3>
+
+<p>An <dfn>original source record</dfn> represents an entity in
+which another entity first appeared. A original-source
+record is compliant with the
+<span class="nonterminal">originalSourceRecord</span> production.</p>
+
+
+<p> An assertion hadOriginalSource, written <span class="name"> hadOriginalSource(e2,e1,attrs)</span>, contains:</p>
+<ul>
+<li><em>entity</em>: an identifier <span class="name">e1</span> for the entity record representing the original entity; </li>
+<li><em>source</em>: an identifier <span class="name">e2</span> for an entity record, representing an entity that had appeared previously;</li>
+<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p>
+ <span class="name">hasOriginalSource</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
+</p>
+
+<p>In PROV-ASN, an original source record's text matches the <span class="nonterminal">originalSourceRecord</span> production of the grammar.</p>
+
+<div class='grammar'>
+<span class="nonterminal">originalSourceRecord</span> ::=
+<span class="name">hadOriginalSource</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+</section>
+</section>
+
+ <section id="extensibility-section">
+<h2>PROV-DM Extensibility Points</h2>
+
+
+<p>The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
+
+<ul>
+<li> Attributes are constructs of the data model that allow representations of aspects of the world's entities and activities to be expressed. Applications are free to introduce application-specific attributes, according to their perspective on the world. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace declared in a namespace declaration.
+
+<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes: <span class="name">type</span>, <span class="name">location</span>.</li>
+
+
+<li> Sets of Attribute-value pairs offer a mechanism to
+describe modalities of use, generation, and control
+Such attributes are also qualified by namespaces.
+
+<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
+
+
+<li>Note records allow arbitrary metadata to be associated with identifiable records of PROV-DM. Note records consist of name-value pairs. Like attributes, names are qualified by a namespace.</li>
+
+
+<li>Namespaces allow attributes and names to be qualified. </li>
+
+<li>Subtyping is allowed by means of the reserved attribute <span class="name">type</span>.</li>
+
+<li>Domain specific values can be expressed by means of typed literals. </li>
+</ul>
+
+<p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged. To ensure inter-operability, specializations of the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in this document. For instance, a qualified attribute on a domain specific entity record MUST represent an aspect of an entity and this aspect MUST remain unchanged during the characterization's interval of this entity record.</p>
+
+
+
+ </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 example 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-ASN sample below, are expressed within a same account.
+</p>
+
+<pre>
+container
+prefix app urn:example:
+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 idenfier that identifies the entity it represents.
+In this example, three identifiers were minted, and their prefix uses the URN syntax with "example" namespace.</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 a PROV-DM identifier, it identifies a specific characterization of this report. A given identifier identifies a single entity record 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. </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 perspective we take about that resource is expressed as a different entity record, happening to have the same identifier 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 urn:example:
+ 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 class="appendix">
+ <h2>Changes Since First Public Working Draft</h2>
+<ul>
+<li>12/08/11: Explained non-transitivity of wasInformedBy. </li>
+<li>12/05/11: Made attributes optional, and used non-terminal optional-attribute-values. </li>
+<li>12/05/11: Changed syntax of recordContainer to be more user friendly, and removed list of account ids, since redundant. </li>
+<li>12/05/11: Changed syntax of namespace declaration to be more user friendly. </li>
+<li>12/05/11: Simplified Typed literals, now allows for intLiteral, and datatype adjusted to be qualified name. </li>
+<li>11/29/11: Introduced typed identifiers to make grammar clearer. </li>
+<li>11/29/11: Added section 2.4 on grammar notation. </li>
+<li>11/28/11: Changed grammar notation. </li>
+<li>11/25/11: Updated examples of section 8. </li>
+<li>11/25/11: Definition of namespace. Clarification about interpretation of IRI occurrences. </li>
+<li>11/25/11: Definition of attribute and identifier. </li>
+<li>11/24/11: Added figure of Common Relations in Section 6. </li>
+<li>11/24/11: Updated text preceding graphical illustration, removed appendix A. </li>
+<li>11/24/11: Fix on traceability record. </li>
+<li>11/24/11: Revisited Derivation record, with a single name for derivation. </li>
+<li>11/23/11: Defined attribute, identifier, and namespace declaration. </li>
+<li>11/23/11: Consolidation of event in section 2.1.2 and linking to definitions from the rest of document. </li>
+<li>11/21/11: Added wasStartedBy between activities.</li>
+<li>11/21/11: Added wasInformedBy-ordering constraint.</li>
+<li>11/17/11: Added Traceability Record.</li>
+<li>11/17/11: Rewrote the whole section on Derivation Record.</li>
+<li>11/17/11: Updated wasDerivedFrom to refer to generation/usage record ids.</li>
+<li>11/17/11: Simplified hasAnnotation mechanism, now requiring to-be-annotated record to had id.</li>
+<li>11/17/11: Renamed annotation into note.</li>
+<li>11/17/11: Introduced wasStartedBy, wasEndedBy, and actedOnBehalfOf.</li>
+<li>11/16/11: New version of agent/wasAssociatedWith.</li>
+<li>11/16/11: Introduced class anexample.</li>
+<li>11/16/11: Changed presentation of entity and activity.</li>
+<li>11/16/11: Updated examples for usage and generation record.</li>
+<li>11/16/11: Renamed use record into usage record.</li>
+<li>11/16/11: Removed constraint generation-affects-attributes.</li>
+<li>11/16/11: Removed constraint use-attributes.</li>
+<li>11/16/11: Introduced optional identity for use and generation record.</li>
+<li>11/11/11: Swapped sections 6 and 7.</li>
+<li>11/11/11: Use attribute-value pairs uniformly, instead of qualifiers and name-value pairs.</li>
+<li>11/08/11: Renamed 'provenance container' into 'record container'.</li>
+<li>11/07/11: Addressed ISSUE-143 (qualifiers as a set of name value pairs).</li>
+<li>11/07/11: Added a section on Literals (ISSUE-142).</li>
+<li>11/07/11: Aligned terminology 'activity' and 'process execution record'.</li>
+<li>11/07/11: Renamed 'xxx Expression' into 'xxx Record' to avoid the language connotation.</li>
+<li>11/07/11: Defined entity as identifiable characterized thing, and updated text accordingly.</li>
+<li>10/08/11: Made explicit the term expression wherever was appropriate, including section titles.</li>
+</ul>
+ </section>
+
+<section class="appendix">
+ <h2>Acknowledgements</h2>
+ <p>
+ WG membership to be listed here.
+ </p>
+ </section>
+
+ </body></html>
Binary file model/WD-prov-dm-20111215/collections.png has changed
Binary file model/WD-prov-dm-20111215/complement-of.png has changed
Binary file model/WD-prov-dm-20111215/example-graphical.png has changed
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/WD-prov-dm-20111215/extra.css Fri Dec 09 09:01:11 2011 +0000
@@ -0,0 +1,284 @@
+
+/* --- EDITORIAL NOTES --- */
+.pending {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #BFEFFF;
+}
+
+.pending::before {
+ content: "Pending Review";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+.resolved {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #9BCD9B;
+}
+
+.resolved::before {
+ content: "Resolved";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+.inference {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #fff;
+}
+
+.inference::before {
+ content: "Inference";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.unamedconstraint {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #00f;
+ background: #fff;
+}
+
+
+.unamedconstraint::before {
+ content: "Constraint";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #00f;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+
+.constraint {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #00f;
+ background: #fff;
+}
+
+.constraint[id]::before {
+ content: "Constraint: " attr(id);
+ width: 380px; /* How can we compute the length of "Constraint: " attr(id) */
+}
+
+
+.constraint::before {
+ content: "Constraint";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #00f;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+
+.interpretation {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #00f;
+ background: #fff;
+}
+
+.interpretation[id]::before {
+ content: "Interpretation: " attr(id);
+ width: 380px; /* How can we compute the length of "Interpretation: " attr(id) */
+}
+
+
+.interpretation::before {
+ content: "Interpretation";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #00f;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+.deprecatedconstraint {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #00f;
+ background: #fff;
+}
+
+.deprecatedconstraint[id]::before {
+ content: "Deprecated: " attr(id);
+ width: 380px; /* How can we compute the length of "Deprecatedconstraint: " attr(id) */
+}
+
+
+.deprecatedconstraint::before {
+ content: "Deprecated";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #00f;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+
+.conditional {
+ color: blue;
+}
+
+.grammar {
+ margin-top: 1ex;
+ margin-bottom: 1ex;
+ padding-left: 1ex;
+ padding-right: 1ex;
+ padding-top: 1ex;
+ padding-bottom: 0.6ex;
+ border: 1px dashed #2f6fab;
+}
+.nonterminal {
+ font-weight: bold;
+ font-family: sans-serif;
+ font-size: 95%;
+}
+
+.name {
+ font-family: monospace;
+}
+
+
+.xmpl {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #fff;
+}
+
+.xmpl::before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.anexample:before {
+ content: "Example:";
+ font-family: sans-serif;
+ font-size: 1.6ex;
+ font-weight: bold;
+}
+.anexample {
+ margin-top: 1ex;
+ margin-bottom: 1ex;
+ padding-left: 1ex;
+ padding-right: 1ex;
+ padding-top: 1ex;
+ padding-bottom: 0.6ex;
+ border: 1px dashed #2f6fab;
+ background-color: #f9f9f9;
+}
+.anexample table {
+ background-color: #f9f9f9;
+}
+
+div[class="grammar"] span[class="name"]:before {
+ content: "'";
+}
+
+div[class="grammar"] span[class="name"]:after {
+ content: "'";
+}
+
+
+div[class="grammar"] span[class="optional"]:before {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: "(";
+}
+
+div[class="grammar"] span[class="optional"]:after {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: ")?";
+}
+
+
+div[class="grammar"] span[class="plus"]:before {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: "(";
+}
+
+div[class="grammar"] span[class="plus"]:after {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: ")+";
+}
+
+
+div[class="grammar"] span[class="star"]:before {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: "(";
+}
+
+div[class="grammar"] span[class="star"]:after {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: ")*";
+}
+
+div[class="grammar"] span[class="group"]:before {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: "(";
+}
+
+div[class="grammar"] span[class="group"]:after {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: ")";
+}
Binary file model/WD-prov-dm-20111215/informedByNonTransitive.png has changed
Binary file model/WD-prov-dm-20111215/overview.png has changed
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/WD-prov-dm-20111215/prov-dm.html Fri Dec 09 09:01:11 2011 +0000
@@ -0,0 +1,3932 @@
+<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
+<html lang="en" dir="ltr">
+<head>
+ <title>The PROV Data Model and Abstract Syntax Notation</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://www.w3.org/2007/OWL/toggles.js" class="remove"></script>
+
+
+
+ <style type="text/css">
+/*****************************************************************
+ * ReSpec CSS
+ * Robin Berjon (robin at berjon dot com)
+ * v0.05 - 2009-07-31
+ *****************************************************************/
+
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+ border: none;
+}
+
+dfn {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: 1px dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+code {
+ color: #ff4500;
+}
+
+
+/* --- WEB IDL --- */
+pre.idl {
+ border-top: 1px solid #90b8de;
+ border-bottom: 1px solid #90b8de;
+ padding: 1em;
+ line-height: 120%;
+}
+
+pre.idl::before {
+ content: "WebIDL";
+ display: block;
+ width: 150px;
+ background: #90b8de;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+.idlType {
+ color: #ff4500;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+/*.idlModule*/
+/*.idlModuleID*/
+/*.idlInterface*/
+.idlInterfaceID, .idlDictionaryID {
+ font-weight: bold;
+ color: #005a9c;
+}
+
+.idlSuperclass {
+ font-style: italic;
+ color: #005a9c;
+}
+
+/*.idlAttribute*/
+.idlAttrType, .idlFieldType, .idlMemberType {
+ color: #005a9c;
+}
+.idlAttrName, .idlFieldName, .idlMemberName {
+ color: #ff4500;
+}
+.idlAttrName a, .idlFieldName a, .idlMemberName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlMethod*/
+.idlMethType {
+ color: #005a9c;
+}
+.idlMethName {
+ color: #ff4500;
+}
+.idlMethName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlParam*/
+.idlParamType {
+ color: #005a9c;
+}
+.idlParamName {
+ font-style: italic;
+}
+
+.extAttr {
+ color: #666;
+}
+
+/*.idlConst*/
+.idlConstType {
+ color: #005a9c;
+}
+.idlConstName {
+ color: #ff4500;
+}
+.idlConstName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlException*/
+.idlExceptionID {
+ font-weight: bold;
+ color: #c00;
+}
+
+.idlTypedefID, .idlTypedefType {
+ color: #005a9c;
+}
+
+.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
+ color: #c00;
+ font-weight: normal;
+}
+
+.excName a {
+ font-family: monospace;
+}
+
+.idlRaises a.idlType, .excName a.idlType {
+ border-bottom: 1px dotted #c00;
+}
+
+.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
+ width: 45px;
+ text-align: center;
+}
+.excGetSetTrue, .prmNullTrue, .prmOptTrue { color: #0c0; }
+.excGetSetFalse, .prmNullFalse, .prmOptFalse { color: #c00; }
+
+.idlImplements a {
+ font-weight: bold;
+}
+
+dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
+ margin-left: 2em;
+}
+
+.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
+ font-weight: normal;
+}
+
+.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
+ font-weight: bold;
+ color: #000;
+ font-family: monospace;
+}
+
+.attributes dt code, .fields dt code, .dictionary-members dt code {
+ background: #ffffd2;
+}
+
+.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
+ color: #005a9c;
+ background: transparent;
+ font-family: inherit;
+ font-weight: normal;
+ font-style: italic;
+}
+
+.methods dt code {
+ background: #d9e6f8;
+}
+
+.constants dt code {
+ background: #ddffd2;
+}
+
+.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
+ margin-bottom: 1em;
+}
+
+table.parameters, table.exceptions {
+ border-spacing: 0;
+ border-collapse: collapse;
+ margin: 0.5em 0;
+ width: 100%;
+}
+table.parameters { border-bottom: 1px solid #90b8de; }
+table.exceptions { border-bottom: 1px solid #deb890; }
+
+.parameters th, .exceptions th {
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+ font-family: initial;
+ font-weight: normal;
+ text-shadow: #666 1px 1px 0;
+}
+.parameters th { background: #90b8de; }
+.exceptions th { background: #deb890; }
+
+.parameters td, .exceptions td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+ vertical-align: top;
+}
+
+.parameters tr:first-child td, .exceptions tr:first-child td {
+ border-top: none;
+}
+
+.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
+ width: 100px;
+}
+
+.parameters td.prmType {
+ width: 120px;
+}
+
+table.exceptions table {
+ border-spacing: 0;
+ border-collapse: collapse;
+ width: 100%;
+}
+
+/* --- TOC --- */
+.toc a {
+ text-decoration: none;
+}
+
+a .secno {
+ color: #000;
+}
+
+/* --- TABLE --- */
+table.simple {
+ border-spacing: 0;
+ border-collapse: collapse;
+ border-bottom: 3px solid #005a9c;
+}
+
+.simple th {
+ background: #005a9c;
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+}
+
+.simple th[scope="row"] {
+ background: inherit;
+ color: inherit;
+ border-top: 1px solid #ddd;
+}
+
+.simple td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+ background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+ margin-top: 0;
+}
+
+.section dd > p:last-child {
+ margin-bottom: 0;
+}
+
+.section dd {
+ margin-bottom: 1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+
+/* --- EXAMPLES --- */
+pre.example {
+ border-top: 1px solid #ff4500;
+ border-bottom: 1px solid #ff4500;
+ padding: 1em;
+ margin-top: 1em;
+}
+
+pre.example::before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ background: #ff4500;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+/* --- EDITORIAL NOTES --- */
+.issue {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+}
+
+.issue::before {
+ content: "Issue";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.note {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
+}
+
+.note::before {
+ content: "Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+/* --- Best Practices --- */
+div.practice {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+}
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+}
+
+span.practicelab { background: #dfffff; }
+
+span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+}
+
+p.practicedesc {
+ margin: 1.5em 0.5em 1em 1em;
+}
+
+@media screen {
+ p.practicedesc {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+ }
+}
+
+/* --- SYNTAX HIGHLIGHTING --- */
+pre.sh_sourceCode {
+ background-color: white;
+ color: black;
+ font-style: normal;
+ font-weight: normal;
+}
+
+pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; } /* language keywords */
+pre.sh_sourceCode .sh_type { color: #666; } /* basic types */
+pre.sh_sourceCode .sh_usertype { color: teal; } /* user defined types */
+pre.sh_sourceCode .sh_string { color: red; font-family: monospace; } /* strings and chars */
+pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; } /* regular expressions */
+pre.sh_sourceCode .sh_specialchar { color: #ffc0cb; font-family: monospace; } /* e.g., \n, \t, \\ */
+pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; } /* comments */
+pre.sh_sourceCode .sh_number { color: purple; } /* literal numbers */
+pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; } /* e.g., #include, import */
+pre.sh_sourceCode .sh_symbol { color: blue; } /* e.g., *, + */
+pre.sh_sourceCode .sh_function { color: black; font-weight: bold; } /* function calls and declarations */
+pre.sh_sourceCode .sh_cbracket { color: red; } /* block brackets (e.g., {, }) */
+pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; } /* TODO and FIXME */
+
+/* Predefined variables and functions (for instance glsl) */
+pre.sh_sourceCode .sh_predef_var { color: #00008B; }
+pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }
+
+/* for OOP */
+pre.sh_sourceCode .sh_classname { color: teal; }
+
+/* line numbers (not yet implemented) */
+pre.sh_sourceCode .sh_linenum { display: none; }
+
+/* Internet related */
+pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }
+
+/* for ChangeLog and Log files */
+pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
+pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
+pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }
+
+/* for Prolog, Perl... */
+pre.sh_sourceCode .sh_variable { color: #006400; }
+
+/* for LaTeX */
+pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
+pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
+pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
+pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
+pre.sh_sourceCode .sh_argument { color: #006400; }
+pre.sh_sourceCode .sh_optionalargument { color: purple; }
+pre.sh_sourceCode .sh_math { color: orange; }
+pre.sh_sourceCode .sh_bibtex { color: blue; }
+
+/* for diffs */
+pre.sh_sourceCode .sh_oldfile { color: orange; }
+pre.sh_sourceCode .sh_newfile { color: #006400; }
+pre.sh_sourceCode .sh_difflines { color: blue; }
+
+/* for css */
+pre.sh_sourceCode .sh_selector { color: purple; }
+pre.sh_sourceCode .sh_property { color: blue; }
+pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }
+
+/* other */
+pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
+pre.sh_sourceCode .sh_paren { color: red; }
+pre.sh_sourceCode .sh_attribute { color: #006400; }
+
+/* --- EDITORIAL NOTES --- */
+.pending {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #BFEFFF;
+}
+
+.pending::before {
+ content: "Pending Review";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+.resolved {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #9BCD9B;
+}
+
+.resolved::before {
+ content: "Resolved";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+.inference {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #fff;
+}
+
+.inference::before {
+ content: "Inference";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.unamedconstraint {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #00f;
+ background: #fff;
+}
+
+
+.unamedconstraint::before {
+ content: "Constraint";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #00f;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+
+.constraint {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #00f;
+ background: #fff;
+}
+
+.constraint[id]::before {
+ content: "Constraint: " attr(id);
+ width: 380px; /* How can we compute the length of "Constraint: " attr(id) */
+}
+
+
+.constraint::before {
+ content: "Constraint";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #00f;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+
+.interpretation {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #00f;
+ background: #fff;
+}
+
+.interpretation[id]::before {
+ content: "Interpretation: " attr(id);
+ width: 380px; /* How can we compute the length of "Interpretation: " attr(id) */
+}
+
+
+.interpretation::before {
+ content: "Interpretation";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #00f;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+.deprecatedconstraint {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #00f;
+ background: #fff;
+}
+
+.deprecatedconstraint[id]::before {
+ content: "Deprecated: " attr(id);
+ width: 380px; /* How can we compute the length of "Deprecatedconstraint: " attr(id) */
+}
+
+
+.deprecatedconstraint::before {
+ content: "Deprecated";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #00f;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+
+
+.conditional {
+ color: blue;
+}
+
+.grammar {
+ margin-top: 1ex;
+ margin-bottom: 1ex;
+ padding-left: 1ex;
+ padding-right: 1ex;
+ padding-top: 1ex;
+ padding-bottom: 0.6ex;
+ border: 1px dashed #2f6fab;
+}
+.nonterminal {
+ font-weight: bold;
+ font-family: sans-serif;
+ font-size: 95%;
+}
+
+.name {
+ font-family: monospace;
+}
+
+
+.xmpl {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #fff;
+}
+
+.xmpl::before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.anexample:before {
+ content: "Example:";
+ font-family: sans-serif;
+ font-size: 1.6ex;
+ font-weight: bold;
+}
+.anexample {
+ margin-top: 1ex;
+ margin-bottom: 1ex;
+ padding-left: 1ex;
+ padding-right: 1ex;
+ padding-top: 1ex;
+ padding-bottom: 0.6ex;
+ border: 1px dashed #2f6fab;
+ background-color: #f9f9f9;
+}
+.anexample table {
+ background-color: #f9f9f9;
+}
+
+div[class="grammar"] span[class="name"]:before {
+ content: "'";
+}
+
+div[class="grammar"] span[class="name"]:after {
+ content: "'";
+}
+
+
+div[class="grammar"] span[class="optional"]:before {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: "(";
+}
+
+div[class="grammar"] span[class="optional"]:after {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: ")?";
+}
+
+
+div[class="grammar"] span[class="plus"]:before {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: "(";
+}
+
+div[class="grammar"] span[class="plus"]:after {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: ")+";
+}
+
+
+div[class="grammar"] span[class="star"]:before {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: "(";
+}
+
+div[class="grammar"] span[class="star"]:after {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: ")*";
+}
+
+div[class="grammar"] span[class="group"]:before {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: "(";
+}
+
+div[class="grammar"] span[class="group"]:after {
+ font-weight: normal;
+ font-size:130%;
+ font-family: monospace;
+ content: ")";
+}
+
+</style>
+<link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css" charset="utf-8"></head>
+ <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">The PROV Data Model and Abstract Syntax Notation</h1><h2 id="w3c-working-draft-08-december-2011"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 08 December 2011</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111208/">http://www.w3.org/TR/2011/WD-prov-dm-20111208/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html">http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018/">http://www.w3.org/TR/2011/WD-prov-dm-20111018/</a></dd><dt>Editors:</dt><dd><a href="http://www.ecs.soton.ac.uk/~lavm/">Luc Moreau</a>, University of Southampton</dd>
+<dd><a href="http://www.cs.ncl.ac.uk/people/Paolo.Missier">Paolo Missier</a>, Newcastle University</dd>
+<dt>Contributors:</dt><dd><a href="http://semanticweb.org/wiki/Khalid_Belhajjame">Khalid Belhajjame</a>, University of Manchester</dd>
+<dd><span>Stephen Cresswell</span>, legislation.gov.uk</dd>
+<dd><a href="http://www.isi.edu/~gil/">Yolanda Gil</a>, Invited Expert</dd>
+<dd><span>Ryan Golden</span>, Oracle Corporation</dd>
+<dd><a href="http://www.few.vu.nl/~pgroth/">Paul Groth</a>, VU University of Amsterdam</dd>
+<dd><span>Graham Klyne</span>, University of Oxford</dd>
+<dd><a href="http://tw.rpi.edu/web/person/JamesMcCusker">Jim McCusker</a>, Rensselaer Polytechnic Institute</dd>
+<dd><a href="http://www.inf.kcl.ac.uk/staff/simonm/">Simon Miles</a>, Invited Expert</dd>
+<dd><a href="http://www.rpi.edu/research/ccni/">James Myers</a>, Rensselaer Polytechnic Institute</dd>
+<dd><a href="http://cci.case.edu/cci/index.php/Satya_Sahoo">Satya Sahoo</a>, Case Western Reserve University</dd>
+</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
+
+ <div id="abstract" class="introductory section"><h2>Abstract</h2>
+<p>
+PROV-DM is a data model for provenance for building
+representations of the entities, people and activities involved in
+producing a piece of data or thing in the world. PROV-DM is
+domain-agnotisc, but with well-defined extensibility points allowing
+further domain-specific and application-specific extensions to be
+defined. It is accompanied by PROV-ASN, a technology-independent
+abstract syntax notation, which allows serializations of PROV-DM
+instances to be created for human consumption, which facilitates its
+mapping to concrete syntax, and which is used as the basis for a
+formal semantics.
+</p>
+ </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p>
+
+This document is part of a set of specifications aiming to define the various aspects that are necessary to achieve the visition on 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. Three other documents are: 1) a normative serialization of PROV-DM in RDF, specified by means of a mapping to the OWL2 Web Ontology Language; 2)
+the mechanisms for accessing and querying provenance; 3) a primer for the provenance data model.
+<p>This document was published by the <a href="http://www.w3.org/2011/prov/">Provenance Working Group</a> as a Working Draft. This document is intended to become a <acronym title="World Wide Web Consortium">W3C</acronym> Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-prov-wg@w3.org">public-prov-wg@w3.org</a> (<a href="mailto:public-prov-wg-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-prov-wg/">archives</a>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="http://www.w3.org/2004/01/pp-impl/46974/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction<br>
+</a><ul class="toc"><li class="tocline"><a href="#structure-of-this-document" class="tocxref"><span class="secno">1.1 </span>Structure of this Document</a></li><li class="tocline"><a href="#prov-dm-namespace" class="tocxref"><span class="secno">1.2 </span>PROV-DM Namespace</a></li><li class="tocline"><a href="#conventions" class="tocxref"><span class="secno">1.3 </span>Conventions</a></li></ul></li><li class="tocline"><a href="#preliminaries" class="tocxref"><span class="secno">2. </span>Preliminaries</a><ul class="toc"><li class="tocline"><a href="#conceptualization" class="tocxref"><span class="secno">2.1 </span>A Conceptualization of the World</a><ul class="toc"><li class="tocline"><a href="#section-entity-activity-agent" class="tocxref"><span class="secno">2.1.1 </span>Entity, Activity, Agent</a></li><li class="tocline"><a href="#section-time-event" class="tocxref"><span class="secno">2.1.2 </span>Time and Event</a><ul class="toc"><li class="tocline"><a href="#types-of-events" class="tocxref"><span class="secno">2.1.2.1 </span>Types of Events</a></li><li class="tocline"><a href="#event-ordering" class="tocxref"><span class="secno">2.1.2.2 </span>Event Ordering</a></li></ul></li></ul></li><li class="tocline"><a href="#prov-asn--the-provenance-abstract-syntax-notation" class="tocxref"><span class="secno">2.2 </span>PROV-ASN: The Provenance Abstract Syntax Notation</a></li><li class="tocline"><a href="#representation--assertion--and-inference" class="tocxref"><span class="secno">2.3 </span>Representation, Assertion, and Inference</a></li><li class="tocline"><a href="#grammar-notation" class="tocxref"><span class="secno">2.4 </span>Grammar Notation</a></li></ul></li><li class="tocline"><a href="#prov-dm-overview" class="tocxref"><span class="secno">3. </span>PROV-DM: An Overview </a></li><li class="tocline"><a href="#prov-dm-example" class="tocxref"><span class="secno">4. </span>Example</a><ul class="toc"><li class="tocline"><a href="#a-file-scenario" class="tocxref"><span class="secno">4.1 </span>A File Scenario</a></li><li class="tocline"><a href="#example-prov-asn-encoding" class="tocxref"><span class="secno">4.2 </span>Encoding using PROV-ASN</a></li><li class="tocline"><a href="#graphical-illustration" class="tocxref"><span class="secno">4.3 </span>Graphical Illustration</a></li></ul></li><li class="tocline"><a href="#data-model-concepts" class="tocxref"><span class="secno">5. </span>PROV-DM Core</a><ul class="toc"><li class="tocline"><a href="#PROV-DM-record" class="tocxref"><span class="secno">5.1 </span>Record</a></li><li class="tocline"><a href="#record-element" class="tocxref"><span class="secno">5.2 </span>Element</a><ul class="toc"><li class="tocline"><a href="#record-Entity" class="tocxref"><span class="secno">5.2.1 </span>Entity Record</a></li><li class="tocline"><a href="#record-Activity" class="tocxref"><span class="secno">5.2.2 </span>Activity Record</a></li><li class="tocline"><a href="#record-Agent" class="tocxref"><span class="secno">5.2.3 </span>Agent Record</a></li><li class="tocline"><a href="#record-note" class="tocxref"><span class="secno">5.2.4 </span>Note Record</a></li></ul></li><li class="tocline"><a href="#record-relation" class="tocxref"><span class="secno">5.3 </span>Relation</a><ul class="toc"><li class="tocline"><a href="#activity-entity-relation" class="tocxref"><span class="secno">5.3.1 </span>Activity-Entity Relation</a><ul class="toc"><li class="tocline"><a href="#record-Generation" class="tocxref"><span class="secno">5.3.1.1 </span>Generation Record</a></li><li class="tocline"><a href="#record-Usage" class="tocxref"><span class="secno">5.3.1.2 </span>Usage Record</a></li></ul></li><li class="tocline"><a href="#activity-agent-relation" class="tocxref"><span class="secno">5.3.2 </span>Activity-Agent Relation</a><ul class="toc"><li class="tocline"><a href="#record-ActivityAssociation" class="tocxref"><span class="secno">5.3.2.1 </span>Activity Association Record</a></li><li class="tocline"><a href="#record-Start-End" class="tocxref"><span class="secno">5.3.2.2 </span>Start and End Records</a></li></ul></li><li class="tocline"><a href="#entity-entity-agent-agent-relation" class="tocxref"><span class="secno">5.3.3 </span>Entity-Entity or Agent-Agent Relation</a><ul class="toc"><li class="tocline"><a href="#record-responsibility" class="tocxref"><span class="secno">5.3.3.1 </span>Responsibility Record</a></li><li class="tocline"><a href="#Derivation-Relation" class="tocxref"><span class="secno">5.3.3.2 </span>Derivation Record</a></li><li class="tocline"><a href="#record-complement-of" class="tocxref"><span class="secno">5.3.3.3 </span>Complementarity Record</a></li></ul></li><li class="tocline"><a href="#record-annotation" class="tocxref"><span class="secno">5.3.4 </span>Annotation Record</a></li></ul></li><li class="tocline"><a href="#bundle" class="tocxref"><span class="secno">5.4 </span>Bundle</a><ul class="toc"><li class="tocline"><a href="#record-Account" class="tocxref"><span class="secno">5.4.1 </span>Account Record</a></li><li class="tocline"><a href="#RecordContainer" class="tocxref"><span class="secno">5.4.2 </span>Record Container</a></li></ul></li><li class="tocline"><a href="#sub-record" class="tocxref"><span class="secno">5.5 </span>Further Terms in Records</a><ul class="toc"><li class="tocline"><a href="#record-attribute" class="tocxref"><span class="secno">5.5.1 </span>Attribute</a></li><li class="tocline"><a href="#record-identifier" class="tocxref"><span class="secno">5.5.2 </span>Identifier</a></li><li class="tocline"><a href="#record-literal" class="tocxref"><span class="secno">5.5.3 </span>Literal</a></li><li class="tocline"><a href="#record-Time" class="tocxref"><span class="secno">5.5.4 </span>Time</a></li><li class="tocline"><a href="#record-Asserter" class="tocxref"><span class="secno">5.5.5 </span>Asserter</a></li><li class="tocline"><a href="#record-NamespaceDeclaration" class="tocxref"><span class="secno">5.5.6 </span>Namespace Declaration</a></li><li class="tocline"><a href="#record-RecipeLink" class="tocxref"><span class="secno">5.5.7 </span>Recipe Link</a></li><li class="tocline"><a href="#record-Location" class="tocxref"><span class="secno">5.5.8 </span>Location</a></li></ul></li></ul></li><li class="tocline"><a href="#common-relations" class="tocxref"><span class="secno">6. </span>PROV-DM Common Relations</a><ul class="toc"><li class="tocline"><a href="#record-Collection" class="tocxref"><span class="secno">6.1 </span>Collections</a></li><li class="tocline"><a href="#record-traceability" class="tocxref"><span class="secno">6.2 </span>Traceability Record</a></li><li class="tocline"><a href="#record-OrderingOfActivities" class="tocxref"><span class="secno">6.3 </span>Activity Ordering Record</a></li><li class="tocline"><a href="#record-Revision" class="tocxref"><span class="secno">6.4 </span>Revision Record</a></li><li class="tocline"><a href="#attribution-record" class="tocxref"><span class="secno">6.5 </span>Attribution Record</a></li><li class="tocline"><a href="#quotation-record" class="tocxref"><span class="secno">6.6 </span>Quotation Record</a></li><li class="tocline"><a href="#summary-record" class="tocxref"><span class="secno">6.7 </span>Summary Record</a></li><li class="tocline"><a href="#original-source-record" class="tocxref"><span class="secno">6.8 </span>Original Source Record</a></li></ul></li><li class="tocline"><a href="#extensibility-section" class="tocxref"><span class="secno">7. </span>PROV-DM Extensibility Points</a></li><li class="tocline"><a href="#resource-section" class="tocxref"><span class="secno">8. </span>Resources, URIs, Entities, Identifiers, and Scope</a></li><li class="tocline"><a href="#changes-since-first-public-working-draft" class="tocxref"><span class="secno">A. </span>Changes Since First Public Working Draft</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">B. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></div>
+
+
+
+
+<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>
+
+
+ <div id="introduction" class="section">
+ <!--OddPage--><h2><span class="secno">1. </span>Introduction<br>
+</h2>
+
+<p>
+For the purpose of this specification, 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.
+In particular, the provenance of information is crucial in deciding
+whether information is to be trusted, how it should be integrated with
+other diverse information sources, and how to give credit to its
+originators when reusing it. In an open and inclusive environment
+such as the Web, users find information that is often contradictory or
+questionable: provenance can help those users to make trust judgments.
+</p>
+
+
+<p>
+The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
+Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it, process it, and reason over it.</p>
+
+<p>Thus, the vision is that different provenance-aware systems natively adopt their own model for representing their provenance, but a core provenance data model can be readily adopted as a provenance <em>interchange</em> model across such systems.</p>
+
+<p>A set of specifications define the various aspects
+that are necessary to achieve this vision in an inter-operable
+way, the first of which is contained in this document:</p>
+<ul>
+<li> The PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption; </li>
+<li> A normative serialization of PROV-DM in RDF [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-O">PROV-O</a></cite>], specified by means of a mapping to the OWL2 Web Ontology Language [<cite><a class="bibref" rel="biblioentry" href="#bib-OWL2-SYNTAX">OWL2-SYNTAX</a></cite>];</li>
+<li> The mechanisms for accessing and querying provenance [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PAQ">PROV-PAQ</a></cite>];</li>
+<li> A Primer for the PROV approach [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PRIMER">PROV-PRIMER</a></cite>].</li>
+</ul>
+
+
+<p>
+The PROV-DM data model for provenance consists of a set of core
+concepts, and a few common relations, based on these core concepts. PROV-DM is a domain-agnotisc model, but with well-defined extensibility points allowing further domain-specific and application-specific extensions to be defined.</p>
+
+<p>This specification also introduces
+PROV-ASN, an abstract syntax that is primarily aimed at human consumption. PROV-ASN allows
+serializations of PROV-DM instances to be written in a technology independent manner,
+it facilitates its mapping to concrete syntax, and it is used as the basis for a
+formal semantics. This specification uses instances of provenance written in PROV-ASN
+to illustrate the data model.
+</p>
+
+ <div id="structure-of-this-document" class="section">
+<h3><span class="secno">1.1 </span>Structure of this Document</h3>
+
+<p>In <a href="#preliminaries">section 2</a>, a set of preliminaries are introduced, including concepts that underpin PROV-DM and motivations for the PROV-ASN notation.</p>
+
+<p><a href="#prov-dm-overview">Section 3</a> provides an overview of PROV-DM listing its core types and their relations.</p>
+
+<p>In <a href="#prov-dm-example">section 4</a>, PROV-DM is
+applied to a short scenario, encoded in PROV-ASN, and illustrated
+graphically.</p>
+
+<p><a href="#data-model-concepts">Section 5</a> provides the normative definition of PROV-DM and the notation PROV-ASN.</p>
+
+<p><a href="#common-relations">Section 6</a> introduces common relations used in PROV-DM, including relations for data collections and common domain-independent common relations.</p>
+
+<p><a href="#extensibility-section">Section 7</a> summarizes PROV-DM extensibility points.</p>
+
+<p><a href="#resource-section">Section 8</a> discusses how PROV-DM can be applied to the notion of resource.</p>
+
+
+ </div>
+
+<div id="prov-dm-namespace" class="section">
+ <h3><span class="secno">1.2 </span>PROV-DM Namespace</h3>
+
+
+<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
+
+<p> All the elements, relations, reserved names and attributes introduced in this specification belong to the PROV-DM namespace.</p>
+
+<div class="note">
+There is a desire to use a single namespace that all specs can share to refer to common provenance terms.
+</div>
+
+</div>
+
+
+ <div id="conventions" class="section">
+<h3><span class="secno">1.3 </span>Conventions</h3>
+
+
+
+<p>The key words "<em class="rfc2119" title="must">must</em>", "<em class="rfc2119" title="must not">must not</em>", "<em class="rfc2119" title="required">required</em>", "<em class="rfc2119" title="shall">shall</em>", "<em class="rfc2119" title="shall
+ not">shall
+ not</em>", "<em class="rfc2119" title="should">should</em>", "<em class="rfc2119" title="should not">should not</em>", "<em class="rfc2119" title="recommended">recommended</em>", "<em class="rfc2119" title="may">may</em>", and
+ "<em class="rfc2119" title="optional">optional</em>" in this document are to be interpreted as described in
+ [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">RFC2119</a></cite>].</p>
+ </div>
+
+</div>
+
+
+<div id="preliminaries" class="section">
+<!--OddPage--><h2><span class="secno">2. </span>Preliminaries</h2>
+
+ <div id="conceptualization" class="section">
+<h3><span class="secno">2.1 </span>A Conceptualization of the World</h3>
+
+
+
+ <div id="section-entity-activity-agent" class="section">
+<h4><span class="secno">2.1.1 </span>Entity, Activity, Agent</h4>
+
+
+
+
+<p>This specification is based on a conceptualization of the world
+that is described in this section. In the world (whether real or not),
+there are things, which can be physical, digital, conceptual, or
+otherwise, and activities involving things. </p>
+
+<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>Hence, to accommodate different perspectives on things and their situation in the world as perceived by us, we introduce the idea of a characterized thing, which refers to a thing and its situation in the world, as characterized by someone. We then define an <dfn id="concept-entity">entity</dfn> as an identifiable characterized thing. An entity <em>fixes some aspects</em> of a thing and its situation in the world, so that it becomes possible to express its provenance, and what causes these specific aspects to be as such. An alternative entity may fix other aspects, and its provenance may be different.</p>
+
+<div class="anexample">
+Different users may take different perspectives on a resource with
+a URL. These perspectives in this conceptualization of the world are
+referred to as entities. Three such entities may be
+expressed:
+<ul>
+<li>a report available at 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 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>
+
+<!--
+<div class='paolo'>can we follow through from the example. thare three perspectives, possibly by just one observer or multiple ones. but <strong>why is it so important for reporting provenance</strong> that this distinction is made? I feel we need to connect this approach to provenance recording strongly and right away</div>
+-->
+
+<p>We do not assume that any characterization is more important than any other, and in fact, it is possible to describe the processing that occurred for the report to be commissioned, for individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity that characterizes the report appropriately.</p>
+
+<p>In the world, <dfn id="concept-activity">activities</dfn> involve
+entities in multiple ways: they consume them, they process them, they
+transform them, they modify them, they change them, they relocate
+them, they use them, they generate them, they are controlled by them,
+etc.</p>
+
+
+<p>An <dfn id="concept-agent">agent</dfn> is a type of entity that takes an active role in an activity such that it can be assigned some degree of responsibility for the activity taking place.
+This definition intentionally stays away from using concepts such as enabling, causing, initiating, affecting, etc, because any entities also enable, cause, initiate, and affect in some way the activities. So the notion of having some degree of responsibility is really what makes an agent. </p>
+
+<p> Even software agents can be assigned some responsibility for the effects they have in the world, so for example if one is using a Text Editor and one's laptop crashes, then one would say that the Text Editor was responsible for crashing the laptop. If one invokes a service to buy a book, that service can be considered responsible for drawing funds from one's bank to make the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well). So when someone models software as an agent for an activity in our model, they mean the agent has some responsibility for that activity.
+</p>
+<p> In this specification, the qualifier 'identifiable' is implicit whenever a reference is made to an activity, agent, or an entity.</p>
+
+</div>
+
+
+ <div id="section-time-event" class="section">
+<h4><span class="secno">2.1.2 </span>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 in 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 instantaneous event, 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-CSP">CSP</a></cite>], events represent communications or interactions; they are assumed to be atomic and instantaneous.</p>
+
+
+
+
+<div id="types-of-events" class="section">
+<h5><span class="secno">2.1.2.1 </span>Types of Events</h5>
+
+<p>Four kinds of events 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 href="#dfn-event" class="internalDFN">event</a> that marks the final instant of an entity's creation timespan, after which it becomes available for use.</p>
+
+<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the first instant of an entity's consumption timespan by an activity.</p>
+
+<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the instant an activity starts.</p>
+
+<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the instant an activity ends.</p>
+
+</div>
+
+<div id="event-ordering" class="section">
+<h5><span class="secno">2.1.2.2 </span>Event Ordering</h5>
+
+<p>To allow for minimalistic clock assumptions, like Lamport
+[<cite><a class="bibref" rel="biblioentry" href="#bib-CLOCK">CLOCK</a></cite>], PROV-DM relies on a notion of relative ordering of <a title="event" href="#dfn-event" class="internalDFN">events</a>,
+without using physical clocks. This specification assumes that a partial order exists between <a title="event" href="#dfn-event" class="internalDFN">events</a>.
+</p>
+
+
+<p>Specifically, <dfn id="dfn-follows">follows</dfn> is a partial
+order between <a title="event" href="#dfn-event" class="internalDFN">events</a>, indicating that an <a href="#dfn-event" class="internalDFN">event</a> occurs after another.
+For symmetry, <dfn id="dfn-precedes">precedes</dfn> is defined as
+the inverse of follows. </p>
+
+
+<p> How such partial order is realized in practice is beyond the scope
+of this specification. This specification only assumes that
+each <a href="#dfn-event" class="internalDFN">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 href="#dfn-follows" class="internalDFN">follows</a> and <a href="#dfn-precedes" class="internalDFN">precedes</a> correspond to some ordering
+over this timeline.
+</p>
+
+
+<p>This specification introduces a set of "temporal interpretation"
+rules allowing to derive <a href="#dfn-event" class="internalDFN">event</a> ordering constraints from
+provenance records. According to such temporal interpretation,
+provenance records <em class="rfc2119" title="must">must</em> satisfy such constraints. We note that the
+actual verification of such temporal constraints is also outside the
+scope of this specification. </p>
+
+<p>PROV-DM also allows for time observations to be inserted in specific
+provenance records, for each recognized <a href="#dfn-event" class="internalDFN">event</a> introduced
+in this specification. The presence of a time observation for a
+given <a href="#dfn-event" class="internalDFN">event</a> fixes the mapping of this <a href="#dfn-event" class="internalDFN">event</a> to the
+timeline. It can also help with the verification of associated
+temporal constraints (though, again, this verification is outside the
+scope of this specfication).
+
+</p>
+
+
+
+</div>
+
+ </div>
+
+ </div>
+
+ <div id="prov-asn--the-provenance-abstract-syntax-notation" class="section">
+<h3><span class="secno">2.2 </span>PROV-ASN: The Provenance Abstract Syntax Notation</h3>
+
+<p>This specification defines PROV-DM, a data model for provenance, consisting of records describing how people, entities, and activities, were involved in producing,
+influencing, or delivering a piece of data or a thing in the world.</p>
+
+<p>This specification also relies on a language, PROV-ASN, the Provenance Abstract Syntax Notation, to express
+<em>instances</em> of that data model.
+For each construct of PROV-DM, a corresponding ASN expression is introduced, by way of a production in the ASN grammar. </p>
+
+
+
+
+
+<p>PROV-ASN is an abstract syntax, whose goals are:
+</p><ul>
+<li>to allow serializations of PROV-DM instances in a technology independent manner, which makes it more readable for human consumption;
+</li><li>to facilitate the mapping of PROV-DM to concrete syntax;
+</li><li>to provide the basis for a formal semantics.
+</li></ul>
+
+<p>This specification provides a grammar for PROV-ASN. Each record of the PROV-DM data model is explained
+in terms of the production of this grammar.</p>
+
+
+
+<p>The formal semantics of PROV-DM is defined at
+[<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-SEMANTICS">PROV-SEMANTICS</a></cite>] and its encoding in the OWL2 Web Ontology Language at [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-O">PROV-O</a></cite>].
+</p>
+
+
+
+
+
+
+ </div>
+
+ <div id="representation--assertion--and-inference" class="section">
+<h3><span class="secno">2.3 </span>Representation, Assertion, and Inference</h3>
+
+<p>
+PROV-DM is a provenance data model designed to express <em>representations</em> of the world.
+</p>
+
+<div class="anexample">
+A file at some point during its lifecycle, which includes multiple edits by multiple people, can be represented by its location in the file system, a creator, and content.
+</div>
+
+
+<p>
+These representations are relative to an asserter, and in that sense constitute assertions stating properties of the world, as represented by an asserter. Different asserters will normally contribute different representations.
+This specification does not define a notion of consistency between different sets of assertions (whether by the same asserter or different asserters).
+The data model provides the means to associate attribution to assertions.
+</p>
+
+<div class="anexample">
+An alternative representation of the above file is a set of blocks in a hard disk.
+</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 assertions <em class="rfc2119" title="should">should</em> be interpreted as a record of what has happened, as opposed to what may or will happen.</p>
+
+
+
+<p>
+This specification does not prescribe the means by which an asserter arrives at assertions; for example, assertions can be composed on the basis of observations, reasoning, or any other means.
+</p>
+
+
+<p>
+Sometimes, inferences about the world can be made from representations
+conformant to the PROV-DM data model. When this is the case, this
+specification defines such inferences, allowing new provenance records
+to be inferred from existing ones. Hence, representations of the world
+can result either from direct assertions by asserters or from
+application of inferences defined by this specification.
+</p>
+
+
+
+</div>
+ <div id="grammar-notation" class="section">
+<h3><span class="secno">2.4 </span>Grammar Notation</h3>
+
+<p>This specification includes a grammar for PROV-ASN expressed using the Extended Backus-Naur Form (EBNF) notation.</p>
+
+<div class="grammar">
+<p> Each rule in the grammar defines one symbol, in the form:</p>
+<p>
+<span class="nonterminal">E</span> ::= <em>expression</em>
+</p>
+
+
+Within the expression on the right-hand side ofa rule, the follwoing expressions are used to match strings of one or more characters:
+<ul>
+<li>
+<span class="nonterminal">E</span>: matches term satisfying rule for symbol E.
+</li>
+
+<li>
+<span class="name">abc</span>: matches the literal string inside the single quotes.
+</li>
+
+
+<li>
+<span class="optional"><em>expression</em></span>: matches <em>expression</em> or nothing; optional <em>expression</em>.
+</li>
+
+<li>
+<span class="plus"><em>expression</em></span>: matches one or more occurrences of <em>expression</em>.
+</li>
+
+<li>
+<span class="star"><em>expression</em></span>: matches zero or more occurrences of <em>expression</em>.
+</li>
+
+</ul>
+</div>
+
+</div>
+</div>
+
+ <div id="prov-dm-overview" class="section">
+<!--OddPage--><h2><span class="secno">3. </span>PROV-DM: An Overview </h2>
+
+<p>
+The following ER diagram provides a high level overview of the <strong>structure of PROV-DM records</strong>. Examples of provenance assertions that conform to this schema are provided in the next section.</p>
+
+<div style="text-align: center;">
+ <img src="overview.png" alt="PROV-DM overview">
+</div>
+
+<div class="note"> Overview diagram does not represent the sub-relations -- proposal to use a UML notation instead of ER.</div>
+
+
+<p>The model includes the following elements:</p>
+<ul>
+ <li>An <a title="entity record" href="#dfn-entity" class="internalDFN">Entity Record</a> (noted <samp>entity</samp> in the diagram, to reflect the term used in the ASN) is a representation of an <em>entity</em>.
+
+ </li><li>An <a title="activity record" href="#dfn-activity" class="internalDFN">Activity Record</a>(noted <samp>activity</samp> in the diagram) represents an activity that has an effect on entities, namely it either <em>generates</em> or <em>uses</em> one or more entities. Usage and generation are modelled by means of the <a title="usage record" href="#dfn-Use" class="internalDFN">used</a> and the <a title="generation record" href="#dfn-Generation" class="internalDFN">wasGeneratedBy</a> relationships. Activities may include not only computations, but also any other type of activity that can be described in terms of their effect on <samp>entities</samp>.
+Note that multiple <samp>activities</samp> may <em>use</em> the same <samp>entity</samp>, and each activity may use multiple <samp>entities</samp>. Finally, entities can be derived from other entities, and this is specified using the <a title="derivation record" href="#dfn-Derivation" class="internalDFN">wasDerivedFrom</a> relation.</li>
+
+ <li>An <a title="agent record" href="#dfn-Agent" class="internalDFN">Agent Record</a> represents a particular <samp>entity</samp> that can be associated to activities, meaning that it can be assigned some degree of responsibility for an <samp>activity</samp> taking place.
+ Agents have a rather generic connotation: their association with an activity is represented by the <a title="activity association record" href="#dfn-activity-association" class="internalDFN">wasAssociatedWith</a> relationship, which can take up various meanings (attribution, responsibility, supervision, management, etc.), which are not individually specified in the model. Relations <a title="start record" href="#dfn-Start" class="internalDFN">wasStartedBy</a> and <a title="end record" href="#dfn-End" class="internalDFN">wasEndedBy</a> are specializations of <a title="activity association record" href="#dfn-activity-association" class="internalDFN">wasAssociatedWith</a> that can optionally be used to carry additional meaning. Furthermore, it is recognized that agents can act on behalf of others: hence, the relation <a title="responsibility record" href="#dfn-responsibility" class="internalDFN">actedOnBehalfOf</a> allows for chains of responsibility to be stated.
+</li>
+
+
+
+</ul>
+
+<p> A set of attribute-value pairs can be associated to elements and relations of the PROV model in order to further characterize
+their nature.
+The <a title="complementarity record" href="#complementOf" class="internalDFN">wasComplementOf</a> relationship is used to denote that two <samp>entities</samp> <em>complement</em> each other, in the sense that they each represent a partial, but mutually compatible characterization of the same thing.
+The attributes <a title="prov:role" href="#dfn-role" class="internalDFN">role</a> and <a title="prov:type" href="#dfn-type" class="internalDFN">type</a> are pre-defined.
+</p>
+
+
+<p>The set of relations presented here forms a core, which is further extended with additional relations, defined in Section <a href="#common-relations">Common Relations</a>.</p>
+
+
+<p>
+The model includes a further additional element: <a title="note record" href="#dfn-note" class="internalDFN">notes</a>. These are also structured as sets of attribute-value pairs. Notes are used to provide additional, "free-form" information regarding <em>any</em> identifiable construct of the model, with no prescribed meaning. Notes are described in detail <a href="#record-note">here</a>.
+</p>
+
+<p>
+Attributes and notes are the main <em>extensibility points</em> in the model: individual interest groups are expected to extend PROV-DM by introducing new attributes and notes as needed to address applications-specific provenance modelling requirements. </p>
+
+</div>
+
+
+ <div class="informative section" id="prov-dm-example">
+<!--OddPage--><h2><span class="secno">4. </span>Example</h2><p><em>This section is non-normative.</em></p>
+
+<div class="issue"> There is a suggestion that a better example should be adopted for this document. Possibly, several shorter examples. This is <a href="http://www.w3.org/2011/prov/track/issues/132">ISSUE-132</a></div>
+
+
+To illustrate PROV-DM, this section presents an example encoded according to PROV-ASN. For more detailed explanations of how PROV-DM should be used, and for more examples, we refer the reader to the Provenance Primer [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PRIMER">PROV-PRIMER</a></cite>].
+
+
+
+
+
+<div class="pending">Comments on section 3.2. This is <a href="http://www.w3.org/2011/prov/track/issues/71">ISSUE-71</a></div>
+
+ <div id="a-file-scenario" class="section">
+<h3><span class="secno">4.1 </span>A File Scenario</h3>
+
+
+<p>This scenario is concerned with the evolution of a crime statistics
+file (referred to as e0) stored on a shared file system and which
+journalists Alice, Bob, Charles, David, and Edith can share and
+edit. We consider various <a title="event" href="#dfn-event" class="internalDFN">events</a> in the evolution of file e0;
+<a title="event" href="#dfn-event" class="internalDFN">events</a> listed below follow each other, unless otherwise specified.</p>
+
+
+
+<p>
+<a href="#dfn-event" class="internalDFN">Event</a> evt1: Alice creates (a0) an empty file in /share/crime.txt. We denote this file e1.
+</p>
+
+<p>
+<a href="#dfn-event" class="internalDFN">Event</a> evt2: Bob appends (a1) the following line to /share/crime.txt:</p>
+<pre>There was a lot of crime in London last month.
+</pre>
+<p>We denote the revised file e2.</p>
+
+<p><a href="#dfn-event" class="internalDFN">Event</a> evt3: Charles emails (a2) the contents of /share/crime.txt, as an
+attachment, which we refer to as e4. (We specifically refer to a copy of the file that is uploaded on the mail server.)
+</p>
+
+<p>
+<a href="#dfn-event" class="internalDFN">Event</a> evt4: David edits (a3) file /share/crime.txt as follows.</p>
+<pre>There was a lot of crime in London and New-York last month.
+</pre>
+<p>
+We denote the revised file e3.
+</p>
+
+<p><a href="#dfn-event" class="internalDFN">Event</a> evt5: Edith emails (a4) the contents of /share/crime.txt as an attachment, referred to as e5.
+</p>
+
+<p><a href="#dfn-event" class="internalDFN">Event</a> evt6: between <a title="event" href="#dfn-event" class="internalDFN">events</a> evt4 and evt5, someone (unspecified) runs a spell checker (a5) on the file /share/crime.txt.
+ The file after spell checking is referred to as e6.
+</p>
+
+</div>
+
+ <div id="example-prov-asn-encoding" class="section">
+<h3><span class="secno">4.2 </span>Encoding using PROV-ASN</h3>
+
+In this section, the example is encoded according to the provenance data model (specified in section <a href="#data-model-concepts">PROV-DM: The Provenance Data Model</a>) and expressed in PROV-ASN.
+<p>
+Entity Records (described in <a href="#record-Entity">Section Entity</a>). The file in its various forms and its copies are modelled as entity records, corresponding to multiple characterizations, as per scenario. The entity records are identified by <span class="name">e0</span>, ..., <span class="name">e6</span>.</p>
+<pre>entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
+entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London last month."])
+entity(e3, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month."])
+entity(e4)
+entity(e5)
+entity(e6, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month.", ex:spellchecked="yes"])
+</pre>
+
+
+
+<p>These entity records list attributes that have been given values during intervals delimited by <a title="event" href="#dfn-event" class="internalDFN">events</a>; such intervals are referred to as <em>characterization intervals</em>. The following table lists all entity identifiers and their corresponding characterization intervals. When the end of the characterization interval is not delimited by an <a href="#dfn-event" class="internalDFN">event</a> described in this scenario, it is marked by "...".</p>
+<blockquote>
+<table>
+<tbody><tr><td>Entity</td><td>Characterization Interval</td></tr>
+<tr><td>e0</td><td>evt1 - ...</td></tr>
+<tr><td>e1</td><td>evt1 - evt2</td></tr>
+<tr><td>e2</td><td>evt2 - evt4</td></tr>
+<tr><td>e3</td><td>evt4 - ...</td></tr>
+<tr><td>e4</td><td>evt3 - ...</td></tr>
+<tr><td>e5</td><td>evt5 - ...</td></tr>
+<tr><td>e6</td><td>evt6 - ... </td></tr>
+</tbody></table>
+</blockquote>
+
+
+
+<p>
+Activity Records (described in <a href="#record-Activity">Section Activity</a>) represent activities in the scenario.</p>
+<pre>activity(a0, create-file, 2011-11-16T16:00:00,)
+activity(a1, add-crime-in-london, 2011-11-16T16:05:00,)
+activity(a2, email, 2011-11-16T17:00:00,)
+activity(a3, edit-London-New-York, 2011-11-17T09:00:00,)
+activity(a4, email, 2011-11-17T09:30:00,)
+activity(a5, spellcheck,,)
+</pre>
+
+
+<p>
+Generation Records (described in <a href="#record-Generation">Section Generation</a>) represent the <a href="#dfn-event" class="internalDFN">event</a> at which a file is created in a specific form. Attributes are used to describe the modalities according to which a given entity is generated by a given activity. The interpretation of attributes is application specific. Illustrations of such attributes for the scenario are: no attribute is provided for <span class="name">e0</span>;
+<span class="name">e2</span> was generated by the editor's save function; <span class="name">e4</span> can be found on the smtp port, in the attachment section of the mail message; <span class="name">e6</span> was produced on the standard output of <span class="name">a5</span>. Two identifiers <span class="name">g1</span> and <span class="name">g2</span> identify the generation records referenced in derivations introduced below.</p>
+<pre>wasGeneratedBy(e0, a0)
+wasGeneratedBy(e1, a0, [ex:fct="create"])
+wasGeneratedBy(e2, a1, [ex:fct="save"])
+wasGeneratedBy(e3, a3, [ex:fct="save"])
+wasGeneratedBy(g1, e4, a2, [ex:port="smtp", ex:section="attachment"])
+wasGeneratedBy(g2, e5, a4, [ex:port="smtp", ex:section="attachment"])
+wasGeneratedBy(e6, a5, [ex:file="stdout"])
+</pre>
+
+
+
+<p>
+Usage Records (described in <a href="#record-Usage">Section Usage</a>) represent the <a href="#dfn-event" class="internalDFN">event</a> by which a file is read by an activity.
+
+Likewise, attributes describe the modalities according to which the various entities are used by activities. Illustrations of such attributes are:
+<span class="name">e1</span> is used in the context of <span class="name">a1</span>'s <span class="name">load</span> functionality; <span class="name">e2</span> is used by <span class="name">a2</span> in the context of its attach functionality; <span class="name">e3</span> is used on the standard input by <span class="name">a5</span>. Two identifiers <span class="name">u1</span> and <span class="name">u2</span> identify the Usage records referenced in derivations introduced below.</p>
+<pre>used(a1,e1,[ex:fct="load"])
+used(a3,e2,[ex:fct="load"])
+used(u1,a2,e2,[ex:fct="attach"])
+used(u2,a4,e3,[ex:fct="attach"])
+used(a5,e3,[ex:file="stdin"])
+</pre>
+
+
+<p>
+Derivation Records (described in <a href="#Derivation-Relation">Section Derivation Relation</a>) express that an entity is derived from another. The first two are expressed in their compact version, whereas the following two are expressed in their full version, including the activity underpinning the derivation, and associated usage (<span class="name">u1</span>, <span class="name">u2</span>) and generation (<span class="name">g1</span>, <span class="name">g2</span>) records.</p>
+<pre>wasDerivedFrom(e2,e1)
+wasDerivedFrom(e3,e2)
+wasDerivedFrom(e4,e2,a2,g1,u1)
+wasDerivedFrom(e5,e3,a4,g2,u2)
+</pre>
+
+
+
+<p>
+wasComplementOf: (this relation is described in <a href="#record-complement-of">Section wasComplementOf</a>). The crime statistics file (<span class="name">e0</span>) has various contents over its existence (<span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span>); the entity records identified by <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span> complement <span class="name">e0</span> with an attribute <span class="name">content</span>. Likewise, the one denoted by <span class="name">e6</span> complements the record denoted by <span class="name">e3</span> with an attribute <span class="name">spellchecked</span>.</p>
+<pre>wasComplementOf(e1,e0)
+wasComplementOf(e2,e0)
+wasComplementOf(e3,e0)
+wasComplementOf(e6,e3)
+</pre>
+
+
+
+<p>
+Agent Records (described at <a href="#record-Agent">Section Agent</a>): the various users are represented as agents, themselves being a type of entity.</p>
+<pre>agent(ag1, [ prov:type="prov:Person" %% xsd:QName, ex:name="Alice" ])
+
+agent(ag2, [ prov:type="prov:Person" %% xsd:QName, ex:name="Bob" ])
+
+agent(ag3, [ prov:type="prov:Person" %% xsd:QName, ex:name="Charles" ])
+
+agent(ag4, [ prov:type="prov:Person" %% xsd:QName, ex:name="David" ])
+
+agent(ag5, [ prov:type="prov:Person" %% xsd:QName, ex:name="Edith" ])
+</pre>
+
+
+
+<p>
+Activity Assocation Records (described in <a href="#record-ActivityAssociation">Section Activity Association</a>): the association of an agent with an activity is expressed with , and the nature of this association is described by attributes. Illustrations of such attributes include the role of the participating agent, as creator, author and communicator (role is a reserved attribute in PROV-DM).</p>
+<pre>wasAssociatedWith(a0, ag1, [prov:role="creator"])
+wasAssociatedWith(a1, ag2, [prov:role="author"])
+wasAssociatedWith(a2, ag3, [prov:role="communicator"])
+wasAssociatedWith(a3, ag4, [prov:role="author"])
+wasAssociatedWith(a4, ag5, [prov:role="communicator"])
+</pre>
+</div>
+
+
+ <div id="graphical-illustration" class="section">
+<h3><span class="secno">4.3 </span>Graphical Illustration</h3>
+
+
+<p>
+Provenance assertions can be <em>illustrated</em> graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of provenance assertions. Therefore, it cannot be seen as an alternate notation for expressing provenance.</p>
+
+<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and half-hexagonal shapes, respectively. Usage, Generation, Derivation, Activity Association, and Complementarity are represented as directed edges.</p>
+
+<p>Entities are layed out according to the ordering of their generation event. We endeavor to show time progressing from left to right. This means that edges for Usage, Generation and Derivation typically point from right to left.</p>
+
+
+<div style="text-align: center;">
+<img src="example-graphical.png" alt="example">
+</div>
+<br>
+<div style="text-align: center;">
+<img src="timeline.png" alt="example">
+</div>
+</div>
+
+</div>
+
+
+
+<div id="data-model-concepts" class="section">
+
+<!--OddPage--><h2><span class="secno">5. </span>PROV-DM Core</h2>
+
+<p>This section contains the normative specification of PROV-DM core, the core of the PROV data model.</p>
+
+<div class="note">
+In a next iteration of this document, it is proposed to reorganize
+section 5 as follows. First, the presentation of the data model
+alone. Second, its temporal interpretation. Third, the constraints and
+inferences associated with well-formed accounts.
+</div>
+
+ <div id="PROV-DM-record" class="section">
+
+<h3><span class="secno">5.1 </span>Record</h3>
+
+<p>PROV-DM consists of a set of constructs, referred to as <em>records</em>, to formulate representations of the world and constraints that must be satisfied by them.</p>
+
+<p>
+Furthermore, PROV-DM includes a "house-keeping construct", a record container,
+ used to wrap PROV-DM records and facilitate their interchange.</p>
+
+<p>In PROV-ASN, such representations of the world <em class="rfc2119" title="must">must</em> be conformant with the toplevel production <span class="nonterminal">record</span> of the grammar. These <span class="nonterminal">record</span>s are grouped in three categories:
+<span class="nonterminal">elementRecord</span> (see section <a href="#record-element">Element</a>),
+<span class="nonterminal">relationRecord</span> (see section <a href="#record-relation">Relation</a>), and
+<span class="nonterminal">accountRecord</span> (see section <a href="#record-Account">Account</a>).</p>
+
+
+<div class="grammar">
+<span class="nonterminal">record</span> ::=
+<span class="nonterminal">elementRecord</span>
+| <span class="nonterminal">relationRecord</span>
+| <span class="nonterminal">accountRecord</span>
+<br>
+<!-- -->
+<br>
+<span class="nonterminal">elementRecord</span> ::=
+<span class="nonterminal">entityRecord</span>
+| <span class="nonterminal">activityRecord</span>
+| <span class="nonterminal">agentRecord</span>
+| <span class="nonterminal">noteRecord</span> <br>
+<!-- -->
+<br>
+<span class="nonterminal">relationRecord</span> ::=
+<span class="nonterminal">generationRecord</span>
+| <span class="nonterminal">usageRecord</span>
+| <span class="nonterminal">derivationRecord</span>
+| <span class="nonterminal">activityAssociationRecord</span>
+| <span class="nonterminal">responsibilityRecord</span>
+| <span class="nonterminal">startRecord</span>
+| <span class="nonterminal">endRecord</span>
+| <span class="nonterminal">complementRecord</span>
+| <span class="nonterminal">annotationRecord</span>
+</div>
+
+
+<p>In PROV-ASN, a record container is compliant with the production <span class="nonterminal">recordContainer</span> (see section <a href="#RecordContainer">Record Container</a>). </p>
+
+</div>
+
+ <div id="record-element" class="section">
+<h3><span class="secno">5.2 </span>Element</h3>
+
+<p>This section describes all the PROV-DM records referred to as element records. (They are conformant to the <span class="nonterminal">elementRecord</span> production of the grammar.)</p>
+
+
+
+ <div id="record-Entity" class="section">
+
+<h4><span class="secno">5.2.1 </span>Entity Record</h4>
+
+<p>In PROV-DM, an <dfn id="dfn-entity">entity record</dfn> is a representation of an entity.</p>
+
+
+<p>Examples of entities include a linked data set, a sparse-matrix matrix of floating-point numbers, a document in a directory, the same document published on the Web, and meta-data embedded in a document.</p>
+
+<p>An entity record, noted <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> identifying an entity; the identifier of the entity record is defined to be the same as the identifier of the entity; </li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this entity's situation in the world.</li>
+</ul>
+
+
+<p>
+The assertion of an entity record, <span class="name">entity(id, [ attr1=val1, ...])</span>, states, from a given asserter's viewpoint, the existence of an entity, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two <a title="event" href="#dfn-event" class="internalDFN">events</a> in the world.
+</p>
+
+<p>
+In PROV-ASN, an entity record's text matches the <span class="nonterminal">entityRecord</span> production of the grammar defined in this specification document.
+</p>
+
+<div class="grammar">
+<span class="nonterminal">entityRecord</span> ::=
+<span class="name">entity</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br><br>
+<!-- -->
+<span class="nonterminal">optional-attribute-values</span> ::=
+<span class="optional"><span class="name">,</span>
+<span class="name">[</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">]</span>
+</span><br>
+<span class="nonterminal">attribute-values</span> ::=
+<span class="nonterminal">attribute-value</span>
+| <span class="nonterminal">attribute-value</span> <span class="name">,</span> <span class="nonterminal">attribute-values</span>
+<br>
+<span class="nonterminal">attribute-value</span> ::=
+<span class="nonterminal">attribute</span>
+<span class="name">=</span>
+<span class="nonterminal">Literal</span>
+<br>
+</div>
+
+<div class="anexample">
+<p>
+The following entity record,</p>
+<pre class="codeexample">entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+</pre>
+states the existence of an entity, denoted by identifier <span class="name">e0</span>, with type <span class="name">File</span> and path <span class="name">/shared/crime.txt</span> in the file system, and creator alice The attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span class="name">type</span> is reserved in the PROV-DM namespace.
+</div>
+
+Further considerations:
+<ul>
+<li>If an asserter wishes to characterize an entity with the same attribute-value pairs over several intervals, then they are required to assert multiple entity records, each with its own identifier (so as to allow potential dependencies between the various entity records to be expressed). </li>
+
+<li>There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.</li>
+
+<li>A characterization interval may collapse into a single instant.</li>
+
+<li>An entity assertion
+ is about a thing, whose situation in the world may be variant.
+ An entity record is asserted at a particular point and is invariant, in the sense that
+its attributes are given a value as part of that assertion.
+</li>
+
+<li>Activities are not represented by entity records, but instead by activity records, as explained below.</li>
+</ul>
+
+
+
+
+
+
+<div class="note">The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define wasComplementOf more precisely. It would also allow us to address
+<a href="http://www.w3.org/2011/prov/track/issues/108">ISSUE-108</a>.
+Beginning and end of characterization interval could be expressed by attributes (similarly to activities). </div>
+
+
+
+
+ </div>
+
+ <div id="record-Activity" class="section">
+
+<h4><span class="secno">5.2.2 </span>Activity Record</h4>
+<p>In PROV-DM, an <dfn id="dfn-activity">activity record</dfn> is a representation of an identifiable activity, which performs a piece of work.</p>
+
+
+<p>An activity, represented by an activity record, is delimited by its <a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a> and its <a title="activity end event" href="#dfn-end-event" class="internalDFN">end</a> events; hence, it occurs over an interval delimited by two <a title="event" href="#dfn-event" class="internalDFN">events</a>. However, an activity record need not mention time information, nor duration, because they may not be known.</p>
+
+<p>Such start and end times constitute <em>attributes</em> of an activity, where the interpretation of attribute in the context of an activity record is the same as the interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the world can be represented by other attribute-value pairs, which <em class="rfc2119" title="must">must</em> also remain unchanged during the activity duration.</p>
+
+<p>
+Examples of activities include assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a sparql query over a triple store, editing a file, and publishing a web page. </p>
+
+<p> An activity record, written <span class="name">activity(id, rl, st, et, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> identifying an activity; the identifier of the activity record is defined to be the same as the identifier of the activity;</li>
+<li><em>recipeLink</em>: an <em class="rfc2119" title="optional">optional</em> <a href="#record-RecipeLink">recipe link</a> <span class="name">rl</span>, which consists of a domain specific specification of the activity;</li>
+<li><em>startTime</em>: an <em class="rfc2119" title="optional">optional</em> time <span class="name">st</span> indicating the start of the activity;</li>
+<li><em>endTime</em>: an <em class="rfc2119" title="optional">optional</em> time <span class="name">et</span> indicating the end of the activity;</li>
+<li><em>attributes</em>: a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole duration.</li>
+</ul>
+
+<p>In PROV-ASN, an activity record's text matches the <span class="nonterminal">activityRecord</span> production of the grammar defined in this specification document.</p>
+
+
+
+<div class="grammar">
+<span class="nonterminal">activityRecord</span> ::=
+<span class="name">activity</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="optional"><span class="name">,</span>
+<span class="nonterminal">recipeLink</span> </span>
+<span class="name">,</span>
+<span class="optional"><span class="nonterminal">time</span></span>
+<span class="name">,</span>
+<span class="optional"><span class="nonterminal">time</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br>
+</div>
+
+<div class="anexample">
+<p>
+The following activity assertion</p>
+<pre class="codeexample">activity(a1,add-crime-in-london,2011-11-16T16:05:00,2011-11-16T16:06:00,[ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
+</pre>
+<p>identified by identifier <span class="name">a1</span>, states the existence of an activity with recipe link <span class="name">add-crime-in-london</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix <span class="name">ex</span>). The attribute <span class="name">host</span> is application specific, but <em class="rfc2119" title="must">must</em> hold for the duration of activity. The attribute <span class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
+</div>
+
+<p>The mere existence of an activity assertion entails some <a href="#dfn-event" class="internalDFN">event</a> ordering in the world, since an <a href="#dfn-start-event" class="internalDFN">activity start event</a> always <a href="#dfn-precedes" class="internalDFN">precedes</a> the corresponding <a href="#dfn-end-event" class="internalDFN">activity end event</a>. This is expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
+
+<div class="interpretation" id="start-precedes-end"> The following temporal constraint holds for any activity record: the
+<a title="activity start event" href="#dfn-start-event" class="internalDFN">start event</a> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end event</a>.</div>
+
+<p>An activity record is not an entity record.
+Indeed, an entity record represents an entity that exists in full at
+any point in its characterization interval, persists during this
+interval, and preserves the characteristics that makes it
+identifiable. Alternatively, an activity in 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-Logic">Logic</a></cite>].</p>
+
+
+</div>
+
+<div id="record-Agent" class="section">
+<h4><span class="secno">5.2.3 </span>Agent Record</h4>
+
+
+
+<p>An <dfn id="dfn-Agent">agent record</dfn> is a representation of an agent, which is an entity that can be assigned some degree of responsibility for an activity taking place.</p>
+
+<p>Many agents can have an association with a given activity. An agent may do the ordering of the activity, another agent may do its design, another agent may push the button to start it, another agent may run it, etc.
+As many agents as one wishes to mention can occur in the provenance record, if it is important to indicate that they were associated with the activity. </p>
+
+<p>
+From an inter-operability perspective, it is useful to define some basic categories of agents since
+it will improve the use of provenance records by applications.
+There should be very few of these basic categories to keep the model simple and accessible.
+There are three types of agents in the model:
+</p><ul>
+<li><span class="name">Person</span>: agents of type Person are people. (This type is equivalent to a "foaf:person" [<cite><a class="bibref" rel="biblioentry" href="#bib-FOAF">FOAF</a></cite>])</li>
+<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc. (This type is equivalent to a "foaf:organization" [<cite><a class="bibref" rel="biblioentry" href="#bib-FOAF">FOAF</a></cite>])</li>
+<li><span class="name">SoftwareAgent</span>: a software agent is a piece of software. </li>
+</ul>
+<p>These types are mutually exclusive, though they do not cover all kinds of agent. </p>
+
+<p>An agent record, noted <span class="name">agent(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> identifying an agent; the identifier of the agent record is defined to be the same as the identifier of the agent;</li>
+<li><em>attributes</em>: contains a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this agent's situation in the world.</li>
+</ul>
+
+<p>In PROV-ASN, an agent record's text matches the <span class="nonterminal">agentRecord</span> production of the grammar defined in this specification document.
+</p>
+
+
+<div class="grammar">
+<span class="nonterminal">agentRecord</span> ::=
+<span class="name">agent</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+
+
+<div class="anexample">
+<p>With the following assertions,</p>
+<pre class="codeexample">agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Person" %% xsd:QName])
+
+entity(e2) and wasStartedBy(a1,e2,[prov:role="author"])
+
+entity(e3) and wasAssociatedWith(a1,e3,[prov:role="sponsor"])
+</pre>
+<p>the agent record identified by <span class="name">e1</span> is an explicit agent assertion that holds irrespective of activities it may be associated with. On the other hand, from the entity records identified by <span class="name">e2</span> and <span class="name">e3</span>, one can infer agent records, as per the following inference.</p>
+</div>
+
+<p>One can assert an agent record or alternatively, one can infer an agent record
+by its association with an activity. </p>
+
+<div class="constraint" 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>
+
+ <div id="record-note" class="section">
+
+<h4><span class="secno">5.2.4 </span>Note Record</h4>
+
+<p>As provenance records are exchanged between systems, it may be useful to add extra-information about such records. For instance, a "trust service" may add value-judgements about the trustworthiness of some of the assertions made. Likewise, an interactive visualization component may want to enrich a set of provenance records with information helping reproduce their visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing any identifiable record to be associated with notes.</p>
+
+<p>An <dfn id="dfn-note">note record</dfn> is a set of attribute-value pairs, whose meaning is application specific. It may or may not be a representation of something in the world.</p>
+
+<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
+</p>
+
+
+<div class="grammar">
+<span class="nonterminal">noteRecord</span> ::=
+<span class="name">note</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">)</span><br>
+<!-- -->
+</div>
+
+<p>A separate PROV-DM record is used to associate a note with an identifiable record (see <a href="#record-annotation">Section on annotation</a>). A given note may be associated with multiple records.
+</p>
+
+
+<div class="anexample">
+<p>
+The following note record</p>
+<pre class="codeexample">note(ann1,[ex:color="blue", ex:screenX=20, ex:screenY=30])
+</pre>
+<p>consists of a set of application-specific attribute-value pairs, intended
+to help the rendering of the record it is associated with, by
+specifying its color and its position on the screen. In this example,
+these attribute-value pairs do not constitute a representation of something
+in the world; they are just used to help render provenance.
+</p>
+</div>
+
+<p>
+Attribute-value pairs occurring in notes differ from attribute-value pairs occurring in entity records and activity records. In entity and activity records, attribute-value pairs <em class="rfc2119" title="must">must</em> be a representation of something in the world, which remain constant for the duration of the characterization interval (for entity record) or the activity duration (for activity records). In note records, it is <em class="rfc2119" title="optional">optional</em> for attribute-value pairs to be representations of something in the world. If they are a representation of something in the world, then it <em class="rfc2119" title="may">may</em> change value for the corresponding duration. If attribute-value pairs of a note record are a representation of something in the world that does not change, they are not regarded as determining characteristics of an entity or activity, for the purpose of provenance.
+</p>
+
+
+ </div>
+
+</div>
+
+
+<div id="record-relation" class="section">
+<h3><span class="secno">5.3 </span>Relation</h3>
+
+<p>This section describes all the PROV-DM records representing relations between the elements introduced in <a href="#record-element">Section Element</a>. While these relations are not binary, they all involve two primary elements. They can be summarized as follows. </p>
+
+
+<div style="text-align: center;">
+<table border="1" style="margin-left: auto; margin-right: auto;">
+<caption>PROV-DM Core Relation Summary</caption>
+<tbody><tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Note</td></tr>
+<tr><td>Entity</td><td><a title="derivation record" href="#dfn-Derivation" class="internalDFN">wasDerivedFrom</a><br><a title="complementarity record" href="#complementOf" class="internalDFN">wasComplementOf</a></td><td><a title="generation record" href="#dfn-Generation" class="internalDFN">wasGeneratedBy</a></td><td>-</td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
+<tr><td>Activity</td><td><a title="usage record" href="#dfn-Use" class="internalDFN">used</a></td><td>-</td><td><a title="start record" href="#dfn-Start" class="internalDFN">wasStartedBy</a><br><a title="end record" href="#dfn-End" class="internalDFN">wasEndedBy</a><br><a title="activity association record" href="#dfn-activity-association" class="internalDFN">wasAssociatedWith</a></td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
+<tr><td>Agent</td><td>-</td><td>-</td><td><a title="responsibility record" href="#dfn-responsibility" class="internalDFN">actedOnBehalfOf</a></td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
+<tr><td>Note</td><td>-</td><td>-</td><td>-</td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
+</tbody></table>
+</div>
+
+
+<p>In PROV-ASN, all these relation records are conformant to the <span class="nonterminal">relationRecord</span> production of the grammar.</p>
+
+<div id="activity-entity-relation" class="section">
+<h4><span class="secno">5.3.1 </span>Activity-Entity Relation</h4>
+
+<div id="record-Generation" class="section">
+<h5><span class="secno">5.3.1.1 </span>Generation Record</h5>
+
+
+<p>In PROV-DM, a <dfn id="dfn-Generation">generation record</dfn> is a representation of a world <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">event</a>, the creation of a new entity by an activity. This entity did not exist before creation.
+The representation of this <a href="#dfn-event" class="internalDFN">event</a> encompasses a description of the modalities of generation of this entity by this activity.</p>
+
+<p>A <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation event</a> may be, for example, the creation of a file by a program, the creation of a linked data set, the production of a new version of a document, and the sending of a value on a communication channel.</p>
+
+<p>A generation record, written <span class="name">wasGeneratedBy(id,e,a,attrs,t)</span> in PROV-ASN, has the following components:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the generation record;</li>
+<li><em>entity</em>: an identifier <span class="name">e</span> identifying an entity record that represents the entity that is created; </li>
+<li><em>activity</em>: an identifier <span class="name">a</span> identifying an activity record that represents the activity that creates the entity;</li>
+
+<li><em>time</em>: an <em class="rfc2119" title="optional">optional</em> "generation time" <span class="name">t</span>, the time at which the entity was created;</li>
+
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describes the modalities of generation of this entity by this activity.</li>
+
+</ul>
+
+<p>In PROV-ASN, a generation record's text matches the <span class="nonterminal">generationRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class="grammar">
+<span class="nonterminal">generationRecord</span> ::=
+<span class="name">wasGeneratedBy</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>
+<span class="name">,</span> </span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="optional"><span class="name">,</span>
+<span class="nonterminal">time</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br>
+</div>
+
+
+<p>
+A generation record's id is <em class="rfc2119" title="optional">optional</em>. It <em class="rfc2119" title="must">must</em> be used when annotating generation records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).
+</p>
+
+
+<div class="anexample">
+<p>
+The following generation assertions</p>
+<pre class="codeexample"> wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1", ex:order=1])
+ wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p1", ex:order=2])
+</pre>
+<p>state the existence of two <a title="event" href="#dfn-event" class="internalDFN">events</a> in the world (with respective times <span class="name">2001-10-26T21:32:52</span> and <span class="name">2001-10-26T10:00:00</span>), at which new entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an activity, itself represented by an activity record identified by <span class="name">a1</span>.
+The first one is available as the first value on port p1, whereas the other is the second value on port p1. The semantics of <span class="name">port</span> and <span class="name">order</span> in these records are application specific.
+</p>
+</div>
+
+
+
+<p>The assertion of a generation record implies ordering of <a title="event" href="#dfn-event" class="internalDFN">events</a> in the world.</p>
+
+
+<div class="interpretation" id="generation-activity-ordering"><span class="conditional">If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class="conditional">then</span> the following temporal constraint also holds: the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation</a> of the entity denoted by <span class="name">x</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end</a>
+of <span class="name">a</span> and <a href="#dfn-follows" class="internalDFN">follows</a> the <a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a> of <span class="name">a</span>.
+</div>
+
+
+
+<p>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
+The rationale for this constraint is as follows.
+If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation events</a>, then they generate distinct entities. Alternatively, for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This unicity constraint is formalized as follows.
+
+</p><div class="constraint" id="generation-unicity">Given an entity record denoted by <span class="name">e</span>, two activity records 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> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given account,
+<span class="conditional">then</span> <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
+</div>
+
+<div class="note">TODO: Introduce the well-formed-ness constraint in a entirely separate section.</div>
+
+
+</div>
+
+
+<div id="record-Usage" class="section">
+<h5><span class="secno">5.3.1.2 </span>Usage Record</h5>
+
+
+
+<p>In PROV-DM, a <dfn id="dfn-Use">usage record</dfn> is a representation of a world <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">event</a>: the consumption of an entity by an activity. The representation includes a description of the modalities of usage of this entity by this activity.</p>
+
+<p>
+A <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usage event</a> may be the consumption of a parameter by a procedure, the reading of a value on a port by a service, the reading of a configuration file by a program, or the adding of an ingredient, such as eggs, in a baking activity. Usage may entirely consume an entity (e.g. eggs are not longer available after being added to the mix), or leave it as such, ready for further uses (e.g. a file on a file system can be read indefinitely).</p>
+
+
+<p>A usage record, written <span class="name">used(id,a,e,attrs,t)</span> in PROV-ASN, has the following constituent:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the usage record;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record, which represents the consuming activity;</li>
+<li><em>entity</em>: an identifier <span class="name">e</span> for an entity record, which represents the entity that is consumed;</li>
+<li><em>time</em>: an <em class="rfc2119" title="optional">optional</em> "usage time" <span class="name">t</span>, the time at which the entity was used;</li>
+<li><em>attributes</em>: an OPTIONIAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of usage of this entity by this activity;</li>
+</ul>
+
+<p>In PROV-ASN, a usage record's text matches the <span class="nonterminal">usageRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class="grammar">
+<span class="nonterminal">usageRecord</span> ::=
+<span class="name">used</span>
+<span class="name">(</span>
+<span class="optional">
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="optional">
+<span class="name">,</span>
+ <span class="nonterminal">time</span>
+</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br>
+</div>
+
+
+<p>
+A usage record's id is <em class="rfc2119" title="optional">optional</em>, but comes handy when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining derivations.
+</p>
+
+
+<div class="anexample">
+<p>The following usage records</p>
+<pre class="codeexample"> used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"])
+ used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])
+</pre>
+<p>state that the activity, represented by the activity record identified by <span class="name">a1</span>, consumed two entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, at times <span class="name">2011-11-16T16:00:00</span> and <span class="name">2011-11-16T16:00:01</span>, respectively; the first one was found as the value of parameter <span class="name">p1</span>, whereas the second was found as value of parameter <span class="name">p2</span>. The semantics of <span class="name">parameter</span> in these records is application specific.</p>
+</div>
+
+
+
+
+
+<p>
+A usage record's id is <em class="rfc2119" title="optional">optional</em>. It <em class="rfc2119" title="must">must</em> be present when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).</p>
+
+<p>
+A reference to a given entity record <em class="rfc2119" title="may">may</em> appear in multiple usage records that share
+ a given activity record identifier.
+</p>
+
+
+
+
+
+<div class="interpretation" id="usage-generation-ordering">For any entity, the following temporal constraint holds: the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation</a> of an entity always <a href="#dfn-precedes" class="internalDFN">precedes</a> any of its <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usages</a>.
+</div>
+
+
+<div class="interpretation" id="usage-activity-ordering">Given an activity record identified by <span class="name">a</span>, an entity record identified by <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 temporal constraint holds:
+ the <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usage</a> of the entity represented by entity record identified by <span class="name">e</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end</a> of activity represented by record identified by <span class="name">a</span> and <a href="#dfn-follows" class="internalDFN">follows</a> its <a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a>.
+</div>
+
+
+
+
+<div class="issue">Should we define a taxonomy of use? This is <a href="http://www.w3.org/2011/prov/track/issues/23">ISSUE-23</a>.</div>
+
+</div>
+</div>
+
+
+
+
+
+<div id="activity-agent-relation" class="section">
+<h4><span class="secno">5.3.2 </span>Activity-Agent Relation</h4>
+
+<div id="record-ActivityAssociation" class="section">
+<h5><span class="secno">5.3.2.1 </span>Activity Association Record</h5>
+
+<p>The key purpose of agents in PROV-DM is to assign responsibility
+for activities. It is important to reflect that there is a degree in
+the responsibility of agents, and that is a major reason for
+distinguishing among all the agents that have some association with an
+activity and determine which ones are really the originators of the
+entity. For example, a programmer and a researcher could both be
+associated with running a workflow, but it may not matter what
+programmer clicked the button to start the workflow while it would
+matter a lot what researcher told the programmer to do so. Another
+example: a student publishing a web page describing an academic
+department could result in both the student and the department being
+agents associated with the activity, and it may not matter what
+student published a web page but it matters a lot that the department
+told the student to put up the web page. So there is some notion of
+responsibility that needs to be captured. </p>
+
+<p>To this end, PROV-DM offers two kinds of records. The first, introduced in this section, represents an association between an agent and an activity; the second, introduced in <a href="#record-responsibility">Section Responsibility record</a>, represents the fact that an agent was acting on behalf of another, in the context of an activity. </p>
+
+<p>Examples of activity association include designing, participation, initiation and termination, timetabling or sponsoring. </p>
+
+<p>An <dfn id="dfn-activity-association">activity association record</dfn>, written <span class="name">wasAssociatedWith(a,ag2,attrs)</span> in PROV-ASN, has the following constituents:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the activity association record;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record;</li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of association of this activity with this agent;</li>
+<li><em>agent</em>: an identifier <span class="name">ag2</span> for an agent record, which represents the agent associated with the activity.</li>
+
+</ul>
+
+<p>In PROV-ASN, an activity association record's text matches the <span class="nonterminal">activityAssociationRecord</span> productions of the grammar defined in this specification document.</p>
+
+<div class="grammar">
+<span class="nonterminal">activityAssociationRecord</span> ::=
+<span class="name">wasAssociatedWith</span>
+<span class="name">(</span>
+<span class="optional"><span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">aIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<div class="anexample">
+In the following example, a programmer and a researcher agents are asserted to be associated with an activity.
+<pre class="codeexample">activity(a,[prov:type="workflow"])
+agent(ag1,[prov:type="programmer"])
+agent(ag2,[prov:type="researcher"])
+wasAssociatedWith(a,ag1,[prov:role="loggedInUser", ex:how="webapp"])
+wasAssociatedWith(a,ag2,[prov:role="designer", ex:context="phd"])
+</pre>
+</div>
+
+
+
+</div>
+
+<div id="record-Start-End" class="section">
+<h5><span class="secno">5.3.2.2 </span>Start and End Records</h5>
+
+<p> A <dfn id="dfn-Start">start record</dfn> is a representation of an agent starting an activity.
+ An <dfn id="dfn-End">end record</dfn> is a representation of an agent ending an activity. Both relations are specialized forms of <span class="name">wasAssociatedWith</span>. They contain attributes describing the modalities of acting/ending activities.</p>
+
+
+
+<p>A start record, written <span class="name">wasStartedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the start record;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the started activity;
+</li><li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the starting agent;
+</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent started the activity.
+</li></ul>
+
+<p>An end record, written <span class="name">wasEndedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the end record;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the ended activity;
+</li><li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the ending agent;
+</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent ended the activity.
+</li></ul>
+
+<p>In PROV-ASN, start and end record's texts match the <span class="nonterminal">startRecord</span> and <span class="nonterminal">endRecord</span> productions of the grammar defined in this specification document.
+</p>
+
+
+<div class="grammar">
+<span class="nonterminal">startRecord</span> ::=
+<span class="name">wasStartedBy</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">aIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br>
+<span class="nonterminal">endRecord</span> ::=
+<span class="name">wasEndedBy</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">aIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+<div class="anexample">
+<p>
+The following assertions</p>
+<pre class="codeexample">wasStartedBy(a,ag,[ex:mode="manual"])
+wasEndedby(a,ag,[ex:mode="manual"])
+</pre>
+<p>state that the activity, represented by the activity record denoted by <span class="name">a</span>
+was started and ended by an agent, represented by record denoted by <span class="name">ah</span>, in "manual" mode, an application specific characterization of these relations.
+</p>
+</div>
+</div>
+
+<div class="note">Temporal constraints for these relations remain to be
+written. The temporal constraints should ensure that the agent started
+its existence before the effect it may have on the activity. </div>
+
+
+
+<!--
+
+<section id="record-Participation">
+<h4>Participation Record</h4>
+
+<p>A <dfn id="dfn-Participation">participation record</dfn> is a representation of the involvement of an entity in an activity. A participation record can be asserted or inferred.</p>
+
+
+<p>In PROV-ASN, a participation record's text matches the <span class="nonterminal">participationRecord</span> production of the grammar defined in this specification document.</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">participationRecord</span> ::=
+<span class="name">hadParticipant</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">identifier</span>
+<span class="name">)</span>
+</div>
+
+
+
+<p> A participation record,
+written <span class="name">hadParticipant(pe,e)</span> in PROV-ASN:
+<ul>
+<li> contains to identifier <span class="name">pe</span> identifying an activity record representing an activity;
+<li> contains an identifier <span class="name">e</span> identifying an entity record, which is
+a representation of an entity involved in this activity.
+</ul>
+
+<p>An entity's participation in an activity can be by direct usage or direct control. But also, if an entity and situation are characterized in two complementary manners (and are represented by two entity records related by <span class="name">isComplementOf</span>), if one of them participates in an activity, so does the other. The following captures the definition of participation.</p>
+
+<div class='constraint' id='participation'>
+Given two identifiers <span class="name">pe</span> and <span class="name">e</span>, respectively identifying an activity record and an entity record, the record <span class="name">hadParticipant(pe,e)</span> holds <span class='conditional'>if and only if</span>:
+<ul>
+<li> <span class="name">used(pe,e)</span> holds, or</li>
+<li> <span class="name">wasControlledBy(pe,e)</span> holds, or</li>
+<li> <span class="name">wasComplementOf(e1,e)</span> holds for some entity record identified by <span class="name">e1</span>, and
+ <span class="name">hadParticipant(pe,e1)</span> holds some activity record identified by <span class="name">pe</span>.</li>
+</ul>
+</div>
+
+
+<div class='pending'>Suggested definition for participation. This is <a href="http://www.w3.org/2011/prov/track/issues/49">ISSUE-49</a>.</div>
+
+</section>
+
+-->
+
+</div>
+
+<div id="entity-entity-agent-agent-relation" class="section">
+<h4><span class="secno">5.3.3 </span>Entity-Entity or Agent-Agent Relation</h4>
+
+<div id="record-responsibility" class="section">
+
+<h5><span class="secno">5.3.3.1 </span>Responsibility Record</h5>
+
+<p>To promote take-up, PROV-DM offers a mild version of responsibility
+in the form of a relation to represent when an agent acted on another
+agent's behalf. So in the example of someone running a mail program,
+the program is an agent of that activity and the person is also an
+agent of the activity, but we would also add that the mail software
+agent is running on the person's behalf. In the other example, the
+student acted on behalf of his supervisor, who acted on behalf of the
+department chair, who acts on behalf of the university, and all those
+agents are responsible in some way for the activity to take place but
+we don't say explicitly who bears responsibility and to what
+degree. </p>
+
+<p>We could also say that an agent can act on behalf of several other
+agents (a group of agents). This would also make possible to
+indirectly reflect chains of responsibility. This also indirectly
+reflects control without requiring that control is explicitly
+indicated. In some contexts there will be a need to represent
+responsibility explicitly, for example to indicate legal
+responsibility, and that could be added as an extension to this core
+model. Similarly with control, since in particular contexts there
+might be a need to define specific aspects of control that various
+agents exert over a given activity.</p>
+
+<p>Given an activity association record <span class="name">wasAssociatedWith(a,ag2,attrs)</span>,
+a <dfn id="dfn-responsibility">responsibility record</dfn>, written <span class="name">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-ASN, has the following constituents:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the responsibility record;</li>
+<li><em>subordinate</em>: an identifier <span class="name">ag2</span> for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible agent;</li>
+<li><em>responsible</em>: an identifier <span class="name">ag1</span> for an agent record, which represents the agent on behalf of which the subordinate agent <span class="name">ag2</span> acts;</li>
+<li><em>activity</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">a</span> of an activity record for which the responsibility record holds;</li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this relation.</li>
+</ul>
+
+
+<div class="grammar">
+<span class="nonterminal">responsibilityRecord</span> ::=
+<span class="name">actedOnBehalfOf</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">agIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>,
+<span class="optional"><span class="nonterminal">aIdentifier</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<div class="anexample">
+In the following example, a programmer, a researcher and a funder agents are asserted. The porgrammer and researcher are associated with a workflow activity. The programmer acts on behalf of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher.
+<pre class="codeexample">activity(a,[prov:type="workflow"])
+agent(ag1,[prov:type="programmer"])
+agent(ag2,[prov:type="researcher"])
+agent(ag3,[prov:type="funder"])
+wasAssociatedWith(a,ag1,[prov:role="loggedInUser"])
+wasAssociatedWith(a,ag2)
+actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])
+actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
+</pre>
+</div>
+
+
+</div>
+
+<div id="Derivation-Relation" class="section">
+<h5><span class="secno">5.3.3.2 </span>Derivation Record</h5>
+
+<p>In PROV-DM, a <dfn id="dfn-Derivation">derivation record</dfn> is a representation that some entity is transformed from, created from, or affected by another entity in the world. </p>
+
+
+<p>Examples of derivation include the transformation of a canvas into a painting, the transportation of a person from London to New-York, the transformation of a relational table into a linked data set, and the melting of ice into water.</p>
+
+
+<p>According to <a href="#conceptualization">Section Conceptualization</a>, for an entity to be transformed from, created from, or affected by another in some way, there must be some underpinning activities performing the necessary actions resulting in such a derivation.
+However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or less precise records of derivation to be asserted. Hence, PROV-DM uses the terms <em>precise</em> and <em>imprecise</em> to characterize the different kinds of derivation record. We note that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation record, that may be imprecise. </p>
+
+<p>The lack of precision may come from two sources:</p>
+<ul>
+<li> the number of activities that underpin a derivation is not asserted or known, or</li>
+<li> any of the other details that are involved in the derivation is not asserted or known; these include activity identities, generation and usage records, and their attributes.</li>
+</ul>
+
+
+<!--
+Furthermore, assuming that an asserter has full knowledge of an activity underpinning a derivation, the same activity can generally be modelled in terms of sub-activities, composed in a such a way as to deliver the same behavior. Hence, since activities can be modelled at arbitrary levels of granularity, there is a distinguished case in which a derivation between two entities <span class="name">e2</span> and <span class="name">e1</span> corresponds <em>exactly</em> to <em>one</em> activity that used <span class="name">e1</span> and generated <span class="name">e2</span>. This is to be contrasted to the case where one derivation corresponds to n activities, where n can be any number greater than 1.
+Hence, PROV-DM uses the terms <em>one-activity</em> and <em>n-activities</em> to distinguish these two cases.</p>
+-->
+
+
+<p>Hence, given a precision axis, with values <em>precise</em> and <em>imprecise</em>, and an activity axis, with values <em>one activity</em> and <em>n activities</em>, we can then form a matrix of possible derivations, precise or imprecise, or corresponding to one activity or n activities.
+Out of the four possibilities, PROV-DM offers three forms of derivation, while the fourth one is not meaningful. The following table summarises names for the three kinds of derivation, which we then explain.</p>
+
+<div style="text-align: center;">
+<table border="1" style="margin-left: auto; margin-right: auto;">
+<caption>PROV-DM Derivation Type Summary</caption>
+<tbody><tr><td colspan="2" rowspan="2"></td><td colspan="2">precision axis</td></tr>
+<tr><td>precise</td><td>imprecise</td></tr>
+<tr><td rowspan="2">activity<br>axis</td><td>one activity</td><td><a href="#dfn-precise-1-derivation-record" class="internalDFN">precise-1 derivation record</a></td><td><a href="#dfn-imprecise-1-derivation-record" class="internalDFN">imprecise-1 derivation record</a></td></tr>
+<tr><td>n activities</td><td>---</td><td><a href="#dfn-imprecise-n-derivation-record" class="internalDFN">imprecise-n derivation record</a></td></tr>
+</tbody></table>
+</div>
+
+<ul>
+<li> The asserter asserts that derivation is due to exactly one activity, and all the details are asserted. We call this a precise-1 derivation record.</li>
+<li> The asserter asserts that derivation is due to exactly one activity, but other details, whether known or unknown, are not asserted. We call this an imprecise-1 derivation record.</li>
+<li> The asserter does not know how many activities are involved in the derivation, and other details, whether known or unknown, are also not asserted. We call this an imprecise-n derivation record.</li>
+</ul>
+
+<p> We note that the fourth theoretical case of a precise derivation, where the number of activities is not known or asserted cannot occur. </p>
+
+
+<p>The three kinds of derivation records are successively introduced. To minimize the number of relation types in PROV-DM, we introduce a PROV-DM reserved attribute <span class="name">steps</span>, which allows us to distinguish the various derivation types. </p>
+
+<p>A <dfn id="dfn-precise-1-derivation-record">precise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the derivation record;</li>
+<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
+<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity;</li>
+<li><em>activity</em>: an identifier <span class="name">a</span> of an activity record, which is a representation of the activity using and generating the above entities;</li>
+<li><em>generation</em>: an identifier <span class="name">g2</span> of the generation record pertaining to <span class="name">e2</span> and <span class="name">a</span>;</li>
+<li><em>usage</em>: an identifier <span class="name">u1</span> of the usage record pertaining to <span class="name">e1</span> and <span class="name">a</span>.</li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation, optionally including the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
+</ul>
+<p>It is <em class="rfc2119" title="optional">optional</em> to include the attribute <span class="name">prov:steps</span> in a precise-1 derivation since the record already refers to the one and only one activity underpinning the derivation.</p>
+
+
+<p>An <dfn id="dfn-imprecise-1-derivation-record">imprecise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2,e1, attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the derivation record;</li>
+<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
+<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
+<li><em>attributes</em>: a set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it <em class="rfc2119" title="must">must</em> include the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
+</ul>
+<p>An imprecise-1 derivation <em class="rfc2119" title="must">must</em> include the attribute <span class="name">prov:steps</span>, since it is the only means to distinguish this record from an imprecise-n derivation record.</p>
+
+
+<p>An <dfn id="dfn-imprecise-n-derivation-record">imprecise-n derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the derivation record;</li>
+<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
+<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it optionally includes the attribute-value pair <span class="name">prov:steps="n"</span>.</li>
+</ul>
+<p>It is <em class="rfc2119" title="optional">optional</em> to include the attribute <span class="name">prov:steps</span> in an imprecise-n derivation record. It defaults to <span class="name">prov:steps="n"</span>.</p>
+
+
+<p>None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property holds.</p>
+
+
+<p>In PROV-ASN, a derivation record's text matches the <span class="nonterminal">derivationRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class="grammar">
+<span class="nonterminal">derivationRecord</span> ::=
+<span class="nonterminal">precise-1-derivationRecord</span>
+| <span class="nonterminal">imprecise-1-derivationRecord</span>
+| <span class="nonterminal">imprecise-n-derivationRecord</span><br>
+<br>
+<span class="nonterminal">precise-1-derivationRecord</span> ::=
+<span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">gIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">uIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br>
+<span class="nonterminal">imprecise-1-derivationRecord</span>::=
+<span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">)</span>
+<br>
+<span class="nonterminal">imprecise-n-derivationRecord</span>::=
+<span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+<div class="note">
+The grammar should make it clear that attribute <span class="name">prov:steps="1"</span> is required for imprecise-1-derivationRecord.<br>
+ PM: suggestion -- remove the distinction between imprecise-1 and imprecise-n in the grammar and instead explain that the qualification (1 vs n) is through attribute prov:steps.
+</div>
+
+<div class="anexample">
+<p>The following assertions state the existence of derivations.</p>
+<pre class="codeexample">wasDerivedFrom(e5,e3,a4,g2,u2,[])
+wasDerivedFrom(e5,e3,a4,g2,u2,[prov:steps="1"])
+
+wasDerivedFrom(e3,e2,[prov:steps="1"])
+
+wasDerivedFrom(e2,e1,[])
+wasDerivedFrom(e2,e1,[prov:steps="n"])
+</pre>
+<p>
+The first two are precise-1 derivation records expressing that the activity represented by the activity <span class="name">a4</span>, by
+using the entity denoted by <span class="name">e3</span> according to usage record <span class="name">u2</span>
+ derived the
+entity denoted by <span class="name">e5</span> and generated it according to generation record
+ <span class="name">g2</span>.
+
+The third record is an imprecise-1 derivation, which is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity record and associated attributes implicit. The fourth and fifth records are imprecise-n derivation records between <span class="name">e2</span> and <span class="name">e1</span>, but no information is provided as to the number and identity of activities underpinning the derivation.
+</p>
+</div>
+
+
+<p>An precise-1 derivation record is richer than an imprecise-1 derivation record, itself, being more informative that an imprecise-n derivation record. Hence, the following implications hold.</p>
+<div class="constraint" id="derivation-implications">
+Given two entity records 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 record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, then <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> also holds.<br>
+
+Given two entity records 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, [prov:steps="1"] ∪ attrs)</span>
+ holds, then <span class="name">wasDerivedFrom(e2,e1,attrs)</span> also holds.<br>
+ </div>
+
+
+
+<p>
+</p><p>If a derivation record holds for <span class="name">e2</span> and <span class="name">e1</span>, then
+this means that the entity represented by entity record identified by <span class="name">e1</span> has an influence on the entity represented entity record identified by <span class="name">e2</span>,
+ which at the minimum implies temporal ordering, specified as follows.
+First, we consider one-activity derivations.</p>
+
+<div class="interpretation" id="derivation-usage-generation-ordering">Given an activity record identified by <span class="name">a</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, <span class="conditional">if</span> the record <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
+or <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> holds, <span class="conditional">then</span>
+the following temporal constraint holds:
+the <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usage</a>
+of entity denoted by <span class="name">e1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation</a> of
+the entity denoted by <span class="name">e2</span>.
+</div>
+
+<p>Then, imprecise-n derivations.</p>
+
+<div class="interpretation" id="derivation-generation-generation-ordering">
+Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class="conditional">if</span> the record <span class="name">wasDerivedFrom(e2,e1,[prov:steps="n"] ∪ attrs)</span>
+ holds, <span class="conditional">then</span> the following temporal constraint holds:
+the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation event</a> of the entity denoted by <span class="name">e1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation event</a> of
+the entity denoted by <span class="name">e2</span>.
+ </div>
+
+<p>Note that temporal ordering is between generations of <span class="name">e1</span>
+and <span class="name">e2</span>, as opposed to precise-1 derivation,
+which implies temporal ordering between the usage of <span class="name">e1</span> and
+generation of <span class="name">e2</span>. Indeed, in the case of
+imprecise-n derivation, nothing is known about the usage of <span class="name">e1</span>,
+since there is no associated activity.</p>
+
+
+
+
+<p>The imprecise-1 derivation has the same meaning as the precise-1
+ derivation, except that an activity
+ is known to exist, though it does not need to be
+asserted. This is formalized by the following inference rule,
+referred to as <em>activity introduction</em>:</p>
+<div class="constraint" id="activity-introduction">
+<span class="conditional">If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class="conditional">then</span> there exist an activity record identified by <span class="name">a</span>, a usage record identified by <span class="name">u</span>, and a generation record identified by <span class="name">g</span>
+such that:
+<pre class="codeexample">activity(a,aAttrs)
+wasGeneratedBy(g,e2,a,gAttrs)
+used(u,a,e1,uAttrs)
+</pre>
+for sets of attribute-value pairs <span class="name">gAttrs</span>, <span class="name">uAttrs</span>, and <span class="name">aAttrs</span>.
+</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 href="#dfn-precedes" class="internalDFN">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 determined by
+of <span class="name">e1</span>, given the creation of <span class="name">e2</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the use
+of <span class="name">e1</span>.
+</p>
+
+<div class="note">The following property holds for account where
+generation-unicity applies. Move it to separate section with all
+related material. </div>
+
+<p>A further inference is permitted from the imprecise-1 derivation record: </p>
+<div class="constraint" id="derivation-use">
+<p>Given an activity record identified by <span class="name">pe</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and set of attribute-value pairs <span class="name">attrs2</span>,
+<span class="conditional">if</span> <span class="name">wasDerivedFrom(e2,e1, [prov:steps="1"])</span> and <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> hold, <span class="conditional">then</span> <span class="name">used(pe,e1,attrs1)</span> also holds
+for some set of attribute-value pairs <span class="name">attrs1</span>.
+</p></div>
+<p>This inference is justified by the fact that the entity represented by entity record identified by <span class="name">e2</span> is generated by at most one activity in a given account (see <a href="#generation-unicity">generation-unicity</a>). Hence, this activity record is also the one referred to in the usage record 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(pe,e1)</span>, one cannot
+derive <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> because identifier <span class="name">e1</span> may occur in usage records referring to
+many activity records, but they may not be referred to in generation records containing identifier <span class="name">e2</span>.</p>
+
+
+
+
+<div class="issue">Should derivation have a time? Which time? This is <a href="http://www.w3.org/2011/prov/track/issues/43">ISSUE-43</a>.</div>
+
+</div>
+
+
+<div id="record-complement-of" class="section">
+
+<h5><span class="secno">5.3.3.3 </span>Complementarity Record</h5>
+
+<div class="note">While the working group recognizes the importance of the complementarity record concept, its name and its exact semantics are still being discussed.
+</div>
+
+
+<p>A <dfn id="complementOf">complementarity record</dfn> is a relationship between two entities stated to have compatible characterization over some continuous interval between two events.</p>
+
+<!-- PAOLO, which event do you refer to? <a>event</a>?? -->
+
+
+<p>
+The rationale for introducing this relationship is that in general, at any given time, for an entity in the world, there may be multiple ways of characterizing it, and hence multiple representations can be asserted by different asserters. In the example that follows, suppose thing "Royal Society" is represented by two asserters, each using a different set of attributes. If the asserters agree that both representations refer to "The Royal Society", the question of whether any correspondence can be established between the two representations arises naturally. This is particularly relevant when (a) the sets of attributes used by the two representations overlap partially, or (b) when one set is subsumed by the other. In both these cases, we have a situation where each of the two asserters has a partial view of "The Royal Society", and establishing a correspondence between them on the shared attributes is beneficial, as in case (a) each of the two representation <em>complements</em> the other, and in case (b) one of the two (that with the additional attributes) complements the other.</p>
+
+<p>This intuition is made more precise by considering the entities that form the representations of entities at a certain point in time.
+
+An entity record represents, by means of attribute-value pairs, a thing and its situation in the world, which remain constant over a characterization interval.
+As soon as the thing's situation changes, this marks the end of the characterization interval for the entity record representing it. The thing's novel situation is represented by an attribute with a new value, or an entirely different set of attribute-value pairs, embodied in another entity record, with a new characterization interval. Thus, if we overlap the timelines (or, more generally, the sequences of value-changing events) for the two entities, we can hope to establish correspondences amongst the entity records that represent them at various points along that events line. The figure below illustrates this intuition.</p>
+
+<div style="text-align: center;">
+<img src="complement-of.png" alt="illustration complementOf">
+</div>
+
+<p>
+Relation <em>complement-of</em> between two entity records is intended to capture these correspondences, as follows. Suppose entity records A and B share a set P of attributes, and each of them has other attributes in addition to P. If the values assigned to each attribute in P are <em>compatible</em> between A and B, then we say that <em>A is-complement-of B</em>, and <em>B is-complement-of A</em>, in a symmetrical fashion. In the particular case where the set P of attributes of B is a strict superset of A's attributes, then we say that <em>B is-complement-of A</em>, but in this case the opposite does not hold. In this case, the relation is not symmetric. (as a special case, A and B may not share any attributes at all, and yet the asserters may still stipulate that they are representing the same thing "Royal Society". The symmetric relation may hold trivially in this case).</p>
+
+<p>The term <em>compatible</em> used above means that a mapping can be established amongst the values of attributes in P and found in the two entity expession. This generalizes to the case where attribute sets P1 and P2 of A, and B, respectively, are not identical but they can be mapped to one another. The simplest case is the identity mapping, in which A and B share attribute set P, and furthermore the values assigned to attributes in P match exactly.</p>
+
+<p>It is important to note that the relation holds only for the characterization intervals of the entity expessions involved As soon as one attribute changes value in one of them, new correspondences need to be found amongst the new entities. Thus, the relation has a validity span that can be expressed in terms of the event lines of the entity.</p>
+
+<!--
+The "IVP of" relationship is designed to represent pairs of entities that correspond to each other. By their own nature, an entity remains valid only as long as all of its attributes do not change their value. It follows that the correspondence "B IVP of A" is only valid within the time interval during which such invariance attribute holds for both A and B. When any of the attribute values change in either A or B, those entities are replaced by new ones, and a new correspondence may be established. Thus, "IVP of" is defined relative to the intersection of the temporal intervals for which A and B are valid.
+-->
+
+
+
+<p>A complementarity record is written <span class="name">wasComplementOf(e2,e1)</span>, where <span class="name">e1</span> and <span class="name">e2</span> are two identifiers denoting entity records.</p>
+
+
+<div class="anexample">
+<p>The following example illustrates the entity "Royal Society"and its perspectives at various points in time.</p>
+<pre class="codeexample">entity(rs,[ex:created=1870])
+
+entity(rs_l1,[prov:location="loc2"])
+entity(rs_l2,[prov:location="The Mall"])
+
+entity(rs_m1,[ex:membership=250, ex:year=1900])
+entity(rs_m2,[ex:membership=300, ex:year=1945])
+entity(rs_m3,[ex:membership=270, ex:year=2010])
+
+wasComplementOf(rs_m3, rs_l2)
+wasComplementOf(rs_m2, rs_l1)
+wasComplementOf(rs_m2, rs_l2)
+wasComplementOf(rs_m1, rs_l1)
+
+wasComplementOf(rs_m3, rs)
+wasComplementOf(rs_m2, rs)
+wasComplementOf(rs_m1, rs)
+wasComplementOf(rs_l1, rs)
+wasComplementOf(rs_l2, rs)
+</pre>
+</div>
+
+
+
+<div class="constraint" id="wasComplementOf-necessary-cond">
+An assertion "wasComplementOf(B,A)" holds over the temporal intersection of A and B, <span class="conditional">only if</span>:
+<ol>
+<li> if a mapping can be established from an attribute X of entity record identified by B to an attribute Y of entity record identified by A, then the values of A and B must be consistent with that mapping;</li>
+<li>entity record identified by B has some attribute that entity record identified by A does not have.</li>
+</ol>
+ </div>
+
+<p>The complementarity relation is not transitive. Let us consider identifiers <span class="name">e1</span>, <span class="name">e2</span>, and <span class="name">e3</span> identifying three entity records such that
+ <span class="name">wasComplementOf(e3,e2)</span> and <span class="name">wasComplementOf(e2,e1)</span> hold. The record <span class="name">wasComplementOf(e3,e1)</span> may not hold because the characterization intervals of the denoted entity records may not overlap.</p>
+
+
+<p>In PROV-ASN, a complementarity record's text matches the <span class="nonterminal">complementarityRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class="grammar">
+<span class="nonterminal">complementarityRecord</span> ::=
+<span class="name">wasComplementOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span> <br>
+|
+<span class="name">wasComplementOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">accIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">accIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+<p>
+An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to link two entity record identifiers that are appear in different accounts. (In particular, the entity record identifiers in two different account are allowed to be the same.). When account identifiers are not available, then the linking of entity records through complementarity can only take place within the scope of a single account.
+</p>
+
+
+<div class="anexample">
+<p>In the following example, the same description of the Royal Society is structured according to two different accounts. In the second account, we find a complementarity record linking <span class="name">rs_m1</span> in account <span class="name">ex:acc2</span> to
+<span class="name">rs</span> in account <span class="name">ex:acc1</span>.
+</p><pre class="codeexample">account(ex:acc1,
+ http://example.org/asserter1,
+
+ ...
+ entity(rs,[ex:created=1870])
+ ...
+ )
+
+
+account(ex:acc2,
+ http://example.org/asserter2,
+
+ ...
+ entity(rs_m1,[ex:membership=250, ex:year=1900])
+ ...
+ wasComplementOf(rs_m1, ex:acc2, rs, ex:acc1)
+
+)
+</pre>
+</div>
+
+
+
+<div class="note">It is suggested that the name 'wasComplementOf' does not capture the meaning of this relation adequately. No concrete suggestion has been made so far.
+Furthermore, there is a suggestion that an alternative relation that is transitive may also be useful.
+This is raised in the following <a href="http://lists.w3.org/Archives/Public/public-prov-wg/2011Sep/0315.html">email</a>.</div>
+
+
+
+<div class="issue">A discussion on alternative definition of wasComplementOf has not reached a satisfactory conclusion yet. This is <a href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a></div>
+
+
+
+<div class="pending"> Comments on ivpof in <a href="http://www.w3.org/2011/prov/track/issues/57">ISSUE-57</a>.</div>
+
+
+</div>
+</div>
+
+
+<!--
+<section>
+<h4>Transitive Derivation Record</h4>
+
+
+<p>
+If <span class="name">wasDerivedFrom(e2,e1)</span> holds because attribute <span class="name">a2.1</span> of <span class="name">e2</span> is determined by attribute <span class="name">a1.1</span> of <span class="name">e1</span>,
+and if <span class="name">wasDerivedFrom(e3,e2)</span> holds because attribute <span class="name">a3.1</span>of <span class="name">e3</span> is determined by attribute <span class="name">a2.2</span> of <span class="name">e1</span>, it is not necessarily the case that an attribute of <span class="name">e3</span> is determined by an attribute of <span class="name">e1</span>; so, an asserter may not be able to assert <span class="name">wasDerivedFrom(e3,e1)</span>, since it would fail to satisfy constraint <a href="#derivation-attributes">derivation-attributes</a>. Hence, the constraint on attributes as expressed in <a href="#derivation-attributes">derivation-attributes</a> invalidates transitivity in the general case.
+</p>
+
+<p>However, there is sense that <span class="name">e3</span> still depends on <span class="name">e1</span>, since <span class="name">e3</span> could not be generated without <span class="name">e1</span> existing. Hence, we introduce a weaker notion of derivation record, which is transitive.</p>
+
+A transitive derivation record, written <span class="name">dependedOn(e2, e1)</span> in PROV-ASN:
+<ul>
+<li> contains an identifier <span class="name">e2</span>, denoting an entity record, which represents the entity that is the result of the derivation;
+<li> contains an identifier <span class="name">e1</span>, denoting an entity record, which represents the entity that the derivation relies upon.
+</ul>
+<p>The record <span class="name">dependedOn</span> can only be inferred; in other words, it cannot be asserted. It is
+transitive by definition and relies on the previously defined derivation assertions for its
+base case.</p>
+
+<div class='constraint' id='transitive-derivation'>
+<ul>
+<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> or <span class="name">wasDerivedFrom(e2,e1,pe,attrs2,attrs1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasEventuallyDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
+<li><span class='conditional'>If</span> <span class="name">dependedOn(e3,e2)</span> and <span class="name">dependedOn(e2,e1)</span> hold, <span class='conditional'>then</span> <span class="name">dependedOn(e3,e1)</span> holds.</li>
+</ul>
+</div>
+
+</section>
+-->
+
+
+
+
+
+
+
+<div id="record-annotation" class="section">
+<h4><span class="secno">5.3.4 </span>Annotation Record</h4>
+
+
+<p>An <dfn id="dfn-annotation">annotation record</dfn> establishes a link between an identifiable PROV-DM record and a note record referred to by its identifier. Multiple note records can be associated with a given PROV-DM record; symmetrically, multiple PROV-DM records can be associated with a given note record. Since note records have identifiers, they can also be annotated. The annotation mechanism (with note record and the annotation record) forms a key aspect of the extensibility mechanism of PROV-DM (see <a href="#extensibility-section">extensibility section</a>).</p>
+
+<p>An annotation record, written <span class="name">hasAnnotation(r,n,attrs)</span> in PROV-ASN, has the following constituents:</p>
+<ul>
+<li><em>record</em>: an identifier <span class="name">r</span> of the record being annnotated;</li>
+<li><em>note</em>: an identifier <span class="name">n</span> of a note record;</li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+
+<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
+</p>
+
+<div class="grammar">
+<span class="nonterminal">annotationRecord</span> ::=
+<span class="name">hasAnnotation</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">nIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<p>The interpretation of notes is application-specific. See Section <a href="#record-note">Note</a> for a discussion of the difference between note attributes and other records attributes. We also note the present tense in this term to indicate that it may not denote something in the past.</p>
+
+<div class="anexample">
+<p>
+The following records</p>
+<pre class="codexample">entity(e1,[prov:type="document"])
+entity(e2,[prov:type="document"])
+activity(a,transform,t1,t2,[])
+used(u1,a,e1,[ex:file="stdin"])
+wasGeneratedBy(e2, a, [ex:file="stdout"])
+
+note(n1,[ex:icon="doc.png"])
+hasAnnotation(e1,n1)
+hasAnnotation(e2,n1)
+
+note(n2,[ex:style="dotted"])
+hasAnnotation(u1,n2)
+</pre>
+<p>assert the existence of two documents in the world (attribute-value pair: <span class="name">prov:type="document"</span>) represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these records with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also asserts an activity, its usage of the first entity, and its generation of the second entity. The <span class="name">usage</span> record is annotated with a style (an application specific way of rendering this edge graphically). To be able to express this annotation, the usage record was provided with an identifier <span class="name">u1</span>, which was then referred to in <span class="name">hasAnnotation(u1,n2)</span>.
+</p>
+</div>
+
+
+</div>
+</div>
+
+<div id="bundle" class="section">
+<h3><span class="secno">5.4 </span>Bundle</h3>
+
+<p>In this section, two constructs are introduced to group
+PROV-DM records. The first
+one, <a href="#dfn-Account" class="internalDFN">account record</a> is itself a
+record, whereas the second
+one <a href="#dfn-RecordContainer" class="internalDFN">record container</a> is not.
+</p>
+
+
+<div id="record-Account" class="section">
+<h4><span class="secno">5.4.1 </span>Account Record</h4>
+
+<p>In PROV-DM, an <dfn id="dfn-Account">account record</dfn> is a wrapper of records with a dual purpose: </p>
+<ul>
+<li> It is the mechanism by which attribution of provenance can be assserted; it allows asserters to bundle up their assertions, and assert suitable attribution;
+</li><li> It provides a scoping mechanism for record identifiers and for some contraints (such as
+ <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>).
+</li></ul>
+
+
+
+<p>An account record, written <span class="name">account(id, assertIRI, recs, attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> that identifies this account globally;</li>
+<li><em>asserter</em>: an IRI, denoted by <span class="name">assertIRI</span>, to identify an asserter; such IRI has no specific interpretation in the context of PROV-DM;</li>
+<li><em>records</em>: a set <span class="name">recs</span> of provenance records;</li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p>In PROV-ASN, an account record's text matches the <span class="nonterminal">accountRecord</span> production of the grammar defined in this specification document.</p>
+
+<div class="grammar">
+<span class="nonterminal">accountRecord</span> ::=
+<span class="name">account</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">asserter</span>
+<span class="name">,</span>
+<span class="plus">
+<span class="nonterminal">record</span> </span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<div class="note">
+Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI and its interpretation is outside PROV-DM. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM assertions. The editors seek inputs on how to resolve this issue. </div>
+
+<div class="anexample">
+<p>
+The following account record</p>
+<pre class="codeexample">account(ex:acc0,
+ http://example.org/asserter,
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+ ...
+ wasDerivedFrom(e2,e1)
+ ...
+ activity(a0,create-file,t)
+ ...
+ wasGeneratedBy(e0,a0,[])
+ ...
+ wasAssociatedWith(a4, ag5, [prov:role="communicator"]) )
+</pre>
+<p>contains the set of provenance records of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span class="name">http://example.org/asserter</span>, and is identified by identifier <span class="name">ex:acc0</span>.
+</p>
+</div>
+
+<p>Account records constitue a scope for record identifiers. A record identifier within the scope of an account is intended to denote a single record. However, nothing prevents an asserter from asserting an account containing, for example, multiple entity records with a same identifier but different attribute-values. In that case, they should be understood as a single entity record with this identifier and the union of all attributes values, as formalized in <a href="#identified-entity-in-account">identified-entity-in-account</a>.</p>
+
+<div class="constraint" id="identified-entity-in-account">
+Given an entity record identifier <span class="name">e</span>, two sets of attribute-values denoted by <span class="name">av1</span> and <span class="name">av2</span>,
+ two entity records <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account are equivalent to the entity record <span class="name">entity(e,av)</span> where <span class="name">av</span> is the set of attribute-value pairs formed by the union of <span class="name">av1</span> and <span class="name">av2</span>.
+</div>
+
+<p>Whilst constraint <a href="#identified-entity-in-account">identified-entity-in-account</a> specifies how to understand multiple entity records with a same identifier within a given account, it does not guarantee that the entity record formed with the union of all attribute-value pairs is consistent. Indeed, a given attribute may be assigned multiple values, resulting in an inconsistent entity record, as illustrated by the following example.</p>
+
+<div class="anexample">
+<p>
+In the following account record, we find two entity records with a same identifier <span class="name">e</span>.</p>
+<pre class="codeexample">account(ex:acc1,
+ http://example.org/id,
+ entity(e,[prov:type="person", ex:age=20])
+ entity(e,[prov:type="person", ex:age=30])
+ ...)
+</pre>
+<p>Application of <a href="#identified-entity-in-account">identified-entity-in-account</a> results in an entity record containing the attribute-value pairs <span class="name">age=20</span> and <span class="name">age=30</span>. This results in an inconsistent characterization of a person. We note that deciding whether a set of attribute-values is consistent or not is application specific and outside the scope of this specification.
+</p></div>
+
+<p>Account records can be nested since an account record can occur among the records being wrapped by another account. </p>
+
+
+<p>
+An account is said to be well-formed if
+it satisfies the constraints <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>.</p>
+
+<p> The union of two accounts is another account,
+containing the unions of their respective records, where
+ records with a same identifier should be understood according to constraint <a href="#identified-entity-in-account">identified-entity-in-account</a>. Well-formed
+accounts are not
+closed under union because the
+constraint <a href="#generation-unicity">generation-unicity</a> may no
+longer be satisfied in the resulting union. </p>
+
+<div class="anexample">
+<p>
+Indeed, let us consider another account record</p>
+<pre class="codeexample">account(ex:acc2,
+ http://example.org/asserter2,
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+ ...
+ activity(a1,create-file,t1)
+ ...
+ 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-unicity">generation-unicity</a>.</p>
+</div>
+
+<p>Account records constitute a scope for record identifiers. Since accounts can be nested, scopes can also be nested; thus, the scope of record identifiers should be understood in the context of such nested scopes. When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur. </p>
+
+<div class="anexample">
+<p>
+The following account record is inspired from section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>. This account, identified by <span class="name">ex:acc3</span>, declares entity record with identifier <span class="name">e0</span>, which is being referred to in the nested account <span class="name">ex:acc4</span>. The scope of identifier <span class="name">e0</span> is account <span class="name">ex:acc3</span>, including subaccount <span class="name">ex:acc4</span>.</p>
+<pre class="codeexample">account(ex:acc3,
+ http://example.org/asserter1,
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+ activity(a0,create-file,t)
+ wasGeneratedBy(e0,a0,[])
+ account(ex:acc4,
+ http://example.org/asserter2,
+ entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
+ activity(a0,copy-file,t)
+ wasGeneratedBy(e1,a0,[ex:fct="create"])
+ wasComplementOf(e1,e0)))
+</pre>
+<p>Alternatively, an activity record identified by <span class="name">a0</span> occurs in each of the two accounts. Therefore, each activity record is asserted in a separate scope, and therefore may represent different activities in the world.
+</p>
+</div>
+
+<p>The account record is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. The annotation mechanism can be used for this purpose, but how general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>
+
+
+</div>
+
+<div id="RecordContainer" class="section">
+<h4><span class="secno">5.4.2 </span>Record Container</h4>
+
+<p>A <dfn id="dfn-RecordContainer">record container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM records. A record container is not a record, but can be exploited to return assertions in response to a request for the provenance of something ([<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PAQ">PROV-PAQ</a></cite>]). </p>
+
+<p>
+
+
+</p><p>A record container, written <span class="name">container decls recs endContainer</span> in PROV-ASN, contains:
+</p><ul>
+<li><em>namespaceDeclarations</em>: a set <span class="name">decls</span> of namespace declarations, declaring namespaces and associated prefixes, which can be used in <a title="attribute" href="#dfn-attribute" class="internalDFN">attributes</a> and <a title="identifier" href="#dfn-identifier" class="internalDFN">identifiers</a> occurring inside <span class="name">recs</span>;</li>
+<li><em>records</em>: a non-empty set of records <span class="name">recs</span>.</li>
+</ul>
+<p>All the records in <span class="name">recs</span> are implictly wrapped in a default account, scoping all the record identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts. Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a container's default account.</p>
+
+<p>In PROV-ASN, a record container's text matches the <span class="nonterminal">recordContainer</span> production of the grammar defined in this specification document.</p>
+
+
+<div class="grammar">
+<span class="nonterminal">recordContainer</span> ::=
+<span class="name">container</span>
+<span class="nonterminal">namespaceDeclarations</span>
+<span class="plus"> <span class="nonterminal">record</span> </span>
+<span class="name">endContainer</span>
+</div>
+
+
+<div class="anexample">
+<p>
+The following container </p>
+<pre class="codeexample">container
+ prefix ex: http://example.org/,
+
+ account(ex:acc1,http://example.org/asserter1,...)
+ account(ex:acc2,http://example.org/asserter1,...)
+endContainer
+</pre>
+<p> illustrates how two accounts with identifiers <span class="name">ex:acc1</span> and <span class="name">ex:acc2</span> can be returned in a PROV-ASN serialization of the provenance of something.
+</p>
+</div>
+
+
+<div class="pending">Asserter needs to be defined. This is <a href="http://www.w3.org/2011/prov/track/issues/51">ISSUE-51</a>.</div>
+
+
+<div class="pending">Scope and Identifiers. This is <a href="http://www.w3.org/2011/prov/track/issues/81">ISSUE-81</a>.</div>
+
+
+</div>
+</div>
+
+
+<div id="sub-record" class="section">
+<h3><span class="secno">5.5 </span>Further Terms in Records</h3>
+
+This section further terms in PROV-DM records.
+
+
+
+<div id="record-attribute" class="section">
+<h4><span class="secno">5.5.1 </span>Attribute</h4>
+
+<p>An <dfn id="dfn-attribute">attribute</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
+ by concatenating the IRI associated with the prefix and the local part (see detailed rule in [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SPARQL-QUERY">RDF-SPARQL-QUERY</a></cite>], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
+
+<div class="grammar">
+<span class="nonterminal">attribute</span> ::= <span class="nonterminal">qualifiedName</span><br>
+<span class="nonterminal">qualifiedName</span> ::= <span class="nonterminal">prefixedName</span> | <span class="nonterminal">unprefixedName</span><br>
+<span class="nonterminal">prefixedName</span> ::= <span class="nonterminal">prefix</span> <span class="name">:</span> <span class="nonterminal">localPart</span><br>
+<span class="nonterminal">unprefixedName</span> ::= <span class="nonterminal">localPart</span><br>
+<span class="nonterminal">prefix</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES">XML-NAMES</a></cite>]</em><br>
+<span class="nonterminal">localPart</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES">XML-NAMES</a></cite>]</em>
+</div>
+
+<p>A qualified name's prefix is <em class="rfc2119" title="optional">optional</em>. If a prefix occurs in a
+ qualified name, it refers to a <a href="#dfn-namespace" class="internalDFN">namespace</a> declared in the
+ record container. In the absence of prefix, the qualified name
+ refers to the default namespace declared in the container.</p>
+
+<div class="note">Note that XML NC_NAME don't allow local identifiers to start with a number. Instead, should we use the productions used in SPARQL or TURTLE?</div>
+
+<p>From this specification's viewpoint, the interpretation of an attribute declared in a namespace other than prov-dm is out of
+scope.</p>
+
+<p>The PROV data model introduces a fixed set of attributes in the <a href="#prov-dm-namespace">PROV-DM namespace</a>:</p>
+<ul>
+<li> The attribute <dfn id="dfn-role"><span class="name">prov:role</span></dfn> denotes the function of an entity with respect to an activity, in the context of a usage, generation, activity association, start, end record. The value associated with a <span class="name">prov:role</span> attribute <em class="rfc2119" title="must">must</em> be conformant with <span class="nonterminal">Literal</span>.
+
+<div class="anexample">
+<p>The following start record describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
+<pre class="codeexample"> wasStartedBy(a,ag, [prov:role="program-operator"])
+</pre>
+</div>
+ </li>
+
+<li> The attribute <dfn id="dfn-type"><span class="name">prov:type</span></dfn> provides further typing information for the element or relation asserted in the record. The value associated with a <span class="name">prov:type</span> attribute <em class="rfc2119" title="must">must</em> be conformant with <span class="nonterminal">Literal</span>.
+
+<div class="anexample">
+<p>The following record declares an agent of type software agent</p>
+<pre class="codeexample"> agent(ag, [prov:type="prov:SoftwareAgent" %% xsd:QName])
+</pre>
+</div>
+
+
+</li><li> The attribute <dfn id="dfn-steps"><span class="name">prov:steps</span></dfn> defines the level of precision associated with a derivation record. The value associated with a <span class="name">prov:steps</span> attribute <em class="rfc2119" title="must">must</em> be <span class="name">"1"</span> or <span class="name">"n"</span>. </li>
+
+</ul>
+</div>
+
+
+
+<div id="record-identifier" class="section">
+<h4><span class="secno">5.5.2 </span>Identifier</h4>
+
+
+<p>An <dfn id="dfn-identifier">identifier</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
+ by concatenating the IRI associated with the prefix and the local part (see detailed rule in [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SPARQL-QUERY">RDF-SPARQL-QUERY</a></cite>], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
+
+<div class="grammar">
+<span class="nonterminal">identifier</span> ::= <span class="nonterminal">qualifiedName</span><br>
+<span class="nonterminal">eIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an entity record)</em><br>
+<span class="nonterminal">aIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an activity record)</em><br>
+<span class="nonterminal">agIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an agent record)</em><br>
+<span class="nonterminal">gIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a generation record)</em><br>
+<span class="nonterminal">uIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a usage record)</em><br>
+<span class="nonterminal">nIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a note record)</em><br>
+<span class="nonterminal">accIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote an account record)</em>
+</div>
+
+
+</div>
+
+<div id="record-literal" class="section">
+<h4><span class="secno">5.5.3 </span>Literal</h4>
+
+<p>
+A PROV-DM Literal represents a data value such as a particular string
+or number. A PROV-DM Literal represents a value whose interpretation is outside the scope of PROV-DM.
+</p>
+
+<p>In PROV-ASN, a Literal's text matches the <span class="nonterminal">Literal</span> production of the grammar defined in this specification document.</p>
+
+<div class="grammar">
+<span class="nonterminal">Literal</span> ::= <span class="nonterminal">typedLiteral</span> | <span class="nonterminal">convenienceNotation</span> <br>
+<span class="nonterminal">typedLiteral</span> ::= <span class="nonterminal">quotedString</span> <span class="name">%%</span> <span class="nonterminal">datatype</span><br>
+<span class="nonterminal">datatype</span> ::= <span class="nonterminal">qualifiedName</span><br>
+<span class="nonterminal">convenienceNotation</span> ::= <span class="nonterminal">stringLiteral</span> | <span class="nonterminal">intLiteral</span><br>
+<span class="nonterminal">stringLiteral</span> ::= <span class="nonterminal">quotedString</span><br>
+<span class="nonterminal">quotedString</span> ::= <em>a finite sequence of characters in which " (U+22) and \ (U+5C) occur only in pairs of the form \" (U+5C, U+22) and \\ (U+5C, U+5C), enclosed in a pair of " (U+22) characters</em><br>
+<span class="nonterminal">intLiteral</span> ::= <em>a finite-length sequence of decimal digits (#x30-#x39) with an optional leading negative sign (-)</em>
+</div>
+
+<p>The non terminals <span class="nonterminal">stringLiteral</span> and
+<span class="nonterminal">intLiteral</span>
+are syntactic sugar for quoted strings with datatype <span class="name">xsd:string</span> and <span class="name">xsd:int</span>, respectively.
+</p>
+
+<p> In particular, a PROV-DM Literal may be an IRI-typed string (with datatype <span class="name">xsd:anyURI</span>); such IRI has no specific interpretation in the context of PROV-DM.</p>
+
+
+<div class="anexample">
+<p>
+The following examples respectively are the string "abc" (expressed using the convenience notation), the string "abc", the integer number 1, the integer number 1 (expressed using the convenience notation) and the IRI "http://example.org/foo".
+</p><pre class="codeexample"> "abc"
+ "abc" %% xsd:string
+ "1" %% xsd:int
+ 1
+ "http://example.org/foo" %% xsd:anyURI
+</pre>
+The following example shows a literal of type <span class="name">xsd:QName</span> (see
+<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#QName">QName</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>]).
+The prefix <span class="name">ex</span> <em class="rfc2119" title="must">must</em> be bound to a <a href="#dfn-namespace" class="internalDFN">namespace</a> declared in the
+ record container.
+<pre class="codeexample"> "ex:value" %% xsd:QName
+</pre>
+</div>
+
+
+
+<div class="note">Should we define structural equivalence of literals as in OWL2? [<cite><a class="bibref" rel="biblioentry" href="#bib-OWL2-SYNTAX">OWL2-SYNTAX</a></cite>]
+(see section <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Literals">Literals</a>).
+</div>
+
+</div>
+
+
+
+
+<div id="record-Time" class="section">
+<h4><span class="secno">5.5.4 </span>Time</h4>
+
+<p><dfn id="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].</p>
+
+
+
+<p>It is <em class="rfc2119" title="optional">optional</em> to assert time in usage, generation, and activity records.</p>
+
+
+
+
+</div>
+
+<div id="record-Asserter" class="section">
+<h4><span class="secno">5.5.5 </span>Asserter</h4>
+
+<p>An <dfn id="dfn-asserter">asserter</dfn> is a creator of PROV-DM records. An asserter is denoted by an IRI. Such IRI has no specific interpretation in the context of PROV-DM.</p>
+
+<div class="grammar">
+<span class="nonterminal">asserter</span> ::= <span class="nonterminal">IRI</span><br>
+<span class="nonterminal">IRI</span> ::= <em>an IRI compatible with production IRI in [<cite><a class="bibref" rel="biblioentry" href="#bib-IRI">IRI</a></cite>], enclosed in a pair of < (U+3C) and > (U+3E) characters </em>
+</div>
+
+<div class="note">
+Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM. We seek inputs on how to resolve this issue. </div>
+
+</div>
+
+<div id="record-NamespaceDeclaration" class="section">
+<h4><span class="secno">5.5.6 </span>Namespace Declaration</h4>
+
+<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [<cite><a class="bibref" rel="biblioentry" href="#bib-IRI">IRI</a></cite>]. In PROV-DM, attributes, identifiers, and literals of with datatype <span class="name">xsd:QName</span> can be placed in a namespace using the mechanisms described in this specification. </p>
+
+
+<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this declaration refers to this namespace.
+A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration refers to this namespace.</p>
+
+<div class="grammar">
+<span class="nonterminal">namespaceDeclarations</span> ::=
+ | <span class="group"><span class="nonterminal">defaultNamespaceDeclaration</span> | <span class="nonterminal">namespaceDeclaration</span></span> <span class="star"> <span class="nonterminal">namespaceDeclaration</span></span><br>
+<span class="nonterminal">namespaceDeclaration</span> ::=
+<span class="name">prefix</span> <span class="nonterminal">prefix</span> <span class="nonterminal">IRI</span><br>
+<span class="nonterminal">defaultNamespaceDeclaration</span> ::=
+ <span class="name">default</span> <span class="nonterminal">IRI</span> <br>
+</div>
+</div>
+
+
+<div id="record-RecipeLink" class="section">
+<h4><span class="secno">5.5.7 </span>Recipe Link</h4>
+
+
+<p>A <dfn id="dfn-RecipeLink">recipe link</dfn> is an association between an activity record and a process specification that underpins the represented activity. Such IRI has no specific interpretation in the context of PROV-DM.
+</p>
+
+<div class="grammar">
+<span class="nonterminal">recipeLink</span> ::= <span class="nonterminal">IRI</span>
+</div>
+
+<p>
+It is <em class="rfc2119" title="optional">optional</em> to assert recipe links in activities.
+</p>
+
+
+<p>
+Process specifications, as referred to by recipe links, are out of scope of this specification.
+</p>
+
+<div class="note">
+By defining a recipe link as an IRI whose interpretation is out of
+scope of PROV-DM, we don't allow it to refer to an entity (in an
+inter-operable manner). Is this what we intend?
+</div>
+
+<div class="issue"> Simplify the references to recipe link. This is <a href="http://www.w3.org/2011/prov/track/issues/131">ISSUE-131</a></div>
+
+</div>
+
+
+
+
+
+<div id="record-Location" class="section">
+<h4><span class="secno">5.5.8 </span>Location</h4>
+
+<p><dfn id="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, row, column, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations in assertions. </p>
+
+
+<p>
+Location is an <em class="rfc2119" title="optional">optional</em> attribute of entity records and activity records. The value associated with a attribute <span class="name">location</span> <em class="rfc2119" title="must">must</em> be a <span class="nonterminal">Literal</span>, expected to denote a location.
+</p>
+
+
+
+
+</div>
+
+</div>
+
+</div>
+
+
+ <div id="common-relations" class="section">
+<!--OddPage--><h2><span class="secno">6. </span>PROV-DM Common Relations</h2>
+
+<p>This section contains the normative specification of common relations of PROV-DM.</p>
+
+
+<div class="issue">We have defined a set of common relation, in response to <a href="http://www.w3.org/2011/prov/track/issues/44">ISSUE-44</a>. Is this set complete?</div>
+
+
+<div class="note">The types of these relations need to be made explicit.</div>
+
+<p>The following figure summarizes the additional relations described in subsections 6.2 onwards.</p>
+
+<div style="text-align: center;">
+<img src="sec6-summary.png" alt="common relations">
+</div>
+
+
+<div id="record-Collection" class="section">
+<h3><span class="secno">6.1 </span>Collections</h3>
+
+The purpose of this section is to enable modelling of part-of relationships amongst entities. In particular, a form of <strong>collection</strong> entity type is introduced, consisting of a set of key-value pairs. Key-value pairs provide a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more.<br>
+
+The relations introduced here are all specializations of the <a href="#record-Derivation"><strong>wasDerivedFrom</strong></a> relation, specifically precise-1 or imprecise-1. They are designed to model:
+
+<ul>
+ <li><strong>insertion</strong>: a collection entity c' is obtained from collection entity c, by adding entity e having key k to c;
+ </li><li><strong>removal</strong>: a collection entity c' is obtained from collection entity c, by removing entity e having key k from c;
+ </li><li><strong>selection</strong>: an entity e was selected from collection c using key k.
+ </li></ul>
+
+ A collection record is defined as follows.
+<div class="grammar">
+ <span class="nonterminal">collectionRecord</span> ::=
+<span class="nonterminal">collectionDerivationRecord</span>
+| <span class="nonterminal">keyDerivationRecord</span>
+| <span class="nonterminal">entityMembershipRecord</span>
+<br>
+
+ <span class="nonterminal">collectionDerivationRecord</span> ::=
+<span class="name">wasAddedTo_Coll</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+ |
+<span class="name">wasRemovedFrom_Coll</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+<br>
+
+ <span class="nonterminal">keyDerivationRecord</span> ::=
+<span class="name">wasAddedTo_Key</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+|
+<span class="name">wasRemovedFrom_Key</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+ <br>
+
+ <span class="nonterminal">entityMembershipRecord</span> ::=
+<span class="name">wasAddedTo_Entity</span>
+ <span class="name">(</span>
+ <span class="nonterminal">identifier</span>
+ <span class="name">,</span>
+<span class="nonterminal">identifier</span>
+ <span class="name">)</span>
+<br>
+ </div>
+
+<p> Record: <span class="name">wasAddedTo_Coll(c2,c1)</span> (resp. <span class="name">wasRemovedFrom_Coll(c2,c1)</span>) denotes that collection <span class="name">c2</span> is an updated version of collection <span class="name">c1</span>, following an insertion (resp. deletion) operation.</p>
+
+<p> Record: <span class="name">wasAddedTo_Key(c,k)</span> (resp. <span class="name">wasRemovedFrom_Key(c,k)</span>) denotes that collection <span class="name">c</span> had
+ a new value with key <span class="name">k</span> added to (resp. removed from) it.</p>
+
+<p> Record: <span class="name">wasAddedTo_Entity(c,e)</span> denotes that collection <span class="name">c</span> had entity
+ <span class="name">e</span> added to it.
+</p>
+
+
+<div class="anexample">
+<p>Consider the following assertions:</p>
+<pre class="codeexample">
+
+ <span class="name">wasAddedTo_Coll(c2,c1)</span>
+ <span class="name">wasAddedTo_Key(c2,k1)</span>
+ <span class="name">wasAddedTo_Entity(c2,e1)</span>
+
+ <span class="name">wasAddedTo_Coll(c3,c2)</span>
+ <span class="name">wasAddedTo_Key(c3,k2)</span>
+ <span class="name">wasAddedTo_Entity(c3,e2)</span>
+
+ <span class="name">wasRemovedFrom_Coll(c4,c3)</span>
+ <span class="name">wasRemovedFrom_Key(c4,k1)</span>
+</pre>
+<p>The corresponding graphical representation is shown below.</p>
+
+<div style="text-align: center;">
+<img src="collections.png" alt="collections">
+</div>
+
+
+<p> With these assertions:</p>
+ <ul>
+ <li><span class="name">c2</span> is known to contain the key-value pair <span class="name">(k1,e1)</span>
+ </li><li><span class="name">c3</span> is known to contain pairs <span class="name">(k1,e1)</span> and <span class="name">(k2,e2)</span>.
+ </li><li><span class="name">c4</span> is known <em>not</em> to contain pair <span class="name">(k1,e1)</span> and to contain pair <span class="name">(k2,e2)</span>.
+ </li></ul>
+</div>
+
+ </div>
+
+<div id="record-traceability" class="section">
+<h3><span class="secno">6.2 </span>Traceability Record</h3>
+
+<p> A <dfn id="dfn-Traceability">traceability record</dfn> states the existence of a "dependency path" between two entities, indicating that one entity can be shown to be in the lineage of another, and may have influenced it in some way. This relation is transitive. </p>
+
+<p> A traceability record, written <span class="name">tracedTo(id,e2,e1,attrs)</span> in PROV-ASN:</p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the traceability record;</li>
+<li><em>entity</em>: an identifier <span class="name">e2</span> identifying an entity;
+</li><li><em>ancestor</em>: an identifier <span class="name">e1</span> identifying an ancestor entity in the lineage of <span class="name">e2</span>;
+</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p>In PROV-ASN, a traceability record's text matches the <span class="nonterminal">traceabilityRecord</span> production of the grammar defined in this specification document.</p>
+
+
+<div class="grammar">
+<span class="nonterminal">traceabilityRecord</span> ::=
+<span class="name">tracedTo</span>
+<span class="name">(</span>
+<span class="optional"><span class="nonterminal">identifier</span>
+<span class="name">,</span></span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<p>A traceability record can be inferred from existing relations, or can be asserted stating that such a dependency path exists without the asserter knowing its individual steps, as expressed by the following constraints.
+
+</p><div class="constraint" id="traceability-inference">
+Given two identifiers <span class="name">e2</span> and <span class="name">e1</span> identifying entity records,
+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>
+
+<div class="constraint" id="traceability-assertion">
+<span class="conditional">If</span> the record <span class="name">tracedTo(r2,r1)</span> holds
+for two identifiers <span class="name">r2</span> and <span class="name">r1</span> identifying entity records,
+ <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 record. </p>
+
+
+</div>
+
+<div id="record-OrderingOfActivities" class="section">
+<h3><span class="secno">6.3 </span>Activity Ordering Record</h3>
+
+
+
+<p>PROV-DM allows dependencies amongst activities to be expressed.
+An <dfn id="InformationFlowOrdering">information flow ordering record</dfn> is a representation that an entity was generated by an activity, before it was used by another activity.
+A <dfn id="ControlOrdering">control ordering record</dfn> is a representation that an activity was initiated by another activity.
+</p>
+
+<p>In PROV-ASN, an activity ordering record's text matches the <span class="nonterminal">activityOrderingRecord</span> production of the grammar defined in this specification document.
+</p>
+
+<div class="grammar">
+<span class="nonterminal">activityOrderingRecord</span> ::=
+<span class="nonterminal">informationFlowOrderingRecord</span> |
+<span class="nonterminal">controlOrderingRecord</span>
+<br>
+
+<span class="nonterminal">informationFlowOrderingRecord</span> ::=
+<span class="name">wasInformedBy</span>
+<span class="name">(</span>
+<span class="optional"><span class="nonterminal">identifier</span>
+<span class="name">,</span>
+</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+<br>
+
+<span class="nonterminal">controlOrderingRecord</span> ::=
+<span class="name">wasStartedBy</span>
+<span class="name">(</span>
+<span class="optional"><span class="nonterminal">identifier</span>
+<span class="name">,</span>
+</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+<br>
+</div>
+
+
+<p>
+An information flow ordering record, written as
+<span class="name">wasInformedBy(id,a2,a1,attrs)</span> in PROV-ASN, contains:
+</p><ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the record;</li>
+<li><em>informed</em>: the identifier <span class="name">a2</span> of an activity record representing the informed activity;
+</li><li><em>informant</em>: the identifier <span class="name">a1</span> of an activity record representing the informant activity;
+</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p> An information flow ordering record is formally defined as follows.</p>
+
+<div class="constraint" id="wasInformedBy-Definition">Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
+ the record <span class="name">wasInformedBy(a2,a1)</span>
+holds, <span class="conditional">if and only if</span>
+ there is an entity record identified by <span class="name">e</span> and 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" id="wasInformedBy-ordering">
+Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class="conditional">if</span> the record <span class="name">wasInformedBy(a2,a1)</span>
+ holds, <span class="conditional">then</span> the following temporal constraint holds:
+the <a title="activity start event" href="#dfn-start-event" class="internalDFN">start event</a> of the activity record denoted by <span class="name">a1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end event</a> of
+the activity record denoted by <span class="name">a2</span>.
+</div>
+
+
+<p>The relationship <span class="name">wasInformedBy</span> is not transitive. Indeed, consider the following records.</p>
+<pre class="codeexample">wasInformedBy(a2,a1)
+wasInformedBy(a3,a2)
+</pre>
+<p> We cannot infer <span class="name">wasInformedBy(a3,a1)</span> from them. 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 where transitivity cannot hold. The horizontal axis represents time. 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;">
+<img src="informedByNonTransitive.png" alt="non transitivity of wasInformedBy">
+</div>
+
+<div class="note">
+The relation wasScheduledAfter was dropped, and replaced by a simplier relation wasStartedBy(a2,a1). It is intentional that the name wasStartedBy is overloaded.
+</div>
+
+<p>
+A control ordering record, written as
+<span class="name">wasStartedBy(a2,a1)</span> in PROV-ASN, contains: </p>
+<ul>
+<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span>;</li>
+<li><em>started</em>: refers to an activity record identified by <span class="name">a2</span>, representing the started activity;
+</li><li><em>starter</em>: refers to an activity record identified by <span class="name">a1</span>, representing the activity that started <span class="name">a1</span>;</li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+<p>Such a record states control ordering between <span class="name">a2</span> and <span class="name">a1</span>, specified as follows.</p>
+
+<div class="constraint" id="wasStartedBy">Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
+ the record <span class="name">wasStartedBy(a2,a1)</span>
+holds <span class="conditional">if and only if</span>
+ there exist an entity record identified by <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>
+
+
+<div class="anexample">
+<p>
+In the following assertions, we find two activity records, identified by <span class="name">a1</span> and <span class="name">a2</span>, representing two activities, which took place on two separate hosts. The third record indicates that the latter activity was started by the former.</p>
+<pre class="codeexample">activity(a1,workflow,t1,t2,[ex:host="server1.example.org"])
+activity(a2,sub-workflow,t3,t4,[ex:host="server2.example.org"])
+wasStartedBy(a2,a1)
+</pre>
+
+<p>Alternatively, we could have asserted the existence of an entity, representing a request to create a sub-workflow. This request, issued by <span class="name">a1</span>, triggered the start of <span class="name">a2</span>.
+</p>
+<pre class="codeexample">entity(e,[prov:type="creation-request"])
+wasGeneratedBy(e,a1)
+wasStartedBy(a2,e)
+</pre>
+</div>
+
+<div class="interpretation" id="wasStartedBy-ordering">
+Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class="conditional">if</span> the record <span class="name">wasStartedBy(a2,a1)</span>
+ holds, <span class="conditional">then</span> the following temporal constraint holds: the
+<a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a> event of the activity record denoted by <span class="name">a1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity start event" href="#dfn-start-event" class="internalDFN">start event</a> of
+the activity record denoted by <span class="name">a2</span>.
+</div>
+
+
+
+<div class="pending">Suggested definition for process ordering. This is <a href="http://www.w3.org/2011/prov/track/issues/50">ISSUE-50</a>.</div>
+
+</div>
+
+<div id="record-Revision" class="section">
+<h3><span class="secno">6.4 </span>Revision Record</h3>
+
+<p> A <dfn id="dfn-Revision">revision record</dfn> is a representation of the creation of an entity considered to be a variant of another. Deciding whether something is made available as a revision of something else usually involves an agent who represents someone in the world who takes responsibility for approving that the former is a due variant of the latter. </p>
+
+<p> A revision record, written <span class="name">wasRevisionOf(e2,e1,ag,attrs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>newer</em>: an identifier <span class="name">e2</span> identifying an entity that represents a newer version of an entity;
+</li><li><em>older</em>: an identifier <span class="name">e1</span> identifying an entity that represents an older version of an entity;
+</li><li><em>responsibility</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">ag</span> for the agent who approved that <span class="name">e2</span> is a variant of <span class="name">e1</span>;
+</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+
+<p>In PROV-ASN, a revision record's text matches the <span class="nonterminal">revisionRecord</span> production of the grammar defined in this specification document.
+</p>
+
+<div class="grammar">
+<span class="nonterminal">revisionRecord</span> ::=
+<span class="name">wasRevisionOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="optional"><span class="name">,</span>
+<span class="nonterminal">agIdentifier</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+
+
+
+<p>A revision record needs to satisfy the following constraint, linking the two entity records by a derivation, and stating them to be a complement of a third entity record.</p>
+
+<div class="constraint" 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> a record <span class="name">wasRevisionOf(new,old,ag)</span> is asserted, <span class="conditional">then</span>
+there exists an entity record identifier <span class="name">e</span> and attribute-values <span class="name">eAttrs</span>, <span class="name">dAttrs</span>, such that the following records hold:
+<ul>
+<li> <span class="name">wasDerivedFrom(new,old,dAttrs)</span>;
+</li><li> <span class="name">entity(e,eAttrs)</span>;
+</li><li> <span class="name">wasComplementOf(new,e)</span>;
+</li><li> <span class="name">wasComplementOf(old,e)</span>.
+</li></ul>
+The derivation record may be imprecise-1 or imprecise-n.
+</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>
+
+<div class="anexample">
+<p>
+The following revision assertion</p>
+<pre class="codeexample">agent(ag,[prov:type="QualityController"])
+entity(e1,[prov:type="document"])
+entity(e2,[prov:type="document"])
+wasRevisionOf(e2,e1,ag)
+</pre>
+<p>states that the document represented by entity record identified by <span class="name">e2</span> is a revision of document represented by entity record identified by <span class="name">e1</span>; agent denoted by <span class="name">ag</span> is responsible for this new versioning of the document.
+</p>
+</div>
+
+
+<div class="pending">Revision should be a class not a property. This is <a href="http://www.w3.org/2011/prov/track/issues/48">ISSUE-48</a>.</div>
+
+
+</div>
+
+
+<div id="attribution-record" class="section">
+<h3><span class="secno">6.5 </span>Attribution Record</h3>
+
+<p>An attribution record represents that an entity is ascribed to an agent and is compliant with the <span class="nonterminal">attributionRecord</span> production.</p>
+
+
+<p> An attribution record, written <span class="name"> wasAttributedTo(e,ag,attr)</span>, contains the following components:</p>
+<ul>
+<li><em>entity</em>: an identifier <span class="name">e</span> of an entity record;</li>
+<li><em>agent</em>: an identifier <span class="name">ag</span> of an agent whom the entity is attributed to;</li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+<p>Attribution models the notion of an activity generating an entity identified by <span class="name">e</span> being controlled by an agent <span class="name">ag</span>, which takes responsibility for generating <span class="name">e</span>. Formally, this is expressed as the following necessary condition.</p>
+
+<p>In PROV-ASN, an attribution record's text matches the <span class="nonterminal">attributionRecord</span> production of the grammar.</p>
+
+<div class="grammar">
+<span class="nonterminal">attributionRecord</span> ::=
+<span class="name">wasAttributedTo</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<div class="constraint" 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 identified by <span class="name">pe</span> such that the following statements hold:
+<pre>activity(pe,recipe,t1,t2,attr1)
+wasGenerateBy(e,pe)
+wasAssociatedWith(pe,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>
+</div>
+
+
+<div id="quotation-record" class="section">
+<h3><span class="secno">6.6 </span>Quotation Record</h3>
+
+
+<p> A quotation record is a representation of the repeating or copying of some part of an entity, compatible with
+the <span class="nonterminal">quotationRecord</span> production.</p>
+
+
+<p> A quotation record, written <span class="name"> wasQuotedFrom(e2,e1,ag2,ag1,attrs)</span>, contains:</p>
+<ul>
+<li><em>quote</em>: an identifier <span class="name">e2</span>, identifying an entity record that represents the quote;
+</li><li><em>quoted</em>: an identifier <span class="name">e1</span>, identifying an entity record representing what is being quoted;
+</li><li><em>quoterAgent</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">ag2</span> of the agent who is doing the quoting;
+</li><li><em>quotedAgent</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">ag1</span> of the agent that is quoted;
+</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+
+</ul>
+
+<p>In PROV-ASN, a quotation record's text matches the <span class="nonterminal">quotationRecord</span> production of the grammar.</p>
+
+<div class="grammar">
+<span class="nonterminal">quotationRecord</span> ::=
+<span class="name">wasQuotedFrom</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">agIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+
+<div class="constraint" id="quotation-implication">
+<span class="conditional">If</span>
+<span class="name">wasQuotedFrom(e2,e1,ag2,ag1)</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 records hold:
+<pre>wasDerivedFrom(e2,e1)
+wasAttributedTo(e2,ag2)
+wasAttributedTo(e1,ag1)
+</pre>
+</div>
+
+</div>
+
+
+<div id="summary-record" class="section">
+<h3><span class="secno">6.7 </span>Summary Record</h3>
+<p>A <dfn id="dfn-summary-record">summary record</dfn> represents that an entity is a synopsis or abbreviation of another entity. A summary record is compliant with the
+<span class="nonterminal">summaryRecord</span> production.</p>
+
+
+
+<p> An assertion wasSummaryOf, written <span class="name"> wasSummaryOf(e2,e1,attrs)</span>, contains:</p>
+<ul>
+<li><em>summarizedEntity</em>: an identifier <span class="name">e2</span> for the entity record that represents the summary;
+</li><li><em>fullEntity</em>: an identifier <span class="name">e1</span> for the entity record that represents what is being summarized;
+</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p>In PROV-ASN, a summary record's text matches the <span class="nonterminal">summaryRecord</span> production of the grammar.</p>
+
+<div class="grammar">
+<span class="nonterminal">summaryRecord</span> ::=
+<span class="name">wasSummaryOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<p>
+<span class="name">wasSummaryOf</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
+</p>
+
+
+</div>
+
+<div id="original-source-record" class="section">
+<h3><span class="secno">6.8 </span>Original Source Record</h3>
+
+<p>An <dfn id="dfn-original-source-record">original source record</dfn> represents an entity in
+which another entity first appeared. A original-source
+record is compliant with the
+<span class="nonterminal">originalSourceRecord</span> production.</p>
+
+
+<p> An assertion hadOriginalSource, written <span class="name"> hadOriginalSource(e2,e1,attrs)</span>, contains:</p>
+<ul>
+<li><em>entity</em>: an identifier <span class="name">e1</span> for the entity record representing the original entity; </li>
+<li><em>source</em>: an identifier <span class="name">e2</span> for an entity record, representing an entity that had appeared previously;</li>
+<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
+</ul>
+
+<p>
+ <span class="name">hasOriginalSource</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
+</p>
+
+<p>In PROV-ASN, an original source record's text matches the <span class="nonterminal">originalSourceRecord</span> production of the grammar.</p>
+
+<div class="grammar">
+<span class="nonterminal">originalSourceRecord</span> ::=
+<span class="name">hadOriginalSource</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+</div>
+</div>
+
+ <div id="extensibility-section" class="section">
+<!--OddPage--><h2><span class="secno">7. </span>PROV-DM Extensibility Points</h2>
+
+
+<p>The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
+
+</p><ul>
+<li> Attributes are constructs of the data model that allow representations of aspects of the world's entities and activities to be expressed. Applications are free to introduce application-specific attributes, according to their perspective on the world. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace declared in a namespace declaration.
+
+<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes: <span class="name">type</span>, <span class="name">location</span>.</p></li>
+
+
+<li> Sets of Attribute-value pairs offer a mechanism to
+describe modalities of use, generation, and control
+Such attributes are also qualified by namespaces.
+
+<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
+
+
+<li>Note records allow arbitrary metadata to be associated with identifiable records of PROV-DM. Note records consist of name-value pairs. Like attributes, names are qualified by a namespace.</li>
+
+
+<li>Namespaces allow attributes and names to be qualified. </li>
+
+<li>Subtyping is allowed by means of the reserved attribute <span class="name">type</span>.</li>
+
+<li>Domain specific values can be expressed by means of typed literals. </li>
+</ul>
+
+<p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged. To ensure inter-operability, specializations of the PROV data model that exploit the extensibility points summarized in this section <em class="rfc2119" title="must">must</em> preserve the semantics specified in this document. For instance, a qualified attribute on a domain specific entity record <em class="rfc2119" title="must">must</em> represent an aspect of an entity and this aspect <em class="rfc2119" title="must">must</em> remain unchanged during the characterization's interval of this entity record.</p>
+
+
+
+ </div>
+
+
+
+<div id="resource-section" class="section">
+<!--OddPage--><h2><span class="secno">8. </span>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 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3986">RFC3986</a></cite>]. 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 example 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-ASN sample below, are expressed within a same account.
+</p>
+
+<pre>container
+prefix app urn:example:
+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 idenfier that identifies the entity it represents.
+In this example, three identifiers were minted, and their prefix uses the URN syntax with "example" namespace.</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 a PROV-DM identifier, it identifies a specific characterization of this report. A given identifier identifies a single entity record 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. </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 perspective we take about that resource is expressed as a different entity record, happening to have the same identifier 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 <em class="rfc2119" title="must">must</em> be used, one of them being allowed to be the resource URI.</p>
+
+<pre>container
+ prefix app http://example.org/
+ prefix app2 urn:example:
+ 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>
+
+
+</div>
+
+
+<!--
+<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.
+-->
+
+
+<div class="appendix section" id="changes-since-first-public-working-draft">
+ <!--OddPage--><h2><span class="secno">A. </span>Changes Since First Public Working Draft</h2>
+<ul>
+<li>12/08/11: Explained non-transitivity of wasInformedBy. </li>
+<li>12/05/11: Made attributes optional, and used non-terminal optional-attribute-values. </li>
+<li>12/05/11: Changed syntax of recordContainer to be more user friendly, and removed list of account ids, since redundant. </li>
+<li>12/05/11: Changed syntax of namespace declaration to be more user friendly. </li>
+<li>12/05/11: Simplified Typed literals, now allows for intLiteral, and datatype adjusted to be qualified name. </li>
+<li>11/29/11: Introduced typed identifiers to make grammar clearer. </li>
+<li>11/29/11: Added section 2.4 on grammar notation. </li>
+<li>11/28/11: Changed grammar notation. </li>
+<li>11/25/11: Updated examples of section 8. </li>
+<li>11/25/11: Definition of namespace. Clarification about interpretation of IRI occurrences. </li>
+<li>11/25/11: Definition of attribute and identifier. </li>
+<li>11/24/11: Added figure of Common Relations in Section 6. </li>
+<li>11/24/11: Updated text preceding graphical illustration, removed appendix A. </li>
+<li>11/24/11: Fix on traceability record. </li>
+<li>11/24/11: Revisited Derivation record, with a single name for derivation. </li>
+<li>11/23/11: Defined attribute, identifier, and namespace declaration. </li>
+<li>11/23/11: Consolidation of event in section 2.1.2 and linking to definitions from the rest of document. </li>
+<li>11/21/11: Added wasStartedBy between activities.</li>
+<li>11/21/11: Added wasInformedBy-ordering constraint.</li>
+<li>11/17/11: Added Traceability Record.</li>
+<li>11/17/11: Rewrote the whole section on Derivation Record.</li>
+<li>11/17/11: Updated wasDerivedFrom to refer to generation/usage record ids.</li>
+<li>11/17/11: Simplified hasAnnotation mechanism, now requiring to-be-annotated record to had id.</li>
+<li>11/17/11: Renamed annotation into note.</li>
+<li>11/17/11: Introduced wasStartedBy, wasEndedBy, and actedOnBehalfOf.</li>
+<li>11/16/11: New version of agent/wasAssociatedWith.</li>
+<li>11/16/11: Introduced class anexample.</li>
+<li>11/16/11: Changed presentation of entity and activity.</li>
+<li>11/16/11: Updated examples for usage and generation record.</li>
+<li>11/16/11: Renamed use record into usage record.</li>
+<li>11/16/11: Removed constraint generation-affects-attributes.</li>
+<li>11/16/11: Removed constraint use-attributes.</li>
+<li>11/16/11: Introduced optional identity for use and generation record.</li>
+<li>11/11/11: Swapped sections 6 and 7.</li>
+<li>11/11/11: Use attribute-value pairs uniformly, instead of qualifiers and name-value pairs.</li>
+<li>11/08/11: Renamed 'provenance container' into 'record container'.</li>
+<li>11/07/11: Addressed ISSUE-143 (qualifiers as a set of name value pairs).</li>
+<li>11/07/11: Added a section on Literals (ISSUE-142).</li>
+<li>11/07/11: Aligned terminology 'activity' and 'process execution record'.</li>
+<li>11/07/11: Renamed 'xxx Expression' into 'xxx Record' to avoid the language connotation.</li>
+<li>11/07/11: Defined entity as identifiable characterized thing, and updated text accordingly.</li>
+<li>10/08/11: Made explicit the term expression wherever was appropriate, including section titles.</li>
+</ul>
+ </div>
+
+<div class="appendix section" id="acknowledgements">
+ <!--OddPage--><h2><span class="secno">B. </span>Acknowledgements</h2>
+ <p>
+ WG membership to be listed here.
+ </p>
+ </div>
+
+
+<div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">C. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">C.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-IRI">[IRI]</dt><dd>M. Duerst, M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRI).</cite></a> January 2005. Internet RFC 3987. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
+</dd><dt id="bib-OWL2-SYNTAX">[OWL2-SYNTAX]</dt><dd>Boris Motik; Peter F. Patel-Schneider; Bijan Parsia. <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/"><cite>OWL 2 Web Ontology Language:Structural Specification and Functional-Style Syntax.</cite></a> 27 October 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/">http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/</a>
+</dd><dt id="bib-RDF-SPARQL-QUERY">[RDF-SPARQL-QUERY]</dt><dd>Andy Seaborne; Eric Prud'hommeaux. <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115"><cite>SPARQL Query Language for RDF.</cite></a> 15 January 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115">http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115</a>
+</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119. URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
+</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd>T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax.</cite></a> January 2005. Internet RFC 3986. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
+</dd><dt id="bib-XML-NAMES">[XML-NAMES]</dt><dd>Richard Tobin; et al. <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/"><cite>Namespaces in XML 1.0 (Third Edition).</cite></a> 8 December 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/">http://www.w3.org/TR/2009/REC-xml-names-20091208/</a>
+</dd><dt id="bib-XMLSCHEMA-2">[XMLSCHEMA-2]</dt><dd>Paul V. Biron; Ashok Malhotra. <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2: Datatypes Second Edition.</cite></a> 28 October 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/</a>
+</dd></dl></div><div id="informative-references" class="section"><h3><span class="secno">C.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-CLOCK">[CLOCK]</dt><dd>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. 1978URL: <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.
+</dd><dt id="bib-CSP">[CSP]</dt><dd>Hoare, C. A. R. <a href="http://www.usingcsp.com/cspbook.pdf"><cite>Communicating Sequential Processes</cite></a>.Prentice-Hall. 1985URL: <a href="http://www.usingcsp.com/cspbook.pdf">http://www.usingcsp.com/cspbook.pdf</a>
+</dd><dt id="bib-FOAF">[FOAF]</dt><dd>Dan Brickley, Libby Miller. <a href="http://xmlns.com/foaf/spec/"><cite>FOAF Vocabulary Specification 0.98.</cite></a> 9 August 2010. URL: <a href="http://xmlns.com/foaf/spec/">http://xmlns.com/foaf/spec/</a>
+</dd><dt id="bib-Logic">[Logic]</dt><dd>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>
+</dd><dt id="bib-PROV-O">[PROV-O]</dt><dd>Satya Sahoo and Deborah McGuinness <a href="http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html"><cite>Provenance Formal Model</cite></a>. 2011, Work in progress. URL: <a href="http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html">http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html</a>
+</dd><dt id="bib-PROV-PAQ">[PROV-PAQ]</dt><dd>Graham Klyne and Paul Groth <a href="http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html"><cite>Provenance Access and Query</cite></a>. 2011, Work in progress. URL: <a href="http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html">http://dvcs.w3.org/hg/prov/tip/paq/provenance-access.html</a>
+</dd><dt id="bib-PROV-PRIMER">[PROV-PRIMER]</dt><dd>Yolanda Gil and Simon Miles <a href="http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html"><cite>Prov Model Primer</cite></a>. 2011, Work in progress. URL: <a href="http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html">http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html</a>
+</dd><dt id="bib-PROV-SEMANTICS">[PROV-SEMANTICS]</dt><dd>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>
+</dd></dl></div></div></body></html>
Binary file model/WD-prov-dm-20111215/sec6-summary.png has changed
Binary file model/WD-prov-dm-20111215/timeline.png has changed
--- a/model/informedByNonTransitive.svg Fri Dec 09 08:06:10 2011 +0000
+++ b/model/informedByNonTransitive.svg Fri Dec 09 09:01:11 2011 +0000
@@ -14,7 +14,10 @@
id="svg6710"
version="1.1"
inkscape:version="0.47 r22583"
- sodipodi:docname="informedByNonTransitive.svg">
+ sodipodi:docname="informedByNonTransitive.svg"
+ inkscape:export-filename="/home/lavm/papers/papers/prov-wg/hg/model/informedByNonTransitive.png"
+ inkscape:export-xdpi="53.787918"
+ inkscape:export-ydpi="53.787918">
<defs
id="defs6712">
<marker
@@ -161,6 +164,7 @@
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
--- a/model/wd2/ProvenanceModel.html Fri Dec 09 08:06:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,3328 +0,0 @@
-<!DOCTYPE html>
-
-<html><head>
- <title>The PROV Data Model and Abstract Syntax Notation</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-SEMANTICS":
- "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 "+
- "<a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html\"><cite>Prov Model Primer</cite></a>. "+
- "2011, Work in progress. "+
- "URL: <a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html\">http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html</a>",
-
- "PROV-O":
- "Satya Sahoo and Deborah McGuinness "+
- "<a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html\"><cite>Provenance Formal Model</cite></a>. "+
- "2011, Work in progress. "+
- "URL: <a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html\">http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html</a>",
-
- "PROV-PAQ":
- "Graham Klyne and Paul Groth "+
- "<a href=\"http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html\"><cite>Provenance Access and Query</cite></a>. "+
- "2011, Work in progress. "+
- "URL: <a href=\"http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html\">http://dvcs.w3.org/hg/prov/tip/paq/provenance-access.html</a>",
- };
- var respecConfig = {
- // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
- specStatus: "WD",
-
- // the specification's short name, as in http://www.w3.org/TR/short-name/
- shortName: "prov-dm",
-
- // if your specification has a subtitle that goes below the main
- // formal title, define it here
- // subtitle : "Initial draft for internal discussion",
-
- // if you wish the publication date to be other than today, set this
- // publishDate: "2011-10-18",
-
- // if the specification's copyright date is a range of years, specify
- // the start date here:
- // copyrightStart: "2005"
-
- // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
- // and its maturity status
- previousPublishDate: "2011-10-18",
- previousMaturity: "FPWD",
-
- // if there a publicly available Editor's Draft, this is the link
- edDraftURI: "http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.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: [
- { name: "Khalid Belhajjame", url: "http://semanticweb.org/wiki/Khalid_Belhajjame",
- company: "University of Manchester" },
- { name: "Stephen Cresswell",
- company: "legislation.gov.uk"},
- { name: "Yolanda Gil",
- company: "Invited Expert", url:"http://www.isi.edu/~gil/"},
- { name: "Ryan Golden",
- company: "Oracle Corporation" },
- { name: "Paul Groth", url: "http://www.few.vu.nl/~pgroth/",
- company: "VU University of Amsterdam" },
- { name: "Graham Klyne",
- company: "University of Oxford" },
- { name: "Jim McCusker", url: "http://tw.rpi.edu/web/person/JamesMcCusker",
- company: "Rensselaer Polytechnic Institute" },
- { name: "Simon Miles",
- company: "Invited Expert", url:"http://www.inf.kcl.ac.uk/staff/simonm/" },
- { name: "James Myers", url:"http://www.rpi.edu/research/ccni/",
- company: "Rensselaer Polytechnic Institute"},
- { name: "Satya Sahoo", url:"http://cci.case.edu/cci/index.php/Satya_Sahoo",
- company: "Case Western Reserve University" },
- ],
-
- // 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 for building
-representations of the entities, people and activities involved in
-producing a piece of data or thing in the world. PROV-DM is
-domain-agnotisc, but with well-defined extensibility points allowing
-further domain-specific and application-specific extensions to be
-defined. It is accompanied by PROV-ASN, a technology-independent
-abstract syntax notation, which allows serializations of PROV-DM
-instances to be created for human consumption, which facilitates its
-mapping to concrete syntax, and which is used as the basis for a
-formal semantics.
-</p>
- </section>
-
-<section id="sotd">
-<em>TODO: update this section for next publication.</em>
-This document is part of a set of specifications aiming to define the various aspects that are necessary to achieve the visition on 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. Three other documents are: 1) a normative serialization of PROV-DM in RDF, specified by means of a mapping to the OWL2 Web Ontology Language; 2)
-the mechanisms for accessing and querying provenance; 3) a primer for the provenance data model.
-</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>
- <h2>Introduction<br>
-</h2>
-
-<p>
-For the purpose of this specification, 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.
-In particular, the provenance of information is crucial in deciding
-whether information is to be trusted, how it should be integrated with
-other diverse information sources, and how to give credit to its
-originators when reusing it. In an open and inclusive environment
-such as the Web, users find information that is often contradictory or
-questionable: provenance can help those users to make trust judgments.
-</p>
-
-
-<p>
-The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
-Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it, process it, and reason over it.</p>
-
-<p>Thus, the vision is that different provenance-aware systems natively adopt their own model for representing their provenance, but a core provenance data model can be readily adopted as a provenance <em>interchange</em> model across such systems.</p>
-
-<p>A set of specifications define the various aspects
-that are necessary to achieve this vision in an inter-operable
-way, the first of which is contained in this document:</p>
-<ul>
-<li> The PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption; </li>
-<li> 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> The mechanisms for accessing and querying provenance [[PROV-PAQ]];</li>
-<li> A Primer for the PROV approach [[PROV-PRIMER]].</li>
-</ul>
-
-
-<p>
-The PROV-DM data model for provenance consists of a set of core
-concepts, and a few common relations, based on these core concepts. PROV-DM is a domain-agnotisc model, but with well-defined extensibility points allowing further domain-specific and application-specific extensions to be defined.</p>
-
-<p>This specification also introduces
-PROV-ASN, an abstract syntax that is primarily aimed at human consumption. PROV-ASN allows
-serializations of PROV-DM instances to be written in a technology independent manner,
-it facilitates its mapping to concrete syntax, and it is used as the basis for a
-formal semantics. This specification uses instances of provenance written in PROV-ASN
-to illustrate the data model.
-</p>
-
- <section>
-<h3>Structure of this Document</h3>
-
-<p>In <a href="#preliminaries">section 2</a>, a set of preliminaries are introduced, including concepts that underpin PROV-DM and motivations for the PROV-ASN notation.</p>
-
-<p><a href="#prov-dm-overview">Section 3</a> provides an overview of PROV-DM listing its core types and their relations.</p>
-
-<p>In <a href="#prov-dm-example">section 4</a>, PROV-DM is
-applied to a short scenario, encoded in PROV-ASN, and illustrated
-graphically.</p>
-
-<p><a href="#data-model-concepts">Section 5</a> provides the normative definition of PROV-DM and the notation PROV-ASN.</p>
-
-<p><a href="#common-relations">Section 6</a> introduces common relations used in PROV-DM, including relations for data collections and common domain-independent common relations.</p>
-
-<p><a href="#extensibility-section">Section 7</a> summarizes PROV-DM extensibility points.</p>
-
-<p><a href="#resource-section">Section 8</a> discusses how PROV-DM can be applied to the notion of resource.</p>
-
-
- </section>
-
-<section id="prov-dm-namespace">
- <h3>PROV-DM Namespace</h3>
-
-
-<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
-
-<p> All the elements, relations, reserved names and attributes introduced in this specification belong to the PROV-DM namespace.</p>
-
-<div class="note">
-There is a desire to use a single namespace that all specs can share to refer to common provenance terms.
-</div>
-
-</section>
-
-
- <section>
-<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='preliminaries'>
-<h2>Preliminaries</h2>
-
- <section id='conceptualization'>
-<h3>A Conceptualization of the World</h3>
-
-
-
- <section id='section-entity-activity-agent'>
-<h4>Entity, Activity, Agent</h4>
-
-
-
-
-<p>This specification is based on a conceptualization of the world
-that is described in this section. In the world (whether real or not),
-there are things, which can be physical, digital, conceptual, or
-otherwise, and activities involving things. </p>
-
-<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>Hence, to accommodate different perspectives on things and their situation in the world as perceived by us, we introduce the idea of a characterized thing, which refers to a thing and its situation in the world, as characterized by someone. We then define an <dfn id="concept-entity">entity</dfn> as an identifiable characterized thing. An entity <em>fixes some aspects</em> of a thing and its situation in the world, so that it becomes possible to express its provenance, and what causes these specific aspects to be as such. An alternative entity may fix other aspects, and its provenance may be different.</p>
-
-<div class="anexample">
-Different users may take different perspectives on a resource with
-a URL. These perspectives in this conceptualization of the world are
-referred to as entities. Three such entities may be
-expressed:
-<ul>
-<li>a report available at 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 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>
-
-<!--
-<div class='paolo'>can we follow through from the example. thare three perspectives, possibly by just one observer or multiple ones. but <strong>why is it so important for reporting provenance</strong> that this distinction is made? I feel we need to connect this approach to provenance recording strongly and right away</div>
--->
-
-<p>We do not assume that any characterization is more important than any other, and in fact, it is possible to describe the processing that occurred for the report to be commissioned, for individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity that characterizes the report appropriately.</p>
-
-<p>In the world, <dfn id="concept-activity">activities</dfn> involve
-entities in multiple ways: they consume them, they process them, they
-transform them, they modify them, they change them, they relocate
-them, they use them, they generate them, they are controlled by them,
-etc.</p>
-
-
-<p>An <dfn id="concept-agent">agent</dfn> is a type of entity that takes an active role in an activity such that it can be assigned some degree of responsibility for the activity taking place.
-This definition intentionally stays away from using concepts such as enabling, causing, initiating, affecting, etc, because any entities also enable, cause, initiate, and affect in some way the activities. So the notion of having some degree of responsibility is really what makes an agent. </p>
-
-<p> Even software agents can be assigned some responsibility for the effects they have in the world, so for example if one is using a Text Editor and one's laptop crashes, then one would say that the Text Editor was responsible for crashing the laptop. If one invokes a service to buy a book, that service can be considered responsible for drawing funds from one's bank to make the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well). So when someone models software as an agent for an activity in our model, they mean the agent has some responsibility for that activity.
-</p>
-<p> In this specification, the qualifier 'identifiable' is implicit whenever a reference is made to an activity, agent, or an entity.</p>
-
-</section>
-
-
- <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 in 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 instantaneous event, 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>
-<h4>Types of Events</h4>
-
-<p>Four kinds of events 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>event</a> that marks the final instant of an entity's creation timespan, after which it becomes available for use.</p>
-
-<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a>event</a> that marks the first instant of an entity's consumption timespan by an activity.</p>
-
-<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a>event</a> that marks the instant an activity starts.</p>
-
-<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a>event</a> that marks the instant an activity ends.</p>
-
-</section>
-
-<section>
-<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">events</a>,
-without using physical clocks. This specification assumes that a partial order exists between <a title="event">events</a>.
-</p>
-
-
-<p>Specifically, <dfn id="dfn-follows">follows</dfn> is a partial
-order between <a title="event">events</a>, indicating that an <a>event</a> occurs after another.
-For symmetry, <dfn id="dfn-precedes">precedes</dfn> is defined as
-the inverse of follows. </p>
-
-
-<p> How such partial order is realized in practice is beyond the scope
-of this specification. This specification only assumes that
-each <a>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 to derive <a>event</a> ordering constraints from
-provenance records. According to such temporal interpretation,
-provenance records MUST satisfy such constraints. We note that the
-actual verification of such temporal constraints is also outside the
-scope of this specification. </p>
-
-<p>PROV-DM also allows for time observations to be inserted in specific
-provenance records, for each recognized <a>event</a> introduced
-in this specification. The presence of a time observation for a
-given <a>event</a> fixes the mapping of this <a>event</a> to the
-timeline. It can also help with the verification of associated
-temporal constraints (though, again, this verification is outside the
-scope of this specfication).
-
-</p>
-
-
-
-</section>
-
- </section>
-
- </section>
-
- <section>
-<h3>PROV-ASN: The Provenance Abstract Syntax Notation</h3>
-
-<p>This specification defines PROV-DM, a data model for provenance, consisting of records describing how people, entities, and activities, were involved in producing,
-influencing, or delivering a piece of data or a thing in the world.</p>
-
-<p>This specification also relies on a language, PROV-ASN, the Provenance Abstract Syntax Notation, to express
-<em>instances</em> of that data model.
-For each construct of PROV-DM, a corresponding ASN expression is introduced, by way of a production in the ASN grammar. </p>
-
-
-
-
-
-<p>PROV-ASN is an abstract syntax, whose goals are:
-<ul>
-<li>to allow serializations of PROV-DM instances in a technology independent manner, which makes it more readable for human consumption;
-<li>to facilitate the mapping of PROV-DM to concrete syntax;
-<li>to provide the basis for a formal semantics.
-</ul>
-
-<p>This specification provides a grammar for PROV-ASN. Each record of the PROV-DM data model is explained
-in terms of the production of this grammar.</p>
-
-
-
-<p>The formal semantics of PROV-DM is defined at
-[[PROV-SEMANTICS]] and its encoding in the OWL2 Web Ontology Language at [[PROV-O]].
-</p>
-
-
-
-
-
-
- </section>
-
- <section>
-<h3>Representation, Assertion, and Inference</h3>
-
-<p>
-PROV-DM is a provenance data model designed to express <em>representations</em> of the world.
-</p>
-
-<div class="anexample">
-A file at some point during its lifecycle, which includes multiple edits by multiple people, can be represented by its location in the file system, a creator, and content.
-</div>
-
-
-<p>
-These representations are relative to an asserter, and in that sense constitute assertions stating properties of the world, as represented by an asserter. Different asserters will normally contribute different representations.
-This specification does not define a notion of consistency between different sets of assertions (whether by the same asserter or different asserters).
-The data model provides the means to associate attribution to assertions.
-</p>
-
-<div class="anexample">
-An alternative representation of the above file is a set of blocks in a hard disk.
-</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 assertions SHOULD be interpreted as a record of what has happened, as opposed to what may or will happen.</p>
-
-
-
-<p>
-This specification does not prescribe the means by which an asserter arrives at assertions; for example, assertions can be composed on the basis of observations, reasoning, or any other means.
-</p>
-
-
-<p>
-Sometimes, inferences about the world can be made from representations
-conformant to the PROV-DM data model. When this is the case, this
-specification defines such inferences, allowing new provenance records
-to be inferred from existing ones. Hence, representations of the world
-can result either from direct assertions by asserters or from
-application of inferences defined by this specification.
-</p>
-
-
-
-</section>
- <section>
-<h3>Grammar Notation</h3>
-
-<p>This specification includes a grammar for PROV-ASN expressed using the Extended Backus-Naur Form (EBNF) notation.</p>
-
-<div class="grammar">
-<p> Each rule in the grammar defines one symbol, in the form:</p>
-<p>
-<span class="nonterminal">E</span> ::= <em>expression</em>
-</p>
-
-
-Within the expression on the right-hand side ofa rule, the follwoing expressions are used to match strings of one or more characters:
-<ul>
-<li>
-<span class="nonterminal">E</span>: matches term satisfying rule for symbol E.
-</li>
-
-<li>
-<span class="name">abc</span>: matches the literal string inside the single quotes.
-</li>
-
-
-<li>
-<span class="optional"><em>expression</em></span>: matches <em>expression</em> or nothing; optional <em>expression</em>.
-</li>
-
-<li>
-<span class="plus"><em>expression</em></span>: matches one or more occurrences of <em>expression</em>.
-</li>
-
-<li>
-<span class="star"><em>expression</em></span>: matches zero or more occurrences of <em>expression</em>.
-</li>
-
-</ul>
-</div>
-
-</section>
-</section>
-
- <section id="prov-dm-overview">
-<h2>PROV-DM: An Overview </h2>
-
-<p>
-The following ER diagram provides a high level overview of the <strong>structure of PROV-DM records</strong>. Examples of provenance assertions that conform to this schema are provided in the next section.</p>
-
-<div style="text-align: center;">
- <img src="overview.png" alt="PROV-DM overview"/>
-</div>
-
-<div class="note"> Overview diagram does not represent the sub-relations -- proposal to use a UML notation instead of ER.</div>
-
-
-<p>The model includes the following elements:</p>
-<ul>
- <li>An <a title="entity record">Entity Record</a> (noted <samp>entity</samp> in the diagram, to reflect the term used in the ASN) is a representation of an <em>entity</em>.
-
- <li>An <a title="activity record">Activity Record</a>(noted <samp>activity</samp> in the diagram) represents an activity that has an effect on entities, namely it either <em>generates</em> or <em>uses</em> one or more entities. Usage and generation are modelled by means of the <a title="usage record">used</a> and the <a title="generation record">wasGeneratedBy</a> relationships. Activities may include not only computations, but also any other type of activity that can be described in terms of their effect on <samp>entities</samp>.
-Note that multiple <samp>activities</samp> may <em>use</em> the same <samp>entity</samp>, and each activity may use multiple <samp>entities</samp>. Finally, entities can be derived from other entities, and this is specified using the <a title="derivation record">wasDerivedFrom</a> relation.</li>
-
- <li>An <a title="agent record">Agent Record</a> represents a particular <samp>entity</samp> that can be associated to activities, meaning that it can be assigned some degree of responsibility for an <samp>activity</samp> taking place.
- Agents have a rather generic connotation: their association with an activity is represented by the <a title="activity association record">wasAssociatedWith</a> relationship, which can take up various meanings (attribution, responsibility, supervision, management, etc.), which are not individually specified in the model. Relations <a title="start record">wasStartedBy</a> and <a title="end record">wasEndedBy</a> are specializations of <a title="activity association record">wasAssociatedWith</a> that can optionally be used to carry additional meaning. Furthermore, it is recognized that agents can act on behalf of others: hence, the relation <a title="responsibility record">actedOnBehalfOf</a> allows for chains of responsibility to be stated.
-</li>
-
-
-
-</ul>
-
-<p> A set of attribute-value pairs can be associated to elements and relations of the PROV model in order to further characterize
-their nature.
-The <a title="complementarity record">wasComplementOf</a> relationship is used to denote that two <samp>entities</samp> <em>complement</em> each other, in the sense that they each represent a partial, but mutually compatible characterization of the same thing.
-The attributes <a title="prov:role">role</a> and <a title="prov:type">type</a> are pre-defined.
-</p>
-
-
-<p>The set of relations presented here forms a core, which is further extended with additional relations, defined in Section <a href="#common-relations">Common Relations</a>.</p>
-
-
-<p>
-The model includes a further additional element: <a title="note record">notes</a>. These are also structured as sets of attribute-value pairs. Notes are used to provide additional, "free-form" information regarding <em>any</em> identifiable construct of the model, with no prescribed meaning. Notes are described in detail <a href="#record-note">here</a>.
-</p>
-
-<p>
-Attributes and notes are the main <em>extensibility points</em> in the model: individual interest groups are expected to extend PROV-DM by introducing new attributes and notes as needed to address applications-specific provenance modelling requirements. </p>
-
-</section>
-
-
- <section class="informative" id="prov-dm-example">
-<h2>Example</h2>
-
-<div class='issue'> There is a suggestion that a better example should be adopted for this document. Possibly, several shorter examples. This is <a href="http://www.w3.org/2011/prov/track/issues/132">ISSUE-132</a></div>
-
-
-To illustrate PROV-DM, this section presents an example encoded according to PROV-ASN. For more detailed explanations of how PROV-DM should be used, and for more examples, we refer the reader to the Provenance Primer [[PROV-PRIMER]].
-
-
-
-
-
-<div class='pending'>Comments on section 3.2. This is <a href="http://www.w3.org/2011/prov/track/issues/71">ISSUE-71</a></div>
-
- <section>
-<h3>A File Scenario</h3>
-
-
-<p>This scenario is concerned with the evolution of a crime statistics
-file (referred to as e0) stored on a shared file system and which
-journalists Alice, Bob, Charles, David, and Edith can share and
-edit. We consider various <a title="event">events</a> in the evolution of file e0;
-<a title="event">events</a> listed below follow each other, unless otherwise specified.</p>
-
-
-
-<p>
-<a>Event</a> evt1: Alice creates (a0) an empty file in /share/crime.txt. We denote this file e1.
-</p>
-
-<p>
-<a>Event</a> evt2: Bob appends (a1) the following line to /share/crime.txt:</p>
-<pre>
-There was a lot of crime in London last month.
-</pre>
-<p>We denote the revised file e2.</p>
-
-<p><a>Event</a> evt3: Charles emails (a2) the contents of /share/crime.txt, as an
-attachment, which we refer to as e4. (We specifically refer to a copy of the file that is uploaded on the mail server.)
-</p>
-
-<p>
-<a>Event</a> evt4: David edits (a3) file /share/crime.txt as follows.</p>
-<pre>
-There was a lot of crime in London and New-York last month.
-</pre>
-<p>
-We denote the revised file e3.
-</p>
-
-<p><a>Event</a> evt5: Edith emails (a4) the contents of /share/crime.txt as an attachment, referred to as e5.
-</p>
-
-<p><a>Event</a> evt6: between <a title="event">events</a> evt4 and evt5, someone (unspecified) runs a spell checker (a5) on the file /share/crime.txt.
- The file after spell checking is referred to as e6.
-</p>
-
-</section>
-
- <section id="example-prov-asn-encoding">
-<h3>Encoding using PROV-ASN</h3>
-
-In this section, the example is encoded according to the provenance data model (specified in section <a href="#data-model-concepts">PROV-DM: The Provenance Data Model</a>) and expressed in PROV-ASN.
-<p>
-Entity Records (described in <a href="#record-Entity">Section Entity</a>). The file in its various forms and its copies are modelled as entity records, corresponding to multiple characterizations, as per scenario. The entity records are identified by <span class="name">e0</span>, ..., <span class="name">e6</span>.</p>
-<pre>
-entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
-entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
-entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London last month."])
-entity(e3, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month."])
-entity(e4)
-entity(e5)
-entity(e6, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month.", ex:spellchecked="yes"])
-</pre>
-
-
-
-<p>These entity records list attributes that have been given values during intervals delimited by <a title="event">events</a>; such intervals are referred to as <em>characterization intervals</em>. The following table lists all entity identifiers and their corresponding characterization intervals. When the end of the characterization interval is not delimited by an <a>event</a> described in this scenario, it is marked by "...".</p>
-<blockquote>
-<table>
-<tr><td>Entity</td><td>Characterization Interval</td></tr>
-<tr><td>e0</td><td>evt1 - ...</td></tr>
-<tr><td>e1</td><td>evt1 - evt2</td></tr>
-<tr><td>e2</td><td>evt2 - evt4</td></tr>
-<tr><td>e3</td><td>evt4 - ...</td></tr>
-<tr><td>e4</td><td>evt3 - ...</td></tr>
-<tr><td>e5</td><td>evt5 - ...</td></tr>
-<tr><td>e6</td><td>evt6 - ... </td></tr>
-</table>
-</blockquote>
-
-
-
-<p>
-Activity Records (described in <a href="#record-Activity">Section Activity</a>) represent activities in the scenario.</p>
-<pre>
-activity(a0, create-file, 2011-11-16T16:00:00,)
-activity(a1, add-crime-in-london, 2011-11-16T16:05:00,)
-activity(a2, email, 2011-11-16T17:00:00,)
-activity(a3, edit-London-New-York, 2011-11-17T09:00:00,)
-activity(a4, email, 2011-11-17T09:30:00,)
-activity(a5, spellcheck,,)
-</pre>
-
-
-<p>
-Generation Records (described in <a href="#record-Generation">Section Generation</a>) represent the <a>event</a> at which a file is created in a specific form. Attributes are used to describe the modalities according to which a given entity is generated by a given activity. The interpretation of attributes is application specific. Illustrations of such attributes for the scenario are: no attribute is provided for <span class="name">e0</span>;
-<span class="name">e2</span> was generated by the editor's save function; <span class="name">e4</span> can be found on the smtp port, in the attachment section of the mail message; <span class="name">e6</span> was produced on the standard output of <span class="name">a5</span>. Two identifiers <span class="name">g1</span> and <span class="name">g2</span> identify the generation records referenced in derivations introduced below.</p>
-<pre>
-wasGeneratedBy(e0, a0)
-wasGeneratedBy(e1, a0, [ex:fct="create"])
-wasGeneratedBy(e2, a1, [ex:fct="save"])
-wasGeneratedBy(e3, a3, [ex:fct="save"])
-wasGeneratedBy(g1, e4, a2, [ex:port="smtp", ex:section="attachment"])
-wasGeneratedBy(g2, e5, a4, [ex:port="smtp", ex:section="attachment"])
-wasGeneratedBy(e6, a5, [ex:file="stdout"])
-</pre>
-
-
-
-<p>
-Usage Records (described in <a href="#record-Usage">Section Usage</a>) represent the <a>event</a> by which a file is read by an activity.
-
-Likewise, attributes describe the modalities according to which the various entities are used by activities. Illustrations of such attributes are:
-<span class="name">e1</span> is used in the context of <span class="name">a1</span>'s <span class="name">load</span> functionality; <span class="name">e2</span> is used by <span class="name">a2</span> in the context of its attach functionality; <span class="name">e3</span> is used on the standard input by <span class="name">a5</span>. Two identifiers <span class="name">u1</span> and <span class="name">u2</span> identify the Usage records referenced in derivations introduced below.</p>
-<pre>
-used(a1,e1,[ex:fct="load"])
-used(a3,e2,[ex:fct="load"])
-used(u1,a2,e2,[ex:fct="attach"])
-used(u2,a4,e3,[ex:fct="attach"])
-used(a5,e3,[ex:file="stdin"])
-</pre>
-
-
-<p>
-Derivation Records (described in <a href="#Derivation-Relation">Section Derivation Relation</a>) express that an entity is derived from another. The first two are expressed in their compact version, whereas the following two are expressed in their full version, including the activity underpinning the derivation, and associated usage (<span class="name">u1</span>, <span class="name">u2</span>) and generation (<span class="name">g1</span>, <span class="name">g2</span>) records.</p>
-<pre>
-wasDerivedFrom(e2,e1)
-wasDerivedFrom(e3,e2)
-wasDerivedFrom(e4,e2,a2,g1,u1)
-wasDerivedFrom(e5,e3,a4,g2,u2)
-</pre>
-
-
-
-<p>
-wasComplementOf: (this relation is described in <a href="#record-complement-of">Section wasComplementOf</a>). The crime statistics file (<span class="name">e0</span>) has various contents over its existence (<span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span>); the entity records identified by <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span> complement <span class="name">e0</span> with an attribute <span class="name">content</span>. Likewise, the one denoted by <span class="name">e6</span> complements the record denoted by <span class="name">e3</span> with an attribute <span class="name">spellchecked</span>.</p>
-<pre>
-wasComplementOf(e1,e0)
-wasComplementOf(e2,e0)
-wasComplementOf(e3,e0)
-wasComplementOf(e6,e3)
-</pre>
-
-
-
-<p>
-Agent Records (described at <a href="#record-Agent">Section Agent</a>): the various users are represented as agents, themselves being a type of entity.</p>
-<pre>
-agent(ag1, [ prov:type="prov:Person" %% xsd:QName, ex:name="Alice" ])
-
-agent(ag2, [ prov:type="prov:Person" %% xsd:QName, ex:name="Bob" ])
-
-agent(ag3, [ prov:type="prov:Person" %% xsd:QName, ex:name="Charles" ])
-
-agent(ag4, [ prov:type="prov:Person" %% xsd:QName, ex:name="David" ])
-
-agent(ag5, [ prov:type="prov:Person" %% xsd:QName, ex:name="Edith" ])
-</pre>
-
-
-
-<p>
-Activity Assocation Records (described in <a href="#record-ActivityAssociation">Section Activity Association</a>): the association of an agent with an activity is expressed with , and the nature of this association is described by attributes. Illustrations of such attributes include the role of the participating agent, as creator, author and communicator (role is a reserved attribute in PROV-DM).</p>
-<pre>
-wasAssociatedWith(a0, ag1, [prov:role="creator"])
-wasAssociatedWith(a1, ag2, [prov:role="author"])
-wasAssociatedWith(a2, ag3, [prov:role="communicator"])
-wasAssociatedWith(a3, ag4, [prov:role="author"])
-wasAssociatedWith(a4, ag5, [prov:role="communicator"])
-</pre>
-</section>
-
-
- <section>
-<h3>Graphical Illustration</h3>
-
-
-<p>
-Provenance assertions can be <em>illustrated</em> graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of provenance assertions. Therefore, it cannot be seen as an alternate notation for expressing provenance.</p>
-
-<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and half-hexagonal shapes, respectively. Usage, Generation, Derivation, Activity Association, and Complementarity are represented as directed edges.</p>
-
-<p>Entities are layed out according to the ordering of their generation event. We endeavor to show time progressing from left to right. This means that edges for Usage, Generation and Derivation typically point from right to left.</p>
-
-
-<div style="text-align: center;">
-<img src="example-graphical.png" alt="example"/>
-</div>
-<br/>
-<div style="text-align: center;">
-<img src="timeline.png" alt="example"/>
-</div>
-</section>
-
-</section>
-
-
-
-<section id="data-model-concepts">
-
-<h2>PROV-DM Core</h2>
-
-<p>This section contains the normative specification of PROV-DM core, the core of the PROV data model.</p>
-
-<div class="note">
-In a next iteration of this document, it is proposed to reorganize
-section 5 as follows. First, the presentation of the data model
-alone. Second, its temporal interpretation. Third, the constraints and
-inferences associated with well-formed accounts.
-</div>
-
- <section id="PROV-DM-record">
-
-<h3>Record</h3>
-
-<p>PROV-DM consists of a set of constructs, referred to as <em>records</em>, to formulate representations of the world and constraints that must be satisfied by them.</p>
-
-<p>
-Furthermore, PROV-DM includes a "house-keeping construct", a record container,
- used to wrap PROV-DM records and facilitate their interchange.</p>
-
-<p>In PROV-ASN, such representations of the world MUST be conformant with the toplevel production <span class="nonterminal">record</span> of the grammar. These <span class="nonterminal">record</span>s are grouped in three categories:
-<span class="nonterminal">elementRecord</span> (see section <a href="#record-element">Element</a>),
-<span class="nonterminal">relationRecord</span> (see section <a href="#record-relation">Relation</a>), and
-<span class="nonterminal">accountRecord</span> (see section <a href="#record-Account">Account</a>).</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">record</span> ::=
-<span class="nonterminal">elementRecord</span>
-| <span class="nonterminal">relationRecord</span>
-| <span class="nonterminal">accountRecord</span>
-<br/>
-<!-- -->
-<br/>
-<span class="nonterminal">elementRecord</span> ::=
-<span class="nonterminal">entityRecord</span>
-| <span class="nonterminal">activityRecord</span>
-| <span class="nonterminal">agentRecord</span>
-| <span class="nonterminal">noteRecord</span> <br/>
-<!-- -->
-<br/>
-<span class="nonterminal">relationRecord</span> ::=
-<span class="nonterminal">generationRecord</span>
-| <span class="nonterminal">usageRecord</span>
-| <span class="nonterminal">derivationRecord</span>
-| <span class="nonterminal">activityAssociationRecord</span>
-| <span class="nonterminal">responsibilityRecord</span>
-| <span class="nonterminal">startRecord</span>
-| <span class="nonterminal">endRecord</span>
-| <span class="nonterminal">complementRecord</span>
-| <span class="nonterminal">annotationRecord</span>
-</div>
-
-
-<p>In PROV-ASN, a record container is compliant with the production <span class="nonterminal">recordContainer</span> (see section <a href="#RecordContainer">Record Container</a>). </p>
-
-</section>
-
- <section id="record-element">
-<h3>Element</h3>
-
-<p>This section describes all the PROV-DM records referred to as element records. (They are conformant to the <span class='nonterminal'>elementRecord</span> production of the grammar.)</p>
-
-
-
- <section id="record-Entity">
-
-<h4>Entity Record</h4>
-
-<p>In PROV-DM, an <dfn id="dfn-entity">entity record</dfn> is a representation of an entity.</p>
-
-
-<p>Examples of entities include a linked data set, a sparse-matrix matrix of floating-point numbers, a document in a directory, the same document published on the Web, and meta-data embedded in a document.</p>
-
-<p>An entity record, noted <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> identifying an entity; the identifier of the entity record is defined to be the same as the identifier of the entity; </li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this entity's situation in the world.</li>
-</ul>
-
-
-<p>
-The assertion of an entity record, <span class="name">entity(id, [ attr1=val1, ...])</span>, states, from a given asserter's viewpoint, the existence of an entity, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two <a title="event">events</a> in the world.
-</p>
-
-<p>
-In PROV-ASN, an entity record's text matches the <span class="nonterminal">entityRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class='grammar'>
-<span class="nonterminal">entityRecord</span> ::=
-<span class="name">entity</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/><br/>
-<!-- -->
-<span class="nonterminal">optional-attribute-values</span> ::=
-<span class="optional"><span class="name">,</span>
-<span class="name">[</span>
-<span class="nonterminal">attribute-values</span>
-<span class="name">]</span>
-</span><br/>
-<span class="nonterminal">attribute-values</span> ::=
-<span class="nonterminal">attribute-value</span>
-| <span class="nonterminal">attribute-value</span> <span class="name">,</span> <span class="nonterminal">attribute-values</span>
-<br/>
-<span class="nonterminal">attribute-value</span> ::=
-<span class="nonterminal">attribute</span>
-<span class="name">=</span>
-<span class="nonterminal">Literal</span>
-<br/>
-</div>
-
-<div class="anexample">
-<p>
-The following entity record,</p>
-<pre class="codeexample">
-entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
-</pre>
-states the existence of an entity, denoted by identifier <span class="name">e0</span>, with type <span class="name">File</span> and path <span class="name">/shared/crime.txt</span> in the file system, and creator alice The attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span class="name">type</span> is reserved in the PROV-DM namespace.
-</div>
-
-Further considerations:
-<ul>
-<li>If an asserter wishes to characterize an entity with the same attribute-value pairs over several intervals, then they are required to assert multiple entity records, each with its own identifier (so as to allow potential dependencies between the various entity records to be expressed). </li>
-
-<li>There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.</li>
-
-<li>A characterization interval may collapse into a single instant.</li>
-
-<li>An entity assertion
- is about a thing, whose situation in the world may be variant.
- An entity record is asserted at a particular point and is invariant, in the sense that
-its attributes are given a value as part of that assertion.
-</li>
-
-<li>Activities are not represented by entity records, but instead by activity records, as explained below.</li>
-</ul>
-
-
-
-
-
-
-<div class='note'>The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define wasComplementOf more precisely. It would also allow us to address
-<a href="http://www.w3.org/2011/prov/track/issues/108">ISSUE-108</a>.
-Beginning and end of characterization interval could be expressed by attributes (similarly to activities). </div>
-
-
-
-
- </section>
-
- <section id="record-Activity">
-
-<h3>Activity Record</h3>
-<p>In PROV-DM, an <dfn id="dfn-activity">activity record</dfn> is a representation of an identifiable activity, which performs a piece of work.</p>
-
-
-<p>An activity, represented by an activity record, 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">events</a>. However, an activity record need not mention time information, nor duration, because they may not be known.</p>
-
-<p>Such start and end times constitute <em>attributes</em> of an activity, where the interpretation of attribute in the context of an activity record is the same as the interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the world can be represented by other attribute-value pairs, which MUST also remain unchanged during the activity duration.</p>
-
-<p>
-Examples of activities include assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a sparql query over a triple store, editing a file, and publishing a web page. </p>
-
-<p> An activity record, written <span class="name">activity(id, rl, st, et, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> identifying an activity; the identifier of the activity record is defined to be the same as the identifier of the activity;</li>
-<li><em>recipeLink</em>: an OPTIONAL <a href="#record-RecipeLink">recipe link</a> <span class="name">rl</span>, which consists of a domain specific specification of the activity;</li>
-<li><em>startTime</em>: an OPTIONAL time <span class="name">st</span> indicating the start of the activity;</li>
-<li><em>endTime</em>: an OPTIONAL time <span class="name">et</span> indicating the end of the activity;</li>
-<li><em>attributes</em>: a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole duration.</li>
-</ul>
-
-<p>In PROV-ASN, an activity record's text matches the <span class='nonterminal'>activityRecord</span> production of the grammar defined in this specification document.</p>
-
-
-
-<div class='grammar'>
-<span class="nonterminal">activityRecord</span> ::=
-<span class="name">activity</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="optional"><span class="name">,</span>
-<span class="nonterminal">recipeLink</span> </span>
-<span class="name">,</span>
-<span class="optional"><span class="nonterminal">time</span></span>
-<span class="name">,</span>
-<span class="optional"><span class="nonterminal">time</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/>
-</div>
-
-<div class="anexample">
-<p>
-The following activity assertion</p>
-<pre class="codeexample">
-activity(a1,add-crime-in-london,2011-11-16T16:05:00,2011-11-16T16:06:00,[ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
-</pre>
-<p>identified by identifier <span class="name">a1</span>, states the existence of an activity with recipe link <span class="name">add-crime-in-london</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix <span class="name">ex</span>). The attribute <span class="name">host</span> is application specific, but MUST hold for the duration of activity. The attribute <span class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
-</div>
-
-<p>The mere existence of an activity assertion 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 expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
-
-<div class='interpretation' id='start-precedes-end'> The following temporal constraint holds for any activity record: the
-<a title="activity start event">start event</a> <a>precedes</a> the <a title="activity end event">end event</a>.</div>
-
-<p>An activity record is not an entity record.
-Indeed, an entity record represents an entity that exists in full at
-any point in its characterization interval, persists during this
-interval, and preserves the characteristics that makes it
-identifiable. Alternatively, an activity in 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]].</p>
-
-
-</section>
-
-<section id="record-Agent">
-<h3>Agent Record</h3>
-
-
-
-<p>An <dfn id="dfn-Agent">agent record</dfn> is a representation of an agent, which is an entity that can be assigned some degree of responsibility for an activity taking place.</p>
-
-<p>Many agents can have an association with a given activity. An agent may do the ordering of the activity, another agent may do its design, another agent may push the button to start it, another agent may run it, etc.
-As many agents as one wishes to mention can occur in the provenance record, if it is important to indicate that they were associated with the activity. </p>
-
-<p>
-From an inter-operability perspective, it is useful to define some basic categories of agents since
-it will improve the use of provenance records by applications.
-There should be very few of these basic categories to keep the model simple and accessible.
-There are three types of agents in the model:
-<ul>
-<li><span class="name">Person</span>: agents of type Person are people. (This type is equivalent to a "foaf:person" [[FOAF]])</li>
-<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc. (This type is equivalent to a "foaf:organization" [[FOAF]])</li>
-<li><span class="name">SoftwareAgent</span>: a software agent is a piece of software. </li>
-</ul>
-<p>These types are mutually exclusive, though they do not cover all kinds of agent. </p>
-
-<p>An agent record, noted <span class="name">agent(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> identifying an agent; the identifier of the agent record is defined to be the same as the identifier of the agent;</li>
-<li><em>attributes</em>: contains a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this agent's situation in the world.</li>
-</ul>
-
-<p>In PROV-ASN, an agent record's text matches the <span class="nonterminal">agentRecord</span> production of the grammar defined in this specification document.
-</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">agentRecord</span> ::=
-<span class="name">agent</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-
-
-<div class="anexample">
-<p>With the following assertions,</p>
-<pre class="codeexample">
-agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Person" %% xsd:QName])
-
-entity(e2) and wasStartedBy(a1,e2,[prov:role="author"])
-
-entity(e3) and wasAssociatedWith(a1,e3,[prov:role="sponsor"])
-</pre>
-<p>the agent record identified by <span class="name">e1</span> is an explicit agent assertion that holds irrespective of activities it may be associated with. On the other hand, from the entity records identified by <span class="name">e2</span> and <span class="name">e3</span>, one can infer agent records, as per the following inference.</p>
-</div>
-
-<p>One can assert an agent record or alternatively, one can infer an agent record
-by its association with an activity. </p>
-
-<div class='constraint' 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>
-
-</section>
-
- <section id="record-note">
-
-<h4>Note Record</h4>
-
-<p>As provenance records are exchanged between systems, it may be useful to add extra-information about such records. For instance, a "trust service" may add value-judgements about the trustworthiness of some of the assertions made. Likewise, an interactive visualization component may want to enrich a set of provenance records with information helping reproduce their visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing any identifiable record to be associated with notes.</p>
-
-<p>An <dfn id="dfn-note">note record</dfn> is a set of attribute-value pairs, whose meaning is application specific. It may or may not be a representation of something in the world.</p>
-
-<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
-</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">noteRecord</span> ::=
-<span class="name">note</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">attribute-values</span>
-<span class="name">)</span><br/>
-<!-- -->
-</div>
-
-<p>A separate PROV-DM record is used to associate a note with an identifiable record (see <a href="#record-annotation">Section on annotation</a>). A given note may be associated with multiple records.
-</p>
-
-
-<div class="anexample">
-<p>
-The following note record</p>
-<pre class="codeexample">
-note(ann1,[ex:color="blue", ex:screenX=20, ex:screenY=30])
-</pre>
-<p>consists of a set of application-specific attribute-value pairs, intended
-to help the rendering of the record it is associated with, by
-specifying its color and its position on the screen. In this example,
-these attribute-value pairs do not constitute a representation of something
-in the world; they are just used to help render provenance.
-</p>
-</div>
-
-<p>
-Attribute-value pairs occurring in notes differ from attribute-value pairs occurring in entity records and activity records. In entity and activity records, attribute-value pairs MUST be a representation of something in the world, which remain constant for the duration of the characterization interval (for entity record) or the activity duration (for activity records). In note records, it is OPTIONAL for attribute-value pairs to be representations of something in the world. If they are a representation of something in the world, then it MAY change value for the corresponding duration. If attribute-value pairs of a note record are a representation of something in the world that does not change, they are not regarded as determining characteristics of an entity or activity, for the purpose of provenance.
-</p>
-
-
- </section>
-
-</section>
-
-
-<section id="record-relation">
-<h3>Relation</h3>
-
-<p>This section describes all the PROV-DM records representing relations between the elements introduced in <a href="#record-element">Section Element</a>. While these relations are not binary, they all involve two primary elements. They can be summarized as follows. </p>
-
-
-<div style="text-align: center;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption>PROV-DM Core Relation Summary</caption>
-<tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Note</td></tr>
-<tr><td>Entity</td><td><a title="derivation record">wasDerivedFrom</a><br><a title="complementarity record">wasComplementOf</a></td><td><a title="generation record">wasGeneratedBy</a></td><td>-</td><td><a title="annotation record">hasAnnotation</a></td></tr>
-<tr><td>Activity</td><td><a title="usage record">used</a></td><td>-</td><td><a title="start record">wasStartedBy</a><br><a title="end record">wasEndedBy</a><br><a title="activity association record">wasAssociatedWith</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
-<tr><td>Agent</td><td>-</td><td>-</td><td><a title="responsibility record">actedOnBehalfOf</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
-<tr><td>Note</td><td>-</td><td>-</td><td>-</td><td><a title="annotation record">hasAnnotation</a></td></tr>
-</table>
-</div>
-
-
-<p>In PROV-ASN, all these relation records are conformant to the <span class='nonterminal'>relationRecord</span> production of the grammar.</p>
-
-<section id="activity-entity-relation">
-<h3>Activity-Entity Relation</h3>
-
-<section id="record-Generation">
-<h4>Generation Record</h4>
-
-
-<p>In PROV-DM, a <dfn id="dfn-Generation">generation record</dfn> is a representation of a world <a title="entity generation event">event</a>, the creation of a new entity by an activity. This entity did not exist before creation.
-The representation of this <a>event</a> encompasses a description of the modalities of generation of this entity by this activity.</p>
-
-<p>A <a title="entity generation event">generation event</a> may be, for example, the creation of a file by a program, the creation of a linked data set, the production of a new version of a document, and the sending of a value on a communication channel.</p>
-
-<p>A generation record, written <span class="name">wasGeneratedBy(id,e,a,attrs,t)</span> in PROV-ASN, has the following components:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the generation record;</li>
-<li><em>entity</em>: an identifier <span class="name">e</span> identifying an entity record that represents the entity that is created; </li>
-<li><em>activity</em>: an identifier <span class="name">a</span> identifying an activity record that represents the activity that creates the entity;</li>
-
-<li><em>time</em>: an OPTIONAL "generation time" <span class="name">t</span>, the time at which the entity was created;</li>
-
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describes the modalities of generation of this entity by this activity.</li>
-
-</ul>
-
-<p>In PROV-ASN, a generation record's text matches the <span class='nonterminal'>generationRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">generationRecord</span> ::=
-<span class="name">wasGeneratedBy</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>
-<span class="name">,</span> </span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="optional"><span class="name">,</span>
-<span class="nonterminal">time</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/>
-</div>
-
-
-<p>
-A generation record's id is OPTIONAL. It MUST be used when annotating generation records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).
-</p>
-
-
-<div class='anexample'>
-<p>
-The following generation assertions</p>
-<pre class="codeexample">
- wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1", ex:order=1])
- wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p1", ex:order=2])
-</pre>
-<p>state the existence of two <a title="event">events</a> in the world (with respective times <span class="name">2001-10-26T21:32:52</span> and <span class="name">2001-10-26T10:00:00</span>), at which new entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an activity, itself represented by an activity record identified by <span class="name">a1</span>.
-The first one is available as the first value on port p1, whereas the other is the second value on port p1. The semantics of <span class="name">port</span> and <span class="name">order</span> in these records are application specific.
-</p>
-</div>
-
-
-
-<p>The assertion of a generation record implies ordering of <a title="event">events</a> in the world.</p>
-
-
-<div class='interpretation' id='generation-activity-ordering'><span class='conditional'>If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following temporal constraint also holds: the <a title="entity generation event">generation</a> of the entity denoted by <span class="name">x</span> <a>precedes</a> the <a title="activity end event">end</a>
-of <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>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
-The rationale for this constraint is as follows.
-If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct entities. Alternatively, for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This unicity constraint is formalized as follows.
-
-<div class='constraint' id='generation-unicity'>Given an entity record denoted by <span class="name">e</span>, two activity records 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> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given account,
-<span class='conditional'>then</span> <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
-</div>
-
-<div class='note'>TODO: Introduce the well-formed-ness constraint in a entirely separate section.</div>
-
-
-</section>
-
-
-<section id="record-Usage">
-<h3>Usage Record</h3>
-
-
-
-<p>In PROV-DM, a <dfn id="dfn-Use">usage record</dfn> is a representation of a world <a title="entity usage event">event</a>: the consumption of an entity by an activity. The representation includes a description of the modalities of usage of this entity by this activity.</p>
-
-<p>
-A <a title="entity usage event">usage event</a> may be the consumption of a parameter by a procedure, the reading of a value on a port by a service, the reading of a configuration file by a program, or the adding of an ingredient, such as eggs, in a baking activity. Usage may entirely consume an entity (e.g. eggs are not longer available after being added to the mix), or leave it as such, ready for further uses (e.g. a file on a file system can be read indefinitely).</p>
-
-
-<p>A usage record, written <span class="name">used(id,a,e,attrs,t)</span> in PROV-ASN, has the following constituent:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the usage record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record, which represents the consuming activity;</li>
-<li><em>entity</em>: an identifier <span class="name">e</span> for an entity record, which represents the entity that is consumed;</li>
-<li><em>time</em>: an OPTIONAL "usage time" <span class="name">t</span>, the time at which the entity was used;</li>
-<li><em>attributes</em>: an OPTIONIAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of usage of this entity by this activity;</li>
-</ul>
-
-<p>In PROV-ASN, a usage record's text matches the <span class='nonterminal'>usageRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">usageRecord</span> ::=
-<span class="name">used</span>
-<span class="name">(</span>
-<span class="optional">
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="optional">
-<span class="name">,</span>
- <span class="nonterminal">time</span>
-</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/>
-</div>
-
-
-<p>
-A usage record's id is OPTIONAL, but comes handy when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining derivations.
-</p>
-
-
-<div class='anexample'>
-<p>The following usage records</p>
-<pre class="codeexample">
- used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"])
- used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])
-</pre>
-<p>state that the activity, represented by the activity record identified by <span class="name">a1</span>, consumed two entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, at times <span class="name">2011-11-16T16:00:00</span> and <span class="name">2011-11-16T16:00:01</span>, respectively; the first one was found as the value of parameter <span class="name">p1</span>, whereas the second was found as value of parameter <span class="name">p2</span>. The semantics of <span class="name">parameter</span> in these records is application specific.</p>
-</div>
-
-
-
-
-
-<p>
-A usage record's id is OPTIONAL. It MUST be present when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).</p>
-
-<p>
-A reference to a given entity record MAY appear in multiple usage records that share
- a given activity record identifier.
-</p>
-
-
-
-
-
-<div class='interpretation' id='usage-generation-ordering'>For any entity, the following temporal 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>
-
-
-<div class='interpretation' id='usage-activity-ordering'>Given an activity record identified by <span class="name">a</span>, an entity record identified by <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 temporal constraint holds:
- the <a title="entity usage event">usage</a> of the entity represented by entity record identified by <span class="name">e</span> <a>precedes</a> the <a title="activity end event">end</a> of activity represented by record identified by <span class="name">a</span> and <a>follows</a> its <a title="activity start event">start</a>.
-</div>
-
-
-
-
-<div class='issue'>Should we define a taxonomy of use? This is <a href="http://www.w3.org/2011/prov/track/issues/23">ISSUE-23</a>.</div>
-
-</section>
-</section>
-
-
-
-
-
-<section id="activity-agent-relation">
-<h3>Activity-Agent Relation</h3>
-
-<section id="record-ActivityAssociation">
-<h4>Activity Association Record</h4>
-
-<p>The key purpose of agents in PROV-DM is to assign responsibility
-for activities. It is important to reflect that there is a degree in
-the responsibility of agents, and that is a major reason for
-distinguishing among all the agents that have some association with an
-activity and determine which ones are really the originators of the
-entity. For example, a programmer and a researcher could both be
-associated with running a workflow, but it may not matter what
-programmer clicked the button to start the workflow while it would
-matter a lot what researcher told the programmer to do so. Another
-example: a student publishing a web page describing an academic
-department could result in both the student and the department being
-agents associated with the activity, and it may not matter what
-student published a web page but it matters a lot that the department
-told the student to put up the web page. So there is some notion of
-responsibility that needs to be captured. </p>
-
-<p>To this end, PROV-DM offers two kinds of records. The first, introduced in this section, represents an association between an agent and an activity; the second, introduced in <a href="#record-responsibility">Section Responsibility record</a>, represents the fact that an agent was acting on behalf of another, in the context of an activity. </p>
-
-<p>Examples of activity association include designing, participation, initiation and termination, timetabling or sponsoring. </p>
-
-<p>An <dfn id="dfn-activity-association">activity association record</dfn>, written <span class="name">wasAssociatedWith(a,ag2,attrs)</span> in PROV-ASN, has the following constituents:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the activity association record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record;</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of association of this activity with this agent;</li>
-<li><em>agent</em>: an identifier <span class="name">ag2</span> for an agent record, which represents the agent associated with the activity.</li>
-
-</ul>
-
-<p>In PROV-ASN, an activity association record's text matches the <span class="nonterminal">activityAssociationRecord</span> productions of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">activityAssociationRecord</span> ::=
-<span class="name">wasAssociatedWith</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">aIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class="anexample">
-In the following example, a programmer and a researcher agents are asserted to be associated with an activity.
-<pre class="codeexample">
-activity(a,[prov:type="workflow"])
-agent(ag1,[prov:type="programmer"])
-agent(ag2,[prov:type="researcher"])
-wasAssociatedWith(a,ag1,[prov:role="loggedInUser", ex:how="webapp"])
-wasAssociatedWith(a,ag2,[prov:role="designer", ex:context="phd"])
-</pre>
-</div>
-
-
-
-</section>
-
-<section id="record-Start-End">
-<h4>Start and End Records</h4>
-
-<p> A <dfn id="dfn-Start">start record</dfn> is a representation of an agent starting an activity.
- An <dfn id="dfn-End">end record</dfn> is a representation of an agent ending an activity. Both relations are specialized forms of <span class="name">wasAssociatedWith</span>. They contain attributes describing the modalities of acting/ending activities.</p>
-
-
-
-<p>A start record, written <span class="name">wasStartedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the start record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the started activity;
-<li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the starting agent;
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent started the activity.
-</ul>
-
-<p>An end record, written <span class="name">wasEndedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the end record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the ended activity;
-<li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the ending agent;
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent ended the activity.
-</ul>
-
-<p>In PROV-ASN, start and end record's texts match the <span class="nonterminal">startRecord</span> and <span class="nonterminal">endRecord</span> productions of the grammar defined in this specification document.
-</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">startRecord</span> ::=
-<span class="name">wasStartedBy</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">aIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/>
-<span class="nonterminal">endRecord</span> ::=
-<span class="name">wasEndedBy</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">aIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-<div class="anexample">
-<p>
-The following assertions</p>
-<pre class="codeexample">
-wasStartedBy(a,ag,[ex:mode="manual"])
-wasEndedby(a,ag,[ex:mode="manual"])
-</pre>
-<p>state that the activity, represented by the activity record denoted by <span class="name">a</span>
-was started and ended by an agent, represented by record denoted by <span class="name">ah</span>, in "manual" mode, an application specific characterization of these relations.
-</p>
-</div>
-</section>
-
-<div class="note">Temporal constraints for these relations remain to be
-written. The temporal constraints should ensure that the agent started
-its existence before the effect it may have on the activity. </div>
-
-
-
-<!--
-
-<section id="record-Participation">
-<h4>Participation Record</h4>
-
-<p>A <dfn id="dfn-Participation">participation record</dfn> is a representation of the involvement of an entity in an activity. A participation record can be asserted or inferred.</p>
-
-
-<p>In PROV-ASN, a participation record's text matches the <span class="nonterminal">participationRecord</span> production of the grammar defined in this specification document.</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">participationRecord</span> ::=
-<span class="name">hadParticipant</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">identifier</span>
-<span class="name">)</span>
-</div>
-
-
-
-<p> A participation record,
-written <span class="name">hadParticipant(pe,e)</span> in PROV-ASN:
-<ul>
-<li> contains to identifier <span class="name">pe</span> identifying an activity record representing an activity;
-<li> contains an identifier <span class="name">e</span> identifying an entity record, which is
-a representation of an entity involved in this activity.
-</ul>
-
-<p>An entity's participation in an activity can be by direct usage or direct control. But also, if an entity and situation are characterized in two complementary manners (and are represented by two entity records related by <span class="name">isComplementOf</span>), if one of them participates in an activity, so does the other. The following captures the definition of participation.</p>
-
-<div class='constraint' id='participation'>
-Given two identifiers <span class="name">pe</span> and <span class="name">e</span>, respectively identifying an activity record and an entity record, the record <span class="name">hadParticipant(pe,e)</span> holds <span class='conditional'>if and only if</span>:
-<ul>
-<li> <span class="name">used(pe,e)</span> holds, or</li>
-<li> <span class="name">wasControlledBy(pe,e)</span> holds, or</li>
-<li> <span class="name">wasComplementOf(e1,e)</span> holds for some entity record identified by <span class="name">e1</span>, and
- <span class="name">hadParticipant(pe,e1)</span> holds some activity record identified by <span class="name">pe</span>.</li>
-</ul>
-</div>
-
-
-<div class='pending'>Suggested definition for participation. This is <a href="http://www.w3.org/2011/prov/track/issues/49">ISSUE-49</a>.</div>
-
-</section>
-
--->
-
-</section>
-
-<section id="entity-entity-agent-agent-relation">
-<h4>Entity-Entity or Agent-Agent Relation</h4>
-
-<section id="record-responsibility">
-
-<h4>Responsibility Record</h4>
-
-<p>To promote take-up, PROV-DM offers a mild version of responsibility
-in the form of a relation to represent when an agent acted on another
-agent's behalf. So in the example of someone running a mail program,
-the program is an agent of that activity and the person is also an
-agent of the activity, but we would also add that the mail software
-agent is running on the person's behalf. In the other example, the
-student acted on behalf of his supervisor, who acted on behalf of the
-department chair, who acts on behalf of the university, and all those
-agents are responsible in some way for the activity to take place but
-we don't say explicitly who bears responsibility and to what
-degree. </p>
-
-<p>We could also say that an agent can act on behalf of several other
-agents (a group of agents). This would also make possible to
-indirectly reflect chains of responsibility. This also indirectly
-reflects control without requiring that control is explicitly
-indicated. In some contexts there will be a need to represent
-responsibility explicitly, for example to indicate legal
-responsibility, and that could be added as an extension to this core
-model. Similarly with control, since in particular contexts there
-might be a need to define specific aspects of control that various
-agents exert over a given activity.</p>
-
-<p>Given an activity association record <span class="name">wasAssociatedWith(a,ag2,attrs)</span>,
-a <dfn id="dfn-responsibility">responsibility record</dfn>, written <span class="name">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-ASN, has the following constituents:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the responsibility record;</li>
-<li><em>subordinate</em>: an identifier <span class="name">ag2</span> for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible agent;</li>
-<li><em>responsible</em>: an identifier <span class="name">ag1</span> for an agent record, which represents the agent on behalf of which the subordinate agent <span class="name">ag2</span> acts;</li>
-<li><em>activity</em>: an OPTIONAL identifier <span class="name">a</span> of an activity record for which the responsibility record holds;</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this relation.</li>
-</ul>
-
-
-<div class='grammar'>
-<span class="nonterminal">responsibilityRecord</span> ::=
-<span class="name">actedOnBehalfOf</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">agIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>,
-<span class="optional"><span class="nonterminal">aIdentifier</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class="anexample">
-In the following example, a programmer, a researcher and a funder agents are asserted. The porgrammer and researcher are associated with a workflow activity. The programmer acts on behalf of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher.
-<pre class="codeexample">
-activity(a,[prov:type="workflow"])
-agent(ag1,[prov:type="programmer"])
-agent(ag2,[prov:type="researcher"])
-agent(ag3,[prov:type="funder"])
-wasAssociatedWith(a,ag1,[prov:role="loggedInUser"])
-wasAssociatedWith(a,ag2)
-actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])
-actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
-</pre>
-</div>
-
-
-</section>
-
-<section id="Derivation-Relation">
-<h4>Derivation Record</h4>
-
-<p>In PROV-DM, a <dfn id="dfn-Derivation">derivation record</dfn> is a representation that some entity is transformed from, created from, or affected by another entity in the world. </p>
-
-
-<p>Examples of derivation include the transformation of a canvas into a painting, the transportation of a person from London to New-York, the transformation of a relational table into a linked data set, and the melting of ice into water.</p>
-
-
-<p>According to <a href="#conceptualization">Section Conceptualization</a>, for an entity to be transformed from, created from, or affected by another in some way, there must be some underpinning activities performing the necessary actions resulting in such a derivation.
-However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or less precise records of derivation to be asserted. Hence, PROV-DM uses the terms <em>precise</em> and <em>imprecise</em> to characterize the different kinds of derivation record. We note that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation record, that may be imprecise. </p>
-
-<p>The lack of precision may come from two sources:</p>
-<ul>
-<li> the number of activities that underpin a derivation is not asserted or known, or</li>
-<li> any of the other details that are involved in the derivation is not asserted or known; these include activity identities, generation and usage records, and their attributes.</li>
-</ul>
-
-
-<!--
-Furthermore, assuming that an asserter has full knowledge of an activity underpinning a derivation, the same activity can generally be modelled in terms of sub-activities, composed in a such a way as to deliver the same behavior. Hence, since activities can be modelled at arbitrary levels of granularity, there is a distinguished case in which a derivation between two entities <span class="name">e2</span> and <span class="name">e1</span> corresponds <em>exactly</em> to <em>one</em> activity that used <span class="name">e1</span> and generated <span class="name">e2</span>. This is to be contrasted to the case where one derivation corresponds to n activities, where n can be any number greater than 1.
-Hence, PROV-DM uses the terms <em>one-activity</em> and <em>n-activities</em> to distinguish these two cases.</p>
--->
-
-
-<p>Hence, given a precision axis, with values <em>precise</em> and <em>imprecise</em>, and an activity axis, with values <em>one activity</em> and <em>n activities</em>, we can then form a matrix of possible derivations, precise or imprecise, or corresponding to one activity or n activities.
-Out of the four possibilities, PROV-DM offers three forms of derivation, while the fourth one is not meaningful. The following table summarises names for the three kinds of derivation, which we then explain.</p>
-
-<div style="text-align: center;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption>PROV-DM Derivation Type Summary</caption>
-<tr><td colspan=2 rowspan=2></td><td colspan=2>precision axis</td></tr>
-<tr><td>precise</td><td>imprecise</td></tr>
-<tr><td rowspan=2>activity<br>axis</td><td>one activity</td><td><a>precise-1 derivation record</a></td><td><a>imprecise-1 derivation record</a></td></tr>
-<tr><td>n activities</td><td>---</td><td><a>imprecise-n derivation record</a></td></tr>
-</table>
-</div>
-
-<ul>
-<li> The asserter asserts that derivation is due to exactly one activity, and all the details are asserted. We call this a precise-1 derivation record.</li>
-<li> The asserter asserts that derivation is due to exactly one activity, but other details, whether known or unknown, are not asserted. We call this an imprecise-1 derivation record.</li>
-<li> The asserter does not know how many activities are involved in the derivation, and other details, whether known or unknown, are also not asserted. We call this an imprecise-n derivation record.</li>
-</ul>
-
-<p> We note that the fourth theoretical case of a precise derivation, where the number of activities is not known or asserted cannot occur. </p>
-
-
-<p>The three kinds of derivation records are successively introduced. To minimize the number of relation types in PROV-DM, we introduce a PROV-DM reserved attribute <span class="name">steps</span>, which allows us to distinguish the various derivation types. </p>
-
-<p>A <dfn>precise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
-<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
-<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> of an activity record, which is a representation of the activity using and generating the above entities;</li>
-<li><em>generation</em>: an identifier <span class="name">g2</span> of the generation record pertaining to <span class="name">e2</span> and <span class="name">a</span>;</li>
-<li><em>usage</em>: an identifier <span class="name">u1</span> of the usage record pertaining to <span class="name">e1</span> and <span class="name">a</span>.</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation, optionally including the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
-</ul>
-<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in a precise-1 derivation since the record already refers to the one and only one activity underpinning the derivation.</p>
-
-
-<p>An <dfn>imprecise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2,e1, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
-<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
-<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
-<li><em>attributes</em>: a set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it MUST include the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
-</ul>
-<p>An imprecise-1 derivation MUST include the attribute <span class="name">prov:steps</span>, since it is the only means to distinguish this record from an imprecise-n derivation record.</p>
-
-
-<p>An <dfn>imprecise-n derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
-<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
-<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it optionally includes the attribute-value pair <span class="name">prov:steps="n"</span>.</li>
-</ul>
-<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in an imprecise-n derivation record. It defaults to <span class="name">prov:steps="n"</span>.</p>
-
-
-<p>None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property holds.</p>
-
-
-<p>In PROV-ASN, a derivation record's text matches the <span class='nonterminal'>derivationRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">derivationRecord</span> ::=
-<span class="nonterminal">precise-1-derivationRecord</span>
-| <span class="nonterminal">imprecise-1-derivationRecord</span>
-| <span class="nonterminal">imprecise-n-derivationRecord</span><br/>
-<br/>
-<span class="nonterminal">precise-1-derivationRecord</span> ::=
-<span class="name">wasDerivedFrom</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">gIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">uIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/>
-<span class="nonterminal">imprecise-1-derivationRecord</span>::=
-<span class="name">wasDerivedFrom</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">attribute-values</span>
-<span class="name">)</span>
-<br/>
-<span class="nonterminal">imprecise-n-derivationRecord</span>::=
-<span class="name">wasDerivedFrom</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-<div class="note">
-The grammar should make it clear that attribute <span class="name">prov:steps="1"</span> is required for imprecise-1-derivationRecord.<br/>
- PM: suggestion -- remove the distinction between imprecise-1 and imprecise-n in the grammar and instead explain that the qualification (1 vs n) is through attribute prov:steps.
-</div>
-
-<div class="anexample">
-<p>The following assertions state the existence of derivations.</p>
-<pre class="codeexample">
-wasDerivedFrom(e5,e3,a4,g2,u2,[])
-wasDerivedFrom(e5,e3,a4,g2,u2,[prov:steps="1"])
-
-wasDerivedFrom(e3,e2,[prov:steps="1"])
-
-wasDerivedFrom(e2,e1,[])
-wasDerivedFrom(e2,e1,[prov:steps="n"])
-</pre>
-<p>
-The first two are precise-1 derivation records expressing that the activity represented by the activity <span class="name">a4</span>, by
-using the entity denoted by <span class="name">e3</span> according to usage record <span class="name">u2</span>
- derived the
-entity denoted by <span class="name">e5</span> and generated it according to generation record
- <span class="name">g2</span>.
-
-The third record is an imprecise-1 derivation, which is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity record and associated attributes implicit. The fourth and fifth records are imprecise-n derivation records between <span class="name">e2</span> and <span class="name">e1</span>, but no information is provided as to the number and identity of activities underpinning the derivation.
-</p>
-</div>
-
-
-<p>An precise-1 derivation record is richer than an imprecise-1 derivation record, itself, being more informative that an imprecise-n derivation record. Hence, the following implications hold.</p>
-<div class='constraint' id='derivation-implications'>
-Given two entity records 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 record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, then <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> also holds.<br>
-
-Given two entity records 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, [prov:steps="1"] ∪ attrs)</span>
- holds, then <span class="name">wasDerivedFrom(e2,e1,attrs)</span> also holds.<br>
- </div>
-
-
-
-<p>
-<p>If a derivation record holds for <span class="name">e2</span> and <span class="name">e1</span>, then
-this means that the entity represented by entity record identified by <span class="name">e1</span> has an influence on the entity represented entity record identified by <span class="name">e2</span>,
- which at the minimum implies temporal ordering, specified as follows.
-First, we consider one-activity derivations.</p>
-
-<div class='interpretation' id='derivation-usage-generation-ordering'>Given an activity record identified by <span class="name">a</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, <span class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
-or <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> holds, <span class='conditional'>then</span>
-the following temporal 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>Then, imprecise-n derivations.</p>
-
-<div class='interpretation' id='derivation-generation-generation-ordering'>
-Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the record <span class="name">wasDerivedFrom(e2,e1,[prov:steps="n"] ∪ attrs)</span>
- holds, <span class='conditional'>then</span> the following temporal 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 temporal ordering is between generations of <span class="name">e1</span>
-and <span class="name">e2</span>, as opposed to precise-1 derivation,
-which implies temporal ordering between the usage of <span class="name">e1</span> and
-generation of <span class="name">e2</span>. Indeed, in the case of
-imprecise-n derivation, nothing is known about the usage of <span class="name">e1</span>,
-since there is no associated activity.</p>
-
-
-
-
-<p>The imprecise-1 derivation has the same meaning as the precise-1
- derivation, except that an activity
- is known to exist, though it does not need to be
-asserted. This is formalized by the following inference rule,
-referred to as <em>activity introduction</em>:</p>
-<div class='constraint' id="activity-introduction">
-<span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> there exist an activity record identified by <span class="name">a</span>, a usage record identified by <span class="name">u</span>, and a generation record identified by <span class="name">g</span>
-such that:
-<pre class="codeexample">
-activity(a,aAttrs)
-wasGeneratedBy(g,e2,a,gAttrs)
-used(u,a,e1,uAttrs)
-</pre>
-for sets of attribute-value pairs <span class="name">gAttrs</span>, <span class="name">uAttrs</span>, and <span class="name">aAttrs</span>.
-</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 determined by
-of <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>
-
-<div class="note">The following property holds for account where
-generation-unicity applies. Move it to separate section with all
-related material. </div>
-
-<p>A further inference is permitted from the imprecise-1 derivation record: </p>
-<div class='constraint' id='derivation-use'>
-<p>Given an activity record identified by <span class="name">pe</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and set of attribute-value pairs <span class="name">attrs2</span>,
-<span class='conditional'>if</span> <span class="name">wasDerivedFrom(e2,e1, [prov:steps="1"])</span> and <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> hold, <span class='conditional'>then</span> <span class="name">used(pe,e1,attrs1)</span> also holds
-for some set of attribute-value pairs <span class="name">attrs1</span>.
-</div>
-<p>This inference is justified by the fact that the entity represented by entity record identified by <span class="name">e2</span> is generated by at most one activity in a given account (see <a href="#generation-unicity">generation-unicity</a>). Hence, this activity record is also the one referred to in the usage record 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(pe,e1)</span>, one cannot
-derive <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> because identifier <span class="name">e1</span> may occur in usage records referring to
-many activity records, but they may not be referred to in generation records containing identifier <span class="name">e2</span>.</p>
-
-
-
-
-<div class='issue'>Should derivation have a time? Which time? This is <a href="http://www.w3.org/2011/prov/track/issues/43">ISSUE-43</a>.</div>
-
-</section>
-
-
-<section id="record-complement-of">
-
-<h4>Complementarity Record</h4>
-
-<div class="note">While the working group recognizes the importance of the complementarity record concept, its name and its exact semantics are still being discussed.
-</div>
-
-
-<p>A <dfn id="complementOf">complementarity record</dfn> is a relationship between two entities stated to have compatible characterization over some continuous interval between two events.</p>
-
-<!-- PAOLO, which event do you refer to? <a>event</a>?? -->
-
-
-<p>
-The rationale for introducing this relationship is that in general, at any given time, for an entity in the world, there may be multiple ways of characterizing it, and hence multiple representations can be asserted by different asserters. In the example that follows, suppose thing "Royal Society" is represented by two asserters, each using a different set of attributes. If the asserters agree that both representations refer to "The Royal Society", the question of whether any correspondence can be established between the two representations arises naturally. This is particularly relevant when (a) the sets of attributes used by the two representations overlap partially, or (b) when one set is subsumed by the other. In both these cases, we have a situation where each of the two asserters has a partial view of "The Royal Society", and establishing a correspondence between them on the shared attributes is beneficial, as in case (a) each of the two representation <em>complements</em> the other, and in case (b) one of the two (that with the additional attributes) complements the other.</p>
-
-<p>This intuition is made more precise by considering the entities that form the representations of entities at a certain point in time.
-
-An entity record represents, by means of attribute-value pairs, a thing and its situation in the world, which remain constant over a characterization interval.
-As soon as the thing's situation changes, this marks the end of the characterization interval for the entity record representing it. The thing's novel situation is represented by an attribute with a new value, or an entirely different set of attribute-value pairs, embodied in another entity record, with a new characterization interval. Thus, if we overlap the timelines (or, more generally, the sequences of value-changing events) for the two entities, we can hope to establish correspondences amongst the entity records that represent them at various points along that events line. The figure below illustrates this intuition.</p>
-
-<div style="text-align: center;">
-<img src="complement-of.png" alt="illustration complementOf"/>
-</div>
-
-<p>
-Relation <em>complement-of</em> between two entity records is intended to capture these correspondences, as follows. Suppose entity records A and B share a set P of attributes, and each of them has other attributes in addition to P. If the values assigned to each attribute in P are <em>compatible</em> between A and B, then we say that <em>A is-complement-of B</em>, and <em>B is-complement-of A</em>, in a symmetrical fashion. In the particular case where the set P of attributes of B is a strict superset of A's attributes, then we say that <em>B is-complement-of A</em>, but in this case the opposite does not hold. In this case, the relation is not symmetric. (as a special case, A and B may not share any attributes at all, and yet the asserters may still stipulate that they are representing the same thing "Royal Society". The symmetric relation may hold trivially in this case).</p>
-
-<p>The term <em>compatible</em> used above means that a mapping can be established amongst the values of attributes in P and found in the two entity expession. This generalizes to the case where attribute sets P1 and P2 of A, and B, respectively, are not identical but they can be mapped to one another. The simplest case is the identity mapping, in which A and B share attribute set P, and furthermore the values assigned to attributes in P match exactly.</p>
-
-<p>It is important to note that the relation holds only for the characterization intervals of the entity expessions involved As soon as one attribute changes value in one of them, new correspondences need to be found amongst the new entities. Thus, the relation has a validity span that can be expressed in terms of the event lines of the entity.</p>
-
-<!--
-The "IVP of" relationship is designed to represent pairs of entities that correspond to each other. By their own nature, an entity remains valid only as long as all of its attributes do not change their value. It follows that the correspondence "B IVP of A" is only valid within the time interval during which such invariance attribute holds for both A and B. When any of the attribute values change in either A or B, those entities are replaced by new ones, and a new correspondence may be established. Thus, "IVP of" is defined relative to the intersection of the temporal intervals for which A and B are valid.
--->
-
-
-
-<p>A complementarity record is written <span class="name">wasComplementOf(e2,e1)</span>, where <span class="name">e1</span> and <span class="name">e2</span> are two identifiers denoting entity records.</p>
-
-
-<div class="anexample">
-<p>The following example illustrates the entity "Royal Society"and its perspectives at various points in time.</p>
-<pre class="codeexample">
-entity(rs,[ex:created=1870])
-
-entity(rs_l1,[prov:location="loc2"])
-entity(rs_l2,[prov:location="The Mall"])
-
-entity(rs_m1,[ex:membership=250, ex:year=1900])
-entity(rs_m2,[ex:membership=300, ex:year=1945])
-entity(rs_m3,[ex:membership=270, ex:year=2010])
-
-wasComplementOf(rs_m3, rs_l2)
-wasComplementOf(rs_m2, rs_l1)
-wasComplementOf(rs_m2, rs_l2)
-wasComplementOf(rs_m1, rs_l1)
-
-wasComplementOf(rs_m3, rs)
-wasComplementOf(rs_m2, rs)
-wasComplementOf(rs_m1, rs)
-wasComplementOf(rs_l1, rs)
-wasComplementOf(rs_l2, rs)
-</pre>
-</div>
-
-
-
-<div class='constraint' id='wasComplementOf-necessary-cond'>
-An assertion "wasComplementOf(B,A)" holds over the temporal intersection of A and B, <span class='conditional'>only if</span>:
-<ol>
-<li> if a mapping can be established from an attribute X of entity record identified by B to an attribute Y of entity record identified by A, then the values of A and B must be consistent with that mapping;</li>
-<li>entity record identified by B has some attribute that entity record identified by A does not have.</li>
-</ol>
- </div>
-
-<p>The complementarity relation is not transitive. Let us consider identifiers <span class="name">e1</span>, <span class="name">e2</span>, and <span class="name">e3</span> identifying three entity records such that
- <span class="name">wasComplementOf(e3,e2)</span> and <span class="name">wasComplementOf(e2,e1)</span> hold. The record <span class="name">wasComplementOf(e3,e1)</span> may not hold because the characterization intervals of the denoted entity records may not overlap.</p>
-
-
-<p>In PROV-ASN, a complementarity record's text matches the <span class="nonterminal">complementarityRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">complementarityRecord</span> ::=
-<span class="name">wasComplementOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span> <br/>
-|
-<span class="name">wasComplementOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">accIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">accIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-<p>
-An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to link two entity record identifiers that are appear in different accounts. (In particular, the entity record identifiers in two different account are allowed to be the same.). When account identifiers are not available, then the linking of entity records through complementarity can only take place within the scope of a single account.
-</p>
-
-
-<div class="anexample">
-<p>In the following example, the same description of the Royal Society is structured according to two different accounts. In the second account, we find a complementarity record linking <span class="name">rs_m1</span> in account <span class="name">ex:acc2</span> to
-<span class="name">rs</span> in account <span class="name">ex:acc1</span>.
-<pre class="codeexample">
-account(ex:acc1,
- http://example.org/asserter1,
-
- ...
- entity(rs,[ex:created=1870])
- ...
- )
-
-
-account(ex:acc2,
- http://example.org/asserter2,
-
- ...
- entity(rs_m1,[ex:membership=250, ex:year=1900])
- ...
- wasComplementOf(rs_m1, ex:acc2, rs, ex:acc1)
-
-)
-</pre>
-</div>
-
-
-
-<div class='note'>It is suggested that the name 'wasComplementOf' does not capture the meaning of this relation adequately. No concrete suggestion has been made so far.
-Furthermore, there is a suggestion that an alternative relation that is transitive may also be useful.
-This is raised in the following <a href="http://lists.w3.org/Archives/Public/public-prov-wg/2011Sep/0315.html">email</a>.</div>
-
-
-
-<div class='issue'>A discussion on alternative definition of wasComplementOf has not reached a satisfactory conclusion yet. This is <a href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a></div>
-
-
-
-<div class='pending'> Comments on ivpof in <a href="http://www.w3.org/2011/prov/track/issues/57">ISSUE-57</a>.</div>
-
-
-</section>
-</section>
-
-
-<!--
-<section>
-<h4>Transitive Derivation Record</h4>
-
-
-<p>
-If <span class="name">wasDerivedFrom(e2,e1)</span> holds because attribute <span class="name">a2.1</span> of <span class="name">e2</span> is determined by attribute <span class="name">a1.1</span> of <span class="name">e1</span>,
-and if <span class="name">wasDerivedFrom(e3,e2)</span> holds because attribute <span class="name">a3.1</span>of <span class="name">e3</span> is determined by attribute <span class="name">a2.2</span> of <span class="name">e1</span>, it is not necessarily the case that an attribute of <span class="name">e3</span> is determined by an attribute of <span class="name">e1</span>; so, an asserter may not be able to assert <span class="name">wasDerivedFrom(e3,e1)</span>, since it would fail to satisfy constraint <a href="#derivation-attributes">derivation-attributes</a>. Hence, the constraint on attributes as expressed in <a href="#derivation-attributes">derivation-attributes</a> invalidates transitivity in the general case.
-</p>
-
-<p>However, there is sense that <span class="name">e3</span> still depends on <span class="name">e1</span>, since <span class="name">e3</span> could not be generated without <span class="name">e1</span> existing. Hence, we introduce a weaker notion of derivation record, which is transitive.</p>
-
-A transitive derivation record, written <span class="name">dependedOn(e2, e1)</span> in PROV-ASN:
-<ul>
-<li> contains an identifier <span class="name">e2</span>, denoting an entity record, which represents the entity that is the result of the derivation;
-<li> contains an identifier <span class="name">e1</span>, denoting an entity record, which represents the entity that the derivation relies upon.
-</ul>
-<p>The record <span class="name">dependedOn</span> can only be inferred; in other words, it cannot be asserted. It is
-transitive by definition and relies on the previously defined derivation assertions for its
-base case.</p>
-
-<div class='constraint' id='transitive-derivation'>
-<ul>
-<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> or <span class="name">wasDerivedFrom(e2,e1,pe,attrs2,attrs1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
-<li><span class='conditional'>If</span> <span class="name">wasEventuallyDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
-<li><span class='conditional'>If</span> <span class="name">dependedOn(e3,e2)</span> and <span class="name">dependedOn(e2,e1)</span> hold, <span class='conditional'>then</span> <span class="name">dependedOn(e3,e1)</span> holds.</li>
-</ul>
-</div>
-
-</section>
--->
-
-
-
-
-
-
-
-<section id="record-annotation">
-<h4>Annotation Record</h4>
-
-
-<p>An <dfn id="dfn-annotation">annotation record</dfn> establishes a link between an identifiable PROV-DM record and a note record referred to by its identifier. Multiple note records can be associated with a given PROV-DM record; symmetrically, multiple PROV-DM records can be associated with a given note record. Since note records have identifiers, they can also be annotated. The annotation mechanism (with note record and the annotation record) forms a key aspect of the extensibility mechanism of PROV-DM (see <a href="#extensibility-section">extensibility section</a>).</p>
-
-<p>An annotation record, written <span class="name">hasAnnotation(r,n,attrs)</span> in PROV-ASN, has the following constituents:</p>
-<ul>
-<li><em>record</em>: an identifier <span class="name">r</span> of the record being annnotated;</li>
-<li><em>note</em>: an identifier <span class="name">n</span> of a note record;</li>
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-
-<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class='grammar'>
-<span class="nonterminal">annotationRecord</span> ::=
-<span class="name">hasAnnotation</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">nIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<p>The interpretation of notes is application-specific. See Section <a href="#record-note">Note</a> for a discussion of the difference between note attributes and other records attributes. We also note the present tense in this term to indicate that it may not denote something in the past.</p>
-
-<div class="anexample">
-<p>
-The following records</p>
-<pre class="codexample">
-entity(e1,[prov:type="document"])
-entity(e2,[prov:type="document"])
-activity(a,transform,t1,t2,[])
-used(u1,a,e1,[ex:file="stdin"])
-wasGeneratedBy(e2, a, [ex:file="stdout"])
-
-note(n1,[ex:icon="doc.png"])
-hasAnnotation(e1,n1)
-hasAnnotation(e2,n1)
-
-note(n2,[ex:style="dotted"])
-hasAnnotation(u1,n2)
-</pre>
-<p>assert the existence of two documents in the world (attribute-value pair: <span class="name">prov:type="document"</span>) represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these records with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also asserts an activity, its usage of the first entity, and its generation of the second entity. The <span class="name">usage</span> record is annotated with a style (an application specific way of rendering this edge graphically). To be able to express this annotation, the usage record was provided with an identifier <span class="name">u1</span>, which was then referred to in <span class="name">hasAnnotation(u1,n2)</span>.
-</p>
-</div>
-
-
-</section>
-</section>
-
-<section id="bundle">
-<h3>Bundle</h3>
-
-<p>In this section, two constructs are introduced to group
-PROV-DM records. The first
-one, <a>account record</a> is itself a
-record, whereas the second
-one <a>record container</a> is not.
-</p>
-
-
-<section id="record-Account">
-<h3>Account Record</h3>
-
-<p>In PROV-DM, an <dfn id="dfn-Account">account record</dfn> is a wrapper of records with a dual purpose: </p>
-<ul>
-<li> It is the mechanism by which attribution of provenance can be assserted; it allows asserters to bundle up their assertions, and assert suitable attribution;
-<li> It provides a scoping mechanism for record identifiers and for some contraints (such as
- <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>).
-</ul>
-
-
-
-<p>An account record, written <span class="name">account(id, assertIRI, recs, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> that identifies this account globally;</li>
-<li><em>asserter</em>: an IRI, denoted by <span class="name">assertIRI</span>, to identify an asserter; such IRI has no specific interpretation in the context of PROV-DM;</li>
-<li><em>records</em>: a set <span class="name">recs</span> of provenance records;</li>
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p>In PROV-ASN, an account record's text matches the <span class="nonterminal">accountRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">accountRecord</span> ::=
-<span class="name">account</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">asserter</span>
-<span class="name">,</span>
-<span class="plus">
-<span class="nonterminal">record</span> </span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class='note'>
-Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI and its interpretation is outside PROV-DM. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM assertions. The editors seek inputs on how to resolve this issue. </div>
-
-<div class="anexample">
-<p>
-The following account record</p>
-<pre class="codeexample">
-account(ex:acc0,
- http://example.org/asserter,
- entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
- ...
- wasDerivedFrom(e2,e1)
- ...
- activity(a0,create-file,t)
- ...
- wasGeneratedBy(e0,a0,[])
- ...
- wasAssociatedWith(a4, ag5, [prov:role="communicator"]) )
-</pre>
-<p>contains the set of provenance records of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span class="name">http://example.org/asserter</span>, and is identified by identifier <span class="name">ex:acc0</span>.
-</p>
-</div>
-
-<p>Account records constitue a scope for record identifiers. A record identifier within the scope of an account is intended to denote a single record. However, nothing prevents an asserter from asserting an account containing, for example, multiple entity records with a same identifier but different attribute-values. In that case, they should be understood as a single entity record with this identifier and the union of all attributes values, as formalized in <a href="#identified-entity-in-account">identified-entity-in-account</a>.</p>
-
-<div class='constraint' id='identified-entity-in-account'>
-Given an entity record identifier <span class="name">e</span>, two sets of attribute-values denoted by <span class="name">av1</span> and <span class="name">av2</span>,
- two entity records <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account are equivalent to the entity record <span class="name">entity(e,av)</span> where <span class="name">av</span> is the set of attribute-value pairs formed by the union of <span class="name">av1</span> and <span class="name">av2</span>.
-</div>
-
-<p>Whilst constraint <a href="#identified-entity-in-account">identified-entity-in-account</a> specifies how to understand multiple entity records with a same identifier within a given account, it does not guarantee that the entity record formed with the union of all attribute-value pairs is consistent. Indeed, a given attribute may be assigned multiple values, resulting in an inconsistent entity record, as illustrated by the following example.</p>
-
-<div class="anexample">
-<p>
-In the following account record, we find two entity records with a same identifier <span class="name">e</span>.</p>
-<pre class="codeexample">
-account(ex:acc1,
- http://example.org/id,
- entity(e,[prov:type="person", ex:age=20])
- entity(e,[prov:type="person", ex:age=30])
- ...)
-</pre>
-<p>Application of <a href="#identified-entity-in-account">identified-entity-in-account</a> results in an entity record containing the attribute-value pairs <span class="name">age=20</span> and <span class="name">age=30</span>. This results in an inconsistent characterization of a person. We note that deciding whether a set of attribute-values is consistent or not is application specific and outside the scope of this specification.
-</p></div>
-
-<p>Account records can be nested since an account record can occur among the records being wrapped by another account. </p>
-
-
-<p>
-An account is said to be well-formed if
-it satisfies the constraints <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>.</p>
-
-<p> The union of two accounts is another account,
-containing the unions of their respective records, where
- records with a same identifier should be understood according to constraint <a href="#identified-entity-in-account">identified-entity-in-account</a>. Well-formed
-accounts are not
-closed under union because the
-constraint <a href="#generation-unicity">generation-unicity</a> may no
-longer be satisfied in the resulting union. </p>
-
-<div class="anexample">
-<p>
-Indeed, let us consider another account record</p>
-<pre class="codeexample">
-account(ex:acc2,
- http://example.org/asserter2,
- entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
- ...
- activity(a1,create-file,t1)
- ...
- 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-unicity">generation-unicity</a>.</p>
-</div>
-
-<p>Account records constitute a scope for record identifiers. Since accounts can be nested, scopes can also be nested; thus, the scope of record identifiers should be understood in the context of such nested scopes. When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur. </p>
-
-<div class="anexample">
-<p>
-The following account record is inspired from section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>. This account, identified by <span class="name">ex:acc3</span>, declares entity record with identifier <span class="name">e0</span>, which is being referred to in the nested account <span class="name">ex:acc4</span>. The scope of identifier <span class="name">e0</span> is account <span class="name">ex:acc3</span>, including subaccount <span class="name">ex:acc4</span>.</p>
-<pre class="codeexample">
-account(ex:acc3,
- http://example.org/asserter1,
- entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
- activity(a0,create-file,t)
- wasGeneratedBy(e0,a0,[])
- account(ex:acc4,
- http://example.org/asserter2,
- entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
- activity(a0,copy-file,t)
- wasGeneratedBy(e1,a0,[ex:fct="create"])
- wasComplementOf(e1,e0)))
-</pre>
-<p>Alternatively, an activity record identified by <span class="name">a0</span> occurs in each of the two accounts. Therefore, each activity record is asserted in a separate scope, and therefore may represent different activities in the world.
-</p>
-</div>
-
-<p>The account record is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. The annotation mechanism can be used for this purpose, but how general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>
-
-
-</section>
-
-<section id="RecordContainer">
-<h4>Record Container</h4>
-
-<p>A <dfn id="dfn-RecordContainer">record container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM records. A record container is not a record, but can be exploited to return assertions in response to a request for the provenance of something ([[PROV-PAQ]]). </p>
-
-<p>
-
-
-<p>A record container, written <span class="name">container decls recs endContainer</span> in PROV-ASN, contains:
-<ul>
-<li><em>namespaceDeclarations</em>: a set <span class="name">decls</span> of namespace declarations, declaring namespaces and associated prefixes, which can be used in <a title="attribute">attributes</a> and <a title="identifier">identifiers</a> occurring inside <span class="name">recs</span>;</li>
-<li><em>records</em>: a non-empty set of records <span class="name">recs</span>.</li>
-</ul>
-<p>All the records in <span class="name">recs</span> are implictly wrapped in a default account, scoping all the record identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts. Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a container's default account.</p>
-
-<p>In PROV-ASN, a record container's text matches the <span class="nonterminal">recordContainer</span> production of the grammar defined in this specification document.</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">recordContainer</span> ::=
-<span class="name">container</span>
-<span class="nonterminal">namespaceDeclarations</span>
-<span class="plus"> <span class="nonterminal">record</span> </span>
-<span class="name">endContainer</span>
-</div>
-
-
-<div class="anexample">
-<p>
-The following container </p>
-<pre class="codeexample">
-container
- prefix ex: http://example.org/,
-
- account(ex:acc1,http://example.org/asserter1,...)
- account(ex:acc2,http://example.org/asserter1,...)
-endContainer
-</pre>
-<p> illustrates how two accounts with identifiers <span class="name">ex:acc1</span> and <span class="name">ex:acc2</span> can be returned in a PROV-ASN serialization of the provenance of something.
-</p>
-</div>
-
-
-<div class='pending'>Asserter needs to be defined. This is <a href="http://www.w3.org/2011/prov/track/issues/51">ISSUE-51</a>.</div>
-
-
-<div class='pending'>Scope and Identifiers. This is <a href="http://www.w3.org/2011/prov/track/issues/81">ISSUE-81</a>.</div>
-
-
-</section>
-</section>
-
-
-<section id="sub-record">
-<h3>Further Terms in Records</h3>
-
-This section further terms in PROV-DM records.
-
-
-
-<section id="record-attribute">
-<h4>Attribute</h4>
-
-<p>An <dfn id="dfn-attribute">attribute</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
- by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
-
-<div class='grammar'>
-<span class="nonterminal">attribute</span> ::= <span class="nonterminal">qualifiedName</span><br/>
-<span class="nonterminal">qualifiedName</span> ::= <span class="nonterminal">prefixedName</span> | <span class="nonterminal">unprefixedName</span><br/>
-<span class="nonterminal">prefixedName</span> ::= <span class="nonterminal">prefix</span> <span class="name">:</span> <span class="nonterminal">localPart</span><br/>
-<span class="nonterminal">unprefixedName</span> ::= <span class="nonterminal">localPart</span><br/>
-<span class="nonterminal">prefix</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [[!XML-NAMES]]</em><br/>
-<span class="nonterminal">localPart</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [[!XML-NAMES]]</em>
-</div>
-
-<p>A qualified name's prefix is OPTIONAL. If a prefix occurs in a
- qualified name, it refers to a <a>namespace</a> declared in the
- record container. In the absence of prefix, the qualified name
- refers to the default namespace declared in the container.</p>
-
-<div class="note">Note that XML NC_NAME don't allow local identifiers to start with a number. Instead, should we use the productions used in SPARQL or TURTLE?</div>
-
-<p>From this specification's viewpoint, the interpretation of an attribute declared in a namespace other than prov-dm is out of
-scope.</p>
-
-<p>The PROV data model introduces a fixed set of attributes in the <a href="#prov-dm-namespace">PROV-DM namespace</a>:</p>
-<ul>
-<li> The attribute <dfn id="dfn-role"><span class="name">prov:role</span></dfn> denotes the function of an entity with respect to an activity, in the context of a usage, generation, activity association, start, end record. The value associated with a <span class="name">prov:role</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>.
-
-<div class="anexample">
-<p>The following start record describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
-<pre class="codeexample">
- wasStartedBy(a,ag, [prov:role="program-operator"])
-</pre>
-</div>
- </li>
-
-<li> The attribute <dfn id="dfn-type"><span class="name">prov:type</span></dfn> provides further typing information for the element or relation asserted in the record. The value associated with a <span class="name">prov:type</span> attribute MUST be conformant with <span class="nonterminal">Literal</span>.
-
-<div class="anexample">
-<p>The following record declares an agent of type software agent</p>
-<pre class="codeexample">
- agent(ag, [prov:type="prov:SoftwareAgent" %% xsd:QName])
-</pre>
-</div>
-
-
-<li> The attribute <dfn id="dfn-steps"><span class="name">prov:steps</span></dfn> defines the level of precision associated with a derivation record. The value associated with a <span class="name">prov:steps</span> attribute MUST be <span class="name">"1"</span> or <span class="name">"n"</span>. </li>
-
-</ul>
-</section>
-
-
-
-<section id="record-identifier">
-<h4>Identifier</h4>
-
-
-<p>An <dfn id="dfn-identifier">identifier</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
- by concatenating the IRI associated with the prefix and the local part (see detailed rule in [[!RDF-SPARQL-QUERY]], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
-
-<div class='grammar'>
-<span class="nonterminal">identifier</span> ::= <span class="nonterminal">qualifiedName</span><br/>
-<span class="nonterminal">eIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an entity record)</em><br/>
-<span class="nonterminal">aIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an activity record)</em><br/>
-<span class="nonterminal">agIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an agent record)</em><br/>
-<span class="nonterminal">gIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a generation record)</em><br/>
-<span class="nonterminal">uIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a usage record)</em><br/>
-<span class="nonterminal">nIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a note record)</em><br/>
-<span class="nonterminal">accIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote an account record)</em>
-</div>
-
-
-</section>
-
-<section id="record-literal">
-<h4>Literal</h4>
-
-<p>
-A PROV-DM Literal represents a data value such as a particular string
-or number. A PROV-DM Literal represents a value whose interpretation is outside the scope of PROV-DM.
-</p>
-
-<p>In PROV-ASN, a Literal's text matches the <span class="nonterminal">Literal</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">Literal</span> ::= <span class="nonterminal">typedLiteral</span> | <span class="nonterminal">convenienceNotation</span> <br/>
-<span class="nonterminal">typedLiteral</span> ::= <span class="nonterminal">quotedString</span> <span class="name">%%</span> <span class="nonterminal">datatype</span><br/>
-<span class="nonterminal">datatype</span> ::= <span class="nonterminal">qualifiedName</span><br/>
-<span class="nonterminal">convenienceNotation</span> ::= <span class="nonterminal">stringLiteral</span> | <span class="nonterminal">intLiteral</span><br/>
-<span class="nonterminal">stringLiteral</span> ::= <span class="nonterminal">quotedString</span><br/>
-<span class="nonterminal">quotedString</span> ::= <em>a finite sequence of characters in which " (U+22) and \ (U+5C) occur only in pairs of the form \" (U+5C, U+22) and \\ (U+5C, U+5C), enclosed in a pair of " (U+22) characters</em><br/>
-<span class="nonterminal">intLiteral</span> ::= <em>a finite-length sequence of decimal digits (#x30-#x39) with an optional leading negative sign (-)</em>
-</div>
-
-<p>The non terminals <span class="nonterminal">stringLiteral</span> and
-<span class="nonterminal">intLiteral</span>
-are syntactic sugar for quoted strings with datatype <span class="name">xsd:string</span> and <span class="name">xsd:int</span>, respectively.
-</p>
-
-<p> In particular, a PROV-DM Literal may be an IRI-typed string (with datatype <span class="name">xsd:anyURI</span>); such IRI has no specific interpretation in the context of PROV-DM.</p>
-
-
-<div class="anexample">
-<p>
-The following examples respectively are the string "abc" (expressed using the convenience notation), the string "abc", the integer number 1, the integer number 1 (expressed using the convenience notation) and the IRI "http://example.org/foo".
-<pre class="codeexample">
- "abc"
- "abc" %% xsd:string
- "1" %% xsd:int
- 1
- "http://example.org/foo" %% xsd:anyURI
-</pre>
-The following example shows a literal of type <span class="name">xsd:QName</span> (see
-<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#QName">QName</a> [[!XMLSCHEMA-2]]).
-The prefix <span class="name">ex</span> MUST be bound to a <a>namespace</a> declared in the
- record container.
-<pre class="codeexample">
- "ex:value" %% xsd:QName
-</pre>
-</div>
-
-
-
-<div class='note'>Should we define structural equivalence of literals as in OWL2? [[!OWL2-SYNTAX]]
-(see section <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Literals">Literals</a>).
-</div>
-
-</section>
-
-
-
-
-<section id="record-Time">
-<h4>Time</h4>
-
-<p><dfn id="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [[!XMLSCHEMA-2]].</p>
-
-
-
-<p>It is OPTIONAL to assert time in usage, generation, and activity records.</p>
-
-
-
-
-</section>
-
-<section id="record-Asserter">
-<h3>Asserter</h3>
-
-<p>An <dfn id="dfn-asserter">asserter</dfn> is a creator of PROV-DM records. An asserter is denoted by an IRI. Such IRI has no specific interpretation in the context of PROV-DM.</p>
-
-<div class='grammar'>
-<span class="nonterminal">asserter</span> ::= <span class="nonterminal">IRI</span><br/>
-<span class="nonterminal">IRI</span> ::= <em>an IRI compatible with production IRI in [[!IRI]], enclosed in a pair of < (U+3C) and > (U+3E) characters </em>
-</div>
-
-<div class='note'>
-Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM. We seek inputs on how to resolve this issue. </div>
-
-</section>
-
-<section id="record-NamespaceDeclaration">
-<h3>Namespace Declaration</h3>
-
-<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [[!IRI]]. In PROV-DM, attributes, identifiers, and literals of with datatype <span class="name">xsd:QName</span> can be placed in a namespace using the mechanisms described in this specification. </p>
-
-
-<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this declaration refers to this namespace.
-A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration refers to this namespace.</p>
-
-<div class='grammar'>
-<span class="nonterminal">namespaceDeclarations</span> ::=
- | <span class="group"><span class="nonterminal">defaultNamespaceDeclaration</span> | <span class="nonterminal">namespaceDeclaration</span></span> <span class="star"> <span class="nonterminal">namespaceDeclaration</span></span><br>
-<span class="nonterminal">namespaceDeclaration</span> ::=
-<span class="name">prefix</span> <span class="nonterminal">prefix</span> <span class="nonterminal">IRI</span><br/>
-<span class="nonterminal">defaultNamespaceDeclaration</span> ::=
- <span class="name">default</span> <span class="nonterminal">IRI</span> <br/>
-</div>
-</section>
-
-
-<section id="record-RecipeLink">
-<h3>Recipe Link</h3>
-
-
-<p>A <dfn id="dfn-RecipeLink">recipe link</dfn> is an association between an activity record and a process specification that underpins the represented activity. Such IRI has no specific interpretation in the context of PROV-DM.
-</p>
-
-<div class='grammar'>
-<span class="nonterminal">recipeLink</span> ::= <span class="nonterminal">IRI</span>
-</div>
-
-<p>
-It is OPTIONAL to assert recipe links in activities.
-</p>
-
-
-<p>
-Process specifications, as referred to by recipe links, are out of scope of this specification.
-</p>
-
-<div class="note">
-By defining a recipe link as an IRI whose interpretation is out of
-scope of PROV-DM, we don't allow it to refer to an entity (in an
-inter-operable manner). Is this what we intend?
-</div>
-
-<div class='issue'> Simplify the references to recipe link. This is <a href="http://www.w3.org/2011/prov/track/issues/131">ISSUE-131</a></div>
-
-</section>
-
-
-
-
-
-<section id="record-Location">
-<h3>Location</h3>
-
-<p><dfn id="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, row, column, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations in assertions. </p>
-
-
-<p>
-Location is an OPTIONAL attribute of entity records and activity records. The value associated with a attribute <span class="name">location</span> MUST be a <span class="nonterminal">Literal</span>, expected to denote a location.
-</p>
-
-
-
-
-</section>
-
-</section>
-
-</section>
-
-
- <section id="common-relations">
-<h2>PROV-DM Common Relations</h2>
-
-<p>This section contains the normative specification of common relations of PROV-DM.</p>
-
-
-<div class='issue'>We have defined a set of common relation, in response to <a href="http://www.w3.org/2011/prov/track/issues/44">ISSUE-44</a>. Is this set complete?</div>
-
-
-<div class='note'>The types of these relations need to be made explicit.</div>
-
-<p>The following figure summarizes the additional relations described in subsections 6.2 onwards.</p>
-
-<div style="text-align: center;">
-<img src="sec6-summary.png" alt="common relations"/>
-</div>
-
-
-<section id="record-Collection">
-<h3>Collections</h3>
-
-The purpose of this section is to enable modelling of part-of relationships amongst entities. In particular, a form of <strong>collection</strong> entity type is introduced, consisting of a set of key-value pairs. Key-value pairs provide a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more.<br/>
-
-The relations introduced here are all specializations of the <a href="#record-Derivation"><strong>wasDerivedFrom</strong></a> relation, specifically precise-1 or imprecise-1. They are designed to model:
-
-<ul>
- <li><strong>insertion</strong>: a collection entity c' is obtained from collection entity c, by adding entity e having key k to c;
- <li><strong>removal</strong>: a collection entity c' is obtained from collection entity c, by removing entity e having key k from c;
- <li><strong>selection</strong>: an entity e was selected from collection c using key k.
- </ul>
-
- A collection record is defined as follows.
-<div class='grammar'>
- <span class="nonterminal">collectionRecord</span> ::=
-<span class="nonterminal">collectionDerivationRecord</span>
-| <span class="nonterminal">keyDerivationRecord</span>
-| <span class="nonterminal">entityMembershipRecord</span>
-<br/>
-
- <span class="nonterminal">collectionDerivationRecord</span> ::=
-<span class="name">wasAddedTo_Coll</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
- |
-<span class="name">wasRemovedFrom_Coll</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
-<br/>
-
- <span class="nonterminal">keyDerivationRecord</span> ::=
-<span class="name">wasAddedTo_Key</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
-|
-<span class="name">wasRemovedFrom_Key</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
- <br/>
-
- <span class="nonterminal">entityMembershipRecord</span> ::=
-<span class="name">wasAddedTo_Entity</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
-<br/>
- </div>
-
-<p> Record: <span class="name">wasAddedTo_Coll(c2,c1)</span> (resp. <span class="name">wasRemovedFrom_Coll(c2,c1)</span>) denotes that collection <span class="name">c2</span> is an updated version of collection <span class="name">c1</span>, following an insertion (resp. deletion) operation.</p>
-
-<p> Record: <span class="name">wasAddedTo_Key(c,k)</span> (resp. <span class="name">wasRemovedFrom_Key(c,k)</span>) denotes that collection <span class="name">c</span> had
- a new value with key <span class="name">k</span> added to (resp. removed from) it.</p>
-
-<p> Record: <span class="name">wasAddedTo_Entity(c,e)</span> denotes that collection <span class="name">c</span> had entity
- <span class="name">e</span> added to it.
-</p>
-
-
-<div class="anexample">
-<p>Consider the following assertions:</p>
-<pre class="codeexample">
-
-
- <span class="name">wasAddedTo_Coll(c2,c1)</span>
- <span class="name">wasAddedTo_Key(c2,k1)</span>
- <span class="name">wasAddedTo_Entity(c2,e1)</span>
-
- <span class="name">wasAddedTo_Coll(c3,c2)</span>
- <span class="name">wasAddedTo_Key(c3,k2)</span>
- <span class="name">wasAddedTo_Entity(c3,e2)</span>
-
- <span class="name">wasRemovedFrom_Coll(c4,c3)</span>
- <span class="name">wasRemovedFrom_Key(c4,k1)</span>
-</pre>
-<p>The corresponding graphical representation is shown below.</p>
-
-<div style="text-align: center;">
-<img src="collections.png" alt="collections"/>
-</div>
-
-
-<p> With these assertions:</p>
- <ul>
- <li><span class="name">c2</span> is known to contain the key-value pair <span class="name">(k1,e1)</span>
- <li><span class="name">c3</span> is known to contain pairs <span class="name">(k1,e1)</span> and <span class="name">(k2,e2)</span>.
- <li><span class="name">c4</span> is known <em>not</em> to contain pair <span class="name">(k1,e1)</span> and to contain pair <span class="name">(k2,e2)</span>.
- </ul>
-</div>
-
- </section>
-
-<section id="record-traceability">
-<h3>Traceability Record</h3>
-
-<p> A <dfn id="dfn-Traceability">traceability record</dfn> states the existence of a "dependency path" between two entities, indicating that one entity can be shown to be in the lineage of another, and may have influenced it in some way. This relation is transitive. </p>
-
-<p> A traceability record, written <span class="name">tracedTo(id,e2,e1,attrs)</span> in PROV-ASN:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the traceability record;</li>
-<li><em>entity</em>: an identifier <span class="name">e2</span> identifying an entity;
-<li><em>ancestor</em>: an identifier <span class="name">e1</span> identifying an ancestor entity in the lineage of <span class="name">e2</span>;
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p>In PROV-ASN, a traceability record's text matches the <span class="nonterminal">traceabilityRecord</span> production of the grammar defined in this specification document.</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">traceabilityRecord</span> ::=
-<span class="name">tracedTo</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>
-<span class="name">,</span></span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<p>A traceability record can be inferred from existing relations, or can be asserted stating that such a dependency path exists without the asserter knowing its individual steps, as expressed by the following constraints.
-
-<div class='constraint' id='traceability-inference'>
-Given two identifiers <span class="name">e2</span> and <span class="name">e1</span> identifying entity records,
-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>
-
-<div class='constraint' id='traceability-assertion'>
-<span class='conditional'>If</span> the record <span class="name">tracedTo(r2,r1)</span> holds
-for two identifiers <span class="name">r2</span> and <span class="name">r1</span> identifying entity records,
- <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 record. </p>
-
-
-</section>
-
-<section id="record-OrderingOfActivities">
-<h3>Activity Ordering Record</h3>
-
-
-
-<p>PROV-DM allows dependencies amongst activities to be expressed.
-An <dfn id="InformationFlowOrdering">information flow ordering record</dfn> is a representation that an entity was generated by an activity, before it was used by another activity.
-A <dfn id="ControlOrdering">control ordering record</dfn> is a representation that an activity was initiated by another activity.
-</p>
-
-<p>In PROV-ASN, an activity ordering record's text matches the <span class="nonterminal">activityOrderingRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class='grammar'>
-<span class="nonterminal">activityOrderingRecord</span> ::=
-<span class="nonterminal">informationFlowOrderingRecord</span> |
-<span class="nonterminal">controlOrderingRecord</span>
-<br/>
-
-<span class="nonterminal">informationFlowOrderingRecord</span> ::=
-<span class="name">wasInformedBy</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>
-<span class="name">,</span>
-</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-<br/>
-
-<span class="nonterminal">controlOrderingRecord</span> ::=
-<span class="name">wasStartedBy</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>
-<span class="name">,</span>
-</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-<br/>
-</div>
-
-
-<p>
-An information flow ordering record, written as
-<span class="name">wasInformedBy(id,a2,a1,attrs)</span> in PROV-ASN, contains:
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the record;</li>
-<li><em>informed</em>: the identifier <span class="name">a2</span> of an activity record representing the informed activity;
-<li><em>informant</em>: the identifier <span class="name">a1</span> of an activity record representing the informant activity;
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p> An information flow ordering record is formally defined as follows.</p>
-
-<div class='constraint' id='wasInformedBy-Definition'>Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
- the record <span class="name">wasInformedBy(a2,a1)</span>
-holds, <span class='conditional'>if and only if</span>
- there is an entity record identified by <span class="name">e</span> and 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' id='wasInformedBy-ordering'>
-Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span class="name">wasInformedBy(a2,a1)</span>
- holds, <span class='conditional'>then</span> the following temporal constraint holds:
-the <a title="activity start event">start event</a> of the activity record denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity end event">end event</a> of
-the activity record denoted by <span class="name">a2</span>.
-</div>
-
-
-<p>The relationship <span class="name">wasInformedBy</span> is not transitive. Indeed, consider the following records.</p>
-<pre class="codeexample">
-wasInformedBy(a2,a1)
-wasInformedBy(a3,a2)
-</pre>
-<p> We cannot infer <span class="name">wasInformedBy(a3,a1)</span> from them. 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 where transitivity cannot hold. The horizontal axis represents time. 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;">
-<img src="informedByNonTransitive.png" alt="non transitivity of wasInformedBy" />
-</div>
-
-<div class="note">
-The relation wasScheduledAfter was dropped, and replaced by a simplier relation wasStartedBy(a2,a1). It is intentional that the name wasStartedBy is overloaded.
-</div>
-
-<p>
-A control ordering record, written as
-<span class="name">wasStartedBy(a2,a1)</span> in PROV-ASN, contains: </p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span>;</li>
-<li><em>started</em>: refers to an activity record identified by <span class="name">a2</span>, representing the started activity;
-<li><em>starter</em>: refers to an activity record identified by <span class="name">a1</span>, representing the activity that started <span class="name">a1</span>;</li>
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-<p>Such a record states control ordering between <span class="name">a2</span> and <span class="name">a1</span>, specified as follows.</p>
-
-<div class='constraint' id='wasStartedBy'>Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
- the record <span class="name">wasStartedBy(a2,a1)</span>
-holds <span class='conditional'>if and only if</span>
- there exist an entity record identified by <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>
-
-
-<div class="anexample">
-<p>
-In the following assertions, we find two activity records, identified by <span class="name">a1</span> and <span class="name">a2</span>, representing two activities, which took place on two separate hosts. The third record indicates that the latter activity was started by the former.</p>
-<pre class="codeexample">
-activity(a1,workflow,t1,t2,[ex:host="server1.example.org"])
-activity(a2,sub-workflow,t3,t4,[ex:host="server2.example.org"])
-wasStartedBy(a2,a1)
-</pre>
-
-<p>Alternatively, we could have asserted the existence of an entity, representing a request to create a sub-workflow. This request, issued by <span class="name">a1</span>, triggered the start of <span class="name">a2</span>.
-</p>
-<pre class="codeexample">
-entity(e,[prov:type="creation-request"])
-wasGeneratedBy(e,a1)
-wasStartedBy(a2,e)
-</pre>
-</div>
-
-<div class='interpretation' id='wasStartedBy-ordering'>
-Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> the record <span class="name">wasStartedBy(a2,a1)</span>
- holds, <span class='conditional'>then</span> the following temporal constraint holds: the
-<a title="activity start event">start</a> event of the activity record denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity start event">start event</a> of
-the activity record denoted by <span class="name">a2</span>.
-</div>
-
-
-
-<div class='pending'>Suggested definition for process ordering. This is <a href="http://www.w3.org/2011/prov/track/issues/50">ISSUE-50</a>.</div>
-
-</section>
-
-<section id="record-Revision">
-<h3>Revision Record</h3>
-
-<p> A <dfn id="dfn-Revision">revision record</dfn> is a representation of the creation of an entity considered to be a variant of another. Deciding whether something is made available as a revision of something else usually involves an agent who represents someone in the world who takes responsibility for approving that the former is a due variant of the latter. </p>
-
-<p> A revision record, written <span class="name">wasRevisionOf(e2,e1,ag,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>newer</em>: an identifier <span class="name">e2</span> identifying an entity that represents a newer version of an entity;
-<li><em>older</em>: an identifier <span class="name">e1</span> identifying an entity that represents an older version of an entity;
-<li><em>responsibility</em>: an OPTIONAL identifier <span class="name">ag</span> for the agent who approved that <span class="name">e2</span> is a variant of <span class="name">e1</span>;
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-
-<p>In PROV-ASN, a revision record's text matches the <span class="nonterminal">revisionRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class='grammar'>
-<span class="nonterminal">revisionRecord</span> ::=
-<span class="name">wasRevisionOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="optional"><span class="name">,</span>
-<span class="nonterminal">agIdentifier</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-
-
-
-<p>A revision record needs to satisfy the following constraint, linking the two entity records by a derivation, and stating them to be a complement of a third entity record.</p>
-
-<div class='constraint' 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> a record <span class="name">wasRevisionOf(new,old,ag)</span> is asserted, <span class='conditional'>then</span>
-there exists an entity record identifier <span class="name">e</span> and attribute-values <span class="name">eAttrs</span>, <span class="name">dAttrs</span>, such that the following records hold:
-<ul>
-<li> <span class="name">wasDerivedFrom(new,old,dAttrs)</span>;
-<li> <span class="name">entity(e,eAttrs)</span>;
-<li> <span class="name">wasComplementOf(new,e)</span>;
-<li> <span class="name">wasComplementOf(old,e)</span>.
-</ul>
-The derivation record may be imprecise-1 or imprecise-n.
-</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>
-
-<div class="anexample">
-<p>
-The following revision assertion</p>
-<pre class="codeexample">
-agent(ag,[prov:type="QualityController"])
-entity(e1,[prov:type="document"])
-entity(e2,[prov:type="document"])
-wasRevisionOf(e2,e1,ag)
-</pre>
-<p>states that the document represented by entity record identified by <span class="name">e2</span> is a revision of document represented by entity record identified by <span class="name">e1</span>; agent denoted by <span class="name">ag</span> is responsible for this new versioning of the document.
-</p>
-</div>
-
-
-<div class='pending'>Revision should be a class not a property. This is <a href="http://www.w3.org/2011/prov/track/issues/48">ISSUE-48</a>.</div>
-
-
-</section>
-
-
-<section>
-<h3>Attribution Record</h3>
-
-<p>An attribution record represents that an entity is ascribed to an agent and is compliant with the <span class="nonterminal">attributionRecord</span> production.</p>
-
-
-<p> An attribution record, written <span class="name"> wasAttributedTo(e,ag,attr)</span>, contains the following components:</p>
-<ul>
-<li><em>entity</em>: an identifier <span class="name">e</span> of an entity record;</li>
-<li><em>agent</em>: an identifier <span class="name">ag</span> of an agent whom the entity is attributed to;</li>
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-<p>Attribution models the notion of an activity generating an entity identified by <span class="name">e</span> being controlled by an agent <span class="name">ag</span>, which takes responsibility for generating <span class="name">e</span>. Formally, this is expressed as the following necessary condition.</p>
-
-<p>In PROV-ASN, an attribution record's text matches the <span class="nonterminal">attributionRecord</span> production of the grammar.</p>
-
-<div class='grammar'>
-<span class="nonterminal">attributionRecord</span> ::=
-<span class="name">wasAttributedTo</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class='constraint' 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 identified by <span class="name">pe</span> such that the following statements hold:
-<pre>
-activity(pe,recipe,t1,t2,attr1)
-wasGenerateBy(e,pe)
-wasAssociatedWith(pe,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>
-<h3>Quotation Record</h3>
-
-
-<p> A quotation record is a representation of the repeating or copying of some part of an entity, compatible with
-the <span class="nonterminal">quotationRecord</span> production.</p>
-
-
-<p> A quotation record, written <span class="name"> wasQuotedFrom(e2,e1,ag2,ag1,attrs)</span>, contains:</p>
-<ul>
-<li><em>quote</em>: an identifier <span class="name">e2</span>, identifying an entity record that represents the quote;
-<li><em>quoted</em>: an identifier <span class="name">e1</span>, identifying an entity record representing what is being quoted;
-<li><em>quoterAgent</em>: an OPTIONAL identifier <span class="name">ag2</span> of the agent who is doing the quoting;
-<li><em>quotedAgent</em>: an OPTIONAL identifier <span class="name">ag1</span> of the agent that is quoted;
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-
-</ul>
-
-<p>In PROV-ASN, a quotation record's text matches the <span class="nonterminal">quotationRecord</span> production of the grammar.</p>
-
-<div class='grammar'>
-<span class="nonterminal">quotationRecord</span> ::=
-<span class="name">wasQuotedFrom</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-
-<div class='constraint' id='quotation-implication'>
-<span class='conditional'>If</span>
-<span class="name">wasQuotedFrom(e2,e1,ag2,ag1)</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 records hold:
-<pre>
-wasDerivedFrom(e2,e1)
-wasAttributedTo(e2,ag2)
-wasAttributedTo(e1,ag1)
-</pre>
-</div>
-
-</section>
-
-
-<section>
-<h3>Summary Record</h3>
-<p>A <dfn>summary record</dfn> represents that an entity is a synopsis or abbreviation of another entity. A summary record is compliant with the
-<span class="nonterminal">summaryRecord</span> production.</p>
-
-
-
-<p> An assertion wasSummaryOf, written <span class="name"> wasSummaryOf(e2,e1,attrs)</span>, contains:</p>
-<ul>
-<li><em>summarizedEntity</em>: an identifier <span class="name">e2</span> for the entity record that represents the summary;
-<li><em>fullEntity</em>: an identifier <span class="name">e1</span> for the entity record that represents what is being summarized;
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p>In PROV-ASN, a summary record's text matches the <span class="nonterminal">summaryRecord</span> production of the grammar.</p>
-
-<div class='grammar'>
-<span class="nonterminal">summaryRecord</span> ::=
-<span class="name">wasSummaryOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<p>
-<span class="name">wasSummaryOf</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
-</p>
-
-
-</section>
-
-<section>
-<h3>Original Source Record</h3>
-
-<p>An <dfn>original source record</dfn> represents an entity in
-which another entity first appeared. A original-source
-record is compliant with the
-<span class="nonterminal">originalSourceRecord</span> production.</p>
-
-
-<p> An assertion hadOriginalSource, written <span class="name"> hadOriginalSource(e2,e1,attrs)</span>, contains:</p>
-<ul>
-<li><em>entity</em>: an identifier <span class="name">e1</span> for the entity record representing the original entity; </li>
-<li><em>source</em>: an identifier <span class="name">e2</span> for an entity record, representing an entity that had appeared previously;</li>
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p>
- <span class="name">hasOriginalSource</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
-</p>
-
-<p>In PROV-ASN, an original source record's text matches the <span class="nonterminal">originalSourceRecord</span> production of the grammar.</p>
-
-<div class='grammar'>
-<span class="nonterminal">originalSourceRecord</span> ::=
-<span class="name">hadOriginalSource</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-</section>
-</section>
-
- <section id="extensibility-section">
-<h2>PROV-DM Extensibility Points</h2>
-
-
-<p>The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
-
-<ul>
-<li> Attributes are constructs of the data model that allow representations of aspects of the world's entities and activities to be expressed. Applications are free to introduce application-specific attributes, according to their perspective on the world. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace declared in a namespace declaration.
-
-<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes: <span class="name">type</span>, <span class="name">location</span>.</li>
-
-
-<li> Sets of Attribute-value pairs offer a mechanism to
-describe modalities of use, generation, and control
-Such attributes are also qualified by namespaces.
-
-<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
-
-
-<li>Note records allow arbitrary metadata to be associated with identifiable records of PROV-DM. Note records consist of name-value pairs. Like attributes, names are qualified by a namespace.</li>
-
-
-<li>Namespaces allow attributes and names to be qualified. </li>
-
-<li>Subtyping is allowed by means of the reserved attribute <span class="name">type</span>.</li>
-
-<li>Domain specific values can be expressed by means of typed literals. </li>
-</ul>
-
-<p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged. To ensure inter-operability, specializations of the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in this document. For instance, a qualified attribute on a domain specific entity record MUST represent an aspect of an entity and this aspect MUST remain unchanged during the characterization's interval of this entity record.</p>
-
-
-
- </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 example 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-ASN sample below, are expressed within a same account.
-</p>
-
-<pre>
-container
-prefix app urn:example:
-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 idenfier that identifies the entity it represents.
-In this example, three identifiers were minted, and their prefix uses the URN syntax with "example" namespace.</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 a PROV-DM identifier, it identifies a specific characterization of this report. A given identifier identifies a single entity record 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. </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 perspective we take about that resource is expressed as a different entity record, happening to have the same identifier 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 urn:example:
- 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 class="appendix">
- <h2>Changes Since First Public Working Draft</h2>
-<ul>
-<li>12/08/11: Explained non-transitivity of wasInformedBy. </li>
-<li>12/05/11: Made attributes optional, and used non-terminal optional-attribute-values. </li>
-<li>12/05/11: Changed syntax of recordContainer to be more user friendly, and removed list of account ids, since redundant. </li>
-<li>12/05/11: Changed syntax of namespace declaration to be more user friendly. </li>
-<li>12/05/11: Simplified Typed literals, now allows for intLiteral, and datatype adjusted to be qualified name. </li>
-<li>11/29/11: Introduced typed identifiers to make grammar clearer. </li>
-<li>11/29/11: Added section 2.4 on grammar notation. </li>
-<li>11/28/11: Changed grammar notation. </li>
-<li>11/25/11: Updated examples of section 8. </li>
-<li>11/25/11: Definition of namespace. Clarification about interpretation of IRI occurrences. </li>
-<li>11/25/11: Definition of attribute and identifier. </li>
-<li>11/24/11: Added figure of Common Relations in Section 6. </li>
-<li>11/24/11: Updated text preceding graphical illustration, removed appendix A. </li>
-<li>11/24/11: Fix on traceability record. </li>
-<li>11/24/11: Revisited Derivation record, with a single name for derivation. </li>
-<li>11/23/11: Defined attribute, identifier, and namespace declaration. </li>
-<li>11/23/11: Consolidation of event in section 2.1.2 and linking to definitions from the rest of document. </li>
-<li>11/21/11: Added wasStartedBy between activities.</li>
-<li>11/21/11: Added wasInformedBy-ordering constraint.</li>
-<li>11/17/11: Added Traceability Record.</li>
-<li>11/17/11: Rewrote the whole section on Derivation Record.</li>
-<li>11/17/11: Updated wasDerivedFrom to refer to generation/usage record ids.</li>
-<li>11/17/11: Simplified hasAnnotation mechanism, now requiring to-be-annotated record to had id.</li>
-<li>11/17/11: Renamed annotation into note.</li>
-<li>11/17/11: Introduced wasStartedBy, wasEndedBy, and actedOnBehalfOf.</li>
-<li>11/16/11: New version of agent/wasAssociatedWith.</li>
-<li>11/16/11: Introduced class anexample.</li>
-<li>11/16/11: Changed presentation of entity and activity.</li>
-<li>11/16/11: Updated examples for usage and generation record.</li>
-<li>11/16/11: Renamed use record into usage record.</li>
-<li>11/16/11: Removed constraint generation-affects-attributes.</li>
-<li>11/16/11: Removed constraint use-attributes.</li>
-<li>11/16/11: Introduced optional identity for use and generation record.</li>
-<li>11/11/11: Swapped sections 6 and 7.</li>
-<li>11/11/11: Use attribute-value pairs uniformly, instead of qualifiers and name-value pairs.</li>
-<li>11/08/11: Renamed 'provenance container' into 'record container'.</li>
-<li>11/07/11: Addressed ISSUE-143 (qualifiers as a set of name value pairs).</li>
-<li>11/07/11: Added a section on Literals (ISSUE-142).</li>
-<li>11/07/11: Aligned terminology 'activity' and 'process execution record'.</li>
-<li>11/07/11: Renamed 'xxx Expression' into 'xxx Record' to avoid the language connotation.</li>
-<li>11/07/11: Defined entity as identifiable characterized thing, and updated text accordingly.</li>
-<li>10/08/11: Made explicit the term expression wherever was appropriate, including section titles.</li>
-</ul>
- </section>
-
-<section class="appendix">
- <h2>Acknowledgements</h2>
- <p>
- WG membership to be listed here.
- </p>
- </section>
-
- </body></html>
Binary file model/wd2/collections.png has changed
Binary file model/wd2/complement-of.png has changed
Binary file model/wd2/example-graphical.png has changed
--- a/model/wd2/extra.css Fri Dec 09 08:06:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,284 +0,0 @@
-
-/* --- EDITORIAL NOTES --- */
-.pending {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #BFEFFF;
-}
-
-.pending::before {
- content: "Pending Review";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-.resolved {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #9BCD9B;
-}
-
-.resolved::before {
- content: "Resolved";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-.inference {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #fff;
-}
-
-.inference::before {
- content: "Inference";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
-}
-
-.unamedconstraint {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #00f;
- background: #fff;
-}
-
-
-.unamedconstraint::before {
- content: "Constraint";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #00f;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-
-.constraint {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #00f;
- background: #fff;
-}
-
-.constraint[id]::before {
- content: "Constraint: " attr(id);
- width: 380px; /* How can we compute the length of "Constraint: " attr(id) */
-}
-
-
-.constraint::before {
- content: "Constraint";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #00f;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-
-.interpretation {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #00f;
- background: #fff;
-}
-
-.interpretation[id]::before {
- content: "Interpretation: " attr(id);
- width: 380px; /* How can we compute the length of "Interpretation: " attr(id) */
-}
-
-
-.interpretation::before {
- content: "Interpretation";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #00f;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-.deprecatedconstraint {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #00f;
- background: #fff;
-}
-
-.deprecatedconstraint[id]::before {
- content: "Deprecated: " attr(id);
- width: 380px; /* How can we compute the length of "Deprecatedconstraint: " attr(id) */
-}
-
-
-.deprecatedconstraint::before {
- content: "Deprecated";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #00f;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-
-.conditional {
- color: blue;
-}
-
-.grammar {
- margin-top: 1ex;
- margin-bottom: 1ex;
- padding-left: 1ex;
- padding-right: 1ex;
- padding-top: 1ex;
- padding-bottom: 0.6ex;
- border: 1px dashed #2f6fab;
-}
-.nonterminal {
- font-weight: bold;
- font-family: sans-serif;
- font-size: 95%;
-}
-
-.name {
- font-family: monospace;
-}
-
-
-.xmpl {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #fff;
-}
-
-.xmpl::before {
- content: "Example";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
-}
-
-.anexample:before {
- content: "Example:";
- font-family: sans-serif;
- font-size: 1.6ex;
- font-weight: bold;
-}
-.anexample {
- margin-top: 1ex;
- margin-bottom: 1ex;
- padding-left: 1ex;
- padding-right: 1ex;
- padding-top: 1ex;
- padding-bottom: 0.6ex;
- border: 1px dashed #2f6fab;
- background-color: #f9f9f9;
-}
-.anexample table {
- background-color: #f9f9f9;
-}
-
-div[class="grammar"] span[class="name"]:before {
- content: "'";
-}
-
-div[class="grammar"] span[class="name"]:after {
- content: "'";
-}
-
-
-div[class="grammar"] span[class="optional"]:before {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: "(";
-}
-
-div[class="grammar"] span[class="optional"]:after {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: ")?";
-}
-
-
-div[class="grammar"] span[class="plus"]:before {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: "(";
-}
-
-div[class="grammar"] span[class="plus"]:after {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: ")+";
-}
-
-
-div[class="grammar"] span[class="star"]:before {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: "(";
-}
-
-div[class="grammar"] span[class="star"]:after {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: ")*";
-}
-
-div[class="grammar"] span[class="group"]:before {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: "(";
-}
-
-div[class="grammar"] span[class="group"]:after {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: ")";
-}
Binary file model/wd2/informedByNonTransitive.png has changed
Binary file model/wd2/overview.png has changed
--- a/model/wd2/prov-dm.html Fri Dec 09 08:06:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,3932 +0,0 @@
-<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
-<html lang="en" dir="ltr">
-<head>
- <title>The PROV Data Model and Abstract Syntax Notation</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://www.w3.org/2007/OWL/toggles.js" class="remove"></script>
-
-
-
- <style type="text/css">
-/*****************************************************************
- * ReSpec CSS
- * Robin Berjon (robin at berjon dot com)
- * v0.05 - 2009-07-31
- *****************************************************************/
-
-
-/* --- INLINES --- */
-em.rfc2119 {
- text-transform: lowercase;
- font-variant: small-caps;
- font-style: normal;
- color: #900;
-}
-
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
- border: none;
-}
-
-dfn {
- font-weight: bold;
-}
-
-a.internalDFN {
- color: inherit;
- border-bottom: 1px solid #99c;
- text-decoration: none;
-}
-
-a.externalDFN {
- color: inherit;
- border-bottom: 1px dotted #ccc;
- text-decoration: none;
-}
-
-a.bibref {
- text-decoration: none;
-}
-
-code {
- color: #ff4500;
-}
-
-
-/* --- WEB IDL --- */
-pre.idl {
- border-top: 1px solid #90b8de;
- border-bottom: 1px solid #90b8de;
- padding: 1em;
- line-height: 120%;
-}
-
-pre.idl::before {
- content: "WebIDL";
- display: block;
- width: 150px;
- background: #90b8de;
- color: #fff;
- font-family: initial;
- padding: 3px;
- font-weight: bold;
- margin: -1em 0 1em -1em;
-}
-
-.idlType {
- color: #ff4500;
- font-weight: bold;
- text-decoration: none;
-}
-
-/*.idlModule*/
-/*.idlModuleID*/
-/*.idlInterface*/
-.idlInterfaceID, .idlDictionaryID {
- font-weight: bold;
- color: #005a9c;
-}
-
-.idlSuperclass {
- font-style: italic;
- color: #005a9c;
-}
-
-/*.idlAttribute*/
-.idlAttrType, .idlFieldType, .idlMemberType {
- color: #005a9c;
-}
-.idlAttrName, .idlFieldName, .idlMemberName {
- color: #ff4500;
-}
-.idlAttrName a, .idlFieldName a, .idlMemberName a {
- color: #ff4500;
- border-bottom: 1px dotted #ff4500;
- text-decoration: none;
-}
-
-/*.idlMethod*/
-.idlMethType {
- color: #005a9c;
-}
-.idlMethName {
- color: #ff4500;
-}
-.idlMethName a {
- color: #ff4500;
- border-bottom: 1px dotted #ff4500;
- text-decoration: none;
-}
-
-/*.idlParam*/
-.idlParamType {
- color: #005a9c;
-}
-.idlParamName {
- font-style: italic;
-}
-
-.extAttr {
- color: #666;
-}
-
-/*.idlConst*/
-.idlConstType {
- color: #005a9c;
-}
-.idlConstName {
- color: #ff4500;
-}
-.idlConstName a {
- color: #ff4500;
- border-bottom: 1px dotted #ff4500;
- text-decoration: none;
-}
-
-/*.idlException*/
-.idlExceptionID {
- font-weight: bold;
- color: #c00;
-}
-
-.idlTypedefID, .idlTypedefType {
- color: #005a9c;
-}
-
-.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
- color: #c00;
- font-weight: normal;
-}
-
-.excName a {
- font-family: monospace;
-}
-
-.idlRaises a.idlType, .excName a.idlType {
- border-bottom: 1px dotted #c00;
-}
-
-.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
- width: 45px;
- text-align: center;
-}
-.excGetSetTrue, .prmNullTrue, .prmOptTrue { color: #0c0; }
-.excGetSetFalse, .prmNullFalse, .prmOptFalse { color: #c00; }
-
-.idlImplements a {
- font-weight: bold;
-}
-
-dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
- margin-left: 2em;
-}
-
-.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
- font-weight: normal;
-}
-
-.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
- font-weight: bold;
- color: #000;
- font-family: monospace;
-}
-
-.attributes dt code, .fields dt code, .dictionary-members dt code {
- background: #ffffd2;
-}
-
-.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
- color: #005a9c;
- background: transparent;
- font-family: inherit;
- font-weight: normal;
- font-style: italic;
-}
-
-.methods dt code {
- background: #d9e6f8;
-}
-
-.constants dt code {
- background: #ddffd2;
-}
-
-.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
- margin-bottom: 1em;
-}
-
-table.parameters, table.exceptions {
- border-spacing: 0;
- border-collapse: collapse;
- margin: 0.5em 0;
- width: 100%;
-}
-table.parameters { border-bottom: 1px solid #90b8de; }
-table.exceptions { border-bottom: 1px solid #deb890; }
-
-.parameters th, .exceptions th {
- color: #fff;
- padding: 3px 5px;
- text-align: left;
- font-family: initial;
- font-weight: normal;
- text-shadow: #666 1px 1px 0;
-}
-.parameters th { background: #90b8de; }
-.exceptions th { background: #deb890; }
-
-.parameters td, .exceptions td {
- padding: 3px 10px;
- border-top: 1px solid #ddd;
- vertical-align: top;
-}
-
-.parameters tr:first-child td, .exceptions tr:first-child td {
- border-top: none;
-}
-
-.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
- width: 100px;
-}
-
-.parameters td.prmType {
- width: 120px;
-}
-
-table.exceptions table {
- border-spacing: 0;
- border-collapse: collapse;
- width: 100%;
-}
-
-/* --- TOC --- */
-.toc a {
- text-decoration: none;
-}
-
-a .secno {
- color: #000;
-}
-
-/* --- TABLE --- */
-table.simple {
- border-spacing: 0;
- border-collapse: collapse;
- border-bottom: 3px solid #005a9c;
-}
-
-.simple th {
- background: #005a9c;
- color: #fff;
- padding: 3px 5px;
- text-align: left;
-}
-
-.simple th[scope="row"] {
- background: inherit;
- color: inherit;
- border-top: 1px solid #ddd;
-}
-
-.simple td {
- padding: 3px 10px;
- border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
- background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
- margin-top: 0;
-}
-
-.section dd > p:last-child {
- margin-bottom: 0;
-}
-
-.section dd {
- margin-bottom: 1em;
-}
-
-.section dl.attrs dd, .section dl.eldef dd {
- margin-bottom: 0;
-}
-
-/* --- EXAMPLES --- */
-pre.example {
- border-top: 1px solid #ff4500;
- border-bottom: 1px solid #ff4500;
- padding: 1em;
- margin-top: 1em;
-}
-
-pre.example::before {
- content: "Example";
- display: block;
- width: 150px;
- background: #ff4500;
- color: #fff;
- font-family: initial;
- padding: 3px;
- font-weight: bold;
- margin: -1em 0 1em -1em;
-}
-
-/* --- EDITORIAL NOTES --- */
-.issue {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #ffc;
-}
-
-.issue::before {
- content: "Issue";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
-}
-
-.note {
- margin: 1em 0em 0em;
- padding: 1em;
- border: 2px solid #cff6d9;
- background: #e2fff0;
-}
-
-.note::before {
- content: "Note";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #cff6d9;
- background: #fff;
- padding: 3px 1em;
-}
-
-/* --- Best Practices --- */
-div.practice {
- border: solid #bebebe 1px;
- margin: 2em 1em 1em 2em;
-}
-
-span.practicelab {
- margin: 1.5em 0.5em 1em 1em;
- font-weight: bold;
- font-style: italic;
-}
-
-span.practicelab { background: #dfffff; }
-
-span.practicelab {
- position: relative;
- padding: 0 0.5em;
- top: -1.5em;
-}
-
-p.practicedesc {
- margin: 1.5em 0.5em 1em 1em;
-}
-
-@media screen {
- p.practicedesc {
- position: relative;
- top: -2em;
- padding: 0;
- margin: 1.5em 0.5em -1em 1em;
- }
-}
-
-/* --- SYNTAX HIGHLIGHTING --- */
-pre.sh_sourceCode {
- background-color: white;
- color: black;
- font-style: normal;
- font-weight: normal;
-}
-
-pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; } /* language keywords */
-pre.sh_sourceCode .sh_type { color: #666; } /* basic types */
-pre.sh_sourceCode .sh_usertype { color: teal; } /* user defined types */
-pre.sh_sourceCode .sh_string { color: red; font-family: monospace; } /* strings and chars */
-pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; } /* regular expressions */
-pre.sh_sourceCode .sh_specialchar { color: #ffc0cb; font-family: monospace; } /* e.g., \n, \t, \\ */
-pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; } /* comments */
-pre.sh_sourceCode .sh_number { color: purple; } /* literal numbers */
-pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; } /* e.g., #include, import */
-pre.sh_sourceCode .sh_symbol { color: blue; } /* e.g., *, + */
-pre.sh_sourceCode .sh_function { color: black; font-weight: bold; } /* function calls and declarations */
-pre.sh_sourceCode .sh_cbracket { color: red; } /* block brackets (e.g., {, }) */
-pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; } /* TODO and FIXME */
-
-/* Predefined variables and functions (for instance glsl) */
-pre.sh_sourceCode .sh_predef_var { color: #00008B; }
-pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }
-
-/* for OOP */
-pre.sh_sourceCode .sh_classname { color: teal; }
-
-/* line numbers (not yet implemented) */
-pre.sh_sourceCode .sh_linenum { display: none; }
-
-/* Internet related */
-pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }
-
-/* for ChangeLog and Log files */
-pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
-pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
-pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }
-
-/* for Prolog, Perl... */
-pre.sh_sourceCode .sh_variable { color: #006400; }
-
-/* for LaTeX */
-pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
-pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
-pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
-pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
-pre.sh_sourceCode .sh_argument { color: #006400; }
-pre.sh_sourceCode .sh_optionalargument { color: purple; }
-pre.sh_sourceCode .sh_math { color: orange; }
-pre.sh_sourceCode .sh_bibtex { color: blue; }
-
-/* for diffs */
-pre.sh_sourceCode .sh_oldfile { color: orange; }
-pre.sh_sourceCode .sh_newfile { color: #006400; }
-pre.sh_sourceCode .sh_difflines { color: blue; }
-
-/* for css */
-pre.sh_sourceCode .sh_selector { color: purple; }
-pre.sh_sourceCode .sh_property { color: blue; }
-pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }
-
-/* other */
-pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
-pre.sh_sourceCode .sh_paren { color: red; }
-pre.sh_sourceCode .sh_attribute { color: #006400; }
-
-/* --- EDITORIAL NOTES --- */
-.pending {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #BFEFFF;
-}
-
-.pending::before {
- content: "Pending Review";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-.resolved {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #9BCD9B;
-}
-
-.resolved::before {
- content: "Resolved";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-.inference {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #fff;
-}
-
-.inference::before {
- content: "Inference";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
-}
-
-.unamedconstraint {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #00f;
- background: #fff;
-}
-
-
-.unamedconstraint::before {
- content: "Constraint";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #00f;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-
-.constraint {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #00f;
- background: #fff;
-}
-
-.constraint[id]::before {
- content: "Constraint: " attr(id);
- width: 380px; /* How can we compute the length of "Constraint: " attr(id) */
-}
-
-
-.constraint::before {
- content: "Constraint";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #00f;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-
-.interpretation {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #00f;
- background: #fff;
-}
-
-.interpretation[id]::before {
- content: "Interpretation: " attr(id);
- width: 380px; /* How can we compute the length of "Interpretation: " attr(id) */
-}
-
-
-.interpretation::before {
- content: "Interpretation";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #00f;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-.deprecatedconstraint {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #00f;
- background: #fff;
-}
-
-.deprecatedconstraint[id]::before {
- content: "Deprecated: " attr(id);
- width: 380px; /* How can we compute the length of "Deprecatedconstraint: " attr(id) */
-}
-
-
-.deprecatedconstraint::before {
- content: "Deprecated";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #00f;
- background: #fff;
- padding: 3px 1em;
-}
-
-
-
-.conditional {
- color: blue;
-}
-
-.grammar {
- margin-top: 1ex;
- margin-bottom: 1ex;
- padding-left: 1ex;
- padding-right: 1ex;
- padding-top: 1ex;
- padding-bottom: 0.6ex;
- border: 1px dashed #2f6fab;
-}
-.nonterminal {
- font-weight: bold;
- font-family: sans-serif;
- font-size: 95%;
-}
-
-.name {
- font-family: monospace;
-}
-
-
-.xmpl {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #fff;
-}
-
-.xmpl::before {
- content: "Example";
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
-}
-
-.anexample:before {
- content: "Example:";
- font-family: sans-serif;
- font-size: 1.6ex;
- font-weight: bold;
-}
-.anexample {
- margin-top: 1ex;
- margin-bottom: 1ex;
- padding-left: 1ex;
- padding-right: 1ex;
- padding-top: 1ex;
- padding-bottom: 0.6ex;
- border: 1px dashed #2f6fab;
- background-color: #f9f9f9;
-}
-.anexample table {
- background-color: #f9f9f9;
-}
-
-div[class="grammar"] span[class="name"]:before {
- content: "'";
-}
-
-div[class="grammar"] span[class="name"]:after {
- content: "'";
-}
-
-
-div[class="grammar"] span[class="optional"]:before {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: "(";
-}
-
-div[class="grammar"] span[class="optional"]:after {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: ")?";
-}
-
-
-div[class="grammar"] span[class="plus"]:before {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: "(";
-}
-
-div[class="grammar"] span[class="plus"]:after {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: ")+";
-}
-
-
-div[class="grammar"] span[class="star"]:before {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: "(";
-}
-
-div[class="grammar"] span[class="star"]:after {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: ")*";
-}
-
-div[class="grammar"] span[class="group"]:before {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: "(";
-}
-
-div[class="grammar"] span[class="group"]:after {
- font-weight: normal;
- font-size:130%;
- font-family: monospace;
- content: ")";
-}
-
-</style>
-<link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css" charset="utf-8"></head>
- <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">The PROV Data Model and Abstract Syntax Notation</h1><h2 id="w3c-working-draft-08-december-2011"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 08 December 2011</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111208/">http://www.w3.org/TR/2011/WD-prov-dm-20111208/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html">http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018/">http://www.w3.org/TR/2011/WD-prov-dm-20111018/</a></dd><dt>Editors:</dt><dd><a href="http://www.ecs.soton.ac.uk/~lavm/">Luc Moreau</a>, University of Southampton</dd>
-<dd><a href="http://www.cs.ncl.ac.uk/people/Paolo.Missier">Paolo Missier</a>, Newcastle University</dd>
-<dt>Contributors:</dt><dd><a href="http://semanticweb.org/wiki/Khalid_Belhajjame">Khalid Belhajjame</a>, University of Manchester</dd>
-<dd><span>Stephen Cresswell</span>, legislation.gov.uk</dd>
-<dd><a href="http://www.isi.edu/~gil/">Yolanda Gil</a>, Invited Expert</dd>
-<dd><span>Ryan Golden</span>, Oracle Corporation</dd>
-<dd><a href="http://www.few.vu.nl/~pgroth/">Paul Groth</a>, VU University of Amsterdam</dd>
-<dd><span>Graham Klyne</span>, University of Oxford</dd>
-<dd><a href="http://tw.rpi.edu/web/person/JamesMcCusker">Jim McCusker</a>, Rensselaer Polytechnic Institute</dd>
-<dd><a href="http://www.inf.kcl.ac.uk/staff/simonm/">Simon Miles</a>, Invited Expert</dd>
-<dd><a href="http://www.rpi.edu/research/ccni/">James Myers</a>, Rensselaer Polytechnic Institute</dd>
-<dd><a href="http://cci.case.edu/cci/index.php/Satya_Sahoo">Satya Sahoo</a>, Case Western Reserve University</dd>
-</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
-
- <div id="abstract" class="introductory section"><h2>Abstract</h2>
-<p>
-PROV-DM is a data model for provenance for building
-representations of the entities, people and activities involved in
-producing a piece of data or thing in the world. PROV-DM is
-domain-agnotisc, but with well-defined extensibility points allowing
-further domain-specific and application-specific extensions to be
-defined. It is accompanied by PROV-ASN, a technology-independent
-abstract syntax notation, which allows serializations of PROV-DM
-instances to be created for human consumption, which facilitates its
-mapping to concrete syntax, and which is used as the basis for a
-formal semantics.
-</p>
- </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p>
-
-This document is part of a set of specifications aiming to define the various aspects that are necessary to achieve the visition on 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. Three other documents are: 1) a normative serialization of PROV-DM in RDF, specified by means of a mapping to the OWL2 Web Ontology Language; 2)
-the mechanisms for accessing and querying provenance; 3) a primer for the provenance data model.
-<p>This document was published by the <a href="http://www.w3.org/2011/prov/">Provenance Working Group</a> as a Working Draft. This document is intended to become a <acronym title="World Wide Web Consortium">W3C</acronym> Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-prov-wg@w3.org">public-prov-wg@w3.org</a> (<a href="mailto:public-prov-wg-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-prov-wg/">archives</a>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="http://www.w3.org/2004/01/pp-impl/46974/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction<br>
-</a><ul class="toc"><li class="tocline"><a href="#structure-of-this-document" class="tocxref"><span class="secno">1.1 </span>Structure of this Document</a></li><li class="tocline"><a href="#prov-dm-namespace" class="tocxref"><span class="secno">1.2 </span>PROV-DM Namespace</a></li><li class="tocline"><a href="#conventions" class="tocxref"><span class="secno">1.3 </span>Conventions</a></li></ul></li><li class="tocline"><a href="#preliminaries" class="tocxref"><span class="secno">2. </span>Preliminaries</a><ul class="toc"><li class="tocline"><a href="#conceptualization" class="tocxref"><span class="secno">2.1 </span>A Conceptualization of the World</a><ul class="toc"><li class="tocline"><a href="#section-entity-activity-agent" class="tocxref"><span class="secno">2.1.1 </span>Entity, Activity, Agent</a></li><li class="tocline"><a href="#section-time-event" class="tocxref"><span class="secno">2.1.2 </span>Time and Event</a><ul class="toc"><li class="tocline"><a href="#types-of-events" class="tocxref"><span class="secno">2.1.2.1 </span>Types of Events</a></li><li class="tocline"><a href="#event-ordering" class="tocxref"><span class="secno">2.1.2.2 </span>Event Ordering</a></li></ul></li></ul></li><li class="tocline"><a href="#prov-asn--the-provenance-abstract-syntax-notation" class="tocxref"><span class="secno">2.2 </span>PROV-ASN: The Provenance Abstract Syntax Notation</a></li><li class="tocline"><a href="#representation--assertion--and-inference" class="tocxref"><span class="secno">2.3 </span>Representation, Assertion, and Inference</a></li><li class="tocline"><a href="#grammar-notation" class="tocxref"><span class="secno">2.4 </span>Grammar Notation</a></li></ul></li><li class="tocline"><a href="#prov-dm-overview" class="tocxref"><span class="secno">3. </span>PROV-DM: An Overview </a></li><li class="tocline"><a href="#prov-dm-example" class="tocxref"><span class="secno">4. </span>Example</a><ul class="toc"><li class="tocline"><a href="#a-file-scenario" class="tocxref"><span class="secno">4.1 </span>A File Scenario</a></li><li class="tocline"><a href="#example-prov-asn-encoding" class="tocxref"><span class="secno">4.2 </span>Encoding using PROV-ASN</a></li><li class="tocline"><a href="#graphical-illustration" class="tocxref"><span class="secno">4.3 </span>Graphical Illustration</a></li></ul></li><li class="tocline"><a href="#data-model-concepts" class="tocxref"><span class="secno">5. </span>PROV-DM Core</a><ul class="toc"><li class="tocline"><a href="#PROV-DM-record" class="tocxref"><span class="secno">5.1 </span>Record</a></li><li class="tocline"><a href="#record-element" class="tocxref"><span class="secno">5.2 </span>Element</a><ul class="toc"><li class="tocline"><a href="#record-Entity" class="tocxref"><span class="secno">5.2.1 </span>Entity Record</a></li><li class="tocline"><a href="#record-Activity" class="tocxref"><span class="secno">5.2.2 </span>Activity Record</a></li><li class="tocline"><a href="#record-Agent" class="tocxref"><span class="secno">5.2.3 </span>Agent Record</a></li><li class="tocline"><a href="#record-note" class="tocxref"><span class="secno">5.2.4 </span>Note Record</a></li></ul></li><li class="tocline"><a href="#record-relation" class="tocxref"><span class="secno">5.3 </span>Relation</a><ul class="toc"><li class="tocline"><a href="#activity-entity-relation" class="tocxref"><span class="secno">5.3.1 </span>Activity-Entity Relation</a><ul class="toc"><li class="tocline"><a href="#record-Generation" class="tocxref"><span class="secno">5.3.1.1 </span>Generation Record</a></li><li class="tocline"><a href="#record-Usage" class="tocxref"><span class="secno">5.3.1.2 </span>Usage Record</a></li></ul></li><li class="tocline"><a href="#activity-agent-relation" class="tocxref"><span class="secno">5.3.2 </span>Activity-Agent Relation</a><ul class="toc"><li class="tocline"><a href="#record-ActivityAssociation" class="tocxref"><span class="secno">5.3.2.1 </span>Activity Association Record</a></li><li class="tocline"><a href="#record-Start-End" class="tocxref"><span class="secno">5.3.2.2 </span>Start and End Records</a></li></ul></li><li class="tocline"><a href="#entity-entity-agent-agent-relation" class="tocxref"><span class="secno">5.3.3 </span>Entity-Entity or Agent-Agent Relation</a><ul class="toc"><li class="tocline"><a href="#record-responsibility" class="tocxref"><span class="secno">5.3.3.1 </span>Responsibility Record</a></li><li class="tocline"><a href="#Derivation-Relation" class="tocxref"><span class="secno">5.3.3.2 </span>Derivation Record</a></li><li class="tocline"><a href="#record-complement-of" class="tocxref"><span class="secno">5.3.3.3 </span>Complementarity Record</a></li></ul></li><li class="tocline"><a href="#record-annotation" class="tocxref"><span class="secno">5.3.4 </span>Annotation Record</a></li></ul></li><li class="tocline"><a href="#bundle" class="tocxref"><span class="secno">5.4 </span>Bundle</a><ul class="toc"><li class="tocline"><a href="#record-Account" class="tocxref"><span class="secno">5.4.1 </span>Account Record</a></li><li class="tocline"><a href="#RecordContainer" class="tocxref"><span class="secno">5.4.2 </span>Record Container</a></li></ul></li><li class="tocline"><a href="#sub-record" class="tocxref"><span class="secno">5.5 </span>Further Terms in Records</a><ul class="toc"><li class="tocline"><a href="#record-attribute" class="tocxref"><span class="secno">5.5.1 </span>Attribute</a></li><li class="tocline"><a href="#record-identifier" class="tocxref"><span class="secno">5.5.2 </span>Identifier</a></li><li class="tocline"><a href="#record-literal" class="tocxref"><span class="secno">5.5.3 </span>Literal</a></li><li class="tocline"><a href="#record-Time" class="tocxref"><span class="secno">5.5.4 </span>Time</a></li><li class="tocline"><a href="#record-Asserter" class="tocxref"><span class="secno">5.5.5 </span>Asserter</a></li><li class="tocline"><a href="#record-NamespaceDeclaration" class="tocxref"><span class="secno">5.5.6 </span>Namespace Declaration</a></li><li class="tocline"><a href="#record-RecipeLink" class="tocxref"><span class="secno">5.5.7 </span>Recipe Link</a></li><li class="tocline"><a href="#record-Location" class="tocxref"><span class="secno">5.5.8 </span>Location</a></li></ul></li></ul></li><li class="tocline"><a href="#common-relations" class="tocxref"><span class="secno">6. </span>PROV-DM Common Relations</a><ul class="toc"><li class="tocline"><a href="#record-Collection" class="tocxref"><span class="secno">6.1 </span>Collections</a></li><li class="tocline"><a href="#record-traceability" class="tocxref"><span class="secno">6.2 </span>Traceability Record</a></li><li class="tocline"><a href="#record-OrderingOfActivities" class="tocxref"><span class="secno">6.3 </span>Activity Ordering Record</a></li><li class="tocline"><a href="#record-Revision" class="tocxref"><span class="secno">6.4 </span>Revision Record</a></li><li class="tocline"><a href="#attribution-record" class="tocxref"><span class="secno">6.5 </span>Attribution Record</a></li><li class="tocline"><a href="#quotation-record" class="tocxref"><span class="secno">6.6 </span>Quotation Record</a></li><li class="tocline"><a href="#summary-record" class="tocxref"><span class="secno">6.7 </span>Summary Record</a></li><li class="tocline"><a href="#original-source-record" class="tocxref"><span class="secno">6.8 </span>Original Source Record</a></li></ul></li><li class="tocline"><a href="#extensibility-section" class="tocxref"><span class="secno">7. </span>PROV-DM Extensibility Points</a></li><li class="tocline"><a href="#resource-section" class="tocxref"><span class="secno">8. </span>Resources, URIs, Entities, Identifiers, and Scope</a></li><li class="tocline"><a href="#changes-since-first-public-working-draft" class="tocxref"><span class="secno">A. </span>Changes Since First Public Working Draft</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">B. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></div>
-
-
-
-
-<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>
-
-
- <div id="introduction" class="section">
- <!--OddPage--><h2><span class="secno">1. </span>Introduction<br>
-</h2>
-
-<p>
-For the purpose of this specification, 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.
-In particular, the provenance of information is crucial in deciding
-whether information is to be trusted, how it should be integrated with
-other diverse information sources, and how to give credit to its
-originators when reusing it. In an open and inclusive environment
-such as the Web, users find information that is often contradictory or
-questionable: provenance can help those users to make trust judgments.
-</p>
-
-
-<p>
-The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
-Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it, process it, and reason over it.</p>
-
-<p>Thus, the vision is that different provenance-aware systems natively adopt their own model for representing their provenance, but a core provenance data model can be readily adopted as a provenance <em>interchange</em> model across such systems.</p>
-
-<p>A set of specifications define the various aspects
-that are necessary to achieve this vision in an inter-operable
-way, the first of which is contained in this document:</p>
-<ul>
-<li> The PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption; </li>
-<li> A normative serialization of PROV-DM in RDF [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-O">PROV-O</a></cite>], specified by means of a mapping to the OWL2 Web Ontology Language [<cite><a class="bibref" rel="biblioentry" href="#bib-OWL2-SYNTAX">OWL2-SYNTAX</a></cite>];</li>
-<li> The mechanisms for accessing and querying provenance [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PAQ">PROV-PAQ</a></cite>];</li>
-<li> A Primer for the PROV approach [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PRIMER">PROV-PRIMER</a></cite>].</li>
-</ul>
-
-
-<p>
-The PROV-DM data model for provenance consists of a set of core
-concepts, and a few common relations, based on these core concepts. PROV-DM is a domain-agnotisc model, but with well-defined extensibility points allowing further domain-specific and application-specific extensions to be defined.</p>
-
-<p>This specification also introduces
-PROV-ASN, an abstract syntax that is primarily aimed at human consumption. PROV-ASN allows
-serializations of PROV-DM instances to be written in a technology independent manner,
-it facilitates its mapping to concrete syntax, and it is used as the basis for a
-formal semantics. This specification uses instances of provenance written in PROV-ASN
-to illustrate the data model.
-</p>
-
- <div id="structure-of-this-document" class="section">
-<h3><span class="secno">1.1 </span>Structure of this Document</h3>
-
-<p>In <a href="#preliminaries">section 2</a>, a set of preliminaries are introduced, including concepts that underpin PROV-DM and motivations for the PROV-ASN notation.</p>
-
-<p><a href="#prov-dm-overview">Section 3</a> provides an overview of PROV-DM listing its core types and their relations.</p>
-
-<p>In <a href="#prov-dm-example">section 4</a>, PROV-DM is
-applied to a short scenario, encoded in PROV-ASN, and illustrated
-graphically.</p>
-
-<p><a href="#data-model-concepts">Section 5</a> provides the normative definition of PROV-DM and the notation PROV-ASN.</p>
-
-<p><a href="#common-relations">Section 6</a> introduces common relations used in PROV-DM, including relations for data collections and common domain-independent common relations.</p>
-
-<p><a href="#extensibility-section">Section 7</a> summarizes PROV-DM extensibility points.</p>
-
-<p><a href="#resource-section">Section 8</a> discusses how PROV-DM can be applied to the notion of resource.</p>
-
-
- </div>
-
-<div id="prov-dm-namespace" class="section">
- <h3><span class="secno">1.2 </span>PROV-DM Namespace</h3>
-
-
-<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
-
-<p> All the elements, relations, reserved names and attributes introduced in this specification belong to the PROV-DM namespace.</p>
-
-<div class="note">
-There is a desire to use a single namespace that all specs can share to refer to common provenance terms.
-</div>
-
-</div>
-
-
- <div id="conventions" class="section">
-<h3><span class="secno">1.3 </span>Conventions</h3>
-
-
-
-<p>The key words "<em class="rfc2119" title="must">must</em>", "<em class="rfc2119" title="must not">must not</em>", "<em class="rfc2119" title="required">required</em>", "<em class="rfc2119" title="shall">shall</em>", "<em class="rfc2119" title="shall
- not">shall
- not</em>", "<em class="rfc2119" title="should">should</em>", "<em class="rfc2119" title="should not">should not</em>", "<em class="rfc2119" title="recommended">recommended</em>", "<em class="rfc2119" title="may">may</em>", and
- "<em class="rfc2119" title="optional">optional</em>" in this document are to be interpreted as described in
- [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">RFC2119</a></cite>].</p>
- </div>
-
-</div>
-
-
-<div id="preliminaries" class="section">
-<!--OddPage--><h2><span class="secno">2. </span>Preliminaries</h2>
-
- <div id="conceptualization" class="section">
-<h3><span class="secno">2.1 </span>A Conceptualization of the World</h3>
-
-
-
- <div id="section-entity-activity-agent" class="section">
-<h4><span class="secno">2.1.1 </span>Entity, Activity, Agent</h4>
-
-
-
-
-<p>This specification is based on a conceptualization of the world
-that is described in this section. In the world (whether real or not),
-there are things, which can be physical, digital, conceptual, or
-otherwise, and activities involving things. </p>
-
-<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>Hence, to accommodate different perspectives on things and their situation in the world as perceived by us, we introduce the idea of a characterized thing, which refers to a thing and its situation in the world, as characterized by someone. We then define an <dfn id="concept-entity">entity</dfn> as an identifiable characterized thing. An entity <em>fixes some aspects</em> of a thing and its situation in the world, so that it becomes possible to express its provenance, and what causes these specific aspects to be as such. An alternative entity may fix other aspects, and its provenance may be different.</p>
-
-<div class="anexample">
-Different users may take different perspectives on a resource with
-a URL. These perspectives in this conceptualization of the world are
-referred to as entities. Three such entities may be
-expressed:
-<ul>
-<li>a report available at 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 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>
-
-<!--
-<div class='paolo'>can we follow through from the example. thare three perspectives, possibly by just one observer or multiple ones. but <strong>why is it so important for reporting provenance</strong> that this distinction is made? I feel we need to connect this approach to provenance recording strongly and right away</div>
--->
-
-<p>We do not assume that any characterization is more important than any other, and in fact, it is possible to describe the processing that occurred for the report to be commissioned, for individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity that characterizes the report appropriately.</p>
-
-<p>In the world, <dfn id="concept-activity">activities</dfn> involve
-entities in multiple ways: they consume them, they process them, they
-transform them, they modify them, they change them, they relocate
-them, they use them, they generate them, they are controlled by them,
-etc.</p>
-
-
-<p>An <dfn id="concept-agent">agent</dfn> is a type of entity that takes an active role in an activity such that it can be assigned some degree of responsibility for the activity taking place.
-This definition intentionally stays away from using concepts such as enabling, causing, initiating, affecting, etc, because any entities also enable, cause, initiate, and affect in some way the activities. So the notion of having some degree of responsibility is really what makes an agent. </p>
-
-<p> Even software agents can be assigned some responsibility for the effects they have in the world, so for example if one is using a Text Editor and one's laptop crashes, then one would say that the Text Editor was responsible for crashing the laptop. If one invokes a service to buy a book, that service can be considered responsible for drawing funds from one's bank to make the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well). So when someone models software as an agent for an activity in our model, they mean the agent has some responsibility for that activity.
-</p>
-<p> In this specification, the qualifier 'identifiable' is implicit whenever a reference is made to an activity, agent, or an entity.</p>
-
-</div>
-
-
- <div id="section-time-event" class="section">
-<h4><span class="secno">2.1.2 </span>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 in 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 instantaneous event, 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-CSP">CSP</a></cite>], events represent communications or interactions; they are assumed to be atomic and instantaneous.</p>
-
-
-
-
-<div id="types-of-events" class="section">
-<h5><span class="secno">2.1.2.1 </span>Types of Events</h5>
-
-<p>Four kinds of events 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 href="#dfn-event" class="internalDFN">event</a> that marks the final instant of an entity's creation timespan, after which it becomes available for use.</p>
-
-<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the first instant of an entity's consumption timespan by an activity.</p>
-
-<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the instant an activity starts.</p>
-
-<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the instant an activity ends.</p>
-
-</div>
-
-<div id="event-ordering" class="section">
-<h5><span class="secno">2.1.2.2 </span>Event Ordering</h5>
-
-<p>To allow for minimalistic clock assumptions, like Lamport
-[<cite><a class="bibref" rel="biblioentry" href="#bib-CLOCK">CLOCK</a></cite>], PROV-DM relies on a notion of relative ordering of <a title="event" href="#dfn-event" class="internalDFN">events</a>,
-without using physical clocks. This specification assumes that a partial order exists between <a title="event" href="#dfn-event" class="internalDFN">events</a>.
-</p>
-
-
-<p>Specifically, <dfn id="dfn-follows">follows</dfn> is a partial
-order between <a title="event" href="#dfn-event" class="internalDFN">events</a>, indicating that an <a href="#dfn-event" class="internalDFN">event</a> occurs after another.
-For symmetry, <dfn id="dfn-precedes">precedes</dfn> is defined as
-the inverse of follows. </p>
-
-
-<p> How such partial order is realized in practice is beyond the scope
-of this specification. This specification only assumes that
-each <a href="#dfn-event" class="internalDFN">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 href="#dfn-follows" class="internalDFN">follows</a> and <a href="#dfn-precedes" class="internalDFN">precedes</a> correspond to some ordering
-over this timeline.
-</p>
-
-
-<p>This specification introduces a set of "temporal interpretation"
-rules allowing to derive <a href="#dfn-event" class="internalDFN">event</a> ordering constraints from
-provenance records. According to such temporal interpretation,
-provenance records <em class="rfc2119" title="must">must</em> satisfy such constraints. We note that the
-actual verification of such temporal constraints is also outside the
-scope of this specification. </p>
-
-<p>PROV-DM also allows for time observations to be inserted in specific
-provenance records, for each recognized <a href="#dfn-event" class="internalDFN">event</a> introduced
-in this specification. The presence of a time observation for a
-given <a href="#dfn-event" class="internalDFN">event</a> fixes the mapping of this <a href="#dfn-event" class="internalDFN">event</a> to the
-timeline. It can also help with the verification of associated
-temporal constraints (though, again, this verification is outside the
-scope of this specfication).
-
-</p>
-
-
-
-</div>
-
- </div>
-
- </div>
-
- <div id="prov-asn--the-provenance-abstract-syntax-notation" class="section">
-<h3><span class="secno">2.2 </span>PROV-ASN: The Provenance Abstract Syntax Notation</h3>
-
-<p>This specification defines PROV-DM, a data model for provenance, consisting of records describing how people, entities, and activities, were involved in producing,
-influencing, or delivering a piece of data or a thing in the world.</p>
-
-<p>This specification also relies on a language, PROV-ASN, the Provenance Abstract Syntax Notation, to express
-<em>instances</em> of that data model.
-For each construct of PROV-DM, a corresponding ASN expression is introduced, by way of a production in the ASN grammar. </p>
-
-
-
-
-
-<p>PROV-ASN is an abstract syntax, whose goals are:
-</p><ul>
-<li>to allow serializations of PROV-DM instances in a technology independent manner, which makes it more readable for human consumption;
-</li><li>to facilitate the mapping of PROV-DM to concrete syntax;
-</li><li>to provide the basis for a formal semantics.
-</li></ul>
-
-<p>This specification provides a grammar for PROV-ASN. Each record of the PROV-DM data model is explained
-in terms of the production of this grammar.</p>
-
-
-
-<p>The formal semantics of PROV-DM is defined at
-[<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-SEMANTICS">PROV-SEMANTICS</a></cite>] and its encoding in the OWL2 Web Ontology Language at [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-O">PROV-O</a></cite>].
-</p>
-
-
-
-
-
-
- </div>
-
- <div id="representation--assertion--and-inference" class="section">
-<h3><span class="secno">2.3 </span>Representation, Assertion, and Inference</h3>
-
-<p>
-PROV-DM is a provenance data model designed to express <em>representations</em> of the world.
-</p>
-
-<div class="anexample">
-A file at some point during its lifecycle, which includes multiple edits by multiple people, can be represented by its location in the file system, a creator, and content.
-</div>
-
-
-<p>
-These representations are relative to an asserter, and in that sense constitute assertions stating properties of the world, as represented by an asserter. Different asserters will normally contribute different representations.
-This specification does not define a notion of consistency between different sets of assertions (whether by the same asserter or different asserters).
-The data model provides the means to associate attribution to assertions.
-</p>
-
-<div class="anexample">
-An alternative representation of the above file is a set of blocks in a hard disk.
-</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 assertions <em class="rfc2119" title="should">should</em> be interpreted as a record of what has happened, as opposed to what may or will happen.</p>
-
-
-
-<p>
-This specification does not prescribe the means by which an asserter arrives at assertions; for example, assertions can be composed on the basis of observations, reasoning, or any other means.
-</p>
-
-
-<p>
-Sometimes, inferences about the world can be made from representations
-conformant to the PROV-DM data model. When this is the case, this
-specification defines such inferences, allowing new provenance records
-to be inferred from existing ones. Hence, representations of the world
-can result either from direct assertions by asserters or from
-application of inferences defined by this specification.
-</p>
-
-
-
-</div>
- <div id="grammar-notation" class="section">
-<h3><span class="secno">2.4 </span>Grammar Notation</h3>
-
-<p>This specification includes a grammar for PROV-ASN expressed using the Extended Backus-Naur Form (EBNF) notation.</p>
-
-<div class="grammar">
-<p> Each rule in the grammar defines one symbol, in the form:</p>
-<p>
-<span class="nonterminal">E</span> ::= <em>expression</em>
-</p>
-
-
-Within the expression on the right-hand side ofa rule, the follwoing expressions are used to match strings of one or more characters:
-<ul>
-<li>
-<span class="nonterminal">E</span>: matches term satisfying rule for symbol E.
-</li>
-
-<li>
-<span class="name">abc</span>: matches the literal string inside the single quotes.
-</li>
-
-
-<li>
-<span class="optional"><em>expression</em></span>: matches <em>expression</em> or nothing; optional <em>expression</em>.
-</li>
-
-<li>
-<span class="plus"><em>expression</em></span>: matches one or more occurrences of <em>expression</em>.
-</li>
-
-<li>
-<span class="star"><em>expression</em></span>: matches zero or more occurrences of <em>expression</em>.
-</li>
-
-</ul>
-</div>
-
-</div>
-</div>
-
- <div id="prov-dm-overview" class="section">
-<!--OddPage--><h2><span class="secno">3. </span>PROV-DM: An Overview </h2>
-
-<p>
-The following ER diagram provides a high level overview of the <strong>structure of PROV-DM records</strong>. Examples of provenance assertions that conform to this schema are provided in the next section.</p>
-
-<div style="text-align: center;">
- <img src="overview.png" alt="PROV-DM overview">
-</div>
-
-<div class="note"> Overview diagram does not represent the sub-relations -- proposal to use a UML notation instead of ER.</div>
-
-
-<p>The model includes the following elements:</p>
-<ul>
- <li>An <a title="entity record" href="#dfn-entity" class="internalDFN">Entity Record</a> (noted <samp>entity</samp> in the diagram, to reflect the term used in the ASN) is a representation of an <em>entity</em>.
-
- </li><li>An <a title="activity record" href="#dfn-activity" class="internalDFN">Activity Record</a>(noted <samp>activity</samp> in the diagram) represents an activity that has an effect on entities, namely it either <em>generates</em> or <em>uses</em> one or more entities. Usage and generation are modelled by means of the <a title="usage record" href="#dfn-Use" class="internalDFN">used</a> and the <a title="generation record" href="#dfn-Generation" class="internalDFN">wasGeneratedBy</a> relationships. Activities may include not only computations, but also any other type of activity that can be described in terms of their effect on <samp>entities</samp>.
-Note that multiple <samp>activities</samp> may <em>use</em> the same <samp>entity</samp>, and each activity may use multiple <samp>entities</samp>. Finally, entities can be derived from other entities, and this is specified using the <a title="derivation record" href="#dfn-Derivation" class="internalDFN">wasDerivedFrom</a> relation.</li>
-
- <li>An <a title="agent record" href="#dfn-Agent" class="internalDFN">Agent Record</a> represents a particular <samp>entity</samp> that can be associated to activities, meaning that it can be assigned some degree of responsibility for an <samp>activity</samp> taking place.
- Agents have a rather generic connotation: their association with an activity is represented by the <a title="activity association record" href="#dfn-activity-association" class="internalDFN">wasAssociatedWith</a> relationship, which can take up various meanings (attribution, responsibility, supervision, management, etc.), which are not individually specified in the model. Relations <a title="start record" href="#dfn-Start" class="internalDFN">wasStartedBy</a> and <a title="end record" href="#dfn-End" class="internalDFN">wasEndedBy</a> are specializations of <a title="activity association record" href="#dfn-activity-association" class="internalDFN">wasAssociatedWith</a> that can optionally be used to carry additional meaning. Furthermore, it is recognized that agents can act on behalf of others: hence, the relation <a title="responsibility record" href="#dfn-responsibility" class="internalDFN">actedOnBehalfOf</a> allows for chains of responsibility to be stated.
-</li>
-
-
-
-</ul>
-
-<p> A set of attribute-value pairs can be associated to elements and relations of the PROV model in order to further characterize
-their nature.
-The <a title="complementarity record" href="#complementOf" class="internalDFN">wasComplementOf</a> relationship is used to denote that two <samp>entities</samp> <em>complement</em> each other, in the sense that they each represent a partial, but mutually compatible characterization of the same thing.
-The attributes <a title="prov:role" href="#dfn-role" class="internalDFN">role</a> and <a title="prov:type" href="#dfn-type" class="internalDFN">type</a> are pre-defined.
-</p>
-
-
-<p>The set of relations presented here forms a core, which is further extended with additional relations, defined in Section <a href="#common-relations">Common Relations</a>.</p>
-
-
-<p>
-The model includes a further additional element: <a title="note record" href="#dfn-note" class="internalDFN">notes</a>. These are also structured as sets of attribute-value pairs. Notes are used to provide additional, "free-form" information regarding <em>any</em> identifiable construct of the model, with no prescribed meaning. Notes are described in detail <a href="#record-note">here</a>.
-</p>
-
-<p>
-Attributes and notes are the main <em>extensibility points</em> in the model: individual interest groups are expected to extend PROV-DM by introducing new attributes and notes as needed to address applications-specific provenance modelling requirements. </p>
-
-</div>
-
-
- <div class="informative section" id="prov-dm-example">
-<!--OddPage--><h2><span class="secno">4. </span>Example</h2><p><em>This section is non-normative.</em></p>
-
-<div class="issue"> There is a suggestion that a better example should be adopted for this document. Possibly, several shorter examples. This is <a href="http://www.w3.org/2011/prov/track/issues/132">ISSUE-132</a></div>
-
-
-To illustrate PROV-DM, this section presents an example encoded according to PROV-ASN. For more detailed explanations of how PROV-DM should be used, and for more examples, we refer the reader to the Provenance Primer [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PRIMER">PROV-PRIMER</a></cite>].
-
-
-
-
-
-<div class="pending">Comments on section 3.2. This is <a href="http://www.w3.org/2011/prov/track/issues/71">ISSUE-71</a></div>
-
- <div id="a-file-scenario" class="section">
-<h3><span class="secno">4.1 </span>A File Scenario</h3>
-
-
-<p>This scenario is concerned with the evolution of a crime statistics
-file (referred to as e0) stored on a shared file system and which
-journalists Alice, Bob, Charles, David, and Edith can share and
-edit. We consider various <a title="event" href="#dfn-event" class="internalDFN">events</a> in the evolution of file e0;
-<a title="event" href="#dfn-event" class="internalDFN">events</a> listed below follow each other, unless otherwise specified.</p>
-
-
-
-<p>
-<a href="#dfn-event" class="internalDFN">Event</a> evt1: Alice creates (a0) an empty file in /share/crime.txt. We denote this file e1.
-</p>
-
-<p>
-<a href="#dfn-event" class="internalDFN">Event</a> evt2: Bob appends (a1) the following line to /share/crime.txt:</p>
-<pre>There was a lot of crime in London last month.
-</pre>
-<p>We denote the revised file e2.</p>
-
-<p><a href="#dfn-event" class="internalDFN">Event</a> evt3: Charles emails (a2) the contents of /share/crime.txt, as an
-attachment, which we refer to as e4. (We specifically refer to a copy of the file that is uploaded on the mail server.)
-</p>
-
-<p>
-<a href="#dfn-event" class="internalDFN">Event</a> evt4: David edits (a3) file /share/crime.txt as follows.</p>
-<pre>There was a lot of crime in London and New-York last month.
-</pre>
-<p>
-We denote the revised file e3.
-</p>
-
-<p><a href="#dfn-event" class="internalDFN">Event</a> evt5: Edith emails (a4) the contents of /share/crime.txt as an attachment, referred to as e5.
-</p>
-
-<p><a href="#dfn-event" class="internalDFN">Event</a> evt6: between <a title="event" href="#dfn-event" class="internalDFN">events</a> evt4 and evt5, someone (unspecified) runs a spell checker (a5) on the file /share/crime.txt.
- The file after spell checking is referred to as e6.
-</p>
-
-</div>
-
- <div id="example-prov-asn-encoding" class="section">
-<h3><span class="secno">4.2 </span>Encoding using PROV-ASN</h3>
-
-In this section, the example is encoded according to the provenance data model (specified in section <a href="#data-model-concepts">PROV-DM: The Provenance Data Model</a>) and expressed in PROV-ASN.
-<p>
-Entity Records (described in <a href="#record-Entity">Section Entity</a>). The file in its various forms and its copies are modelled as entity records, corresponding to multiple characterizations, as per scenario. The entity records are identified by <span class="name">e0</span>, ..., <span class="name">e6</span>.</p>
-<pre>entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
-entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
-entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London last month."])
-entity(e3, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month."])
-entity(e4)
-entity(e5)
-entity(e6, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month.", ex:spellchecked="yes"])
-</pre>
-
-
-
-<p>These entity records list attributes that have been given values during intervals delimited by <a title="event" href="#dfn-event" class="internalDFN">events</a>; such intervals are referred to as <em>characterization intervals</em>. The following table lists all entity identifiers and their corresponding characterization intervals. When the end of the characterization interval is not delimited by an <a href="#dfn-event" class="internalDFN">event</a> described in this scenario, it is marked by "...".</p>
-<blockquote>
-<table>
-<tbody><tr><td>Entity</td><td>Characterization Interval</td></tr>
-<tr><td>e0</td><td>evt1 - ...</td></tr>
-<tr><td>e1</td><td>evt1 - evt2</td></tr>
-<tr><td>e2</td><td>evt2 - evt4</td></tr>
-<tr><td>e3</td><td>evt4 - ...</td></tr>
-<tr><td>e4</td><td>evt3 - ...</td></tr>
-<tr><td>e5</td><td>evt5 - ...</td></tr>
-<tr><td>e6</td><td>evt6 - ... </td></tr>
-</tbody></table>
-</blockquote>
-
-
-
-<p>
-Activity Records (described in <a href="#record-Activity">Section Activity</a>) represent activities in the scenario.</p>
-<pre>activity(a0, create-file, 2011-11-16T16:00:00,)
-activity(a1, add-crime-in-london, 2011-11-16T16:05:00,)
-activity(a2, email, 2011-11-16T17:00:00,)
-activity(a3, edit-London-New-York, 2011-11-17T09:00:00,)
-activity(a4, email, 2011-11-17T09:30:00,)
-activity(a5, spellcheck,,)
-</pre>
-
-
-<p>
-Generation Records (described in <a href="#record-Generation">Section Generation</a>) represent the <a href="#dfn-event" class="internalDFN">event</a> at which a file is created in a specific form. Attributes are used to describe the modalities according to which a given entity is generated by a given activity. The interpretation of attributes is application specific. Illustrations of such attributes for the scenario are: no attribute is provided for <span class="name">e0</span>;
-<span class="name">e2</span> was generated by the editor's save function; <span class="name">e4</span> can be found on the smtp port, in the attachment section of the mail message; <span class="name">e6</span> was produced on the standard output of <span class="name">a5</span>. Two identifiers <span class="name">g1</span> and <span class="name">g2</span> identify the generation records referenced in derivations introduced below.</p>
-<pre>wasGeneratedBy(e0, a0)
-wasGeneratedBy(e1, a0, [ex:fct="create"])
-wasGeneratedBy(e2, a1, [ex:fct="save"])
-wasGeneratedBy(e3, a3, [ex:fct="save"])
-wasGeneratedBy(g1, e4, a2, [ex:port="smtp", ex:section="attachment"])
-wasGeneratedBy(g2, e5, a4, [ex:port="smtp", ex:section="attachment"])
-wasGeneratedBy(e6, a5, [ex:file="stdout"])
-</pre>
-
-
-
-<p>
-Usage Records (described in <a href="#record-Usage">Section Usage</a>) represent the <a href="#dfn-event" class="internalDFN">event</a> by which a file is read by an activity.
-
-Likewise, attributes describe the modalities according to which the various entities are used by activities. Illustrations of such attributes are:
-<span class="name">e1</span> is used in the context of <span class="name">a1</span>'s <span class="name">load</span> functionality; <span class="name">e2</span> is used by <span class="name">a2</span> in the context of its attach functionality; <span class="name">e3</span> is used on the standard input by <span class="name">a5</span>. Two identifiers <span class="name">u1</span> and <span class="name">u2</span> identify the Usage records referenced in derivations introduced below.</p>
-<pre>used(a1,e1,[ex:fct="load"])
-used(a3,e2,[ex:fct="load"])
-used(u1,a2,e2,[ex:fct="attach"])
-used(u2,a4,e3,[ex:fct="attach"])
-used(a5,e3,[ex:file="stdin"])
-</pre>
-
-
-<p>
-Derivation Records (described in <a href="#Derivation-Relation">Section Derivation Relation</a>) express that an entity is derived from another. The first two are expressed in their compact version, whereas the following two are expressed in their full version, including the activity underpinning the derivation, and associated usage (<span class="name">u1</span>, <span class="name">u2</span>) and generation (<span class="name">g1</span>, <span class="name">g2</span>) records.</p>
-<pre>wasDerivedFrom(e2,e1)
-wasDerivedFrom(e3,e2)
-wasDerivedFrom(e4,e2,a2,g1,u1)
-wasDerivedFrom(e5,e3,a4,g2,u2)
-</pre>
-
-
-
-<p>
-wasComplementOf: (this relation is described in <a href="#record-complement-of">Section wasComplementOf</a>). The crime statistics file (<span class="name">e0</span>) has various contents over its existence (<span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span>); the entity records identified by <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span> complement <span class="name">e0</span> with an attribute <span class="name">content</span>. Likewise, the one denoted by <span class="name">e6</span> complements the record denoted by <span class="name">e3</span> with an attribute <span class="name">spellchecked</span>.</p>
-<pre>wasComplementOf(e1,e0)
-wasComplementOf(e2,e0)
-wasComplementOf(e3,e0)
-wasComplementOf(e6,e3)
-</pre>
-
-
-
-<p>
-Agent Records (described at <a href="#record-Agent">Section Agent</a>): the various users are represented as agents, themselves being a type of entity.</p>
-<pre>agent(ag1, [ prov:type="prov:Person" %% xsd:QName, ex:name="Alice" ])
-
-agent(ag2, [ prov:type="prov:Person" %% xsd:QName, ex:name="Bob" ])
-
-agent(ag3, [ prov:type="prov:Person" %% xsd:QName, ex:name="Charles" ])
-
-agent(ag4, [ prov:type="prov:Person" %% xsd:QName, ex:name="David" ])
-
-agent(ag5, [ prov:type="prov:Person" %% xsd:QName, ex:name="Edith" ])
-</pre>
-
-
-
-<p>
-Activity Assocation Records (described in <a href="#record-ActivityAssociation">Section Activity Association</a>): the association of an agent with an activity is expressed with , and the nature of this association is described by attributes. Illustrations of such attributes include the role of the participating agent, as creator, author and communicator (role is a reserved attribute in PROV-DM).</p>
-<pre>wasAssociatedWith(a0, ag1, [prov:role="creator"])
-wasAssociatedWith(a1, ag2, [prov:role="author"])
-wasAssociatedWith(a2, ag3, [prov:role="communicator"])
-wasAssociatedWith(a3, ag4, [prov:role="author"])
-wasAssociatedWith(a4, ag5, [prov:role="communicator"])
-</pre>
-</div>
-
-
- <div id="graphical-illustration" class="section">
-<h3><span class="secno">4.3 </span>Graphical Illustration</h3>
-
-
-<p>
-Provenance assertions can be <em>illustrated</em> graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of provenance assertions. Therefore, it cannot be seen as an alternate notation for expressing provenance.</p>
-
-<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and half-hexagonal shapes, respectively. Usage, Generation, Derivation, Activity Association, and Complementarity are represented as directed edges.</p>
-
-<p>Entities are layed out according to the ordering of their generation event. We endeavor to show time progressing from left to right. This means that edges for Usage, Generation and Derivation typically point from right to left.</p>
-
-
-<div style="text-align: center;">
-<img src="example-graphical.png" alt="example">
-</div>
-<br>
-<div style="text-align: center;">
-<img src="timeline.png" alt="example">
-</div>
-</div>
-
-</div>
-
-
-
-<div id="data-model-concepts" class="section">
-
-<!--OddPage--><h2><span class="secno">5. </span>PROV-DM Core</h2>
-
-<p>This section contains the normative specification of PROV-DM core, the core of the PROV data model.</p>
-
-<div class="note">
-In a next iteration of this document, it is proposed to reorganize
-section 5 as follows. First, the presentation of the data model
-alone. Second, its temporal interpretation. Third, the constraints and
-inferences associated with well-formed accounts.
-</div>
-
- <div id="PROV-DM-record" class="section">
-
-<h3><span class="secno">5.1 </span>Record</h3>
-
-<p>PROV-DM consists of a set of constructs, referred to as <em>records</em>, to formulate representations of the world and constraints that must be satisfied by them.</p>
-
-<p>
-Furthermore, PROV-DM includes a "house-keeping construct", a record container,
- used to wrap PROV-DM records and facilitate their interchange.</p>
-
-<p>In PROV-ASN, such representations of the world <em class="rfc2119" title="must">must</em> be conformant with the toplevel production <span class="nonterminal">record</span> of the grammar. These <span class="nonterminal">record</span>s are grouped in three categories:
-<span class="nonterminal">elementRecord</span> (see section <a href="#record-element">Element</a>),
-<span class="nonterminal">relationRecord</span> (see section <a href="#record-relation">Relation</a>), and
-<span class="nonterminal">accountRecord</span> (see section <a href="#record-Account">Account</a>).</p>
-
-
-<div class="grammar">
-<span class="nonterminal">record</span> ::=
-<span class="nonterminal">elementRecord</span>
-| <span class="nonterminal">relationRecord</span>
-| <span class="nonterminal">accountRecord</span>
-<br>
-<!-- -->
-<br>
-<span class="nonterminal">elementRecord</span> ::=
-<span class="nonterminal">entityRecord</span>
-| <span class="nonterminal">activityRecord</span>
-| <span class="nonterminal">agentRecord</span>
-| <span class="nonterminal">noteRecord</span> <br>
-<!-- -->
-<br>
-<span class="nonterminal">relationRecord</span> ::=
-<span class="nonterminal">generationRecord</span>
-| <span class="nonterminal">usageRecord</span>
-| <span class="nonterminal">derivationRecord</span>
-| <span class="nonterminal">activityAssociationRecord</span>
-| <span class="nonterminal">responsibilityRecord</span>
-| <span class="nonterminal">startRecord</span>
-| <span class="nonterminal">endRecord</span>
-| <span class="nonterminal">complementRecord</span>
-| <span class="nonterminal">annotationRecord</span>
-</div>
-
-
-<p>In PROV-ASN, a record container is compliant with the production <span class="nonterminal">recordContainer</span> (see section <a href="#RecordContainer">Record Container</a>). </p>
-
-</div>
-
- <div id="record-element" class="section">
-<h3><span class="secno">5.2 </span>Element</h3>
-
-<p>This section describes all the PROV-DM records referred to as element records. (They are conformant to the <span class="nonterminal">elementRecord</span> production of the grammar.)</p>
-
-
-
- <div id="record-Entity" class="section">
-
-<h4><span class="secno">5.2.1 </span>Entity Record</h4>
-
-<p>In PROV-DM, an <dfn id="dfn-entity">entity record</dfn> is a representation of an entity.</p>
-
-
-<p>Examples of entities include a linked data set, a sparse-matrix matrix of floating-point numbers, a document in a directory, the same document published on the Web, and meta-data embedded in a document.</p>
-
-<p>An entity record, noted <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> identifying an entity; the identifier of the entity record is defined to be the same as the identifier of the entity; </li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this entity's situation in the world.</li>
-</ul>
-
-
-<p>
-The assertion of an entity record, <span class="name">entity(id, [ attr1=val1, ...])</span>, states, from a given asserter's viewpoint, the existence of an entity, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two <a title="event" href="#dfn-event" class="internalDFN">events</a> in the world.
-</p>
-
-<p>
-In PROV-ASN, an entity record's text matches the <span class="nonterminal">entityRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class="grammar">
-<span class="nonterminal">entityRecord</span> ::=
-<span class="name">entity</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br><br>
-<!-- -->
-<span class="nonterminal">optional-attribute-values</span> ::=
-<span class="optional"><span class="name">,</span>
-<span class="name">[</span>
-<span class="nonterminal">attribute-values</span>
-<span class="name">]</span>
-</span><br>
-<span class="nonterminal">attribute-values</span> ::=
-<span class="nonterminal">attribute-value</span>
-| <span class="nonterminal">attribute-value</span> <span class="name">,</span> <span class="nonterminal">attribute-values</span>
-<br>
-<span class="nonterminal">attribute-value</span> ::=
-<span class="nonterminal">attribute</span>
-<span class="name">=</span>
-<span class="nonterminal">Literal</span>
-<br>
-</div>
-
-<div class="anexample">
-<p>
-The following entity record,</p>
-<pre class="codeexample">entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
-</pre>
-states the existence of an entity, denoted by identifier <span class="name">e0</span>, with type <span class="name">File</span> and path <span class="name">/shared/crime.txt</span> in the file system, and creator alice The attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span class="name">type</span> is reserved in the PROV-DM namespace.
-</div>
-
-Further considerations:
-<ul>
-<li>If an asserter wishes to characterize an entity with the same attribute-value pairs over several intervals, then they are required to assert multiple entity records, each with its own identifier (so as to allow potential dependencies between the various entity records to be expressed). </li>
-
-<li>There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.</li>
-
-<li>A characterization interval may collapse into a single instant.</li>
-
-<li>An entity assertion
- is about a thing, whose situation in the world may be variant.
- An entity record is asserted at a particular point and is invariant, in the sense that
-its attributes are given a value as part of that assertion.
-</li>
-
-<li>Activities are not represented by entity records, but instead by activity records, as explained below.</li>
-</ul>
-
-
-
-
-
-
-<div class="note">The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define wasComplementOf more precisely. It would also allow us to address
-<a href="http://www.w3.org/2011/prov/track/issues/108">ISSUE-108</a>.
-Beginning and end of characterization interval could be expressed by attributes (similarly to activities). </div>
-
-
-
-
- </div>
-
- <div id="record-Activity" class="section">
-
-<h4><span class="secno">5.2.2 </span>Activity Record</h4>
-<p>In PROV-DM, an <dfn id="dfn-activity">activity record</dfn> is a representation of an identifiable activity, which performs a piece of work.</p>
-
-
-<p>An activity, represented by an activity record, is delimited by its <a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a> and its <a title="activity end event" href="#dfn-end-event" class="internalDFN">end</a> events; hence, it occurs over an interval delimited by two <a title="event" href="#dfn-event" class="internalDFN">events</a>. However, an activity record need not mention time information, nor duration, because they may not be known.</p>
-
-<p>Such start and end times constitute <em>attributes</em> of an activity, where the interpretation of attribute in the context of an activity record is the same as the interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the world can be represented by other attribute-value pairs, which <em class="rfc2119" title="must">must</em> also remain unchanged during the activity duration.</p>
-
-<p>
-Examples of activities include assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a sparql query over a triple store, editing a file, and publishing a web page. </p>
-
-<p> An activity record, written <span class="name">activity(id, rl, st, et, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> identifying an activity; the identifier of the activity record is defined to be the same as the identifier of the activity;</li>
-<li><em>recipeLink</em>: an <em class="rfc2119" title="optional">optional</em> <a href="#record-RecipeLink">recipe link</a> <span class="name">rl</span>, which consists of a domain specific specification of the activity;</li>
-<li><em>startTime</em>: an <em class="rfc2119" title="optional">optional</em> time <span class="name">st</span> indicating the start of the activity;</li>
-<li><em>endTime</em>: an <em class="rfc2119" title="optional">optional</em> time <span class="name">et</span> indicating the end of the activity;</li>
-<li><em>attributes</em>: a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole duration.</li>
-</ul>
-
-<p>In PROV-ASN, an activity record's text matches the <span class="nonterminal">activityRecord</span> production of the grammar defined in this specification document.</p>
-
-
-
-<div class="grammar">
-<span class="nonterminal">activityRecord</span> ::=
-<span class="name">activity</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="optional"><span class="name">,</span>
-<span class="nonterminal">recipeLink</span> </span>
-<span class="name">,</span>
-<span class="optional"><span class="nonterminal">time</span></span>
-<span class="name">,</span>
-<span class="optional"><span class="nonterminal">time</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br>
-</div>
-
-<div class="anexample">
-<p>
-The following activity assertion</p>
-<pre class="codeexample">activity(a1,add-crime-in-london,2011-11-16T16:05:00,2011-11-16T16:06:00,[ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
-</pre>
-<p>identified by identifier <span class="name">a1</span>, states the existence of an activity with recipe link <span class="name">add-crime-in-london</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix <span class="name">ex</span>). The attribute <span class="name">host</span> is application specific, but <em class="rfc2119" title="must">must</em> hold for the duration of activity. The attribute <span class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
-</div>
-
-<p>The mere existence of an activity assertion entails some <a href="#dfn-event" class="internalDFN">event</a> ordering in the world, since an <a href="#dfn-start-event" class="internalDFN">activity start event</a> always <a href="#dfn-precedes" class="internalDFN">precedes</a> the corresponding <a href="#dfn-end-event" class="internalDFN">activity end event</a>. This is expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
-
-<div class="interpretation" id="start-precedes-end"> The following temporal constraint holds for any activity record: the
-<a title="activity start event" href="#dfn-start-event" class="internalDFN">start event</a> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end event</a>.</div>
-
-<p>An activity record is not an entity record.
-Indeed, an entity record represents an entity that exists in full at
-any point in its characterization interval, persists during this
-interval, and preserves the characteristics that makes it
-identifiable. Alternatively, an activity in 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-Logic">Logic</a></cite>].</p>
-
-
-</div>
-
-<div id="record-Agent" class="section">
-<h4><span class="secno">5.2.3 </span>Agent Record</h4>
-
-
-
-<p>An <dfn id="dfn-Agent">agent record</dfn> is a representation of an agent, which is an entity that can be assigned some degree of responsibility for an activity taking place.</p>
-
-<p>Many agents can have an association with a given activity. An agent may do the ordering of the activity, another agent may do its design, another agent may push the button to start it, another agent may run it, etc.
-As many agents as one wishes to mention can occur in the provenance record, if it is important to indicate that they were associated with the activity. </p>
-
-<p>
-From an inter-operability perspective, it is useful to define some basic categories of agents since
-it will improve the use of provenance records by applications.
-There should be very few of these basic categories to keep the model simple and accessible.
-There are three types of agents in the model:
-</p><ul>
-<li><span class="name">Person</span>: agents of type Person are people. (This type is equivalent to a "foaf:person" [<cite><a class="bibref" rel="biblioentry" href="#bib-FOAF">FOAF</a></cite>])</li>
-<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc. (This type is equivalent to a "foaf:organization" [<cite><a class="bibref" rel="biblioentry" href="#bib-FOAF">FOAF</a></cite>])</li>
-<li><span class="name">SoftwareAgent</span>: a software agent is a piece of software. </li>
-</ul>
-<p>These types are mutually exclusive, though they do not cover all kinds of agent. </p>
-
-<p>An agent record, noted <span class="name">agent(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> identifying an agent; the identifier of the agent record is defined to be the same as the identifier of the agent;</li>
-<li><em>attributes</em>: contains a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this agent's situation in the world.</li>
-</ul>
-
-<p>In PROV-ASN, an agent record's text matches the <span class="nonterminal">agentRecord</span> production of the grammar defined in this specification document.
-</p>
-
-
-<div class="grammar">
-<span class="nonterminal">agentRecord</span> ::=
-<span class="name">agent</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-
-
-<div class="anexample">
-<p>With the following assertions,</p>
-<pre class="codeexample">agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Person" %% xsd:QName])
-
-entity(e2) and wasStartedBy(a1,e2,[prov:role="author"])
-
-entity(e3) and wasAssociatedWith(a1,e3,[prov:role="sponsor"])
-</pre>
-<p>the agent record identified by <span class="name">e1</span> is an explicit agent assertion that holds irrespective of activities it may be associated with. On the other hand, from the entity records identified by <span class="name">e2</span> and <span class="name">e3</span>, one can infer agent records, as per the following inference.</p>
-</div>
-
-<p>One can assert an agent record or alternatively, one can infer an agent record
-by its association with an activity. </p>
-
-<div class="constraint" 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>
-
- <div id="record-note" class="section">
-
-<h4><span class="secno">5.2.4 </span>Note Record</h4>
-
-<p>As provenance records are exchanged between systems, it may be useful to add extra-information about such records. For instance, a "trust service" may add value-judgements about the trustworthiness of some of the assertions made. Likewise, an interactive visualization component may want to enrich a set of provenance records with information helping reproduce their visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing any identifiable record to be associated with notes.</p>
-
-<p>An <dfn id="dfn-note">note record</dfn> is a set of attribute-value pairs, whose meaning is application specific. It may or may not be a representation of something in the world.</p>
-
-<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
-</p>
-
-
-<div class="grammar">
-<span class="nonterminal">noteRecord</span> ::=
-<span class="name">note</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">attribute-values</span>
-<span class="name">)</span><br>
-<!-- -->
-</div>
-
-<p>A separate PROV-DM record is used to associate a note with an identifiable record (see <a href="#record-annotation">Section on annotation</a>). A given note may be associated with multiple records.
-</p>
-
-
-<div class="anexample">
-<p>
-The following note record</p>
-<pre class="codeexample">note(ann1,[ex:color="blue", ex:screenX=20, ex:screenY=30])
-</pre>
-<p>consists of a set of application-specific attribute-value pairs, intended
-to help the rendering of the record it is associated with, by
-specifying its color and its position on the screen. In this example,
-these attribute-value pairs do not constitute a representation of something
-in the world; they are just used to help render provenance.
-</p>
-</div>
-
-<p>
-Attribute-value pairs occurring in notes differ from attribute-value pairs occurring in entity records and activity records. In entity and activity records, attribute-value pairs <em class="rfc2119" title="must">must</em> be a representation of something in the world, which remain constant for the duration of the characterization interval (for entity record) or the activity duration (for activity records). In note records, it is <em class="rfc2119" title="optional">optional</em> for attribute-value pairs to be representations of something in the world. If they are a representation of something in the world, then it <em class="rfc2119" title="may">may</em> change value for the corresponding duration. If attribute-value pairs of a note record are a representation of something in the world that does not change, they are not regarded as determining characteristics of an entity or activity, for the purpose of provenance.
-</p>
-
-
- </div>
-
-</div>
-
-
-<div id="record-relation" class="section">
-<h3><span class="secno">5.3 </span>Relation</h3>
-
-<p>This section describes all the PROV-DM records representing relations between the elements introduced in <a href="#record-element">Section Element</a>. While these relations are not binary, they all involve two primary elements. They can be summarized as follows. </p>
-
-
-<div style="text-align: center;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption>PROV-DM Core Relation Summary</caption>
-<tbody><tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Note</td></tr>
-<tr><td>Entity</td><td><a title="derivation record" href="#dfn-Derivation" class="internalDFN">wasDerivedFrom</a><br><a title="complementarity record" href="#complementOf" class="internalDFN">wasComplementOf</a></td><td><a title="generation record" href="#dfn-Generation" class="internalDFN">wasGeneratedBy</a></td><td>-</td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
-<tr><td>Activity</td><td><a title="usage record" href="#dfn-Use" class="internalDFN">used</a></td><td>-</td><td><a title="start record" href="#dfn-Start" class="internalDFN">wasStartedBy</a><br><a title="end record" href="#dfn-End" class="internalDFN">wasEndedBy</a><br><a title="activity association record" href="#dfn-activity-association" class="internalDFN">wasAssociatedWith</a></td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
-<tr><td>Agent</td><td>-</td><td>-</td><td><a title="responsibility record" href="#dfn-responsibility" class="internalDFN">actedOnBehalfOf</a></td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
-<tr><td>Note</td><td>-</td><td>-</td><td>-</td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
-</tbody></table>
-</div>
-
-
-<p>In PROV-ASN, all these relation records are conformant to the <span class="nonterminal">relationRecord</span> production of the grammar.</p>
-
-<div id="activity-entity-relation" class="section">
-<h4><span class="secno">5.3.1 </span>Activity-Entity Relation</h4>
-
-<div id="record-Generation" class="section">
-<h5><span class="secno">5.3.1.1 </span>Generation Record</h5>
-
-
-<p>In PROV-DM, a <dfn id="dfn-Generation">generation record</dfn> is a representation of a world <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">event</a>, the creation of a new entity by an activity. This entity did not exist before creation.
-The representation of this <a href="#dfn-event" class="internalDFN">event</a> encompasses a description of the modalities of generation of this entity by this activity.</p>
-
-<p>A <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation event</a> may be, for example, the creation of a file by a program, the creation of a linked data set, the production of a new version of a document, and the sending of a value on a communication channel.</p>
-
-<p>A generation record, written <span class="name">wasGeneratedBy(id,e,a,attrs,t)</span> in PROV-ASN, has the following components:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the generation record;</li>
-<li><em>entity</em>: an identifier <span class="name">e</span> identifying an entity record that represents the entity that is created; </li>
-<li><em>activity</em>: an identifier <span class="name">a</span> identifying an activity record that represents the activity that creates the entity;</li>
-
-<li><em>time</em>: an <em class="rfc2119" title="optional">optional</em> "generation time" <span class="name">t</span>, the time at which the entity was created;</li>
-
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describes the modalities of generation of this entity by this activity.</li>
-
-</ul>
-
-<p>In PROV-ASN, a generation record's text matches the <span class="nonterminal">generationRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class="grammar">
-<span class="nonterminal">generationRecord</span> ::=
-<span class="name">wasGeneratedBy</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>
-<span class="name">,</span> </span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="optional"><span class="name">,</span>
-<span class="nonterminal">time</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br>
-</div>
-
-
-<p>
-A generation record's id is <em class="rfc2119" title="optional">optional</em>. It <em class="rfc2119" title="must">must</em> be used when annotating generation records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).
-</p>
-
-
-<div class="anexample">
-<p>
-The following generation assertions</p>
-<pre class="codeexample"> wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1", ex:order=1])
- wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p1", ex:order=2])
-</pre>
-<p>state the existence of two <a title="event" href="#dfn-event" class="internalDFN">events</a> in the world (with respective times <span class="name">2001-10-26T21:32:52</span> and <span class="name">2001-10-26T10:00:00</span>), at which new entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an activity, itself represented by an activity record identified by <span class="name">a1</span>.
-The first one is available as the first value on port p1, whereas the other is the second value on port p1. The semantics of <span class="name">port</span> and <span class="name">order</span> in these records are application specific.
-</p>
-</div>
-
-
-
-<p>The assertion of a generation record implies ordering of <a title="event" href="#dfn-event" class="internalDFN">events</a> in the world.</p>
-
-
-<div class="interpretation" id="generation-activity-ordering"><span class="conditional">If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class="conditional">then</span> the following temporal constraint also holds: the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation</a> of the entity denoted by <span class="name">x</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end</a>
-of <span class="name">a</span> and <a href="#dfn-follows" class="internalDFN">follows</a> the <a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a> of <span class="name">a</span>.
-</div>
-
-
-
-<p>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
-The rationale for this constraint is as follows.
-If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation events</a>, then they generate distinct entities. Alternatively, for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This unicity constraint is formalized as follows.
-
-</p><div class="constraint" id="generation-unicity">Given an entity record denoted by <span class="name">e</span>, two activity records 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> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given account,
-<span class="conditional">then</span> <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
-</div>
-
-<div class="note">TODO: Introduce the well-formed-ness constraint in a entirely separate section.</div>
-
-
-</div>
-
-
-<div id="record-Usage" class="section">
-<h5><span class="secno">5.3.1.2 </span>Usage Record</h5>
-
-
-
-<p>In PROV-DM, a <dfn id="dfn-Use">usage record</dfn> is a representation of a world <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">event</a>: the consumption of an entity by an activity. The representation includes a description of the modalities of usage of this entity by this activity.</p>
-
-<p>
-A <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usage event</a> may be the consumption of a parameter by a procedure, the reading of a value on a port by a service, the reading of a configuration file by a program, or the adding of an ingredient, such as eggs, in a baking activity. Usage may entirely consume an entity (e.g. eggs are not longer available after being added to the mix), or leave it as such, ready for further uses (e.g. a file on a file system can be read indefinitely).</p>
-
-
-<p>A usage record, written <span class="name">used(id,a,e,attrs,t)</span> in PROV-ASN, has the following constituent:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the usage record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record, which represents the consuming activity;</li>
-<li><em>entity</em>: an identifier <span class="name">e</span> for an entity record, which represents the entity that is consumed;</li>
-<li><em>time</em>: an <em class="rfc2119" title="optional">optional</em> "usage time" <span class="name">t</span>, the time at which the entity was used;</li>
-<li><em>attributes</em>: an OPTIONIAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of usage of this entity by this activity;</li>
-</ul>
-
-<p>In PROV-ASN, a usage record's text matches the <span class="nonterminal">usageRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class="grammar">
-<span class="nonterminal">usageRecord</span> ::=
-<span class="name">used</span>
-<span class="name">(</span>
-<span class="optional">
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="optional">
-<span class="name">,</span>
- <span class="nonterminal">time</span>
-</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br>
-</div>
-
-
-<p>
-A usage record's id is <em class="rfc2119" title="optional">optional</em>, but comes handy when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining derivations.
-</p>
-
-
-<div class="anexample">
-<p>The following usage records</p>
-<pre class="codeexample"> used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"])
- used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])
-</pre>
-<p>state that the activity, represented by the activity record identified by <span class="name">a1</span>, consumed two entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, at times <span class="name">2011-11-16T16:00:00</span> and <span class="name">2011-11-16T16:00:01</span>, respectively; the first one was found as the value of parameter <span class="name">p1</span>, whereas the second was found as value of parameter <span class="name">p2</span>. The semantics of <span class="name">parameter</span> in these records is application specific.</p>
-</div>
-
-
-
-
-
-<p>
-A usage record's id is <em class="rfc2119" title="optional">optional</em>. It <em class="rfc2119" title="must">must</em> be present when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).</p>
-
-<p>
-A reference to a given entity record <em class="rfc2119" title="may">may</em> appear in multiple usage records that share
- a given activity record identifier.
-</p>
-
-
-
-
-
-<div class="interpretation" id="usage-generation-ordering">For any entity, the following temporal constraint holds: the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation</a> of an entity always <a href="#dfn-precedes" class="internalDFN">precedes</a> any of its <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usages</a>.
-</div>
-
-
-<div class="interpretation" id="usage-activity-ordering">Given an activity record identified by <span class="name">a</span>, an entity record identified by <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 temporal constraint holds:
- the <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usage</a> of the entity represented by entity record identified by <span class="name">e</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end</a> of activity represented by record identified by <span class="name">a</span> and <a href="#dfn-follows" class="internalDFN">follows</a> its <a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a>.
-</div>
-
-
-
-
-<div class="issue">Should we define a taxonomy of use? This is <a href="http://www.w3.org/2011/prov/track/issues/23">ISSUE-23</a>.</div>
-
-</div>
-</div>
-
-
-
-
-
-<div id="activity-agent-relation" class="section">
-<h4><span class="secno">5.3.2 </span>Activity-Agent Relation</h4>
-
-<div id="record-ActivityAssociation" class="section">
-<h5><span class="secno">5.3.2.1 </span>Activity Association Record</h5>
-
-<p>The key purpose of agents in PROV-DM is to assign responsibility
-for activities. It is important to reflect that there is a degree in
-the responsibility of agents, and that is a major reason for
-distinguishing among all the agents that have some association with an
-activity and determine which ones are really the originators of the
-entity. For example, a programmer and a researcher could both be
-associated with running a workflow, but it may not matter what
-programmer clicked the button to start the workflow while it would
-matter a lot what researcher told the programmer to do so. Another
-example: a student publishing a web page describing an academic
-department could result in both the student and the department being
-agents associated with the activity, and it may not matter what
-student published a web page but it matters a lot that the department
-told the student to put up the web page. So there is some notion of
-responsibility that needs to be captured. </p>
-
-<p>To this end, PROV-DM offers two kinds of records. The first, introduced in this section, represents an association between an agent and an activity; the second, introduced in <a href="#record-responsibility">Section Responsibility record</a>, represents the fact that an agent was acting on behalf of another, in the context of an activity. </p>
-
-<p>Examples of activity association include designing, participation, initiation and termination, timetabling or sponsoring. </p>
-
-<p>An <dfn id="dfn-activity-association">activity association record</dfn>, written <span class="name">wasAssociatedWith(a,ag2,attrs)</span> in PROV-ASN, has the following constituents:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the activity association record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record;</li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of association of this activity with this agent;</li>
-<li><em>agent</em>: an identifier <span class="name">ag2</span> for an agent record, which represents the agent associated with the activity.</li>
-
-</ul>
-
-<p>In PROV-ASN, an activity association record's text matches the <span class="nonterminal">activityAssociationRecord</span> productions of the grammar defined in this specification document.</p>
-
-<div class="grammar">
-<span class="nonterminal">activityAssociationRecord</span> ::=
-<span class="name">wasAssociatedWith</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">aIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class="anexample">
-In the following example, a programmer and a researcher agents are asserted to be associated with an activity.
-<pre class="codeexample">activity(a,[prov:type="workflow"])
-agent(ag1,[prov:type="programmer"])
-agent(ag2,[prov:type="researcher"])
-wasAssociatedWith(a,ag1,[prov:role="loggedInUser", ex:how="webapp"])
-wasAssociatedWith(a,ag2,[prov:role="designer", ex:context="phd"])
-</pre>
-</div>
-
-
-
-</div>
-
-<div id="record-Start-End" class="section">
-<h5><span class="secno">5.3.2.2 </span>Start and End Records</h5>
-
-<p> A <dfn id="dfn-Start">start record</dfn> is a representation of an agent starting an activity.
- An <dfn id="dfn-End">end record</dfn> is a representation of an agent ending an activity. Both relations are specialized forms of <span class="name">wasAssociatedWith</span>. They contain attributes describing the modalities of acting/ending activities.</p>
-
-
-
-<p>A start record, written <span class="name">wasStartedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the start record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the started activity;
-</li><li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the starting agent;
-</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent started the activity.
-</li></ul>
-
-<p>An end record, written <span class="name">wasEndedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the end record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the ended activity;
-</li><li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the ending agent;
-</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent ended the activity.
-</li></ul>
-
-<p>In PROV-ASN, start and end record's texts match the <span class="nonterminal">startRecord</span> and <span class="nonterminal">endRecord</span> productions of the grammar defined in this specification document.
-</p>
-
-
-<div class="grammar">
-<span class="nonterminal">startRecord</span> ::=
-<span class="name">wasStartedBy</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">aIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br>
-<span class="nonterminal">endRecord</span> ::=
-<span class="name">wasEndedBy</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">aIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-<div class="anexample">
-<p>
-The following assertions</p>
-<pre class="codeexample">wasStartedBy(a,ag,[ex:mode="manual"])
-wasEndedby(a,ag,[ex:mode="manual"])
-</pre>
-<p>state that the activity, represented by the activity record denoted by <span class="name">a</span>
-was started and ended by an agent, represented by record denoted by <span class="name">ah</span>, in "manual" mode, an application specific characterization of these relations.
-</p>
-</div>
-</div>
-
-<div class="note">Temporal constraints for these relations remain to be
-written. The temporal constraints should ensure that the agent started
-its existence before the effect it may have on the activity. </div>
-
-
-
-<!--
-
-<section id="record-Participation">
-<h4>Participation Record</h4>
-
-<p>A <dfn id="dfn-Participation">participation record</dfn> is a representation of the involvement of an entity in an activity. A participation record can be asserted or inferred.</p>
-
-
-<p>In PROV-ASN, a participation record's text matches the <span class="nonterminal">participationRecord</span> production of the grammar defined in this specification document.</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">participationRecord</span> ::=
-<span class="name">hadParticipant</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">identifier</span>
-<span class="name">)</span>
-</div>
-
-
-
-<p> A participation record,
-written <span class="name">hadParticipant(pe,e)</span> in PROV-ASN:
-<ul>
-<li> contains to identifier <span class="name">pe</span> identifying an activity record representing an activity;
-<li> contains an identifier <span class="name">e</span> identifying an entity record, which is
-a representation of an entity involved in this activity.
-</ul>
-
-<p>An entity's participation in an activity can be by direct usage or direct control. But also, if an entity and situation are characterized in two complementary manners (and are represented by two entity records related by <span class="name">isComplementOf</span>), if one of them participates in an activity, so does the other. The following captures the definition of participation.</p>
-
-<div class='constraint' id='participation'>
-Given two identifiers <span class="name">pe</span> and <span class="name">e</span>, respectively identifying an activity record and an entity record, the record <span class="name">hadParticipant(pe,e)</span> holds <span class='conditional'>if and only if</span>:
-<ul>
-<li> <span class="name">used(pe,e)</span> holds, or</li>
-<li> <span class="name">wasControlledBy(pe,e)</span> holds, or</li>
-<li> <span class="name">wasComplementOf(e1,e)</span> holds for some entity record identified by <span class="name">e1</span>, and
- <span class="name">hadParticipant(pe,e1)</span> holds some activity record identified by <span class="name">pe</span>.</li>
-</ul>
-</div>
-
-
-<div class='pending'>Suggested definition for participation. This is <a href="http://www.w3.org/2011/prov/track/issues/49">ISSUE-49</a>.</div>
-
-</section>
-
--->
-
-</div>
-
-<div id="entity-entity-agent-agent-relation" class="section">
-<h4><span class="secno">5.3.3 </span>Entity-Entity or Agent-Agent Relation</h4>
-
-<div id="record-responsibility" class="section">
-
-<h5><span class="secno">5.3.3.1 </span>Responsibility Record</h5>
-
-<p>To promote take-up, PROV-DM offers a mild version of responsibility
-in the form of a relation to represent when an agent acted on another
-agent's behalf. So in the example of someone running a mail program,
-the program is an agent of that activity and the person is also an
-agent of the activity, but we would also add that the mail software
-agent is running on the person's behalf. In the other example, the
-student acted on behalf of his supervisor, who acted on behalf of the
-department chair, who acts on behalf of the university, and all those
-agents are responsible in some way for the activity to take place but
-we don't say explicitly who bears responsibility and to what
-degree. </p>
-
-<p>We could also say that an agent can act on behalf of several other
-agents (a group of agents). This would also make possible to
-indirectly reflect chains of responsibility. This also indirectly
-reflects control without requiring that control is explicitly
-indicated. In some contexts there will be a need to represent
-responsibility explicitly, for example to indicate legal
-responsibility, and that could be added as an extension to this core
-model. Similarly with control, since in particular contexts there
-might be a need to define specific aspects of control that various
-agents exert over a given activity.</p>
-
-<p>Given an activity association record <span class="name">wasAssociatedWith(a,ag2,attrs)</span>,
-a <dfn id="dfn-responsibility">responsibility record</dfn>, written <span class="name">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-ASN, has the following constituents:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the responsibility record;</li>
-<li><em>subordinate</em>: an identifier <span class="name">ag2</span> for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible agent;</li>
-<li><em>responsible</em>: an identifier <span class="name">ag1</span> for an agent record, which represents the agent on behalf of which the subordinate agent <span class="name">ag2</span> acts;</li>
-<li><em>activity</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">a</span> of an activity record for which the responsibility record holds;</li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this relation.</li>
-</ul>
-
-
-<div class="grammar">
-<span class="nonterminal">responsibilityRecord</span> ::=
-<span class="name">actedOnBehalfOf</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">agIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>,
-<span class="optional"><span class="nonterminal">aIdentifier</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class="anexample">
-In the following example, a programmer, a researcher and a funder agents are asserted. The porgrammer and researcher are associated with a workflow activity. The programmer acts on behalf of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher.
-<pre class="codeexample">activity(a,[prov:type="workflow"])
-agent(ag1,[prov:type="programmer"])
-agent(ag2,[prov:type="researcher"])
-agent(ag3,[prov:type="funder"])
-wasAssociatedWith(a,ag1,[prov:role="loggedInUser"])
-wasAssociatedWith(a,ag2)
-actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])
-actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
-</pre>
-</div>
-
-
-</div>
-
-<div id="Derivation-Relation" class="section">
-<h5><span class="secno">5.3.3.2 </span>Derivation Record</h5>
-
-<p>In PROV-DM, a <dfn id="dfn-Derivation">derivation record</dfn> is a representation that some entity is transformed from, created from, or affected by another entity in the world. </p>
-
-
-<p>Examples of derivation include the transformation of a canvas into a painting, the transportation of a person from London to New-York, the transformation of a relational table into a linked data set, and the melting of ice into water.</p>
-
-
-<p>According to <a href="#conceptualization">Section Conceptualization</a>, for an entity to be transformed from, created from, or affected by another in some way, there must be some underpinning activities performing the necessary actions resulting in such a derivation.
-However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or less precise records of derivation to be asserted. Hence, PROV-DM uses the terms <em>precise</em> and <em>imprecise</em> to characterize the different kinds of derivation record. We note that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation record, that may be imprecise. </p>
-
-<p>The lack of precision may come from two sources:</p>
-<ul>
-<li> the number of activities that underpin a derivation is not asserted or known, or</li>
-<li> any of the other details that are involved in the derivation is not asserted or known; these include activity identities, generation and usage records, and their attributes.</li>
-</ul>
-
-
-<!--
-Furthermore, assuming that an asserter has full knowledge of an activity underpinning a derivation, the same activity can generally be modelled in terms of sub-activities, composed in a such a way as to deliver the same behavior. Hence, since activities can be modelled at arbitrary levels of granularity, there is a distinguished case in which a derivation between two entities <span class="name">e2</span> and <span class="name">e1</span> corresponds <em>exactly</em> to <em>one</em> activity that used <span class="name">e1</span> and generated <span class="name">e2</span>. This is to be contrasted to the case where one derivation corresponds to n activities, where n can be any number greater than 1.
-Hence, PROV-DM uses the terms <em>one-activity</em> and <em>n-activities</em> to distinguish these two cases.</p>
--->
-
-
-<p>Hence, given a precision axis, with values <em>precise</em> and <em>imprecise</em>, and an activity axis, with values <em>one activity</em> and <em>n activities</em>, we can then form a matrix of possible derivations, precise or imprecise, or corresponding to one activity or n activities.
-Out of the four possibilities, PROV-DM offers three forms of derivation, while the fourth one is not meaningful. The following table summarises names for the three kinds of derivation, which we then explain.</p>
-
-<div style="text-align: center;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption>PROV-DM Derivation Type Summary</caption>
-<tbody><tr><td colspan="2" rowspan="2"></td><td colspan="2">precision axis</td></tr>
-<tr><td>precise</td><td>imprecise</td></tr>
-<tr><td rowspan="2">activity<br>axis</td><td>one activity</td><td><a href="#dfn-precise-1-derivation-record" class="internalDFN">precise-1 derivation record</a></td><td><a href="#dfn-imprecise-1-derivation-record" class="internalDFN">imprecise-1 derivation record</a></td></tr>
-<tr><td>n activities</td><td>---</td><td><a href="#dfn-imprecise-n-derivation-record" class="internalDFN">imprecise-n derivation record</a></td></tr>
-</tbody></table>
-</div>
-
-<ul>
-<li> The asserter asserts that derivation is due to exactly one activity, and all the details are asserted. We call this a precise-1 derivation record.</li>
-<li> The asserter asserts that derivation is due to exactly one activity, but other details, whether known or unknown, are not asserted. We call this an imprecise-1 derivation record.</li>
-<li> The asserter does not know how many activities are involved in the derivation, and other details, whether known or unknown, are also not asserted. We call this an imprecise-n derivation record.</li>
-</ul>
-
-<p> We note that the fourth theoretical case of a precise derivation, where the number of activities is not known or asserted cannot occur. </p>
-
-
-<p>The three kinds of derivation records are successively introduced. To minimize the number of relation types in PROV-DM, we introduce a PROV-DM reserved attribute <span class="name">steps</span>, which allows us to distinguish the various derivation types. </p>
-
-<p>A <dfn id="dfn-precise-1-derivation-record">precise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the derivation record;</li>
-<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
-<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> of an activity record, which is a representation of the activity using and generating the above entities;</li>
-<li><em>generation</em>: an identifier <span class="name">g2</span> of the generation record pertaining to <span class="name">e2</span> and <span class="name">a</span>;</li>
-<li><em>usage</em>: an identifier <span class="name">u1</span> of the usage record pertaining to <span class="name">e1</span> and <span class="name">a</span>.</li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation, optionally including the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
-</ul>
-<p>It is <em class="rfc2119" title="optional">optional</em> to include the attribute <span class="name">prov:steps</span> in a precise-1 derivation since the record already refers to the one and only one activity underpinning the derivation.</p>
-
-
-<p>An <dfn id="dfn-imprecise-1-derivation-record">imprecise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2,e1, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the derivation record;</li>
-<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
-<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
-<li><em>attributes</em>: a set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it <em class="rfc2119" title="must">must</em> include the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
-</ul>
-<p>An imprecise-1 derivation <em class="rfc2119" title="must">must</em> include the attribute <span class="name">prov:steps</span>, since it is the only means to distinguish this record from an imprecise-n derivation record.</p>
-
-
-<p>An <dfn id="dfn-imprecise-n-derivation-record">imprecise-n derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the derivation record;</li>
-<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
-<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity.</li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it optionally includes the attribute-value pair <span class="name">prov:steps="n"</span>.</li>
-</ul>
-<p>It is <em class="rfc2119" title="optional">optional</em> to include the attribute <span class="name">prov:steps</span> in an imprecise-n derivation record. It defaults to <span class="name">prov:steps="n"</span>.</p>
-
-
-<p>None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property holds.</p>
-
-
-<p>In PROV-ASN, a derivation record's text matches the <span class="nonterminal">derivationRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class="grammar">
-<span class="nonterminal">derivationRecord</span> ::=
-<span class="nonterminal">precise-1-derivationRecord</span>
-| <span class="nonterminal">imprecise-1-derivationRecord</span>
-| <span class="nonterminal">imprecise-n-derivationRecord</span><br>
-<br>
-<span class="nonterminal">precise-1-derivationRecord</span> ::=
-<span class="name">wasDerivedFrom</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">gIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">uIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br>
-<span class="nonterminal">imprecise-1-derivationRecord</span>::=
-<span class="name">wasDerivedFrom</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">attribute-values</span>
-<span class="name">)</span>
-<br>
-<span class="nonterminal">imprecise-n-derivationRecord</span>::=
-<span class="name">wasDerivedFrom</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-<div class="note">
-The grammar should make it clear that attribute <span class="name">prov:steps="1"</span> is required for imprecise-1-derivationRecord.<br>
- PM: suggestion -- remove the distinction between imprecise-1 and imprecise-n in the grammar and instead explain that the qualification (1 vs n) is through attribute prov:steps.
-</div>
-
-<div class="anexample">
-<p>The following assertions state the existence of derivations.</p>
-<pre class="codeexample">wasDerivedFrom(e5,e3,a4,g2,u2,[])
-wasDerivedFrom(e5,e3,a4,g2,u2,[prov:steps="1"])
-
-wasDerivedFrom(e3,e2,[prov:steps="1"])
-
-wasDerivedFrom(e2,e1,[])
-wasDerivedFrom(e2,e1,[prov:steps="n"])
-</pre>
-<p>
-The first two are precise-1 derivation records expressing that the activity represented by the activity <span class="name">a4</span>, by
-using the entity denoted by <span class="name">e3</span> according to usage record <span class="name">u2</span>
- derived the
-entity denoted by <span class="name">e5</span> and generated it according to generation record
- <span class="name">g2</span>.
-
-The third record is an imprecise-1 derivation, which is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity record and associated attributes implicit. The fourth and fifth records are imprecise-n derivation records between <span class="name">e2</span> and <span class="name">e1</span>, but no information is provided as to the number and identity of activities underpinning the derivation.
-</p>
-</div>
-
-
-<p>An precise-1 derivation record is richer than an imprecise-1 derivation record, itself, being more informative that an imprecise-n derivation record. Hence, the following implications hold.</p>
-<div class="constraint" id="derivation-implications">
-Given two entity records 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 record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, then <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> also holds.<br>
-
-Given two entity records 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, [prov:steps="1"] ∪ attrs)</span>
- holds, then <span class="name">wasDerivedFrom(e2,e1,attrs)</span> also holds.<br>
- </div>
-
-
-
-<p>
-</p><p>If a derivation record holds for <span class="name">e2</span> and <span class="name">e1</span>, then
-this means that the entity represented by entity record identified by <span class="name">e1</span> has an influence on the entity represented entity record identified by <span class="name">e2</span>,
- which at the minimum implies temporal ordering, specified as follows.
-First, we consider one-activity derivations.</p>
-
-<div class="interpretation" id="derivation-usage-generation-ordering">Given an activity record identified by <span class="name">a</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, <span class="conditional">if</span> the record <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
-or <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> holds, <span class="conditional">then</span>
-the following temporal constraint holds:
-the <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usage</a>
-of entity denoted by <span class="name">e1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation</a> of
-the entity denoted by <span class="name">e2</span>.
-</div>
-
-<p>Then, imprecise-n derivations.</p>
-
-<div class="interpretation" id="derivation-generation-generation-ordering">
-Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class="conditional">if</span> the record <span class="name">wasDerivedFrom(e2,e1,[prov:steps="n"] ∪ attrs)</span>
- holds, <span class="conditional">then</span> the following temporal constraint holds:
-the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation event</a> of the entity denoted by <span class="name">e1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation event</a> of
-the entity denoted by <span class="name">e2</span>.
- </div>
-
-<p>Note that temporal ordering is between generations of <span class="name">e1</span>
-and <span class="name">e2</span>, as opposed to precise-1 derivation,
-which implies temporal ordering between the usage of <span class="name">e1</span> and
-generation of <span class="name">e2</span>. Indeed, in the case of
-imprecise-n derivation, nothing is known about the usage of <span class="name">e1</span>,
-since there is no associated activity.</p>
-
-
-
-
-<p>The imprecise-1 derivation has the same meaning as the precise-1
- derivation, except that an activity
- is known to exist, though it does not need to be
-asserted. This is formalized by the following inference rule,
-referred to as <em>activity introduction</em>:</p>
-<div class="constraint" id="activity-introduction">
-<span class="conditional">If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class="conditional">then</span> there exist an activity record identified by <span class="name">a</span>, a usage record identified by <span class="name">u</span>, and a generation record identified by <span class="name">g</span>
-such that:
-<pre class="codeexample">activity(a,aAttrs)
-wasGeneratedBy(g,e2,a,gAttrs)
-used(u,a,e1,uAttrs)
-</pre>
-for sets of attribute-value pairs <span class="name">gAttrs</span>, <span class="name">uAttrs</span>, and <span class="name">aAttrs</span>.
-</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 href="#dfn-precedes" class="internalDFN">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 determined by
-of <span class="name">e1</span>, given the creation of <span class="name">e2</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the use
-of <span class="name">e1</span>.
-</p>
-
-<div class="note">The following property holds for account where
-generation-unicity applies. Move it to separate section with all
-related material. </div>
-
-<p>A further inference is permitted from the imprecise-1 derivation record: </p>
-<div class="constraint" id="derivation-use">
-<p>Given an activity record identified by <span class="name">pe</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and set of attribute-value pairs <span class="name">attrs2</span>,
-<span class="conditional">if</span> <span class="name">wasDerivedFrom(e2,e1, [prov:steps="1"])</span> and <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> hold, <span class="conditional">then</span> <span class="name">used(pe,e1,attrs1)</span> also holds
-for some set of attribute-value pairs <span class="name">attrs1</span>.
-</p></div>
-<p>This inference is justified by the fact that the entity represented by entity record identified by <span class="name">e2</span> is generated by at most one activity in a given account (see <a href="#generation-unicity">generation-unicity</a>). Hence, this activity record is also the one referred to in the usage record 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(pe,e1)</span>, one cannot
-derive <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> because identifier <span class="name">e1</span> may occur in usage records referring to
-many activity records, but they may not be referred to in generation records containing identifier <span class="name">e2</span>.</p>
-
-
-
-
-<div class="issue">Should derivation have a time? Which time? This is <a href="http://www.w3.org/2011/prov/track/issues/43">ISSUE-43</a>.</div>
-
-</div>
-
-
-<div id="record-complement-of" class="section">
-
-<h5><span class="secno">5.3.3.3 </span>Complementarity Record</h5>
-
-<div class="note">While the working group recognizes the importance of the complementarity record concept, its name and its exact semantics are still being discussed.
-</div>
-
-
-<p>A <dfn id="complementOf">complementarity record</dfn> is a relationship between two entities stated to have compatible characterization over some continuous interval between two events.</p>
-
-<!-- PAOLO, which event do you refer to? <a>event</a>?? -->
-
-
-<p>
-The rationale for introducing this relationship is that in general, at any given time, for an entity in the world, there may be multiple ways of characterizing it, and hence multiple representations can be asserted by different asserters. In the example that follows, suppose thing "Royal Society" is represented by two asserters, each using a different set of attributes. If the asserters agree that both representations refer to "The Royal Society", the question of whether any correspondence can be established between the two representations arises naturally. This is particularly relevant when (a) the sets of attributes used by the two representations overlap partially, or (b) when one set is subsumed by the other. In both these cases, we have a situation where each of the two asserters has a partial view of "The Royal Society", and establishing a correspondence between them on the shared attributes is beneficial, as in case (a) each of the two representation <em>complements</em> the other, and in case (b) one of the two (that with the additional attributes) complements the other.</p>
-
-<p>This intuition is made more precise by considering the entities that form the representations of entities at a certain point in time.
-
-An entity record represents, by means of attribute-value pairs, a thing and its situation in the world, which remain constant over a characterization interval.
-As soon as the thing's situation changes, this marks the end of the characterization interval for the entity record representing it. The thing's novel situation is represented by an attribute with a new value, or an entirely different set of attribute-value pairs, embodied in another entity record, with a new characterization interval. Thus, if we overlap the timelines (or, more generally, the sequences of value-changing events) for the two entities, we can hope to establish correspondences amongst the entity records that represent them at various points along that events line. The figure below illustrates this intuition.</p>
-
-<div style="text-align: center;">
-<img src="complement-of.png" alt="illustration complementOf">
-</div>
-
-<p>
-Relation <em>complement-of</em> between two entity records is intended to capture these correspondences, as follows. Suppose entity records A and B share a set P of attributes, and each of them has other attributes in addition to P. If the values assigned to each attribute in P are <em>compatible</em> between A and B, then we say that <em>A is-complement-of B</em>, and <em>B is-complement-of A</em>, in a symmetrical fashion. In the particular case where the set P of attributes of B is a strict superset of A's attributes, then we say that <em>B is-complement-of A</em>, but in this case the opposite does not hold. In this case, the relation is not symmetric. (as a special case, A and B may not share any attributes at all, and yet the asserters may still stipulate that they are representing the same thing "Royal Society". The symmetric relation may hold trivially in this case).</p>
-
-<p>The term <em>compatible</em> used above means that a mapping can be established amongst the values of attributes in P and found in the two entity expession. This generalizes to the case where attribute sets P1 and P2 of A, and B, respectively, are not identical but they can be mapped to one another. The simplest case is the identity mapping, in which A and B share attribute set P, and furthermore the values assigned to attributes in P match exactly.</p>
-
-<p>It is important to note that the relation holds only for the characterization intervals of the entity expessions involved As soon as one attribute changes value in one of them, new correspondences need to be found amongst the new entities. Thus, the relation has a validity span that can be expressed in terms of the event lines of the entity.</p>
-
-<!--
-The "IVP of" relationship is designed to represent pairs of entities that correspond to each other. By their own nature, an entity remains valid only as long as all of its attributes do not change their value. It follows that the correspondence "B IVP of A" is only valid within the time interval during which such invariance attribute holds for both A and B. When any of the attribute values change in either A or B, those entities are replaced by new ones, and a new correspondence may be established. Thus, "IVP of" is defined relative to the intersection of the temporal intervals for which A and B are valid.
--->
-
-
-
-<p>A complementarity record is written <span class="name">wasComplementOf(e2,e1)</span>, where <span class="name">e1</span> and <span class="name">e2</span> are two identifiers denoting entity records.</p>
-
-
-<div class="anexample">
-<p>The following example illustrates the entity "Royal Society"and its perspectives at various points in time.</p>
-<pre class="codeexample">entity(rs,[ex:created=1870])
-
-entity(rs_l1,[prov:location="loc2"])
-entity(rs_l2,[prov:location="The Mall"])
-
-entity(rs_m1,[ex:membership=250, ex:year=1900])
-entity(rs_m2,[ex:membership=300, ex:year=1945])
-entity(rs_m3,[ex:membership=270, ex:year=2010])
-
-wasComplementOf(rs_m3, rs_l2)
-wasComplementOf(rs_m2, rs_l1)
-wasComplementOf(rs_m2, rs_l2)
-wasComplementOf(rs_m1, rs_l1)
-
-wasComplementOf(rs_m3, rs)
-wasComplementOf(rs_m2, rs)
-wasComplementOf(rs_m1, rs)
-wasComplementOf(rs_l1, rs)
-wasComplementOf(rs_l2, rs)
-</pre>
-</div>
-
-
-
-<div class="constraint" id="wasComplementOf-necessary-cond">
-An assertion "wasComplementOf(B,A)" holds over the temporal intersection of A and B, <span class="conditional">only if</span>:
-<ol>
-<li> if a mapping can be established from an attribute X of entity record identified by B to an attribute Y of entity record identified by A, then the values of A and B must be consistent with that mapping;</li>
-<li>entity record identified by B has some attribute that entity record identified by A does not have.</li>
-</ol>
- </div>
-
-<p>The complementarity relation is not transitive. Let us consider identifiers <span class="name">e1</span>, <span class="name">e2</span>, and <span class="name">e3</span> identifying three entity records such that
- <span class="name">wasComplementOf(e3,e2)</span> and <span class="name">wasComplementOf(e2,e1)</span> hold. The record <span class="name">wasComplementOf(e3,e1)</span> may not hold because the characterization intervals of the denoted entity records may not overlap.</p>
-
-
-<p>In PROV-ASN, a complementarity record's text matches the <span class="nonterminal">complementarityRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class="grammar">
-<span class="nonterminal">complementarityRecord</span> ::=
-<span class="name">wasComplementOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span> <br>
-|
-<span class="name">wasComplementOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">accIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">accIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-<p>
-An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to link two entity record identifiers that are appear in different accounts. (In particular, the entity record identifiers in two different account are allowed to be the same.). When account identifiers are not available, then the linking of entity records through complementarity can only take place within the scope of a single account.
-</p>
-
-
-<div class="anexample">
-<p>In the following example, the same description of the Royal Society is structured according to two different accounts. In the second account, we find a complementarity record linking <span class="name">rs_m1</span> in account <span class="name">ex:acc2</span> to
-<span class="name">rs</span> in account <span class="name">ex:acc1</span>.
-</p><pre class="codeexample">account(ex:acc1,
- http://example.org/asserter1,
-
- ...
- entity(rs,[ex:created=1870])
- ...
- )
-
-
-account(ex:acc2,
- http://example.org/asserter2,
-
- ...
- entity(rs_m1,[ex:membership=250, ex:year=1900])
- ...
- wasComplementOf(rs_m1, ex:acc2, rs, ex:acc1)
-
-)
-</pre>
-</div>
-
-
-
-<div class="note">It is suggested that the name 'wasComplementOf' does not capture the meaning of this relation adequately. No concrete suggestion has been made so far.
-Furthermore, there is a suggestion that an alternative relation that is transitive may also be useful.
-This is raised in the following <a href="http://lists.w3.org/Archives/Public/public-prov-wg/2011Sep/0315.html">email</a>.</div>
-
-
-
-<div class="issue">A discussion on alternative definition of wasComplementOf has not reached a satisfactory conclusion yet. This is <a href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a></div>
-
-
-
-<div class="pending"> Comments on ivpof in <a href="http://www.w3.org/2011/prov/track/issues/57">ISSUE-57</a>.</div>
-
-
-</div>
-</div>
-
-
-<!--
-<section>
-<h4>Transitive Derivation Record</h4>
-
-
-<p>
-If <span class="name">wasDerivedFrom(e2,e1)</span> holds because attribute <span class="name">a2.1</span> of <span class="name">e2</span> is determined by attribute <span class="name">a1.1</span> of <span class="name">e1</span>,
-and if <span class="name">wasDerivedFrom(e3,e2)</span> holds because attribute <span class="name">a3.1</span>of <span class="name">e3</span> is determined by attribute <span class="name">a2.2</span> of <span class="name">e1</span>, it is not necessarily the case that an attribute of <span class="name">e3</span> is determined by an attribute of <span class="name">e1</span>; so, an asserter may not be able to assert <span class="name">wasDerivedFrom(e3,e1)</span>, since it would fail to satisfy constraint <a href="#derivation-attributes">derivation-attributes</a>. Hence, the constraint on attributes as expressed in <a href="#derivation-attributes">derivation-attributes</a> invalidates transitivity in the general case.
-</p>
-
-<p>However, there is sense that <span class="name">e3</span> still depends on <span class="name">e1</span>, since <span class="name">e3</span> could not be generated without <span class="name">e1</span> existing. Hence, we introduce a weaker notion of derivation record, which is transitive.</p>
-
-A transitive derivation record, written <span class="name">dependedOn(e2, e1)</span> in PROV-ASN:
-<ul>
-<li> contains an identifier <span class="name">e2</span>, denoting an entity record, which represents the entity that is the result of the derivation;
-<li> contains an identifier <span class="name">e1</span>, denoting an entity record, which represents the entity that the derivation relies upon.
-</ul>
-<p>The record <span class="name">dependedOn</span> can only be inferred; in other words, it cannot be asserted. It is
-transitive by definition and relies on the previously defined derivation assertions for its
-base case.</p>
-
-<div class='constraint' id='transitive-derivation'>
-<ul>
-<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> or <span class="name">wasDerivedFrom(e2,e1,pe,attrs2,attrs1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
-<li><span class='conditional'>If</span> <span class="name">wasEventuallyDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
-<li><span class='conditional'>If</span> <span class="name">dependedOn(e3,e2)</span> and <span class="name">dependedOn(e2,e1)</span> hold, <span class='conditional'>then</span> <span class="name">dependedOn(e3,e1)</span> holds.</li>
-</ul>
-</div>
-
-</section>
--->
-
-
-
-
-
-
-
-<div id="record-annotation" class="section">
-<h4><span class="secno">5.3.4 </span>Annotation Record</h4>
-
-
-<p>An <dfn id="dfn-annotation">annotation record</dfn> establishes a link between an identifiable PROV-DM record and a note record referred to by its identifier. Multiple note records can be associated with a given PROV-DM record; symmetrically, multiple PROV-DM records can be associated with a given note record. Since note records have identifiers, they can also be annotated. The annotation mechanism (with note record and the annotation record) forms a key aspect of the extensibility mechanism of PROV-DM (see <a href="#extensibility-section">extensibility section</a>).</p>
-
-<p>An annotation record, written <span class="name">hasAnnotation(r,n,attrs)</span> in PROV-ASN, has the following constituents:</p>
-<ul>
-<li><em>record</em>: an identifier <span class="name">r</span> of the record being annnotated;</li>
-<li><em>note</em>: an identifier <span class="name">n</span> of a note record;</li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-
-<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class="grammar">
-<span class="nonterminal">annotationRecord</span> ::=
-<span class="name">hasAnnotation</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">nIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<p>The interpretation of notes is application-specific. See Section <a href="#record-note">Note</a> for a discussion of the difference between note attributes and other records attributes. We also note the present tense in this term to indicate that it may not denote something in the past.</p>
-
-<div class="anexample">
-<p>
-The following records</p>
-<pre class="codexample">entity(e1,[prov:type="document"])
-entity(e2,[prov:type="document"])
-activity(a,transform,t1,t2,[])
-used(u1,a,e1,[ex:file="stdin"])
-wasGeneratedBy(e2, a, [ex:file="stdout"])
-
-note(n1,[ex:icon="doc.png"])
-hasAnnotation(e1,n1)
-hasAnnotation(e2,n1)
-
-note(n2,[ex:style="dotted"])
-hasAnnotation(u1,n2)
-</pre>
-<p>assert the existence of two documents in the world (attribute-value pair: <span class="name">prov:type="document"</span>) represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these records with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also asserts an activity, its usage of the first entity, and its generation of the second entity. The <span class="name">usage</span> record is annotated with a style (an application specific way of rendering this edge graphically). To be able to express this annotation, the usage record was provided with an identifier <span class="name">u1</span>, which was then referred to in <span class="name">hasAnnotation(u1,n2)</span>.
-</p>
-</div>
-
-
-</div>
-</div>
-
-<div id="bundle" class="section">
-<h3><span class="secno">5.4 </span>Bundle</h3>
-
-<p>In this section, two constructs are introduced to group
-PROV-DM records. The first
-one, <a href="#dfn-Account" class="internalDFN">account record</a> is itself a
-record, whereas the second
-one <a href="#dfn-RecordContainer" class="internalDFN">record container</a> is not.
-</p>
-
-
-<div id="record-Account" class="section">
-<h4><span class="secno">5.4.1 </span>Account Record</h4>
-
-<p>In PROV-DM, an <dfn id="dfn-Account">account record</dfn> is a wrapper of records with a dual purpose: </p>
-<ul>
-<li> It is the mechanism by which attribution of provenance can be assserted; it allows asserters to bundle up their assertions, and assert suitable attribution;
-</li><li> It provides a scoping mechanism for record identifiers and for some contraints (such as
- <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>).
-</li></ul>
-
-
-
-<p>An account record, written <span class="name">account(id, assertIRI, recs, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> that identifies this account globally;</li>
-<li><em>asserter</em>: an IRI, denoted by <span class="name">assertIRI</span>, to identify an asserter; such IRI has no specific interpretation in the context of PROV-DM;</li>
-<li><em>records</em>: a set <span class="name">recs</span> of provenance records;</li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p>In PROV-ASN, an account record's text matches the <span class="nonterminal">accountRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class="grammar">
-<span class="nonterminal">accountRecord</span> ::=
-<span class="name">account</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="nonterminal">asserter</span>
-<span class="name">,</span>
-<span class="plus">
-<span class="nonterminal">record</span> </span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class="note">
-Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI and its interpretation is outside PROV-DM. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM assertions. The editors seek inputs on how to resolve this issue. </div>
-
-<div class="anexample">
-<p>
-The following account record</p>
-<pre class="codeexample">account(ex:acc0,
- http://example.org/asserter,
- entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
- ...
- wasDerivedFrom(e2,e1)
- ...
- activity(a0,create-file,t)
- ...
- wasGeneratedBy(e0,a0,[])
- ...
- wasAssociatedWith(a4, ag5, [prov:role="communicator"]) )
-</pre>
-<p>contains the set of provenance records of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span class="name">http://example.org/asserter</span>, and is identified by identifier <span class="name">ex:acc0</span>.
-</p>
-</div>
-
-<p>Account records constitue a scope for record identifiers. A record identifier within the scope of an account is intended to denote a single record. However, nothing prevents an asserter from asserting an account containing, for example, multiple entity records with a same identifier but different attribute-values. In that case, they should be understood as a single entity record with this identifier and the union of all attributes values, as formalized in <a href="#identified-entity-in-account">identified-entity-in-account</a>.</p>
-
-<div class="constraint" id="identified-entity-in-account">
-Given an entity record identifier <span class="name">e</span>, two sets of attribute-values denoted by <span class="name">av1</span> and <span class="name">av2</span>,
- two entity records <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account are equivalent to the entity record <span class="name">entity(e,av)</span> where <span class="name">av</span> is the set of attribute-value pairs formed by the union of <span class="name">av1</span> and <span class="name">av2</span>.
-</div>
-
-<p>Whilst constraint <a href="#identified-entity-in-account">identified-entity-in-account</a> specifies how to understand multiple entity records with a same identifier within a given account, it does not guarantee that the entity record formed with the union of all attribute-value pairs is consistent. Indeed, a given attribute may be assigned multiple values, resulting in an inconsistent entity record, as illustrated by the following example.</p>
-
-<div class="anexample">
-<p>
-In the following account record, we find two entity records with a same identifier <span class="name">e</span>.</p>
-<pre class="codeexample">account(ex:acc1,
- http://example.org/id,
- entity(e,[prov:type="person", ex:age=20])
- entity(e,[prov:type="person", ex:age=30])
- ...)
-</pre>
-<p>Application of <a href="#identified-entity-in-account">identified-entity-in-account</a> results in an entity record containing the attribute-value pairs <span class="name">age=20</span> and <span class="name">age=30</span>. This results in an inconsistent characterization of a person. We note that deciding whether a set of attribute-values is consistent or not is application specific and outside the scope of this specification.
-</p></div>
-
-<p>Account records can be nested since an account record can occur among the records being wrapped by another account. </p>
-
-
-<p>
-An account is said to be well-formed if
-it satisfies the constraints <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>.</p>
-
-<p> The union of two accounts is another account,
-containing the unions of their respective records, where
- records with a same identifier should be understood according to constraint <a href="#identified-entity-in-account">identified-entity-in-account</a>. Well-formed
-accounts are not
-closed under union because the
-constraint <a href="#generation-unicity">generation-unicity</a> may no
-longer be satisfied in the resulting union. </p>
-
-<div class="anexample">
-<p>
-Indeed, let us consider another account record</p>
-<pre class="codeexample">account(ex:acc2,
- http://example.org/asserter2,
- entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
- ...
- activity(a1,create-file,t1)
- ...
- 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-unicity">generation-unicity</a>.</p>
-</div>
-
-<p>Account records constitute a scope for record identifiers. Since accounts can be nested, scopes can also be nested; thus, the scope of record identifiers should be understood in the context of such nested scopes. When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur. </p>
-
-<div class="anexample">
-<p>
-The following account record is inspired from section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>. This account, identified by <span class="name">ex:acc3</span>, declares entity record with identifier <span class="name">e0</span>, which is being referred to in the nested account <span class="name">ex:acc4</span>. The scope of identifier <span class="name">e0</span> is account <span class="name">ex:acc3</span>, including subaccount <span class="name">ex:acc4</span>.</p>
-<pre class="codeexample">account(ex:acc3,
- http://example.org/asserter1,
- entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
- activity(a0,create-file,t)
- wasGeneratedBy(e0,a0,[])
- account(ex:acc4,
- http://example.org/asserter2,
- entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
- activity(a0,copy-file,t)
- wasGeneratedBy(e1,a0,[ex:fct="create"])
- wasComplementOf(e1,e0)))
-</pre>
-<p>Alternatively, an activity record identified by <span class="name">a0</span> occurs in each of the two accounts. Therefore, each activity record is asserted in a separate scope, and therefore may represent different activities in the world.
-</p>
-</div>
-
-<p>The account record is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. The annotation mechanism can be used for this purpose, but how general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>
-
-
-</div>
-
-<div id="RecordContainer" class="section">
-<h4><span class="secno">5.4.2 </span>Record Container</h4>
-
-<p>A <dfn id="dfn-RecordContainer">record container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM records. A record container is not a record, but can be exploited to return assertions in response to a request for the provenance of something ([<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PAQ">PROV-PAQ</a></cite>]). </p>
-
-<p>
-
-
-</p><p>A record container, written <span class="name">container decls recs endContainer</span> in PROV-ASN, contains:
-</p><ul>
-<li><em>namespaceDeclarations</em>: a set <span class="name">decls</span> of namespace declarations, declaring namespaces and associated prefixes, which can be used in <a title="attribute" href="#dfn-attribute" class="internalDFN">attributes</a> and <a title="identifier" href="#dfn-identifier" class="internalDFN">identifiers</a> occurring inside <span class="name">recs</span>;</li>
-<li><em>records</em>: a non-empty set of records <span class="name">recs</span>.</li>
-</ul>
-<p>All the records in <span class="name">recs</span> are implictly wrapped in a default account, scoping all the record identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts. Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a container's default account.</p>
-
-<p>In PROV-ASN, a record container's text matches the <span class="nonterminal">recordContainer</span> production of the grammar defined in this specification document.</p>
-
-
-<div class="grammar">
-<span class="nonterminal">recordContainer</span> ::=
-<span class="name">container</span>
-<span class="nonterminal">namespaceDeclarations</span>
-<span class="plus"> <span class="nonterminal">record</span> </span>
-<span class="name">endContainer</span>
-</div>
-
-
-<div class="anexample">
-<p>
-The following container </p>
-<pre class="codeexample">container
- prefix ex: http://example.org/,
-
- account(ex:acc1,http://example.org/asserter1,...)
- account(ex:acc2,http://example.org/asserter1,...)
-endContainer
-</pre>
-<p> illustrates how two accounts with identifiers <span class="name">ex:acc1</span> and <span class="name">ex:acc2</span> can be returned in a PROV-ASN serialization of the provenance of something.
-</p>
-</div>
-
-
-<div class="pending">Asserter needs to be defined. This is <a href="http://www.w3.org/2011/prov/track/issues/51">ISSUE-51</a>.</div>
-
-
-<div class="pending">Scope and Identifiers. This is <a href="http://www.w3.org/2011/prov/track/issues/81">ISSUE-81</a>.</div>
-
-
-</div>
-</div>
-
-
-<div id="sub-record" class="section">
-<h3><span class="secno">5.5 </span>Further Terms in Records</h3>
-
-This section further terms in PROV-DM records.
-
-
-
-<div id="record-attribute" class="section">
-<h4><span class="secno">5.5.1 </span>Attribute</h4>
-
-<p>An <dfn id="dfn-attribute">attribute</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
- by concatenating the IRI associated with the prefix and the local part (see detailed rule in [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SPARQL-QUERY">RDF-SPARQL-QUERY</a></cite>], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
-
-<div class="grammar">
-<span class="nonterminal">attribute</span> ::= <span class="nonterminal">qualifiedName</span><br>
-<span class="nonterminal">qualifiedName</span> ::= <span class="nonterminal">prefixedName</span> | <span class="nonterminal">unprefixedName</span><br>
-<span class="nonterminal">prefixedName</span> ::= <span class="nonterminal">prefix</span> <span class="name">:</span> <span class="nonterminal">localPart</span><br>
-<span class="nonterminal">unprefixedName</span> ::= <span class="nonterminal">localPart</span><br>
-<span class="nonterminal">prefix</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES">XML-NAMES</a></cite>]</em><br>
-<span class="nonterminal">localPart</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES">XML-NAMES</a></cite>]</em>
-</div>
-
-<p>A qualified name's prefix is <em class="rfc2119" title="optional">optional</em>. If a prefix occurs in a
- qualified name, it refers to a <a href="#dfn-namespace" class="internalDFN">namespace</a> declared in the
- record container. In the absence of prefix, the qualified name
- refers to the default namespace declared in the container.</p>
-
-<div class="note">Note that XML NC_NAME don't allow local identifiers to start with a number. Instead, should we use the productions used in SPARQL or TURTLE?</div>
-
-<p>From this specification's viewpoint, the interpretation of an attribute declared in a namespace other than prov-dm is out of
-scope.</p>
-
-<p>The PROV data model introduces a fixed set of attributes in the <a href="#prov-dm-namespace">PROV-DM namespace</a>:</p>
-<ul>
-<li> The attribute <dfn id="dfn-role"><span class="name">prov:role</span></dfn> denotes the function of an entity with respect to an activity, in the context of a usage, generation, activity association, start, end record. The value associated with a <span class="name">prov:role</span> attribute <em class="rfc2119" title="must">must</em> be conformant with <span class="nonterminal">Literal</span>.
-
-<div class="anexample">
-<p>The following start record describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
-<pre class="codeexample"> wasStartedBy(a,ag, [prov:role="program-operator"])
-</pre>
-</div>
- </li>
-
-<li> The attribute <dfn id="dfn-type"><span class="name">prov:type</span></dfn> provides further typing information for the element or relation asserted in the record. The value associated with a <span class="name">prov:type</span> attribute <em class="rfc2119" title="must">must</em> be conformant with <span class="nonterminal">Literal</span>.
-
-<div class="anexample">
-<p>The following record declares an agent of type software agent</p>
-<pre class="codeexample"> agent(ag, [prov:type="prov:SoftwareAgent" %% xsd:QName])
-</pre>
-</div>
-
-
-</li><li> The attribute <dfn id="dfn-steps"><span class="name">prov:steps</span></dfn> defines the level of precision associated with a derivation record. The value associated with a <span class="name">prov:steps</span> attribute <em class="rfc2119" title="must">must</em> be <span class="name">"1"</span> or <span class="name">"n"</span>. </li>
-
-</ul>
-</div>
-
-
-
-<div id="record-identifier" class="section">
-<h4><span class="secno">5.5.2 </span>Identifier</h4>
-
-
-<p>An <dfn id="dfn-identifier">identifier</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
- by concatenating the IRI associated with the prefix and the local part (see detailed rule in [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SPARQL-QUERY">RDF-SPARQL-QUERY</a></cite>], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>
-
-<div class="grammar">
-<span class="nonterminal">identifier</span> ::= <span class="nonterminal">qualifiedName</span><br>
-<span class="nonterminal">eIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an entity record)</em><br>
-<span class="nonterminal">aIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an activity record)</em><br>
-<span class="nonterminal">agIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an agent record)</em><br>
-<span class="nonterminal">gIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a generation record)</em><br>
-<span class="nonterminal">uIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a usage record)</em><br>
-<span class="nonterminal">nIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a note record)</em><br>
-<span class="nonterminal">accIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote an account record)</em>
-</div>
-
-
-</div>
-
-<div id="record-literal" class="section">
-<h4><span class="secno">5.5.3 </span>Literal</h4>
-
-<p>
-A PROV-DM Literal represents a data value such as a particular string
-or number. A PROV-DM Literal represents a value whose interpretation is outside the scope of PROV-DM.
-</p>
-
-<p>In PROV-ASN, a Literal's text matches the <span class="nonterminal">Literal</span> production of the grammar defined in this specification document.</p>
-
-<div class="grammar">
-<span class="nonterminal">Literal</span> ::= <span class="nonterminal">typedLiteral</span> | <span class="nonterminal">convenienceNotation</span> <br>
-<span class="nonterminal">typedLiteral</span> ::= <span class="nonterminal">quotedString</span> <span class="name">%%</span> <span class="nonterminal">datatype</span><br>
-<span class="nonterminal">datatype</span> ::= <span class="nonterminal">qualifiedName</span><br>
-<span class="nonterminal">convenienceNotation</span> ::= <span class="nonterminal">stringLiteral</span> | <span class="nonterminal">intLiteral</span><br>
-<span class="nonterminal">stringLiteral</span> ::= <span class="nonterminal">quotedString</span><br>
-<span class="nonterminal">quotedString</span> ::= <em>a finite sequence of characters in which " (U+22) and \ (U+5C) occur only in pairs of the form \" (U+5C, U+22) and \\ (U+5C, U+5C), enclosed in a pair of " (U+22) characters</em><br>
-<span class="nonterminal">intLiteral</span> ::= <em>a finite-length sequence of decimal digits (#x30-#x39) with an optional leading negative sign (-)</em>
-</div>
-
-<p>The non terminals <span class="nonterminal">stringLiteral</span> and
-<span class="nonterminal">intLiteral</span>
-are syntactic sugar for quoted strings with datatype <span class="name">xsd:string</span> and <span class="name">xsd:int</span>, respectively.
-</p>
-
-<p> In particular, a PROV-DM Literal may be an IRI-typed string (with datatype <span class="name">xsd:anyURI</span>); such IRI has no specific interpretation in the context of PROV-DM.</p>
-
-
-<div class="anexample">
-<p>
-The following examples respectively are the string "abc" (expressed using the convenience notation), the string "abc", the integer number 1, the integer number 1 (expressed using the convenience notation) and the IRI "http://example.org/foo".
-</p><pre class="codeexample"> "abc"
- "abc" %% xsd:string
- "1" %% xsd:int
- 1
- "http://example.org/foo" %% xsd:anyURI
-</pre>
-The following example shows a literal of type <span class="name">xsd:QName</span> (see
-<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#QName">QName</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>]).
-The prefix <span class="name">ex</span> <em class="rfc2119" title="must">must</em> be bound to a <a href="#dfn-namespace" class="internalDFN">namespace</a> declared in the
- record container.
-<pre class="codeexample"> "ex:value" %% xsd:QName
-</pre>
-</div>
-
-
-
-<div class="note">Should we define structural equivalence of literals as in OWL2? [<cite><a class="bibref" rel="biblioentry" href="#bib-OWL2-SYNTAX">OWL2-SYNTAX</a></cite>]
-(see section <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Literals">Literals</a>).
-</div>
-
-</div>
-
-
-
-
-<div id="record-Time" class="section">
-<h4><span class="secno">5.5.4 </span>Time</h4>
-
-<p><dfn id="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].</p>
-
-
-
-<p>It is <em class="rfc2119" title="optional">optional</em> to assert time in usage, generation, and activity records.</p>
-
-
-
-
-</div>
-
-<div id="record-Asserter" class="section">
-<h4><span class="secno">5.5.5 </span>Asserter</h4>
-
-<p>An <dfn id="dfn-asserter">asserter</dfn> is a creator of PROV-DM records. An asserter is denoted by an IRI. Such IRI has no specific interpretation in the context of PROV-DM.</p>
-
-<div class="grammar">
-<span class="nonterminal">asserter</span> ::= <span class="nonterminal">IRI</span><br>
-<span class="nonterminal">IRI</span> ::= <em>an IRI compatible with production IRI in [<cite><a class="bibref" rel="biblioentry" href="#bib-IRI">IRI</a></cite>], enclosed in a pair of < (U+3C) and > (U+3E) characters </em>
-</div>
-
-<div class="note">
-Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM. We seek inputs on how to resolve this issue. </div>
-
-</div>
-
-<div id="record-NamespaceDeclaration" class="section">
-<h4><span class="secno">5.5.6 </span>Namespace Declaration</h4>
-
-<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [<cite><a class="bibref" rel="biblioentry" href="#bib-IRI">IRI</a></cite>]. In PROV-DM, attributes, identifiers, and literals of with datatype <span class="name">xsd:QName</span> can be placed in a namespace using the mechanisms described in this specification. </p>
-
-
-<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this declaration refers to this namespace.
-A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration refers to this namespace.</p>
-
-<div class="grammar">
-<span class="nonterminal">namespaceDeclarations</span> ::=
- | <span class="group"><span class="nonterminal">defaultNamespaceDeclaration</span> | <span class="nonterminal">namespaceDeclaration</span></span> <span class="star"> <span class="nonterminal">namespaceDeclaration</span></span><br>
-<span class="nonterminal">namespaceDeclaration</span> ::=
-<span class="name">prefix</span> <span class="nonterminal">prefix</span> <span class="nonterminal">IRI</span><br>
-<span class="nonterminal">defaultNamespaceDeclaration</span> ::=
- <span class="name">default</span> <span class="nonterminal">IRI</span> <br>
-</div>
-</div>
-
-
-<div id="record-RecipeLink" class="section">
-<h4><span class="secno">5.5.7 </span>Recipe Link</h4>
-
-
-<p>A <dfn id="dfn-RecipeLink">recipe link</dfn> is an association between an activity record and a process specification that underpins the represented activity. Such IRI has no specific interpretation in the context of PROV-DM.
-</p>
-
-<div class="grammar">
-<span class="nonterminal">recipeLink</span> ::= <span class="nonterminal">IRI</span>
-</div>
-
-<p>
-It is <em class="rfc2119" title="optional">optional</em> to assert recipe links in activities.
-</p>
-
-
-<p>
-Process specifications, as referred to by recipe links, are out of scope of this specification.
-</p>
-
-<div class="note">
-By defining a recipe link as an IRI whose interpretation is out of
-scope of PROV-DM, we don't allow it to refer to an entity (in an
-inter-operable manner). Is this what we intend?
-</div>
-
-<div class="issue"> Simplify the references to recipe link. This is <a href="http://www.w3.org/2011/prov/track/issues/131">ISSUE-131</a></div>
-
-</div>
-
-
-
-
-
-<div id="record-Location" class="section">
-<h4><span class="secno">5.5.8 </span>Location</h4>
-
-<p><dfn id="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, row, column, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations in assertions. </p>
-
-
-<p>
-Location is an <em class="rfc2119" title="optional">optional</em> attribute of entity records and activity records. The value associated with a attribute <span class="name">location</span> <em class="rfc2119" title="must">must</em> be a <span class="nonterminal">Literal</span>, expected to denote a location.
-</p>
-
-
-
-
-</div>
-
-</div>
-
-</div>
-
-
- <div id="common-relations" class="section">
-<!--OddPage--><h2><span class="secno">6. </span>PROV-DM Common Relations</h2>
-
-<p>This section contains the normative specification of common relations of PROV-DM.</p>
-
-
-<div class="issue">We have defined a set of common relation, in response to <a href="http://www.w3.org/2011/prov/track/issues/44">ISSUE-44</a>. Is this set complete?</div>
-
-
-<div class="note">The types of these relations need to be made explicit.</div>
-
-<p>The following figure summarizes the additional relations described in subsections 6.2 onwards.</p>
-
-<div style="text-align: center;">
-<img src="sec6-summary.png" alt="common relations">
-</div>
-
-
-<div id="record-Collection" class="section">
-<h3><span class="secno">6.1 </span>Collections</h3>
-
-The purpose of this section is to enable modelling of part-of relationships amongst entities. In particular, a form of <strong>collection</strong> entity type is introduced, consisting of a set of key-value pairs. Key-value pairs provide a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more.<br>
-
-The relations introduced here are all specializations of the <a href="#record-Derivation"><strong>wasDerivedFrom</strong></a> relation, specifically precise-1 or imprecise-1. They are designed to model:
-
-<ul>
- <li><strong>insertion</strong>: a collection entity c' is obtained from collection entity c, by adding entity e having key k to c;
- </li><li><strong>removal</strong>: a collection entity c' is obtained from collection entity c, by removing entity e having key k from c;
- </li><li><strong>selection</strong>: an entity e was selected from collection c using key k.
- </li></ul>
-
- A collection record is defined as follows.
-<div class="grammar">
- <span class="nonterminal">collectionRecord</span> ::=
-<span class="nonterminal">collectionDerivationRecord</span>
-| <span class="nonterminal">keyDerivationRecord</span>
-| <span class="nonterminal">entityMembershipRecord</span>
-<br>
-
- <span class="nonterminal">collectionDerivationRecord</span> ::=
-<span class="name">wasAddedTo_Coll</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
- |
-<span class="name">wasRemovedFrom_Coll</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
-<br>
-
- <span class="nonterminal">keyDerivationRecord</span> ::=
-<span class="name">wasAddedTo_Key</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
-|
-<span class="name">wasRemovedFrom_Key</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
- <br>
-
- <span class="nonterminal">entityMembershipRecord</span> ::=
-<span class="name">wasAddedTo_Entity</span>
- <span class="name">(</span>
- <span class="nonterminal">identifier</span>
- <span class="name">,</span>
-<span class="nonterminal">identifier</span>
- <span class="name">)</span>
-<br>
- </div>
-
-<p> Record: <span class="name">wasAddedTo_Coll(c2,c1)</span> (resp. <span class="name">wasRemovedFrom_Coll(c2,c1)</span>) denotes that collection <span class="name">c2</span> is an updated version of collection <span class="name">c1</span>, following an insertion (resp. deletion) operation.</p>
-
-<p> Record: <span class="name">wasAddedTo_Key(c,k)</span> (resp. <span class="name">wasRemovedFrom_Key(c,k)</span>) denotes that collection <span class="name">c</span> had
- a new value with key <span class="name">k</span> added to (resp. removed from) it.</p>
-
-<p> Record: <span class="name">wasAddedTo_Entity(c,e)</span> denotes that collection <span class="name">c</span> had entity
- <span class="name">e</span> added to it.
-</p>
-
-
-<div class="anexample">
-<p>Consider the following assertions:</p>
-<pre class="codeexample">
-
- <span class="name">wasAddedTo_Coll(c2,c1)</span>
- <span class="name">wasAddedTo_Key(c2,k1)</span>
- <span class="name">wasAddedTo_Entity(c2,e1)</span>
-
- <span class="name">wasAddedTo_Coll(c3,c2)</span>
- <span class="name">wasAddedTo_Key(c3,k2)</span>
- <span class="name">wasAddedTo_Entity(c3,e2)</span>
-
- <span class="name">wasRemovedFrom_Coll(c4,c3)</span>
- <span class="name">wasRemovedFrom_Key(c4,k1)</span>
-</pre>
-<p>The corresponding graphical representation is shown below.</p>
-
-<div style="text-align: center;">
-<img src="collections.png" alt="collections">
-</div>
-
-
-<p> With these assertions:</p>
- <ul>
- <li><span class="name">c2</span> is known to contain the key-value pair <span class="name">(k1,e1)</span>
- </li><li><span class="name">c3</span> is known to contain pairs <span class="name">(k1,e1)</span> and <span class="name">(k2,e2)</span>.
- </li><li><span class="name">c4</span> is known <em>not</em> to contain pair <span class="name">(k1,e1)</span> and to contain pair <span class="name">(k2,e2)</span>.
- </li></ul>
-</div>
-
- </div>
-
-<div id="record-traceability" class="section">
-<h3><span class="secno">6.2 </span>Traceability Record</h3>
-
-<p> A <dfn id="dfn-Traceability">traceability record</dfn> states the existence of a "dependency path" between two entities, indicating that one entity can be shown to be in the lineage of another, and may have influenced it in some way. This relation is transitive. </p>
-
-<p> A traceability record, written <span class="name">tracedTo(id,e2,e1,attrs)</span> in PROV-ASN:</p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the traceability record;</li>
-<li><em>entity</em>: an identifier <span class="name">e2</span> identifying an entity;
-</li><li><em>ancestor</em>: an identifier <span class="name">e1</span> identifying an ancestor entity in the lineage of <span class="name">e2</span>;
-</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p>In PROV-ASN, a traceability record's text matches the <span class="nonterminal">traceabilityRecord</span> production of the grammar defined in this specification document.</p>
-
-
-<div class="grammar">
-<span class="nonterminal">traceabilityRecord</span> ::=
-<span class="name">tracedTo</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>
-<span class="name">,</span></span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<p>A traceability record can be inferred from existing relations, or can be asserted stating that such a dependency path exists without the asserter knowing its individual steps, as expressed by the following constraints.
-
-</p><div class="constraint" id="traceability-inference">
-Given two identifiers <span class="name">e2</span> and <span class="name">e1</span> identifying entity records,
-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>
-
-<div class="constraint" id="traceability-assertion">
-<span class="conditional">If</span> the record <span class="name">tracedTo(r2,r1)</span> holds
-for two identifiers <span class="name">r2</span> and <span class="name">r1</span> identifying entity records,
- <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 record. </p>
-
-
-</div>
-
-<div id="record-OrderingOfActivities" class="section">
-<h3><span class="secno">6.3 </span>Activity Ordering Record</h3>
-
-
-
-<p>PROV-DM allows dependencies amongst activities to be expressed.
-An <dfn id="InformationFlowOrdering">information flow ordering record</dfn> is a representation that an entity was generated by an activity, before it was used by another activity.
-A <dfn id="ControlOrdering">control ordering record</dfn> is a representation that an activity was initiated by another activity.
-</p>
-
-<p>In PROV-ASN, an activity ordering record's text matches the <span class="nonterminal">activityOrderingRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class="grammar">
-<span class="nonterminal">activityOrderingRecord</span> ::=
-<span class="nonterminal">informationFlowOrderingRecord</span> |
-<span class="nonterminal">controlOrderingRecord</span>
-<br>
-
-<span class="nonterminal">informationFlowOrderingRecord</span> ::=
-<span class="name">wasInformedBy</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>
-<span class="name">,</span>
-</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-<br>
-
-<span class="nonterminal">controlOrderingRecord</span> ::=
-<span class="name">wasStartedBy</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>
-<span class="name">,</span>
-</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-<br>
-</div>
-
-
-<p>
-An information flow ordering record, written as
-<span class="name">wasInformedBy(id,a2,a1,attrs)</span> in PROV-ASN, contains:
-</p><ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span> identifying the record;</li>
-<li><em>informed</em>: the identifier <span class="name">a2</span> of an activity record representing the informed activity;
-</li><li><em>informant</em>: the identifier <span class="name">a1</span> of an activity record representing the informant activity;
-</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p> An information flow ordering record is formally defined as follows.</p>
-
-<div class="constraint" id="wasInformedBy-Definition">Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
- the record <span class="name">wasInformedBy(a2,a1)</span>
-holds, <span class="conditional">if and only if</span>
- there is an entity record identified by <span class="name">e</span> and 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" id="wasInformedBy-ordering">
-Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class="conditional">if</span> the record <span class="name">wasInformedBy(a2,a1)</span>
- holds, <span class="conditional">then</span> the following temporal constraint holds:
-the <a title="activity start event" href="#dfn-start-event" class="internalDFN">start event</a> of the activity record denoted by <span class="name">a1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end event</a> of
-the activity record denoted by <span class="name">a2</span>.
-</div>
-
-
-<p>The relationship <span class="name">wasInformedBy</span> is not transitive. Indeed, consider the following records.</p>
-<pre class="codeexample">wasInformedBy(a2,a1)
-wasInformedBy(a3,a2)
-</pre>
-<p> We cannot infer <span class="name">wasInformedBy(a3,a1)</span> from them. 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 where transitivity cannot hold. The horizontal axis represents time. 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;">
-<img src="informedByNonTransitive.png" alt="non transitivity of wasInformedBy">
-</div>
-
-<div class="note">
-The relation wasScheduledAfter was dropped, and replaced by a simplier relation wasStartedBy(a2,a1). It is intentional that the name wasStartedBy is overloaded.
-</div>
-
-<p>
-A control ordering record, written as
-<span class="name">wasStartedBy(a2,a1)</span> in PROV-ASN, contains: </p>
-<ul>
-<li><em>id</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">id</span>;</li>
-<li><em>started</em>: refers to an activity record identified by <span class="name">a2</span>, representing the started activity;
-</li><li><em>starter</em>: refers to an activity record identified by <span class="name">a1</span>, representing the activity that started <span class="name">a1</span>;</li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-<p>Such a record states control ordering between <span class="name">a2</span> and <span class="name">a1</span>, specified as follows.</p>
-
-<div class="constraint" id="wasStartedBy">Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>,
- the record <span class="name">wasStartedBy(a2,a1)</span>
-holds <span class="conditional">if and only if</span>
- there exist an entity record identified by <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>
-
-
-<div class="anexample">
-<p>
-In the following assertions, we find two activity records, identified by <span class="name">a1</span> and <span class="name">a2</span>, representing two activities, which took place on two separate hosts. The third record indicates that the latter activity was started by the former.</p>
-<pre class="codeexample">activity(a1,workflow,t1,t2,[ex:host="server1.example.org"])
-activity(a2,sub-workflow,t3,t4,[ex:host="server2.example.org"])
-wasStartedBy(a2,a1)
-</pre>
-
-<p>Alternatively, we could have asserted the existence of an entity, representing a request to create a sub-workflow. This request, issued by <span class="name">a1</span>, triggered the start of <span class="name">a2</span>.
-</p>
-<pre class="codeexample">entity(e,[prov:type="creation-request"])
-wasGeneratedBy(e,a1)
-wasStartedBy(a2,e)
-</pre>
-</div>
-
-<div class="interpretation" id="wasStartedBy-ordering">
-Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class="conditional">if</span> the record <span class="name">wasStartedBy(a2,a1)</span>
- holds, <span class="conditional">then</span> the following temporal constraint holds: the
-<a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a> event of the activity record denoted by <span class="name">a1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity start event" href="#dfn-start-event" class="internalDFN">start event</a> of
-the activity record denoted by <span class="name">a2</span>.
-</div>
-
-
-
-<div class="pending">Suggested definition for process ordering. This is <a href="http://www.w3.org/2011/prov/track/issues/50">ISSUE-50</a>.</div>
-
-</div>
-
-<div id="record-Revision" class="section">
-<h3><span class="secno">6.4 </span>Revision Record</h3>
-
-<p> A <dfn id="dfn-Revision">revision record</dfn> is a representation of the creation of an entity considered to be a variant of another. Deciding whether something is made available as a revision of something else usually involves an agent who represents someone in the world who takes responsibility for approving that the former is a due variant of the latter. </p>
-
-<p> A revision record, written <span class="name">wasRevisionOf(e2,e1,ag,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>newer</em>: an identifier <span class="name">e2</span> identifying an entity that represents a newer version of an entity;
-</li><li><em>older</em>: an identifier <span class="name">e1</span> identifying an entity that represents an older version of an entity;
-</li><li><em>responsibility</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">ag</span> for the agent who approved that <span class="name">e2</span> is a variant of <span class="name">e1</span>;
-</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-
-<p>In PROV-ASN, a revision record's text matches the <span class="nonterminal">revisionRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class="grammar">
-<span class="nonterminal">revisionRecord</span> ::=
-<span class="name">wasRevisionOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="optional"><span class="name">,</span>
-<span class="nonterminal">agIdentifier</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-
-
-
-<p>A revision record needs to satisfy the following constraint, linking the two entity records by a derivation, and stating them to be a complement of a third entity record.</p>
-
-<div class="constraint" 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> a record <span class="name">wasRevisionOf(new,old,ag)</span> is asserted, <span class="conditional">then</span>
-there exists an entity record identifier <span class="name">e</span> and attribute-values <span class="name">eAttrs</span>, <span class="name">dAttrs</span>, such that the following records hold:
-<ul>
-<li> <span class="name">wasDerivedFrom(new,old,dAttrs)</span>;
-</li><li> <span class="name">entity(e,eAttrs)</span>;
-</li><li> <span class="name">wasComplementOf(new,e)</span>;
-</li><li> <span class="name">wasComplementOf(old,e)</span>.
-</li></ul>
-The derivation record may be imprecise-1 or imprecise-n.
-</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>
-
-<div class="anexample">
-<p>
-The following revision assertion</p>
-<pre class="codeexample">agent(ag,[prov:type="QualityController"])
-entity(e1,[prov:type="document"])
-entity(e2,[prov:type="document"])
-wasRevisionOf(e2,e1,ag)
-</pre>
-<p>states that the document represented by entity record identified by <span class="name">e2</span> is a revision of document represented by entity record identified by <span class="name">e1</span>; agent denoted by <span class="name">ag</span> is responsible for this new versioning of the document.
-</p>
-</div>
-
-
-<div class="pending">Revision should be a class not a property. This is <a href="http://www.w3.org/2011/prov/track/issues/48">ISSUE-48</a>.</div>
-
-
-</div>
-
-
-<div id="attribution-record" class="section">
-<h3><span class="secno">6.5 </span>Attribution Record</h3>
-
-<p>An attribution record represents that an entity is ascribed to an agent and is compliant with the <span class="nonterminal">attributionRecord</span> production.</p>
-
-
-<p> An attribution record, written <span class="name"> wasAttributedTo(e,ag,attr)</span>, contains the following components:</p>
-<ul>
-<li><em>entity</em>: an identifier <span class="name">e</span> of an entity record;</li>
-<li><em>agent</em>: an identifier <span class="name">ag</span> of an agent whom the entity is attributed to;</li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-<p>Attribution models the notion of an activity generating an entity identified by <span class="name">e</span> being controlled by an agent <span class="name">ag</span>, which takes responsibility for generating <span class="name">e</span>. Formally, this is expressed as the following necessary condition.</p>
-
-<p>In PROV-ASN, an attribution record's text matches the <span class="nonterminal">attributionRecord</span> production of the grammar.</p>
-
-<div class="grammar">
-<span class="nonterminal">attributionRecord</span> ::=
-<span class="name">wasAttributedTo</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class="constraint" 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 identified by <span class="name">pe</span> such that the following statements hold:
-<pre>activity(pe,recipe,t1,t2,attr1)
-wasGenerateBy(e,pe)
-wasAssociatedWith(pe,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>
-</div>
-
-
-<div id="quotation-record" class="section">
-<h3><span class="secno">6.6 </span>Quotation Record</h3>
-
-
-<p> A quotation record is a representation of the repeating or copying of some part of an entity, compatible with
-the <span class="nonterminal">quotationRecord</span> production.</p>
-
-
-<p> A quotation record, written <span class="name"> wasQuotedFrom(e2,e1,ag2,ag1,attrs)</span>, contains:</p>
-<ul>
-<li><em>quote</em>: an identifier <span class="name">e2</span>, identifying an entity record that represents the quote;
-</li><li><em>quoted</em>: an identifier <span class="name">e1</span>, identifying an entity record representing what is being quoted;
-</li><li><em>quoterAgent</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">ag2</span> of the agent who is doing the quoting;
-</li><li><em>quotedAgent</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">ag1</span> of the agent that is quoted;
-</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-
-</ul>
-
-<p>In PROV-ASN, a quotation record's text matches the <span class="nonterminal">quotationRecord</span> production of the grammar.</p>
-
-<div class="grammar">
-<span class="nonterminal">quotationRecord</span> ::=
-<span class="name">wasQuotedFrom</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-
-<div class="constraint" id="quotation-implication">
-<span class="conditional">If</span>
-<span class="name">wasQuotedFrom(e2,e1,ag2,ag1)</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 records hold:
-<pre>wasDerivedFrom(e2,e1)
-wasAttributedTo(e2,ag2)
-wasAttributedTo(e1,ag1)
-</pre>
-</div>
-
-</div>
-
-
-<div id="summary-record" class="section">
-<h3><span class="secno">6.7 </span>Summary Record</h3>
-<p>A <dfn id="dfn-summary-record">summary record</dfn> represents that an entity is a synopsis or abbreviation of another entity. A summary record is compliant with the
-<span class="nonterminal">summaryRecord</span> production.</p>
-
-
-
-<p> An assertion wasSummaryOf, written <span class="name"> wasSummaryOf(e2,e1,attrs)</span>, contains:</p>
-<ul>
-<li><em>summarizedEntity</em>: an identifier <span class="name">e2</span> for the entity record that represents the summary;
-</li><li><em>fullEntity</em>: an identifier <span class="name">e1</span> for the entity record that represents what is being summarized;
-</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p>In PROV-ASN, a summary record's text matches the <span class="nonterminal">summaryRecord</span> production of the grammar.</p>
-
-<div class="grammar">
-<span class="nonterminal">summaryRecord</span> ::=
-<span class="name">wasSummaryOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<p>
-<span class="name">wasSummaryOf</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
-</p>
-
-
-</div>
-
-<div id="original-source-record" class="section">
-<h3><span class="secno">6.8 </span>Original Source Record</h3>
-
-<p>An <dfn id="dfn-original-source-record">original source record</dfn> represents an entity in
-which another entity first appeared. A original-source
-record is compliant with the
-<span class="nonterminal">originalSourceRecord</span> production.</p>
-
-
-<p> An assertion hadOriginalSource, written <span class="name"> hadOriginalSource(e2,e1,attrs)</span>, contains:</p>
-<ul>
-<li><em>entity</em>: an identifier <span class="name">e1</span> for the entity record representing the original entity; </li>
-<li><em>source</em>: an identifier <span class="name">e2</span> for an entity record, representing an entity that had appeared previously;</li>
-<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-<p>
- <span class="name">hasOriginalSource</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
-</p>
-
-<p>In PROV-ASN, an original source record's text matches the <span class="nonterminal">originalSourceRecord</span> production of the grammar.</p>
-
-<div class="grammar">
-<span class="nonterminal">originalSourceRecord</span> ::=
-<span class="name">hadOriginalSource</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-</div>
-</div>
-
- <div id="extensibility-section" class="section">
-<!--OddPage--><h2><span class="secno">7. </span>PROV-DM Extensibility Points</h2>
-
-
-<p>The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
-
-</p><ul>
-<li> Attributes are constructs of the data model that allow representations of aspects of the world's entities and activities to be expressed. Applications are free to introduce application-specific attributes, according to their perspective on the world. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace declared in a namespace declaration.
-
-<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes: <span class="name">type</span>, <span class="name">location</span>.</p></li>
-
-
-<li> Sets of Attribute-value pairs offer a mechanism to
-describe modalities of use, generation, and control
-Such attributes are also qualified by namespaces.
-
-<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
-
-
-<li>Note records allow arbitrary metadata to be associated with identifiable records of PROV-DM. Note records consist of name-value pairs. Like attributes, names are qualified by a namespace.</li>
-
-
-<li>Namespaces allow attributes and names to be qualified. </li>
-
-<li>Subtyping is allowed by means of the reserved attribute <span class="name">type</span>.</li>
-
-<li>Domain specific values can be expressed by means of typed literals. </li>
-</ul>
-
-<p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged. To ensure inter-operability, specializations of the PROV data model that exploit the extensibility points summarized in this section <em class="rfc2119" title="must">must</em> preserve the semantics specified in this document. For instance, a qualified attribute on a domain specific entity record <em class="rfc2119" title="must">must</em> represent an aspect of an entity and this aspect <em class="rfc2119" title="must">must</em> remain unchanged during the characterization's interval of this entity record.</p>
-
-
-
- </div>
-
-
-
-<div id="resource-section" class="section">
-<!--OddPage--><h2><span class="secno">8. </span>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 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3986">RFC3986</a></cite>]. 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 example 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-ASN sample below, are expressed within a same account.
-</p>
-
-<pre>container
-prefix app urn:example:
-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 idenfier that identifies the entity it represents.
-In this example, three identifiers were minted, and their prefix uses the URN syntax with "example" namespace.</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 a PROV-DM identifier, it identifies a specific characterization of this report. A given identifier identifies a single entity record 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. </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 perspective we take about that resource is expressed as a different entity record, happening to have the same identifier 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 <em class="rfc2119" title="must">must</em> be used, one of them being allowed to be the resource URI.</p>
-
-<pre>container
- prefix app http://example.org/
- prefix app2 urn:example:
- 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>
-
-
-</div>
-
-
-<!--
-<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.
--->
-
-
-<div class="appendix section" id="changes-since-first-public-working-draft">
- <!--OddPage--><h2><span class="secno">A. </span>Changes Since First Public Working Draft</h2>
-<ul>
-<li>12/08/11: Explained non-transitivity of wasInformedBy. </li>
-<li>12/05/11: Made attributes optional, and used non-terminal optional-attribute-values. </li>
-<li>12/05/11: Changed syntax of recordContainer to be more user friendly, and removed list of account ids, since redundant. </li>
-<li>12/05/11: Changed syntax of namespace declaration to be more user friendly. </li>
-<li>12/05/11: Simplified Typed literals, now allows for intLiteral, and datatype adjusted to be qualified name. </li>
-<li>11/29/11: Introduced typed identifiers to make grammar clearer. </li>
-<li>11/29/11: Added section 2.4 on grammar notation. </li>
-<li>11/28/11: Changed grammar notation. </li>
-<li>11/25/11: Updated examples of section 8. </li>
-<li>11/25/11: Definition of namespace. Clarification about interpretation of IRI occurrences. </li>
-<li>11/25/11: Definition of attribute and identifier. </li>
-<li>11/24/11: Added figure of Common Relations in Section 6. </li>
-<li>11/24/11: Updated text preceding graphical illustration, removed appendix A. </li>
-<li>11/24/11: Fix on traceability record. </li>
-<li>11/24/11: Revisited Derivation record, with a single name for derivation. </li>
-<li>11/23/11: Defined attribute, identifier, and namespace declaration. </li>
-<li>11/23/11: Consolidation of event in section 2.1.2 and linking to definitions from the rest of document. </li>
-<li>11/21/11: Added wasStartedBy between activities.</li>
-<li>11/21/11: Added wasInformedBy-ordering constraint.</li>
-<li>11/17/11: Added Traceability Record.</li>
-<li>11/17/11: Rewrote the whole section on Derivation Record.</li>
-<li>11/17/11: Updated wasDerivedFrom to refer to generation/usage record ids.</li>
-<li>11/17/11: Simplified hasAnnotation mechanism, now requiring to-be-annotated record to had id.</li>
-<li>11/17/11: Renamed annotation into note.</li>
-<li>11/17/11: Introduced wasStartedBy, wasEndedBy, and actedOnBehalfOf.</li>
-<li>11/16/11: New version of agent/wasAssociatedWith.</li>
-<li>11/16/11: Introduced class anexample.</li>
-<li>11/16/11: Changed presentation of entity and activity.</li>
-<li>11/16/11: Updated examples for usage and generation record.</li>
-<li>11/16/11: Renamed use record into usage record.</li>
-<li>11/16/11: Removed constraint generation-affects-attributes.</li>
-<li>11/16/11: Removed constraint use-attributes.</li>
-<li>11/16/11: Introduced optional identity for use and generation record.</li>
-<li>11/11/11: Swapped sections 6 and 7.</li>
-<li>11/11/11: Use attribute-value pairs uniformly, instead of qualifiers and name-value pairs.</li>
-<li>11/08/11: Renamed 'provenance container' into 'record container'.</li>
-<li>11/07/11: Addressed ISSUE-143 (qualifiers as a set of name value pairs).</li>
-<li>11/07/11: Added a section on Literals (ISSUE-142).</li>
-<li>11/07/11: Aligned terminology 'activity' and 'process execution record'.</li>
-<li>11/07/11: Renamed 'xxx Expression' into 'xxx Record' to avoid the language connotation.</li>
-<li>11/07/11: Defined entity as identifiable characterized thing, and updated text accordingly.</li>
-<li>10/08/11: Made explicit the term expression wherever was appropriate, including section titles.</li>
-</ul>
- </div>
-
-<div class="appendix section" id="acknowledgements">
- <!--OddPage--><h2><span class="secno">B. </span>Acknowledgements</h2>
- <p>
- WG membership to be listed here.
- </p>
- </div>
-
-
-<div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">C. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">C.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-IRI">[IRI]</dt><dd>M. Duerst, M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRI).</cite></a> January 2005. Internet RFC 3987. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
-</dd><dt id="bib-OWL2-SYNTAX">[OWL2-SYNTAX]</dt><dd>Boris Motik; Peter F. Patel-Schneider; Bijan Parsia. <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/"><cite>OWL 2 Web Ontology Language:Structural Specification and Functional-Style Syntax.</cite></a> 27 October 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/">http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/</a>
-</dd><dt id="bib-RDF-SPARQL-QUERY">[RDF-SPARQL-QUERY]</dt><dd>Andy Seaborne; Eric Prud'hommeaux. <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115"><cite>SPARQL Query Language for RDF.</cite></a> 15 January 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115">http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115</a>
-</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119. URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
-</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd>T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax.</cite></a> January 2005. Internet RFC 3986. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
-</dd><dt id="bib-XML-NAMES">[XML-NAMES]</dt><dd>Richard Tobin; et al. <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/"><cite>Namespaces in XML 1.0 (Third Edition).</cite></a> 8 December 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/">http://www.w3.org/TR/2009/REC-xml-names-20091208/</a>
-</dd><dt id="bib-XMLSCHEMA-2">[XMLSCHEMA-2]</dt><dd>Paul V. Biron; Ashok Malhotra. <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2: Datatypes Second Edition.</cite></a> 28 October 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/</a>
-</dd></dl></div><div id="informative-references" class="section"><h3><span class="secno">C.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-CLOCK">[CLOCK]</dt><dd>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. 1978URL: <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.
-</dd><dt id="bib-CSP">[CSP]</dt><dd>Hoare, C. A. R. <a href="http://www.usingcsp.com/cspbook.pdf"><cite>Communicating Sequential Processes</cite></a>.Prentice-Hall. 1985URL: <a href="http://www.usingcsp.com/cspbook.pdf">http://www.usingcsp.com/cspbook.pdf</a>
-</dd><dt id="bib-FOAF">[FOAF]</dt><dd>Dan Brickley, Libby Miller. <a href="http://xmlns.com/foaf/spec/"><cite>FOAF Vocabulary Specification 0.98.</cite></a> 9 August 2010. URL: <a href="http://xmlns.com/foaf/spec/">http://xmlns.com/foaf/spec/</a>
-</dd><dt id="bib-Logic">[Logic]</dt><dd>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>
-</dd><dt id="bib-PROV-O">[PROV-O]</dt><dd>Satya Sahoo and Deborah McGuinness <a href="http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html"><cite>Provenance Formal Model</cite></a>. 2011, Work in progress. URL: <a href="http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html">http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html</a>
-</dd><dt id="bib-PROV-PAQ">[PROV-PAQ]</dt><dd>Graham Klyne and Paul Groth <a href="http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html"><cite>Provenance Access and Query</cite></a>. 2011, Work in progress. URL: <a href="http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html">http://dvcs.w3.org/hg/prov/tip/paq/provenance-access.html</a>
-</dd><dt id="bib-PROV-PRIMER">[PROV-PRIMER]</dt><dd>Yolanda Gil and Simon Miles <a href="http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html"><cite>Prov Model Primer</cite></a>. 2011, Work in progress. URL: <a href="http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html">http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html</a>
-</dd><dt id="bib-PROV-SEMANTICS">[PROV-SEMANTICS]</dt><dd>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>
-</dd></dl></div></div></body></html>
Binary file model/wd2/sec6-summary.png has changed
Binary file model/wd2/timeline.png has changed
