--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/prov-dm.html.orig Thu Mar 22 09:49:16 2012 +0000
@@ -0,0 +1,2179 @@
+<!DOCTYPE html>
+
+<html><head>
+ <title>PROV-DM Part 1: The Provenance Data Model</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+<!-- PM -->
+ <style type="text/css">
+ .note { font-size:small; margin-left:50px }
+ </style>
+
+ <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
+ <script src="http://www.w3.org/2007/OWL/toggles.js" class="remove"></script>
+ <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js" class="remove"></script>
+
+ <script src="glossary.js" class="remove"></script>
+
+ <script class="remove">
+ function updateGlossaryRefs() {
+ $('.glossary-ref').each(function(index) {
+ var ref=$(this).attr('ref');
+ var span=$(this).attr('withspan')
+ $(this).removeAttr('withspan');
+ $(this).removeAttr('ref');
+
+ $('#'+ref+'.glossary').contents().clone().appendTo($(this));
+ $(this).attr("prov:hadOriginalSource",glossary_hg);
+ if (span) {
+ $(this).children('dfn').replaceWith(function(){return $('<span>').addClass('dfn').append($(this).contents())});
+ }
+ });
+ }
+ $(document).ready(function(){
+ // if glossary is in a string:
+ $('#glossary_div').html(glossary_string)
+ updateGlossaryRefs();
+ });
+
+ </script>
+
+ <script class="remove">
+ var addExtraReferences = function() {
+ for (var k in extraReferences)
+ berjon.biblio[k] = extraReferences[k];
+ };
+ var extraReferences = {
+ "CLOCK":
+ "Lamport, L. "+
+ "<a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\"><cite>Time, clocks, and the ordering of events in a distributed system</cite></a>."+
+ "Communications of the ACM 21 (7): 558–565. 1978. "+
+ "URL: <a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\">http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf</a> " +
+ "DOI: doi:10.1145/359545.359563.",
+ "CSP":
+ "Hoare, C. A. R. "+
+ "<a href=\"http://www.usingcsp.com/cspbook.pdf\"><cite>Communicating Sequential Processes</cite></a>."+
+ "Prentice-Hall. 1985"+
+ "URL: <a href=\"http://www.usingcsp.com/cspbook.pdf\">http://www.usingcsp.com/cspbook.pdf</a>",
+ "Logic":
+ "W. E. Johnson"+
+ "<a href=\"http://www.ditext.com/johnson/intro-3.html\"><cite>Logic: Part III</cite></a>."+
+ "1924. "+
+ "URL: <a href=\"http://www.ditext.com/johnson/intro-3.html\">http://www.ditext.com/johnson/intro-3.html</a>",
+ "PROV-SEM":
+ "James Cheney "+
+ "<a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\"><cite>Formal Semantics Strawman</cite></a>. "+
+ "2011, Work in progress. "+
+ "URL: <a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\">http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman</a>",
+
+ "PROV-PRIMER":
+ "Yolanda Gil and Simon Miles (eds.) Khalid Belhajjame, Helena Deus, Daniel Garijo, Graham Klyne, Paolo Missier, Stian Soiland-Reyes, and Stephan Zednik "+
+ "<a href=\"http://www.w3.org/TR/prov-primer/\"><cite>Prov Model Primer</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-primer/\">http://www.w3.org/TR/prov-primer/</a>",
+
+ "PROV-O":
+ "Satya Sahoo and Deborah McGuinness (eds.) Khalid Belhajjame, James Cheney, Daniel Garijo, Timothy Lebo, Stian Soiland-Reyes, and Stephan Zednik "+
+ "<a href=\"http://www.w3.org/TR/prov-o/\"><cite>Provenance Formal Model</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-o/\">http://www.w3.org/TR/prov-o/</a>",
+
+
+ "PROV-DM":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-dm/\"><cite>PART 1: PROV-DM ...</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-dm/\">http://www.w3.org/TR/prov-dm/</a>",
+
+
+ "PROV-DM-CONSTRAINTS":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-dm-constraints/\"><cite>PROV-DM Constraints</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-dm-constraints/\">http://www.w3.org/TR/prov-dm-constraints/</a>",
+
+ "PROV-N":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-n/\"><cite>PROV-N ....</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-n/\">http://www.w3.org/TR/prov-n/</a>",
+
+ "PROV-AQ":
+ "Graham Klyne and Paul Groth (eds.) Luc Moreau, Olaf Hartig, Yogesh Simmhan, James Meyers, Timothy Lebo, Khalid Belhajjame, and Simon Miles "+
+ "<a href=\"http://www.w3.org/TR/prov-aq/\"><cite>Provenance Access and Query</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-aq/\">http://www.w3.org/TR/prov-aq/</a>",
+ };
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "prov-dm",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ subtitle : "Initial document for discussion, WD5",
+
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "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: "2012-02-02",
+ previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.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: "Reza B'Far",
+ 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">
+ <div class="note">TO EDIT</div>
+<p>
+PROV-DM is a data model for provenance that describes
+the entities, people and activities involved in
+producing a piece of data or thing in the world. PROV-DM is
+domain-agnostic, but is equipped with extensibility points allowing
+further domain-specific and application-specific extensions to be
+defined. PROV-DM is accompanied by PROV-N, a technology-independent
+notation, which allows serializations of PROV-DM
+instances to be created for human consumption, which facilitates the
+mapping of PROV-DM to concrete syntax, and which is used as the basis for a
+formal semantics of PROV-DM.
+</p>
+ </section>
+
+<section id="sotd">
+ <div class="note">TO EDIT</div>
+<section id="prov-family">
+<!-- <h3>Prov Family of Specifications</h3>-->
+This document is part of the PROV family of specifications, a set of specifications aiming to define the various aspects that are necessary to achieve the vision of inter-operable
+interchange of provenance information in heterogeneous environments such as the Web. This document defines the PROV-DM data model for provenance, accompanied with a notation to express
+instances of that data model for human consumption. Other documents are:
+<ul>
+<li> PROV-DM-CONSTRAINTS, a set of constraints applying to the PROV-DM data model,</li>
+<li> PROV-N, a notation for provenance aimed at human consumption,</li>
+<li> PROV-O, the provenance ontology: by means of a mapping of PROV-DM to the OWL2 Web Ontology Language, this specification provides a normative serialization of PROV-DM in RDF</li>
+<li> PROV-AQ, provenance access and query: the mechanisms for accessing and querying provenance; </li>
+<li> PROV-PRIMER: a primer for the PROV-DM provenance data model,</li>
+<li> PROV-SEM: a formal semantics for the PROV-DM provenance data model.</li>
+</ul>
+</section>
+</section>
+
+
+
+<!-- <div class="buttonpanel">
+<form action="#"><p>
+<input id="hide-asn" onclick="set_display_by_class('div','withAsn','none');set_display_by_class('span','withAsn','none'); set_display_by_id('hide-asn','none'); set_display_by_id('show-asn','');" type="button"
+value="Hide ASN" />
+<input id="show-asn" onclick="set_display_by_class('div','withAsn',''); set_display_by_class('span','withAsn',''); set_display_by_id('hide-asn',''); set_display_by_id('show-asn','none');" style="display: none"
+type="button" value="Show ASN" />
+</p>
+</form>
+</div>
+-->
+
+
+
+
+ <section id="introduction">
+ <h2>Introduction<br>
+</h2>
+
+<p>
+For the purpose of this specification, <dfn>provenance</dfn> 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, where users find information that is often contradictory or
+questionable, provenance can help those users to make trust judgements.
+</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, referred to as the PROV family of specifications, define the various aspects
+that are necessary to achieve this vision in an interoperable
+way:</p>
+<ul>
+<li>A data model for provenance, which is presented in three documents:
+<ul>
+<li> PROV-DM (part I): the provenance data model itself, expressed in natural language (this document);
+<li> PROV-DM-CONSTRAINTS (part II): constraints underpinning the data model [[PROV-DM-CONSTRAINTS]];
+<li> PROV-N (part III): a notation to express instances of that data model for human consumption [[PROV-N]];
+</ul>
+</li>
+
+<li>PROV-O: a normative serialization of PROV-DM in RDF [[!PROV-O]], specified by means of a mapping to the OWL2 Web Ontology Language [[!OWL2-SYNTAX]];</li>
+<li>PROV-AQ: the mechanisms for accessing and querying provenance [[PROV-AQ]];</li>
+<li>PROV-PRIMER: a primer for the PROV approach [[PROV-PRIMER]];</li>
+<li>PROV-SEM: semantics of the PROV-DM data model [[PROV-SEM]];</li>
+</ul>
+
+
+<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-agnostic model, but with clear extensibility points allowing further domain-specific and
+application-specific extensions to be defined.</p>
+
+<p>This specification intentionally presents the key concepts of the PROV Data Model, without drilling down into all its subtleties. Using these key concepts, it becomes possible to write useful provenance assertions very quickly, and publish or embed them along side the data they relate to. </p>
+
+<p>However, if data changes, then it is challenging to express its provenance precisely, like it would be for any other form of metadata. To address this challenge, an <em>upgrade path</em> is proposed to enrich simple provenance, with extra-descriptions that help qualify the specific subject of provenance and provenance itself, with attributes and interval, intended to satisfy a comprehensive set of constraints. These aspects are covered in the companion specification [[PROV-DM-CONSTRAINTS]].
+</p>
+
+
+ <section id="structure-of-this-document">
+<h3>Structure of this Document</h3>
+
+<p><a href="#prov-dm-overview">Section 2</a> provides an overview of PROV-DM listing its core types and their relations.</p>
+
+<p>In <a href="#prov-dm-example">section 3</a>, PROV-DM is
+applied to a short scenario, encoded in PROV-N, and illustrated
+graphically.</p>
+
+<p><a href="#data-model-concepts">Section 4</a> provides the definition of PROV-DM constructs.</p>
+
+<p><a href="#common-relations">Section 5</a> introduces further relations offered by PROV-DM, including relations for data collections and domain-independent common relations.</p>
+
+<p><a href="#extensibility-section">Section 6</a> summarizes PROV-DM extensibility points.</p>
+
+<p><a href="#FurtherConsiderations">Section 7</a> introduces constraints that can be applied to the PROV data model
+and that are covered in [[PROV-DM-CONSTRAINTS]].</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="issue">
+There is a desire to use a single namespace that all specifications of the PROV family can share to refer to common provenance terms. This is <a href="http://www.w3.org/2011/prov/track/issues/224">ISSUE-224</a>.
+</div>
+
+</section>
+
+
+ <section id="conventions">
+<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='conceptualization'>
+<h1>Overview</h1>
+
+<p>This section provides an overview of the main concepts found in the PROV data model. </p>
+
+
+
+ <section id='section-entity-activity-agent'>
+<h2>Entity, Activity, Agent</h2>
+
+
+<p>PROV-DM is a data model for describing the provenance of <em>Entities</em>, that is, of things in the world. The term "Things" encompasses a broad diversity of concepts, including digital objects such as a file or web page,
+physical things such as a building or a printed book, or a car as well as abstract concepts and ideas. One can regard any Web resource as an example of Entity in this context. </p>
+
+<p>
+<div class="glossary-ref" ref="glossary-entity">
+</div>
+
+
+
+<div class="anexample" id="entity-example">
+<p>An entity may be the document at URI <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a>, a file in a file system, a car or an idea.</p>
+</div>
+
+
+
+<p>
+<span class="glossary-ref" ref="glossary-activity"></span> Activities that operate on digital entities may for example move, copy, or duplicate them.
+</p>
+
+
+
+<div class="anexample" id="activity-example">
+<p>An activity may be the publishing of a document on the web, sending a twitter message, extracting metadata embedded in a file, or driving a car from Boston to Cambridge, 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, and editing a file.</p>
+</div>
+
+
+<p>
+<span class="glossary-ref" ref="glossary-agent">
+</span>
+</p>
+
+
+<p>The motivation for introducing agents in the model is to denote the agent's responsibility for activities.
+The definition of agent intentionally stays away from using concepts such as enabling, causing, initiating, affecting, etc, because many entities also enable, cause, initiate, and affect in some way
+the activities. Concepts such as initiating are themselves defined as relations between agent and activities. So the notion of having some degree of responsibility is really what makes an agent.</p>
+
+
+<p>An agent is a particular type of Entity. This means that the model can be
+ used to express provenance of the agents themselves. </p>
+
+<div class="anexample" id="agent-example">
+<p>
+Software for checking the use of grammar in a document may be defined as an agent of a document preparation activity, and at the same time one can describe its provenance, including for instance the vendor and the version history.</p>
+</div>
+</section>
+
+
+
+ <section id="section-generation-usage-derivation">
+<h2>Generation, Usage, Derivation</h2>
+
+<p>Activities and entities are associated with each other in two different ways: activities are consumers of entities and activities are producers of entities. The act of producing or consuming an entity may have a duration.
+ The term 'generation' refers to the completion of the the act of producing; likewise, the term 'usage' refers to the beginning of the act of consuming entities. Thus, we define the following notions of generation and usage. </p>
+
+<p>
+<div class="glossary-ref" ref="glossary-generation">
+</div>
+
+
+<p>
+<div class="glossary-ref" ref="glossary-usage">
+</div>
+
+
+
+
+<p><div class="anexample" id="generation-example">
+Examples of generation are the completed creation of a file by a
+program, the completed creation of a linked data set, and the completed
+publication of a new version of a document.
+</div>
+
+
+<p>
+<div class="anexample" id="usage-example">
+Usage examples include a procedure beginning to consume an argument, a service starting to read a value on a port, a program beginning to read a configuration
+file, or the point at which an ingredient, such as eggs, is being added in a baking activity. Usage may entirely consume an entity (e.g. eggs are no longer available after being added to
+the mix); alternatively, a same entity may be used multiple times, possibly by different activities (e.g. a file on a file system can be read indefinitely).
+</div>
+
+
+<p>Activities are consumers of entities and producers of entities. In some case, the consumption of an entity influences the creation of another in some way. This notion is captured by derivations, defined as follows.</p>
+
+<p>
+<span class="glossary-ref" ref="glossary-derivation"></span>
+
+
+
+<div class="anexample" id="derivation-example">
+<p>Examples of derivation include the transformation of a relational table into a
+linked data set, the transformation of a canvas into a painting, the transportation of a work of art from London to New York, and a physical transformation such as the melting of ice into water.</p>
+</div>
+
+</section>
+
+ <section id="section-types-entities-agents">
+<h2>Types of Entities and Agents</h2>
+
+<p>There are some useful types of entities and agents that are commonly encountered in applications making data and documents available on the Web; we introduce them in this section. </p>
+
+<p>
+<span class="glossary-ref" ref="glossary-plan">
+</span>
+PROV-DM is not
+prescriptive about the nature of plans, their representation, the
+actions or steps they consist of, or their intended goals. Since plans may evolve over time,
+it may become necessary to track their provenance, so plans themselves are
+entities. Representing the plan explicitly in the provenance can be useful for various tasks: for example, to
+validate the execution as represented in the provenance record, to
+manage expectation failures, or to provide explanations.</p>
+
+<div class="anexample" id="plan-example">
+<p>
+A plan can be a blog post tutorial for how to set up a web server, a list of instructions for a micro-processor execution, a cook's written recipe for a chocolate cake, or a workflow for a scientific experiment.
+</p>
+</div>
+
+<p>
+<span class="glossary-ref" ref="glossary-collection"></span> This concept allows for the provenance of the collection, but also of its constituents to be expressed. Such a notion of collection corresponds to a wide variety of concrete data structures, such as a <em>maps</em>, <em>dictionaries</em> or <em>associative arrays</em>.</p>
+
+<div class="anexample" id="collection-example">
+<p>
+An example of collection is an archive of documents. Each document has its own provenance, but the archive itself also has some provenance: who maintained it, which documents it contained at which point in time, how it was assembled, etc.
+</div>
+
+
+<!-- alternative names: provenance record, bundle -->
+<p>
+<span class="glossary-ref" ref="glossary-accountEntity">
+</span>
+
+<div class="anexample" id="account-example">
+<p>
+Having found a resource, a user may want to retrieve its
+provenance. For users to decide whether they can place their trust in
+that resource, they may want to analyze its provenance, but also determine
+who the provenance is attributed to, and when it was
+generated. Hence, from the PROV-DM data model, the provenance is
+regarded as an entity, an AccountEntity, for which provenance can be
+sought.
+</p>
+</div>
+
+
+<p>Three types of agents are recognized by PROV-DM because they are commonly encountered in applications making data and documents available on the Web: persons, software agents, and organizations.</p>
+
+<div class="anexample" id="software-agents-example">
+<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). </p>
+</div>
+<p>So when
+someone models software as an agent for an activity in the PROV-DM model, they mean the agent has some responsibility for that activity.</p>
+</section>
+
+ <section id="section-responsibility">
+<h2>Activity Association and Responsibility</h2>
+
+
+
+
+
+<p>
+Agents are defined as having some kind of responsibility for activities. However, one may want to be more specific about the nature of an agent's responsibility.
+For example, a programmer and a researcher could both be
+associated with running a workflow, but it may not matter which
+programmer clicked the button to start the workflow while it would
+matter a lot which researcher told the programmer to do so. So there
+is some notion of responsibility that needs to be captured. </p>
+
+<!-- <div class="note"> to be revisited for WD5. Paolo's proposed text: "Agents are defined in sec. 2.1 as having some kind of responsibility for activities. However, one may want to be more specific regarding the degrees of an agent's responsibility. For example, ..."</div>
+-->
+
+
+<p>Provenance reflects activities that have occurred. In some
+cases, those activities reflect the execution of a plan that was
+designed in advance to guide the execution. PROV-DM allows associating
+a plan to an activity, which represents what was intended to
+happen. </p>
+
+<!-- <div class="note">Proposal: remove the above para as it repeats from 2.3. Proposed text: "the <em>activity association</em> relation provides a way to indicate that an agent is responsible for an activity, possibly with an associated plan."[PM]</div> -->
+
+
+<p>
+<span class="glossary-ref" ref="glossary-activityAssociation"></span>
+</p>
+
+<div class="anexample" id="association-example">
+<p>Examples of association between an activity and agent are:
+<ul>
+<li>creation of a web page under the guidance of a designer;</li>
+<li>various forms of participation in a panel discussion, including audience member, panelist, or panel chair;</li>
+<li>a public event, sponsored by a company, and hosted by a museum;</li>
+<li>an XSLT transform initiated by a user;</li>
+</ul>
+</div>
+
+<p>
+<span class="glossary-ref" ref="glossary-responsibility">
+</span> The nature of this relation is intended to be broad, including delegation or a contractual relation. </p>
+
+<!--<div class="note">Propose to rephrase as follows: <br/>
+A relation between two agents, denoted <dfn title="concept-responsibilityChain">actedOnBehalfOf</dfn> indicates that
+ that a "subordinate" agent acted on behalf of a "responsible" agent, in the context of an activity. The nature of this relation is intended to be broad, including delegation or a contractual relation.
+ When this relation is used transitively, i.e., one agent acts on behalf of another, who also acts on behalf of another, etc., these relations form a <dfn title="concept-responsibilityChain">responsibility chain</dfn>.
+</div>-->
+
+
+
+
+
+<div class="anexample" id="responsibilityChain-example">
+<p>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 which
+student published a web page but it matters a lot that the department
+told the student to put up the web page.
+</p>
+</div>
+</section>
+
+
+ <section id="section-UML">
+<h2>Overview Diagram</h2>
+
+<p> The following diagram summarizes the elements and relations just described</p>
+
+<div class="note">
+ TODO: short text required to explain the overview diagram
+<p> add a sentence saying that it is not complete coverage of the dm in diagram.</p>
+<p>The text should say that we introduce a few relations based on the concepts introduced in section 2.1-2.4, that these relations are used in the example of section 3, and are fully defined in section 4-5.</p>
+<p>The note should also say why relations are in past tense (we had something in previous version of prov-dm)</p>
+<p>I have the impression that the diagram presented in Section 2.5 would
+ > be more useful if placed at the beginning of Section 2 [KB]
+<p>There is some comments that the picture does not print well. We need to check. </p>
+<p>Add links in the svg so that we can click on the figure. </p>
+</div>
+
+
+<div style="text-align: center; ">
+ <figure style="max-width: 70%; " >
+
+
+<embed src="images/OverviewDiagram.svg" width="600" height="400" alt="PROV-DM overview" type="image/svg+xml"></embed>
+
+<!--
+ <img src="images/OverviewDiagram.svg" alt="PROV-DM overview" style="max-width: 70%; " />-->
+
+<figcaption>PROV-DM overview</figcaption>
+ </figure>
+</div>
+
+
+</section>
+</section>
+<!-- </section> -->
+
+<section id="prov-dm-example">
+<h2>Example</h2>
+
+<p>The World Wide Web Consortium publishes many technical reports. In this example, we consider a technical report, and describe its provenance. </p>
+
+<p>Specifically, we consider the second version of the PROV-DM document
+<a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">http://www.w3.org/TR/2011/WD-prov-dm-20111215</a>. Its provenance can be expressed from several perspectives, which we present. In the first one, provenance is concerned with the W3C process, whereas in the second one, it takes the authors' viewpoint. </p>
+
+
+<section id="section-example-a">
+<h3>The Process View</h3>
+
+
+<p style="font-style:italic; " ><b>Description:</b> The World Wide Web
+Consortium publishes technical reports according to its publication
+policy. Working drafts are published regularly to reflect the work
+accomplished by working groups. Every publication of a working draft
+must be preceded by a "publication request" to the Webmaster. The
+very first version of a technical report must also preceded by a
+"transition request" to be approved by the W3C director. All working
+drafts are made available at a unique URI. In this scenario, we consider two successive versions of a given report, the policy according they were published, and the associated requests.
+</p>
+
+<p>
+
+Concretely, in this section, we describe the kind of provenance record that the <a href="http://www.w3.org/Consortium">WWW Consortium</a> could keep for auditors to check that due processes are followed. All entities involved in this example are Web resources, with well defined URIs (some of which locating archived email messages, available to W3C Members).</p>
+
+<ul>
+<li> Two versions of the technical report are involved: <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> (second working draft) and <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> (first working draft);</li>
+<li> Both <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> and <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> were published by the WWW Consortium agent (<span class="name"><a href="http://www.w3.org/Consortium">w3:Consortium</a></span>); </li>
+<li> The publication activity for <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> is <span class="name">ex:act2</span>;</li>
+<li> The publication activity for <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> is <span class="name">ex:act1</span>;
+</li>
+
+<li> The report <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> is derived from <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span>;</li>
+
+<li> The publication activity <span class="name">ex:act1</span> used a <a href="http://www.w3.org/2005/08/01-transitions.html#pubreq">publication request</a> (<span class="name"><a href="https://lists.w3.org/Archives/Member/w3c-archive/2011Oct/0141">ar2:0141</a></span>) and a <a href="http://www.w3.org/2005/08/01-transitions.html#transreq">transition request</a> (<span class="name"><a href="https://lists.w3.org/Archives/Member/chairs/2011OctDec/0004">ar1:0004</a></span>);</li>
+<li> The publication activity <span class="name">ex:act2</span> used a <a href="http://www.w3.org/2005/08/01-transitions.html#pubreq">publication request</a> (<span class="name"><a href="https://lists.w3.org/Archives/Member/w3c-archive/2011Dec/0111">ar3:0111</a></span>);</li>
+<li> Technical reports were published according to the process rules (<span class="name"><a href="http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance">pr:rec-advance</a></span>), a plan in PROV-DM terminology.</li>
+</ul>
+
+<p>
+We now paraphrase some PROV-DM descriptions, and illustrate them with the PROV-N notation, a notation for PROV-DM aimed at human consumption. We then follow them with a graphical illustration. Full details of the provenance record can be found <a href="examples/w3c-publication1.prov-n">here</a>.
+
+<ul>
+<li>There is a technical report, a working draft on the recommendation track (<a href="http://www.w3.org/2005/10/Process-20051014/tr.html#RecsWD">pr:RecsWD</a>), which is regarded as an entity so that we can describe its provenance. Similar descriptions exist for all entities.
+<pre>
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+</pre>
+</li>
+<li>There is a publication activity.
+<pre>
+activity(ex:act2,,,[prov:type="publish"])
+</pre>
+</li>
+
+<li>The technical report was generated by the publication activity: this is a <a title="concept-Generation">Generation</a>.
+<pre>
+wasGeneratedBy(tr:WD-prov-dm-20111215, ex:act2)
+</pre>
+</li>
+
+
+<li>The second draft of the technical report was derived from the first draft of the technical report: this is a <a title="concept-Derivation">Derivation</a>.
+<pre>
+wasDerivedFrom(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018)
+</pre>
+</li>
+
+<li>The activity required a publication request: this is a <a title="concept-Usage">Usage</a>.
+<pre>
+used(ex:act2,ar3:0111)
+</pre>
+</li>
+
+<li>The activity was associated with the Consortium agent, and proceeded according to its publication policy: this is an <a title="concept-activityAssociation">Activity Association</a>.
+<pre>
+wasAssociatedWith(ex:act2, w3:Consortium @ pr:rec-advance)
+</pre>
+</li>
+</ul>
+
+<p>
+Provenance descriptions 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 statements. Therefore, it should not 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 octagonal shapes, respectively. Usage,
+Generation, Derivation, and Activity Association are represented as directed edges.</p>
+
+<p>Entities are laid out according to the ordering of their generation event. We endeavor to show time progressing from top to bottom. This means that edges for Usage, Generation and
+Derivation typically point upwards.</p>
+
+
+
+
+
+
+<div style="text-align: center;">
+ <figure>
+ <img src="examples/w3c-publication1.png" alt="Provenance of a Tech Report" style="max-width: 70%; "/>
+<figcaption>Provenance of a Tech Report</figcaption>
+ </figure>
+</div>
+
+<div class='note'>
+Illustration to be hand crafted instead of being generated automatically. It's important to adopt a common style for all illustrations across all PROV documents.
+<p>CG: It would be helpful to see the properties labelled in the figure.
+</div>
+
+
+<p> This simple example has shown a variety of PROV-DM constructs, such as Entity, Agent, Activity, Usage, Generation, Derivation, and ActivityAssociation. In this example, it happens that all entities were already Web resources, with readily available URIs, which we used. We note that some of the resources are public, whereas others have restricted access: provenance statements only make use of their identifiers. If identifiers do not pre-exist, e.g. for activities, then they can be generated, for instance <span class="name">ex:act2</span>, occurring in the namespace identified by prefix <span class="name">ex</span>. We note that the URI scheme developed by W3C is particularly suited for expressing provenance of these reports, since each URI denotes a specific version of a report. It then becomes very easy to relate the various versions, with PROV-DM constructs. </p>
+
+
+</section>
+<section id="section-example-b">
+<h3>The Authors View</h3>
+
+
+<p style="font-style:italic; " ><b>Description:</b> A technical report
+is edited by some editor, using contributions from various
+contributors.
+</p>
+
+
+
+<p>Here, we consider another perspective on technical report
+<a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">http://www.w3.org/TR/2011/WD-prov-dm-20111215</a>. Provenance is concerned with the document editing activity, as perceived by authors. This kind of information could be used by authors in their CV or in a narrative about this document. </p>
+
+
+
+
+<ul>
+<li> The same technical report is involved: <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>;</li>
+<li> An editing activity for <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> is <span class="name">ex:edit1</span>;</li>
+<li> The report <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> is generated by activity <span class="name">ex:edit1</span>;</li>
+<li> Several persons are associated with activity <span class="name">ex:edit1</span>, some in an editorial role, some in a contributor's role.</li>
+</ul>
+
+<p>Again, we paraphrase some PROV-DM assertions, and illustrate them with the PROV-N notation.
+Full details of the provenance record can be found <a href="examples/w3c-publication3.prov-n">here</a>.</p>
+
+<ul>
+<li>There is a technical report, which from the author's perspective is a document in its second version.
+<pre>
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
+</pre>
+<p>While this description is about the same report <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, its details differ from the author's perspective: it is a document and it has a version number. </p></li>
+
+<li>There is an editing activity.
+<pre>
+activity(ex:edit1,,,[prov:type="edit"])
+</pre>
+</li>
+
+<li>The technical report was generated by the editing activity: this is a <a title="concept-generation">Generation</a>.
+<pre>
+wasGeneratedBy(tr:WD-prov-dm-20111215, ex:edit1)
+</pre>
+</li>
+
+
+<li>There are some agents.
+<pre>
+agent(ex:Paolo, [ prov:type="Person" ])
+agent(ex:Simon, [ prov:type="Person" ])
+</pre>
+</li>
+
+<li>Agents were assigned various responsibilities in the editing activity: contributor and editor.
+<pre>
+wasAssociatedWith(ex:edit1, ex:Paolo, [prov:role="editor"])
+wasAssociatedWith(ex:edit1, ex:Simon, [prov:role="contributor"])
+</pre>
+</li>
+</ul>
+
+
+
+<div style="text-align: center;">
+ <figure>
+ <img src="http://www.w3.org/2011/prov/wiki/images/c/cd/W3c-publication3.png" alt="Provenance of a Tech Report (b)" style="max-width: 98%; "/>
+<figcaption id="prov-tech-report">Provenance of a Tech Report (b)</figcaption>
+ </figure>
+</div>
+
+<div class='note'>
+Illustration to be hand crafted instead of being generated automatically. It's important to adopt a common style for all illustrations across all PROV documents.
+<p>CG: It would be helpful to see the properties labelled in the figure.
+<p> simplify the figure (leave just 2 authors (as in the example), or the editors), and label the edges as well.
+</div>
+
+</section>
+
+<section id="section-example-c">
+<h3>Attribution of Provenance</h3>
+
+<p>The two previous sections provide two different perspectives on the provenance of a technical report. By design, the PROV approach allows for the provenance of a subject to be provided by multiple sources. For users to decide whether they can place their trust in the technical report, they may want to analyze its provenance, but also determine
+who the provenance is attributed to, and when it was
+generated, etc. In other words, we need to be able to express the provenance of provenance.</p>
+
+<p>No new mechanism is required to support this requirement. PROV-DM makes the assumption that provenance statements have been bundled up, and named, by some mechanism outside the scope of PROV-DM. For instance, in this case, provenance statements were put in a file and exposed on the Web, respectively at <a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/examples/w3c-publication1.pn">ex:prov1</a> and <a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/examples/w3c-publication3.pn">ex:prov3</a>. To express their respective provenance, these resources must be seen as entities, and all the constructs of PROV-DM are now available to characterize their provenance. In the example below, <span class="name">ex:prov1</span> is attributed to the agent <span class="name">w3:Consortium</span>, whereas <span class="name">ex:prov3</span> to <span class="name">ex:Simon</span>.
+
+<pre>
+entity(ex:prov1, [prov:type="prov:AccountEntity" %% xsd:QName ])
+wasAttributedTo(ex1:prov1,w3:Consortium)
+
+entity(ex:prov3, [prov:type="prov:AccountEntity" %% xsd:QName ])
+wasAttributedTo(ex1:prov3,ex:Simon)
+</pre>
+
+
+
+</section>
+
+</section>
+
+<section id="data-model-concepts">
+
+<h2>PROV-DM Core</h2>
+
+<p>In this section, we revisit each concept introduced in <a href="'#conceptualization'">Section 2</a>, and provide its detailed definition in the PROV data model, in terms of its various constituents. </p>
+
+<p>In PROV-DM, we distinguish elements from relations, which are respectively discussed in
+<a href="'#term-element'">Section 4.1</a> and <a href="'#term-relation'">Section 4.2</a>.</p>
+
+<section id="term-element">
+<h3>Element</h3>
+
+
+ <section id="term-Entity">
+
+<h4>Entity</h4>
+
+
+<div class="glossary-ref" ref="glossary-entity" withspan="true"></div>
+
+
+<p><div class="attributes" id="attributes-entity">An entity<span class="withPn">, written <span class="pnExpression" id="pn-entity">entity(id, [ attr1=val1, ...])</span> in PROV-N, </span> contains:
+<ul>
+<li><span class='attribute'>id</span>: an identifier for an entity; </li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs representing this entity's situation in the world.</li>
+</ul></div>
+
+<div class="anexample">
+<p>
+The following expression</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
+</pre>
+states the existence of an entity, denoted by identifier <span class="name">tr:WD-prov-dm-20111215</span>, with type <span class="name">document</span> and version number <span class="name">2</span>. The attributes <span class="name">ex:version</span> is application specific, whereas the attribute <span
+class="name">type</span> is reserved in the PROV-DM namespace.
+<!--The following expression</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
+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>
+
+<p>Further considerations:</p>
+<ul>
+<li>The sets of Activities and Entities are disjoint, as described below.</li>
+</ul>
+
+
+<div class='issue'>The characterization interval of an entity is currently implicit. Making it explicit would allow us to define wasComplementOf more precisely.
+Beginning and end of characterization interval could be expressed by attributes (similarly to activities).
+How do we define the end of an entity? This is <a href="http://www.w3.org/2011/prov/track/issues/204">ISSUE-204</a>.
+</div>
+
+
+
+ </section>
+
+ <section id="term-Activity">
+
+<h3>Activity</h3>
+
+<div class="glossary-ref" ref="glossary-activity" withspan="true"></div>
+
+<p><div class="attributes" id="attributes-activity"> An activity<span class="withPn">, written <span class="pnExpression" id="pn-activity">activity(id, st, et, [ attr1=val1, ...])</span> in PROV-N,</span> contains:
+<ul>
+<li><span class='attribute'>id</span>: an identifier for an activity;</li>
+<li><span class='attribute'>startTime</span>: an OPTIONAL time for the start of the activity;</li>
+<li><span class='attribute'>endTime</span>: an OPTIONAL time for the end of the activity;</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs for this activity.</li>
+</ul></div>
+
+<div class="anexample">
+<p>
+The following expression</p>
+<pre class="codeexample">
+activity(a1,2011-11-16T16:05:00,2011-11-16T16:06:00,
+ [ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
+</pre>
+<p>states the existence of an activity with identifier <span class="name">a1</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>. The attribute <span class="name">host</span> is application specific (declared in some namespace with prefix <span class="name">ex</span>). The attribute <span
+class="name">type</span> is a reserved attribute of PROV-DM, allowing for sub-typing to be expressed.</p>
+</div>
+
+
+
+<p>Further considerations:</p>
+<ul>
+<li>An activity is not an entity. This distinction is similar to the distinction between
+'continuant' and 'occurrent' in logic [[Logic]].
+</li>
+</ul>
+
+
+</section>
+
+<section id="term-Agent">
+<h3>Agent</h3>
+
+<div class="glossary-ref" ref="glossary-agent" withspan="true"></div>
+
+
+<p><div class="attributes" id="attributes-agent">An agent<span class="withPn">, noted <span class="pnExpression" id="pn-agent">agent(id, [ attr1=val1, ...])</span> in PROV-N,</span> contains:
+<ul>
+<li><span class='attribute'>id</span>: an identifier for an agent;</li>
+<li><span class='attribute'>attributes</span>: a set of attribute-value pairs representing this agent's situation in the world.
+</li>
+</ul></div>
+
+
+<p>
+From an interoperability perspective, it is useful to define some basic categories of agents since
+it will improve the use of provenance 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 since they are common across most anticipated domains of use:
+<ul>
+<li><span class="name">Person</span>: agents of type Person are people.</li>
+<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc.</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>
+
+
+
+<div class="anexample">
+<p>The following expression is about an agent identified by <span class="name">e1</span>, which is a person, named Alice, with employee number 1234.</p>
+<pre class="codeexample">
+agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Person" %% xsd:QName])
+</pre>
+<p>It is optional to specify the type of an agent. When present, it is expressed using the <span class="name">prov:type</span> attribute.</p>
+</div>
+
+<div class='issue'> Shouldn't we allow for entities (not agent) to be associated with an activity? Should we drop the inference association-agent? <a
+href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
+
+</section>
+
+ <section id="term-note">
+
+<h4>Note</h4>
+
+<p>As provenance descriptions are exchanged between systems, it may be useful to add extra-information to what they are describing. For instance, a "trust service" may add value-judgements about the
+trustworthiness of some of the entities or agents involved. Likewise, an interactive visualization component may want to enrich a set of provenance descriptions with information helping reproduce their
+visual representation. To help with interoperability, PROV-DM introduces a simple annotation mechanism allowing anything that is identifiable to be associated with notes.</p>
+
+<p><div class="attributes" id="attributes-note">A <dfn title="dfn-note">note</dfn><span class="withPn">, noted <span class="pnExpression">note(id, [ attr1=val1, ...])</span> in PROV-N,</span> contains:
+<ul>
+<li><span class='attribute'>id</span>: an identifier for a note;</li>
+<li><span class='attribute'>attributes</span>: a set of attribute-value pairs, whose meaning is application specific.</li>
+</ul></div>
+
+
+
+
+<p>A separate PROV-DM relation is used to associate a note with something that is identifiable (see <a href="#term-annotation">Section on annotation</a>). A given note may be associated with
+multiple identifiable things.
+</p>
+
+
+<div class="anexample" id="anexample-note1">
+<p>
+The following note consists of a set of application-specific attribute-value pairs, intended
+to help the rendering of what it is associated with, by
+specifying its color and its position on the screen.</p>
+<pre class="codeexample">
+note(ex2:n1,[ex2:color="blue", ex2:screenX=20, ex2:screenY=30])
+hasAnnotation(tr:WD-prov-dm-20111215,ex2:n1)
+</pre>
+<p>The note is associated with the entity <span class="name">tr:WD-prov-dm-20111215</span> previously introduced (<a title="annotation">hasAnnotation</a> is
+discussed in Section <a href="#term-annotation">Annotation</a>). The note's identifier and attributes are declared in a separate namespace denoted by prefix <span class="name">ex2</span>.
+</p>
+</div>
+
+<div class="anexample" id="anexample-note2">
+<p>Alternatively, a reputation service may enrich a provenance record with notes providing reputation ratings about agents. In the following fragment, both agents <span class="name">ex:Simon</span> and <span class="name">ex:Paolo</span> are rated "excellent".</p>
+<pre class="codeexample">
+note(ex3:n2,[ex3:reputation="excellent"])
+hasAnnotation(ex:Simon,ex3:n2)
+hasAnnotation(ex:Paolo,ex3:n2)
+</pre>
+<p>The note's identifier and attributes are declares in a separate namespace denoted by prefix <span class="name">ex3</span>.</p>
+
+</div>
+
+
+ </section>
+
+</section>
+
+
+<section id="term-relation">
+<h3>Relation</h3>
+
+<p>
+This section describes all the PROV-DM relations between the elements introduced in <a href="#term-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="derivations">wasDerivedFrom</a><br><a title="dfn-alternate">alternateOf</a><br><a title="dfn-specialization">specializationOf</a></td><td><a
+title="dfn-Generation">wasGeneratedBy</a></td><td>—</td><td><a title="dfn-annotation">hasAnnotation</a></td></tr>
+<tr><td>Activity</td><td><a title="usage">used</a></td><td>—</td><td><a title="start record">wasStartedBy</a><br><a title="end record">wasEndedBy</a><br><a title="dfn-activity-association">wasAssociatedWith</a></td><td><a title="dfn-annotation">hasAnnotation</a></td></tr>
+<tr><td>Agent</td><td>—</td><td>—</td><td><a title="dfn-responsibility-chain">actedOnBehalfOf</a></td><td><a title="dfn-annotation">hasAnnotation</a></td></tr>
+<tr><td>Note</td><td>—</td><td>—</td><td>—</td><td><a title="dfn-annotation">hasAnnotation</a></td></tr>
+</table>
+</div>
+
+
+
+<section id="activity-entity-relation">
+<h3>Activity-Entity Relation</h3>
+
+<section id="term-Generation">
+<h4>Generation</h4>
+
+<div class="glossary-ref" ref="glossary-generation" withspan="true"></div>
+
+<p>
+<div class="attributes" id="attributes-generation"><dfn title="dfn-Generation">Generation</dfn><span class="withPn">, written <span class="pnExpression">wasGeneratedBy(id,e,a,t,attrs)</span> in PROV-N,</span> has the following components:
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier for a generation;</li>
+<li><span class='attribute'>entity</span>: an identifier for a created entity; </li>
+<li><span class='attribute'>activity</span>: an OPTIONAL identifier for the activity that creates the entity;</li>
+
+<li><span class='attribute'>time</span>: an OPTIONAL "generation time", the time at which the entity was completely created;</li>
+
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs that describes the modalities of generation of this entity by this activity.</li>
+</ul></div>
+<p>While each of the components <span class='attribute'>activity</span>, <span class='attribute'>time</span>, and <span class='attribute'>attributes</span> is OPTIONAL, at least one of them MUST be present.</p>
+
+
+
+
+
+<div class='anexample'>
+<p>
+The following expressions</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 generations (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, identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an
+activity, 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> are application specific.
+</p>
+</div>
+
+
+<div class='anexample'>
+<p>
+In some cases, we may want to record the time at which an entity was generated without having to specify the activity that generated it. To support this requirement, the activity component in generation is optional. Hence, the following expression indicates the time at which an entity is generated, without naming the activity that did it.</p>
+<pre class="codeexample">
+ wasGeneratedBy(e,,2001-10-26T21:32:52)
+</pre>
+</div>
+
+
+</section>
+
+
+<section id="term-Usage">
+<h3>Usage</h3>
+
+<div class="glossary-ref" ref="glossary-usage" withspan="true"></div>
+
+
+<p><div class="attributes" id="attributes-usage"><dfn title="dfn-Usage">Usage</dfn><span class="withPn">, written <span class="pnExpression">used(id,a,e,t,attrs)</span> in PROV-N,</span> has the following constituents:
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier for a usage;</li>
+<li><span class='attribute'>activity</span>: an identifier for the consuming activity;</li>
+<li><span class='attribute'>entity</span>: an identifier for the consumed entity;</li>
+<li><span class='attribute'>time</span>: an OPTIONAL "usage time", the time at which the entity started to be used;</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs that describe the modalities of usage of this entity by this activity.</li>
+</ul></div>
+
+<p>
+A reference to a given entity MAY appear in multiple usages that share
+ a given activity identifier.
+</p>
+
+
+<div class='anexample'>
+<p>The following usages</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 identified by <span class="name">a1</span> consumed two entities 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> is application specific.</p>
+</div>
+
+
+
+<div class='note'>
+
+
+
+<p>
+A usage record's id is OPTIONAL. It MUST be present when annotating usage records (see Section <a href="#term-annotation">Annotation Record</a>) or when defining precise-1 derivations (see
+<a href="#Derivation-Relation">Derivation</a>).</p>
+</div>
+
+
+
+
+</section>
+</section>
+
+
+
+
+
+<section id="activity-agent-relation">
+<h3>Activity-Agent Relation</h3>
+
+<section id="term-ActivityAssociation">
+<h4>Activity Association</h4>
+
+<div class="glossary-ref" ref="glossary-activityAssociation" withspan="true"></div>
+
+<p>As far as responsibility is concerned, PROV-DM offers two kinds of constructs. The first, introduced in this section, is a relation between an agent, a plan, and an activity; the second, introduced in <a
+href="#term-responsibility">Section Responsibility</a>, is a relation between agents expressing that an agent was acting on behalf of another, in the context of an activity. </p>
+
+
+<p><div class="attributes" id="attributes-activity-association">An <dfn title="dfn-activity-association">activity association</dfn><span class="withPn">, written <span class="pnExpression">wasAssociatedWith(id,a,ag,pl,attrs)</span> in PROV-N,</span> has the following
+constituents:
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier for the association between an activity and an agent;</li>
+<li><span class='attribute'>activity</span>: an identifier for the activity;</li>
+<li><span class='attribute'>agent</span>: an identifier for the agent associated with the activity;</li>
+<li><span class='attribute'>plan</span>: an OPTIONAL identifier for the plan adopted by the agent in the context of this activity;
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs that describe the modalities of association of this activity with this agent.</li>
+</ul></div>
+
+<div class="anexample">
+In the following example, a designer and an operator agents are associated with an activity. The designer's goals are achieved by a workflow <span class="name">ex:wf</span>.
+<pre class="codeexample">
+activity(ex:a,[prov:type="workflow execution"])
+agent(ex:ag1,[prov:type="operator"])
+agent(ex:ag2,[prov:type="designer"])
+wasAssociatedWith(ex:a,ex:ag1,[prov:role="loggedInUser", ex:how="webapp"])
+wasAssociatedWith(ex:a,ex:ag2,ex:wf,[prov:role="designer", ex:context="project1"])
+entity(ex:wf,[prov:type="prov:Plan"%% xsd:QName, ex:label="Workflow 1",
+ ex:url="http://example.org/workflow1.bpel" %% xsd:anyURI])
+</pre>
+Since the workflow <span class="name">ex:wf</span> is itself an entity, its provenance can also be expressed in PROV-DM: it can be generated by some activity and derived from other entities,
+for instance.
+</div>
+
+<div class='issue'> The activity association record does not allow for a plan to be asserted without an agent.
+This seems over-restrictive. Discussed in the context of <a href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
+
+
+<div class='issue'> Agents should not be inferred. WasAssociatedWith should also work with entities.
+This is <a href="http://www.w3.org/2011/prov/track/issues/206">ISSUE-206</a>.</div>
+
+
+</section>
+
+<section id="term-Start-End">
+<h4>Activity Start and Activity End</h4>
+
+<p> A <dfn title="dfn-Start">activity start</dfn> is a representation of an agent starting an activity.
+ An <dfn title="dfn-End">activity end</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>An activity start<span class="withPn">, written <span class="pnExpression">wasStartedBy(id,a,ag,attrs)</span> in PROV-N,</span> contains:</p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier for the activity start;</li>
+<li><span class='attribute'>activity</span>: an identifier for the started activity;
+<li><span class='attribute'>agent</span>: an identifier for the agent starting the activity;
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs describing modalities according to which the agent started the activity.
+</ul>
+
+<p>An activity end<span class="withPn">, written <span class="pnExpression">wasEndedBy(id,a,ag,attrs)</span> in PROV-N,</span> contains:</p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier for the activity end;</li>
+<li><span class='attribute'>activity</span>: an identifier for the ended activity;
+<li><span class='attribute'>agent</span>: an identifier for the agent ending the activity;
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs describing modalities according to which the agent ended the activity.
+</ul>
+
+
+<div class="anexample">
+<p>
+In the following example,</p>
+<pre class="codeexample">
+wasStartedBy(a,ag,[ex:mode="manual"])
+wasEndedby(a,ag,[ex:mode="manual"])
+</pre>
+<p>there is an activity denoted by <span class="name">a</span>
+that was started and ended by an agent denoted by <span class="name">ag</span>, in "manual" mode, an application specific characterization of these relations.
+</p>
+</div>
+
+<div class='issue'>
+Should we define start/end records as representation of activity start/end events.
+Should time be associated with these events rather than with activities. This will be similar to what
+we do for entities. This is issue <a href="http://www.w3.org/2011/prov/track/issues/207">ISSUE-207</a>.</div>
+
+
+</section>
+
+
+
+
+</section>
+
+<section id="entity-entity-agent-agent-relation">
+<h4>Entity-Entity or Agent-Agent Relation</h4>
+
+<section id="term-responsibility">
+
+<h4>Responsibility Chain</h4>
+
+<div class="glossary-ref" ref="glossary-responsibilityChain" withspan="true"></div>
+
+<p>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 do not 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><div class="attributes" id="attributes-responsibility-chain">A <dfn title="dfn-responsibility-chain">responsibility chain</dfn><span class="withPn">, written <span class="pnExpression">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-N,</span> has the following constituents:
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier for the responsibility chain;</li>
+<li><span class='attribute'>subordinate</span>: an identifier for the agent associated with an activity, acting on behalf of the responsible
+agent;</li>
+<li><span class='attribute'>responsible</span>: an identifier for the agent, on behalf of which the subordinate agent acted;</li>
+<li><span class='attribute'>activity</span>: an OPTIONAL identifier of an activity for which the responsibility chain holds;</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs that describe the modalities of this relation.</li>
+</ul></div>
+
+
+<div class="anexample">
+In the following example, a programmer, a researcher and a funder agents are described. The programmer 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. The terms
+'delegation' and 'contact' used in this example are domain specific.
+<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>
+
+<p>Further considerations:</p>
+<ul>
+<li>If an activity is not specified, then the subordinate agent is considered to act on behalf of
+the responsible agent, in all the activities the subordinate agent is associated with.
+</li>
+</ul>
+</section>
+<section id="Derivation-Relation">
+
+<h4>Derivation</h4>
+
+<div class="glossary-ref" ref="glossary-derivation" withspan="true"></div>
+
+
+
+
+<p>According to <a href="#conceptualization">Section Overview</a>, for an entity to be transformed from, created from, or resulting from an update to another, there must be some
+underpinning activities performing the necessary actions resulting in such a derivation.
+A derivation can be described at various levels of precision. In its simplest form, derivation relates two entities. Optionally, attributes can be added to describe modalities of derivation. If the derivation is the result of a single known activity, then this activity can also be optionally expressed. And to provide a completely accurate description of derivation, the generation and usage of the generated and used entities, respectively, can be provided. The reason for optional information such as activity, generation, and usage to be linked to derivations is to aid analysis of provenance and to facilitate provenance-based reproducibility. </p>
+
+
+<p><div class="attributes" id="attributes-derivation">A <dfn>derivation</dfn><span class="withPn">, written <span class="pnExpression" id="pn-wasDerivedFrom">wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)</span> in PROV-N,</span> contains:
+<ul>
+<li><em>id</em>: an OPTIONAL identifier for a derivation;</li>
+<li><em>generatedEntity</em>: the identifier of the entity generated by the derivation;</li>
+<li><em>usedEntity</em>: the identifier of the entity used by the derivation;</li>
+<li><em>activity</em>: an OPTIONAL identifier for the activity using and generating the above entities;</li>
+<li><em>generation</em>: an OPTIONAL identifier for the generation involving the generated entity and activity;</li>
+<li><em>usage</em>: an OPTIONAL identifier for the usage involving the used entity and activity;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs that describe the modalities of this derivation.</li>
+</ul>
+</div>
+
+<p> Derivation is not defined to be transitive. Domain-specific specializations of derivation may be defined in such a way that the transitivity property
+holds.</p>
+
+
+
+
+
+<div class="anexample">
+<p>The following descriptions state the existence of derivations.</p>
+<pre class="codeexample">
+wasDerivedFrom(e2,e1)
+wasDerivedFrom(e2,e1,[prov:type="physical transform"])
+wasDerivedFrom(e2,e1,a,g2,u1)
+ wasGeneratedBy(g2,e2,a)
+ used(u1,a,e1)
+</pre>
+<p>
+The first and second lines are about derivations between <span class="name">e2</span> and <span class="name">e1</span>, but no information is provided as to the identity of the activity (and usage and generation) underpinning the derivation. In the second line, a type attribute is also provided.</p>
+<p>
+The third description expresses that activity <span class="name">a</span>,
+using the entity <span class="name">e1</span> according to usage <span class="name">u1</span>,
+ derived the
+entity <span class="name">e2</span> and generated it according to generation
+ <span class="name">g2</span>. It is followed by descriptions for generation <span class="name">g2</span> and usage <span class="name">u1</span>. With such a comprehensive description of derivation, a program that analyzes provenance can identify the activity underpinning the derivation, it can identify how the original entity <span class="name">e1</span> was used by the activity (e.g. for instance, which argument it was passed as, if the activity is the result of a function invocation), and which output the derived entity <span class="name">e2</span> was obtained from (say, for a function returning multiple results).</p>
+</div>
+
+
+
+<div class='issue'> Emphasize the notion of 'affected by' <a href="http://www.w3.org/2011/prov/track/issues/133">ISSUE-133</a>.</div>
+
+
+</section>
+
+
+<section id="term-alternate-specialization">
+
+<h4>Alternate and Specialization</h4>
+
+<p>The purpose of this section is to introduce relations between two entities that refer to the same thing in the world.
+Consider for example three entities:
+</p>
+<ul>
+ <li><span class="name">e1</span> denoting "Bob, the holder of Facebook account ABC",
+
+ <li><span class="name">e2</span> denoting "Bob, the holder of Twitter account XYZ",
+
+ <li><span class="name">e3</span> denoting "Bob, the person".
+</ul>
+
+<p>These entities refer to the same real person Bob, either in different contexts, or at different levels of abstraction. Specifically:
+
+
+<ol>
+ <li>e1 and e2 refer to Bob in two contexts (as Facebook and Twitter users, respectively)
+ <li> both of e1 and e2 are more detailed than e3.
+</ol>
+
+
+
+<p>The following two relations are introduced for expressing alternative or specialized entities. </p>
+
+
+
+
+<p><div class="attributes" id="attributes-alternate">
+An <dfn title="dfn-Alternate">alternate relation</dfn><span class="withPn">, written <span class="pnExpression">alternateOf(alt1, alt2)</span> in PROV-N,</span> addresses case (1). It has the following constituents:
+<ul>
+<li><span class='attribute'>firstAlternate</span>: an identifier of the first of the two entities;</li>
+<li><span class='attribute'>secondAlternate</span>: an identifier of the second of the two entities.</li>
+</ul>
+</div>
+
+<div class="anexample" id="anexample-alternate">
+<p>The following expressions describe two persons, respectively holder of a Facebook account and a Twitter account, and their relation as alternate. </p>
+<pre class="codeexample">
+entity(facebook:ABC, [ prov:type="person with Facebook account " ])
+entity(twitter:XYZ, [ prov:type="person with Twitter account" ])
+alternateOf(facebook:ABC, twitter:XYZ)
+</pre>
+</div>
+
+
+
+<p>
+<div class="attributes" id="attributes-specialization">
+A <dfn title="dfn-Specialization">specialization relation</dfn><span class="withPn">, written <span class="pnExpression">specializationOf(sub, super)</span> in PROV-N,</span> addresses case (2). It has the following constituents:
+
+<ul>
+<li><span class='attribute'>specializedEntity</span>: an identifier of the specialized entity;</li>
+<li><span class='attribute'>generalEntity</span>: an identifier of the entity that is being specialized.</li>
+</ul>
+</div>
+
+<div class="anexample" id="anexample-specialization">
+<p>The following expressions describe two persons, the second of which is holder of a Twitter account. The second entity is a specialization of the first. </p>
+<pre class="codeexample">
+entity(ex:Bob, [ prov:type="person", ex:name="Bob" ])
+entity(twitter:XYZ, [ prov:type="person with Twitter account" ])
+specializationOf(twitter:XYZ, ex:Bob)
+</pre>
+</div>
+
+<!--
+<p>To promote take up of these relations, it is not specified whether they are transitive or symmetric. We anticipate that applications will specialize these relations according to their needs. </p>
+-->
+
+<div class='issue'>A discussion on alternative definition of these relations has not yet reached a satisfactory conclusion. This is <a
+href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a>. Also <a href="http://www.w3.org/2011/prov/track/issues/96">ISSUE-96</a>.</div>
+
+
+</section>
+</section>
+
+
+
+<section id="term-annotation">
+<h4>Annotation</h4>
+
+
+
+<span class="glossary-ref" ref="glossary-annotation" withspan="true"></span>
+
+<p>Multiple notes can
+be associated with a given identified object; symmetrically, multiple objects can be associated with a given note. Since notes have identifiers, they can also be
+annotated. The annotation mechanism (with note and annotation) forms a key aspect of the extensibility mechanism of PROV-DM (see <a
+href="#extensibility-section">extensibility section</a>).</p>
+
+<p>An <dfn title="dfn-annotation">annotation relation</dfn><span class="withPn">, written <span class="pnExpression">hasAnnotation(r,n)</span> in PROV-N,</span> has the following constituents:</p>
+<ul>
+<li><span class='attribute'>something</span>: the identifier of something being annotated;</li>
+<li><span class='attribute'>note</span>: an identifier of a note.</li>
+</ul>
+
+<div class="anexample">
+<p>
+The following expressions</p>
+<pre class="codexample">
+entity(e1,[prov:type="document"])
+entity(e2,[prov:type="document"])
+activity(a,t1,t2)
+used(u1,a,e1,[ex:file="stdin"])
+wasGeneratedBy(e2, a, [ex:file="stdout"])
+
+note(n1,[ex:icon="doc.png"])
+hasAnnotation(e1,n1)
+hasAnnotation(e2,n1)
+
+note(n2,[ex:style="dotted"])
+hasAnnotation(u1,n2)
+</pre>
+<p>describe two documents (attribute-value pair: <span class="name">prov:type="document"</span>) identified by <span class="name">e1</span> and <span
+class="name">e2</span>, and their annotation with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. The example also
+includes an activity, its usage of the first entity, and its generation of the second entity. The <a title="dfn-usage">usage</a> is annotated with a style (an application specific way
+of rendering this edge graphically). To be able to express this annotation, the usage 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="second-class-elements">
+<h3>Further Elements of PROV-DM</h3>
+
+This section introduces further elements of PROV-DM.
+
+<section id="term-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 with <a title="qualified name">qualified names</a> as data type 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 un-prefixed qualified name in the scope of this default namespace declaration
+refers to this namespace.</p>
+
+<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
+
+</section>
+
+<section id="term-identifier">
+<h4>Identifier</h4>
+
+<p>
+An <dfn id="dfn-identifier">identifier</dfn> is a <a>qualified
+ name</a>.
+</p>
+
+<p>
+A <dfn id="dfn-qualifiedName">qualified name</dfn> is a name subject to <a>namespace</a> interpretation. It consists of a <a>namespace</a>, denoted by an optional prefix, and a local name.</p>
+
+
+<p>PROV-DM stipulates that a qualified name can be mapped into an IRI
+ by concatenating the IRI associated with the prefix and the local part.</p>
+
+<p>A qualified name's prefix is OPTIONAL. If a prefix occurs in a
+ qualified name, it refers to a <a>namespace</a> declared in a namespace declaration. In the absence of prefix, the qualified name
+ refers to the <a title="default namespace declaration">default namespace</a>.</p>
+
+</section>
+
+<section id="term-attribute">
+<h4>Attribute</h4>
+
+<p>An <dfn title="dfn-attribute">attribute</dfn> is a <a>qualified name</a>.
+
+
+<p>The PROV data model introduces a pre-defined set of attributes in the <a href="#prov-dm-namespace">PROV-DM namespace</a>, which we define below.
+The interpretation of any attribute declared in another namespace is out of scope.</p>
+
+<section id="term-attribute-role">
+<h4>prov:role</h4>
+
+<p>The attribute <dfn title="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, activity start, and activity end. The attribute <span class="name">prov:role</span> is allowed to occur multiple times in a list of attribute-value pairs. The value associated with a <span
+class="name">prov:role</span> attribute MUST be a PROV-DM <a title="literal">Literal</a>.</p>
+
+<div class="anexample">
+<p>The following activity start 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>
+</section>
+
+<section id="term-attribute-type">
+<h4>prov:type</h4>
+
+<p>The attribute <dfn title="dfn-type"><span class="name">prov:type</span></dfn> provides further typing information for an element or relation. PROV-DM liberally
+defines a type as a category of things having common characteristics. PROV-DM is agnostic about the representation of types, and only states that
+the value associated with a <span class="name">prov:type</span> attribute MUST be a PROV-DM Literal. The attribute <span class="name">prov:type</span>
+is allowed to occur multiple times.</p>
+
+<div class="anexample">
+<p>The following describes an agent of type software agent.</p>
+<pre class="codeexample">
+ agent(ag, [prov:type="prov:SoftwareAgent" %% xsd:QName])
+</pre>
+</div>
+</section>
+
+
+<section id="term-attribute-label">
+<h4>prov:label</h4>
+
+<p> The attribute <dfn title="dfn-label"><span class="name">prov:label</span></dfn> provides a human-readable representation of a PROV-DM element or relation. The value associated with the attribute <span class="name">prov:label</span> MUST be a string.</p>
+
+<div class='issue'>
+ This is <a href="http://www.w3.org/2011/prov/track/issues/219">ISSUE-219</a>. </div>
+</section>
+
+
+
+<section id="term-attribute-location">
+<h4>prov:location</h4>
+
+<p>A <dfn title="dfn-Location">location</dfn> can be an identifiable geographic place (ISO 19112), but it can also be a non-geographic place such as a directory, row, or column. As such, there are numerous ways in which location can be expressed, such as by a coordinate,
+address, landmark, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations, by means of attributes. </p>
+
+
+<p>
+The attribute <dfn title="dfn-location"><span class="name">prov:location</span></dfn> is an OPTIONAL attribute of entity and activity. The value associated with the attribute <span class="name">prov:location</span> MUST be a PROV-DM Literal, expected to denote a location.
+</p>
+
+<div class="anexample">
+<p>The following expression describes entity Mona Lisa, a painting, with a location attribute. </p>
+<pre class="codeexample">
+ entity(ex:MonaLisa, [prov:location="Le Louvres, Paris", prov:type="StillImage"])
+</pre>
+</div>
+</section>
+
+
+
+
+</section>
+
+
+</section>
+
+
+
+
+<section id="term-literal">
+<h4>Literal</h4>
+
+<div class='note'>
+Usually, in programming languages, Literal are a notation for values. So, Literals should probably be moved to the serialization. Here, instead, we should define the types of values. Thoughts?
+</div>
+
+<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>
+
+
+<div class="anexample">
+<p>
+The following examples respectively are the string "abc", the string "abc", the integer number 1, and the IRI "http://example.org/foo".
+<pre class="codeexample">
+ "abc"
+ 1
+ "http://example.org/foo" %% xsd:anyURI
+</pre>
+<p>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 a <a>namespace declaration</a>.</p>
+<pre class="codeexample">
+ "ex:value" %% xsd:QName
+</pre>
+</div>
+
+
+
+</section>
+
+
+
+
+<section id="term-Time">
+<h4>Time</h4>
+
+<div class='note'>
+It's a legacy of the charter that time is a top level section. Time is a specific kind of value, and should be folded into the "value" section.
+</div>
+
+
+<p><dfn title="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [[!XMLSCHEMA-2]].</p>
+
+
+
+<p>Time is OPTIONAL in usage, generation, and activity</p>
+
+
+
+
+
+</section>
+
+</section>
+
+
+
+
+<section id="common-relations">
+<h2>PROV-DM Common Relations</h2>
+
+<p>The following figure summarizes the additional relations described in this section.
+</p>
+
+<div style="text-align: center;">
+<figure>
+<img src="images/commonRelations.svg" alt="common relations"/>
+<figcaption>PROV-DM Common Relations</figcaption>
+</figure>
+</div>
+
+
+
+
+
+<section id="term-Revision">
+<h3>Revision</h3>
+
+<p> A <dfn title="dfn-Revision">revision</dfn> is the result of revising an entity into a revised version.
+ Deciding whether something is made available as a revision of something else usually involves an agent who takes responsibility for approving that the former is a due variant of the latter.
+ The agent who is responsible for the revision may optionally be specified.
+ Revision is a particular case of <a href="#Derivation-Relation">derivation</a> of an entity into its revised version.</p>
+
+<p> A revision relation<span class="withPn">, written <span class="pnExpression">wasRevisionOf(id,e2,e1,ag,attrs)</span> in PROV-N,</span> contains:</p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier for the relation;</li>
+<li><span class='attribute'>newer</span>: the identifier of the revised entity;
+<li><span class='attribute'>older</span>: the identifier of the older entity;
+<li><span class='attribute'>responsibility</span>: an OPTIONAL identifier for the agent who approved the newer entity as a variant of the older;
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of this relation.</li>
+</ul>
+
+
+
+<div class="anexample">
+<p>
+Revisiting the example of <a href="#section-example-a">Section 3.1</a>,
+we can now state that the report
+ <span class="name">tr:WD-prov-dm-20111215</span> is a revision of
+ the report <span class="name">tr:WD-prov-dm-20111018</span>, approved by
+agent <span class="name">w3:Consortium</span>.
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+entity(tr:WD-prov-dm-20111018, [ prov:type="pr:RecsWD" %% xsd:QName ])
+wasRevisionOf(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, w3:Consortium)
+</pre>
+</div>
+
+
+
+</section> <!-- end revision -->
+
+
+<section id="term-attribution">
+<h3>Attribution</h3>
+
+<p><dfn id="dfn-attribution">Attribution</dfn> is the ascribing of an entity to an agent. More precisely, when an entity <span class="name">e</span> is attributed to agent <span class="name">ag</span>, entity <span class="name">e</span> was generated by some activity <span class="name">a</span>, which in turn was associated to agent <span class="name">ag</span>. Thus, this relation is useful when the activity is not known, or irrelevant.
+
+<p> An attribution relation<span class="withPn">, written <span class="pnExpression"> wasAttributedTo(id,e,ag,attr)</span> in PROV-N,</span> contains the following elements:</p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier for the relation;</li>
+<li><span class='attribute'>entity</span>: an entity identifier;</li>
+<li><span class='attribute'>agent</span>: the identifier of the agent whom the entity is ascribed to;</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+</ul>
+
+<div class="anexample">
+<p>
+Revisiting the example of <a href="#section-example-b">Section 3.2</a>,
+we can ascribe <span class="name">tr:WD-prov-dm-20111215</span> to some agents without having to make an activity explicit.
+<pre class="codeexample">
+agent(ex:Paolo, [ prov:type="Person" ])
+agent(ex:Simon, [ prov:type="Person" ])
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+wasAttributedTo(tr:WD-prov-dm-20111215, ex:Paolo, [prov:role="editor"])
+wasAttributedTo(tr:WD-prov-dm-20111215, ex:Simon, [prov:role="contributor"])
+</pre>
+</div>
+
+</section> <!-- end attribution -->
+
+<section id="term-OrderingOfActivities">
+<h3>Activity Ordering</h3>
+
+
+<p>The following relations express dependencies amongst activities.</p>
+
+<ul>
+ <li> An <dfn title="InformationFlowOrdering">information flow ordering relation</dfn> states that activity <span class="name">a2</span> is dependent on another <span class="name">a1</span>, by way of some entity <span class="name">e</span> that is generated by <span class="name">a1</span> and used by <span class="name">a2</span>.
+ <li>A <dfn title="ControlOrdering">control ordering relation</dfn> states that activity <span class="name">a2</span> was initiated by another activity <span class="name">a1</span>.
+</ul>
+
+<p>
+An information flow ordering relation<span class="withPn">, written as
+<span class="pnExpression">wasInformedBy(id,a2,a1,attrs)</span> in PROV-N,</span> contains:
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
+<li><span class='attribute'>informed</span>: the identifier of the informed activity;
+<li><span class='attribute'>informant</span>: the identifier of the informant activity;
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe properties of the relation.</li>
+</ul>
+<p> Relation <span class="name">wasInformedBy</span> is not transitive.</p>
+
+
+<div class="anexample">
+<p>
+Consider two long running services, which we represent by activities <span class="name">s1</span> and <span class="name">s2</span>.
+<pre class="codeexample">
+activity(s1,,,[prov:type="service"])
+activity(s2,,,[prov:type="service"])
+wasInformedBy(s2,s1)
+</pre>
+The last line indicates that some entity was generated by <span class="name">s1</span> and used by <span class="name">s2</span>.
+</div>
+
+
+<p>
+A control ordering relation<span class="withPn">, written as
+<span class="pnExpression">wasStartedBy(id, a2, a1, attrs)</span> in PROV-N,</span> contains: </p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier of the relation;</li>
+<li><span class='attribute'>started</span>: the identifier of the started activity;
+<li><span class='attribute'>starter</span>: the identifier of the activity that started the other;</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+</ul>
+
+
+
+
+<div class="anexample">
+<p>
+Suppose activities <span class="name">a1</span> and <span class="name">a2</span> are computer processes that are executed on different hosts, and that <span class="name">a1</span> started <span class="name">a2</span>. This can be expressed as in the following fragment:</p>
+<pre class="codeexample">
+activity(a1,t1,t2,[ex:host="server1.example.org",prov:type="workflow"])
+activity(a2,t3,t4,[ex:host="server2.example.org",prov:type="subworkflow"])
+wasStartedBy(a2,a1)
+</pre>
+</div>
+
+</section>
+
+<section id="term-traceability">
+<h3>Traceability</h3>
+
+<p> A <dfn title="dfn-Traceability">traceability relation</dfn> between two entities <span class="name">e2</span> and <span class="name">e1</span> is a generic dependency of <span class="name">e2</span>
+on <span class="name">e1</span> that indicates either that <span class="name">e1</span> was necessary for <span class="name">e2</span> to be created, or that <span class="name">e1</span> bears
+some responsibility for <span class="name">e2</span>'s existence.
+
+
+<p> A traceability relation<span class="withPn">, written <span class="pnExpression">tracedTo(id,e2,e1,attrs)</span> in PROV-N,</span> contains:</p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
+<li><span class='attribute'>entity</span>: an identifier identifying an entity;
+<li><span class='attribute'>ancestor</span>: an identifier identifying an ancestor entity that the former depends on;
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe properties of the relation.</li>
+</ul>
+<p>We note that the ancestor is allowed to be an agent since agents are entities. </p>
+
+<div class="anexample">
+<p>We refer to the example of <a href="#section-example-a">Section 3.1</a>, and specifically to <a href="#prov-tech-report">Figure prov-tech-report</a>. We can see that there is a path from
+<span class="name">tr:WD-prov-dm-20111215</span> to
+<span class="name">w3:Consortium</span> or to
+<span class="name">pr:rec-advance</span>. This is expressed as follows.
+<pre class="codeexample">
+ tracedTo(tr:WD-prov-dm-20111215,w3:Consortium)
+ tracedTo(tr:WD-prov-dm-20111215,pr:rec-advance)
+</pre>
+</div>
+
+
+<p>
+<a href="#Derivation-Relation">Derivation</a> and association are particular cases of traceability.
+</p>
+
+
+</section>
+
+
+
+<section id="term-quotation">
+<h3>Quotation</h3>
+
+<div class="note">I find that quotation is really a misnomer. This expands into derivation with attribution, in what sense is the derived entity a "quote" of the original? . The agent that is quoted is particularly obscure. It does not seem to be involved in the quoting at all. Why isn't quoting an activity with the quoting agent associated with it? [PM]. Need example [DG].</div>
+
+<p> A <dfn>quotation</dfn>
+ is the repeat of an entity (such as text or image) by
+someone other that its original author. Quotation
+ is a particular case of <a href="#Derivation-Relation">derivation</a> in which entity <span class="name">e2</span> is derived from entity <span class="name">e1</span> by copying, or "quoting", parts of it.</p>
+
+<p> A quotation relation<span class="withPn">, written <span class="pnExpression"> wasQuotedFrom(id,e2,e1,ag2,ag1,attrs)</span> in PROV-N,</span> contains:</p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier for the relation;</li>
+<li><span class='attribute'>quote</span>: an identifier of the entity that represents the quote (the partial copy);
+<li><span class='attribute'>quoted</span>: an identifier of the original entity being quoted;
+<li><span class='attribute'>quoterAgent</span>: an OPTIONAL identifier of the agent who is doing the quoting;
+<li><span class='attribute'>quotedAgent</span>: an OPTIONAL identifier of the agent who attributed to the original entity;
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+
+</ul>
+
+</section> <!-- end quotation -->
+
+
+<section id="term-orignal-source">
+<h3>Original Source</h3>
+
+<div class="note"> I find this relation confusing. Please add an example. I wouldn't really know when to use this. [PM]. Need example [DG]</div>
+
+<p> An <dfn>original source relation</dfn> is a particular case of <a href="#Derivation-Relation">derivation</a> that states that an entity <span class="name">e2</span> (derived) was originally part of some other entity <span class="name">e1</span> (the original source).</p>
+
+<p> An original source relation<span class="withPn">, written <span class="pnExpression"> hadOriginalSource(id,e2,e1,attrs)</span>,</span> contains:</p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
+<li><span class='attribute'>derived</span>: an identifier for the derived entity; </li>
+<li><span class='attribute'>source</span>: an identifier for the original source entity;</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+</ul>
+
+</section> <!-- end original source -->
+
+
+
+<section id="term-Collection">
+<h3>Collections</h3>
+
+<p><strong>Collection relations</strong> address the need to describe the evolution of entities that have a collection structure, that is, which may contain other entities. Specifically, this section exploits the built-in type for entities, called <a title="concept-collection">collection</a>, and two relations to describe the effect of adding elements to, and removing elements from, a collection entity.
+The intent of these relations and entity types is to capture the <em>history of changes that occurred to a collection</em>.
+Thus, a collection entity is an immutable representation of the state of a collection data structure following a sequence of insertion and deletion operations.
+</p>
+
+<p>A collection is an entity that has a logical internal structure consisting of key-value pairs, often referred to as a map.
+More precisely, the following entity types are introduced:
+
+<ul>
+ <li> <span class="name">Collection</span> denotes an entity of type collection, i.e. an entity that can participate in insertion and removal relations;
+
+ <li><span class="name">EmptyCollection</span> denotes an empty collection.
+</ul>
+
+The following relations relate a collection <span class="name">c1</span> with a collection <span class="name">c2</span> obtained after adding or removing a new pair to (resp. from) <span class="name">c1</span>:
+
+<ul>
+ <li>Insertion relation <span class="name">CollectionAfterInsertion(c2, c1, k, v)</span> states that <span class="name">c2</span> is the state of the collection
+following the insertion of pair <span class="name">(k,v)</span> into collection <span class="name">c1</span>;</li>
+
+<li> Removal relation <span class="name">CollectionAfterRemoval(c2,c1, k)</span> states that <span class="name">c2</span> is the state of the collection following the removal of the pair corresponding to key <span class="name">k</span> from <span class="name">c1</span>.</li>
+
+</ul>
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="EmptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+ entity(c1, [prov:type="Collection"])
+ entity(c2, [prov:type="Collection"])
+
+ CollectionAfterInsertion(c1, c, "k1", v1) // c1 = { ("k1",v1) }
+ CollectionAfterInsertion(c2, c1, "k2", v2) // c2 = { ("k1",v1), ("k2", v2) }
+ CollectionAfterRemoval(c3, c2, k1) // c3 = { ("k2",v2) }
+</pre>
+</div>
+
+
+<<<<<<< local
+<p> A relation CollectionAfterInsertion<span class="withPn">, written <span class="pnExpression"> CollectionAfterInsertion(collAfter, collBefore, key, value)</span>,</span> contains:</p>
+=======
+<p> A Derivation-by-Insertion relation<span class="withPn">, written <span class="pnExpression"> derivedByInsertionFrom(id, collAfter, collBefore, key, value, attrs)</span>,</span> contains:</p>
+>>>>>>> other
+<ul>
+<li><span class='attribute'>after</span>: an identifier for the collection <em>after</em> insertion; </li>
+<li><span class='attribute'>before</span>: an identifier for the collection <em>before</em> insertion;</li>
+<li><span class='attribute'>key</span>: the key that has been inserted</li>
+<li><span class='attribute'>value</span>: an identifier for the value that has been inserted with the key.</li>
+</ul>
+
+<<<<<<< local
+<p> A relation CollectionAfterDeletion, written <span class="pnExpression"> CollectionAfterDeletion(collAfter, collBefore, key)</span>, contains:</p>
+=======
+<p> A Derivation-by-Removal relation, written <span class="pnExpression"> derivedByRemovalFrom(id, collAfter, collBefore, key, attrs)</span>, contains:</p>
+>>>>>>> other
+<ul>
+<li><span class='attribute'>after</span>: an identifier for the collection <em>after</em> the deletion; </li>
+<li><span class='attribute'>before</span>: an identifier for the collection <em>before</em> the deletion;</li>
+<li><span class='attribute'>key</span>: the key corresponding to the (key, value) pair that has been deleted from the collection.</li>
+</ul>
+
+<<<<<<< local
+<div class='note'>
+I propose to call them afterInsertion instead of CollectionAfterInsertion (likewise, for deletion).
+What about attributes and optional Id?
+</div>
+=======
+As a convenience, corresponding relations for <em>bulk operations</em> involving a set of key-value pairs are introduced, as follows.
+>>>>>>> other
+
+<<<<<<< local
+=======
+<p> A Derivation-by-Bulk-Insertion relation <span class="withPn">, written <span class="pnExpression"> derivedByBulkInsertionFrom(id, collAfter, collBefore, key-value-set, attrs)</span>,</span> contains:</p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
+<li><span class='attribute'>after</span>: an identifier for the collection <em>after</em> insertion; </li>
+<li><span class='attribute'>before</span>: an identifier for the collection <em>before</em> insertion;</li>
+<li><span class='attribute'>key-value-set</span>: a set of inserted key-value pairs, of the form {(key_1, value_1), ..., (key_n, value_n)}</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+</ul>
+
+<p> A Derivation-by-Bulk-Removal relation, written <span class="pnExpression"> derivedByBulkRemovalFrom(id, collAfter, collBefore, key, attrs)</span>, contains:</p>
+<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
+<li><span class='attribute'>after</span>: an identifier for the collection <em>after</em> the deletion; </li>
+<li><span class='attribute'>before</span>: an identifier for the collection <em>before</em> the deletion;</li>
+<li><span class='attribute'>key-set</span>: a set of deleted keys, of the form {key_1,..., key_n}</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+</ul>
+
+>>>>>>> other
+
+<p>Further considerations:</p>
+
+<ul>
+ <li>The <strong>map</strong> collection type provides 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 (the specification of such specialized structures in terms of key-value pairs is out of the scope of this document).</li>
+
+<<<<<<< local
+<li>Keys are literals, and values are entities. This allows expressing nested collections, that is, collections whose values include entities of type collection.</li>
+=======
+<li>Values are entities. This allows expressing nested collections, that is, collections whose values include entities of type collection.</li>
+>>>>>>> other
+
+<<<<<<< local
+<li>Insertion and removal relations are a particular case of <a href="#Derivation-Relation">derivation</a>.</li>
+=======
+<li>As the relation names suggest, insertion and removal relations are a particular case of <a href="#Derivation-Relation">derivation</a>.</li>
+>>>>>>> other
+
+<<<<<<< local
+ <li>This representation of a collection's evolution makes no assumption regarding the underlying data structure used to store and manage collections. In particular, no assumptions are needed regarding the mutability of a data structure that is subject to updates. In fact, the state of a collection (i.e., the set of key-value pairs it contains) at a given point in a sequence of operations is never stated explicitly. Rather, it can be obtained by querying the chain of derivations involving insertions and removals. Entity type <span class="name">emptyCollection</span> can be used in this context as it marks the start of a sequence of collection operations.</li>
+=======
+<li>This representation of a collection's evolution makes no assumption regarding the underlying data structure used to store and manage collections. In particular, no assumptions are needed regarding the mutability of a data structure that is subject to updates. Entities, however, are immutable and this applies to those entities that represent collections. This is reflected in the constraints listed in Part II. </li>
+>>>>>>> other
+
+<<<<<<< local
+=======
+<li>The state of a collection (i.e., the set of key-value pairs it contains) at a given point in a sequence of operations is never stated explicitly. Rather, it can be obtained by querying the chain of derivations involving insertions and removals. Entity type <span class="name">emptyCollection</span> can be used in this context as it marks the start of a sequence of collection operations.</li>
+>>>>>>> other
+
+<<<<<<< local
+<!--
+ <li> One can have multiple assertions regarding the state of a collection following a <em>set</em> of insertions, for example:<br/>
+<span class="name">CollectionAfterInsertion(c2,c1, k1, v1)</span><br/>
+<span class="name">CollectionAfterInsertion(c2,c1, k2, v2)</span><br/>
+ <span class="name">...</span><br/>
+This is interpreted as <em>" <span class="name">c2</span> is the state that results from inserting <span class="name">(k1, v1)</span>, <span class="name">(k2, v2)</span> etc. into <span class="name">c1</span>"</em></li></p>
+
+<li> It is possible to have multiple derivations from a single root collection, possibly by different asserters, as shown in the following example.
+=======
+<li>An activity may generate a new collection, complete with its content, without visible insertion operations. Nevertheless, one can abstract the collection construction process as a sequence of insertions (or one single bulk insertion). Thus, if the content of the collection at the end of the generation is known, one can state it using the Derivation-by-Insertion relation, starting from the empty collection (or, more generally, from a collection with unknown prior state).
+>>>>>>> other
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c0, [prov:type="EmptyCollection"]) // e is an empty collection
+ activity(a)
+ entity(c1, [prov:type="Collection"])
+ wasGeneratedBy(c1,a)
+ derivedByBulkInsertionFrom(c1, c0, {("k1", v1), {("k2", v2) ) // c1 = { ("k1",v1), ("k2",v2) }
+</pre>
+</div>
+
+</ul>
+<div class='note'>Deleted further items. Some of them are constraints which belong to part 2.</div>
+
+
+</section> <!-- end collections-->
+
+
+</section>
+
+<!-- end sec. 5 -->
+
+ <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 occur in all elements and relations of the data model. 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 catering for extensibility: <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, activity association, and responsibility chain.
+Such attributes are also qualified by namespaces.
+
+<p>To this end, the <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
+
+
+<li>Notes allow arbitrary metadata to be associated with anything identifiable in PROV-DM. Notes 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>Sub-typing of elements and relations 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 interoperability, specializations of
+the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in the PROV-DM documents (part 1 to 3). </p>
+
+
+
+ </section>
+
+
+
+<section id="FurtherConsiderations">
+<h4>Data Model Constraints</h4>
+
+
+<ul>
+
+<li>This specification defines PROV-DM, a data model that allows
+descriptions of the people, institutions, entities, and activities,
+involved in producing, influencing, or delivering a piece of data or a
+thing to be expressed. However, with this data model, it is also possible to compose
+descriptions that would not make sense: for instance, one could
+express that an entity was used before it was generated, or that the
+activity that generated an entity began its existence after the entity
+generation. A set of consistency constraints have been defined for PROV-DM and
+can be found in a companion specification [[PROV-DM-CONSTRAINTS]].
+They can be used by asserters as a guideline for composing provenance descriptions that are consistent, and
+by implementers of reasoning engines. </li>
+
+
+
+<li>
+<p> The example of <a href="#prov-dm-example">section 3</a> contains identifiers such as <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, which denotes a specific version of a technical report. On the other hand, a URI such as <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a> points to the latest version of a document. One needs to ensure that provenance descriptions for the latter document remain valid as denoted resources change. </p>
+
+<p>To this end, PROV-DM allows asserters to describe "<em>partial states</em>" of entities by means of attributes and associated values. Some further constraints apply to the use of these attributes, since the values associated with them are expected to remain unchanged for some period of time. The constraints associated to attributes are also specified in the companion specification [[PROV-DM-CONSTRAINTS]].</p>
+
+
+</li>
+
+
+<li>The existence of some mechanism(s) by which a set of provenance descriptions can be bundled up and named is assumed. No such mechanism is considered as mature for standardization, and therefore such mechanisms remain outside the scope of PROV-DM. Various ways of achieving this functionality exist, for instance, by:
+<ul>
+<li> bundling up a set of descriptions in a file and exposing it as a Web resource;</li>
+<li> relying on specific serializations to name bundles of descriptions;</li>
+<li> using the idea of a service that is capable of associating provenance descriptions to whom they are attributed to.</li>
+</ul>
+<p>Even though a mechanism for blundling up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named bundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-accountEntity">AccountEntity</a> so that its provenance can be expressed. The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as constraint that <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
+</li>
+
+
+</ul>
+
+
+</section>
+
+<div id="glossary_div" class="remove">
+<!-- glossary loaded from glossary.js will be hooked up here,
+ class remove, will remove this element from the final output.
+-->
+</div>
+
+ </body>
+</html>