reorganized working-copy directory
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Mon, 10 Sep 2012 11:15:13 +0100
changeset 4439 7b668ffc729b
parent 4438 a2c9a353a958
child 4440 4e51bc624be6
reorganized working-copy directory
model/working-copy/wd6-bundle.html
model/working-copy/wd6-collections-constraints.html
model/working-copy/wd6-contextualization.html
model/working-copy/wd6-prov-constraints.html
model/working-copy/wd6-prov-dm-with-core.html
model/working-copy/wd6-prov-dm.html
model/working-copy/wd6-prov-n.html
model/working-copy/wd6-wasStartedBy.html
model/working-copy/wd6/wd6-bundle.html
model/working-copy/wd6/wd6-collections-constraints.html
model/working-copy/wd6/wd6-contextualization.html
model/working-copy/wd6/wd6-prov-constraints.html
model/working-copy/wd6/wd6-prov-dm-with-core.html
model/working-copy/wd6/wd6-prov-dm.html
model/working-copy/wd6/wd6-prov-n.html
model/working-copy/wd6/wd6-wasStartedBy.html
--- a/model/working-copy/wd6-bundle.html	Mon Sep 10 07:56:57 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,743 +0,0 @@
-<!DOCTYPE html
->
-
-<html><head> 
-    <title>PROV-DM: The PROV 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('data-ref');
-          var span=$(this).attr('data-withspan')
-          $(this).removeAttr('data-withspan');
-          $(this).removeAttr('data-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-CONSTRAINTS":
-          "James Cheney, Paolo Missier, and Luc Moreau (eds.) "+
-          "<a href=\"http://www.w3.org/TR/prov-constraints/\"><cite>Constraints of the PROV Data Model</cite></a>. "+
-          "2011, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-constraints/\">http://www.w3.org/TR/prov-constraints/</a>",
-
-        "PROV-N":
-          "Luc Moreau and Paolo Missier (eds.)"+
-          "<a href=\"http://www.w3.org/TR/prov-n/\"><cite>PROV-N: The Provenance Notation</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   :  "TEXT NOW MERGED in EDITOR'S DRAFT",
-
- 
-          // if you wish the publication date to be other than today, set this
-//          publishDate:  "2012-05-03",
- 
-          // if the specification's copyright date is a range of years, specify
-          // the start date here:
-          copyrightStart: "2011",
- 
-          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
-          // and its maturity status
-          previousPublishDate:  "2012-05-03",
-          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-dm.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: "Reza B'Far",
-                company: "Oracle Corporation" },
-              { name: "Stephen Cresswell",
-                company: "legislation.gov.uk"},
-              { name: "Yolanda Gil",
-                company: "Invited Expert", url:"http://www.isi.edu/~gil/"},
-              { 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: "Curt Tilmes", 
-                company: "National Aeronautics and Space Administration" },
-          ],
-          
-          // name of the WG
-          wg:           "Provenance Working Group",
-          
-          // URI of the public WG page
-          wgURI:        "http://www.w3.org/2011/prov/",
-          
-          // name (with the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "public-prov-wg",
-          
-          // URI of the patent status for this WG, for Rec-track documents
-          // !!!! IMPORTANT !!!!
-          // This is important for Rec-track documents, do not copy a patent URI from a random
-          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
-          // Team Contact.
-          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/46974/status",
-
-          // Add extraReferences to bibliography database
-          preProcess: [addExtraReferences],
-      };
-    </script> 
-  </head> 
-  <body> 
-
-    <section id="abstract">
-<p>
-PROV-DM, the PROV data model, is a data model for provenance that describes
-the entities, people and activities involved in
-producing a piece of data or thing. 
-PROV-DM is structured in six components, dealing with: 
-(1) entities and activities, and the time at which they were created, used, or ended;
-(2) agents bearing responsibility for entities that were generated and activities that happened;
-(3) derivations of entities from entities;
-(4) properties to link entities that refer to the same thing;
-(5) collections forming a logical structure for its members;
-(6) a simple annotation mechanism.
-</p>
-
-<p>This document introduces the provenance concepts found in
-PROV and defines PROV-DM types and
-relations. PROV data model is domain-agnostic, but is equipped with
-extensibility points allowing domain-specific information to be included. </p>
-
-<p>Two further documents complete the specification of PROV-DM.
-First, a companion document specifies the set of constraints that
-provenance descriptions should follow.  Second, 
-a separate document describes a provenance notation for expressing 
-instances of provenance for human consumption; this notation is used in examples in
-this document. </p>
-
-    </section> 
-
-<section id="sotd">
-<h4>PROV Family of Specifications</h4>
-This document is part of the PROV family of specifications, a set of specifications defining various aspects that are necessary to achieve the vision of inter-operable
-interchange of provenance information in heterogeneous environments such as the Web.  The specifications are:
-<ul>
-<li> PROV-DM, the PROV data model for provenance (this document);</li>
-<li> PROV-CONSTRAINTS, a set of constraints applying to the PROV data model;</li>
-<li> PROV-N, a notation for provenance aimed at human consumption;</li>
-<li> PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF;</li>
-<li> PROV-AQ, the mechanisms for accessing and querying provenance; </li>
-<li> PROV-PRIMER, a primer for the PROV data model;</li>
-<li> PROV-SEM, a formal semantics for the PROV data model;</li>
-<li> PROV-XML, an XML schema for the PROV data model.</li>
-</ul>
-<h4>How to read the PROV Family of Specifications</h4>
-<ul>
-<li>The primer is the entry point to PROV offering an introduction to the provenance model.</li>
-<li>The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL-RL ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. PROV-SEM provides a mathematical semantics.</li>
-<li>The XML community should focus on PROV-XML defining an XML schema for PROV. Further details can also be found in PROV-DM, PROV-CONSTRAINTS, and PROV-SEM.</li>
-<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
-<li>Readers seeking to implement other PROV serializations
-should focus on PROV-DM and PROV-CONSTRAINTS.  PROV-O, PROV-N, PROV-XML offer examples of mapping to RDF, text, and XML, respectively.</li>
-</ul>
-
-
-<h4>Fourth Public Working Draft</h4>
-<p>This is the fourth public release of the PROV-DM document. Following feedback, the Working Group has decided to reorganize this document substantially, separating the data model from its contraints and the notation used to illustrate it. The PROV-DM release is synchronized with the release of the PROV-O, PROV-PRIMER, PROV-N, and PROV-CONSTRAINTS documents. We are now clarifying the entry path to the PROV family of specifications.</p>
-</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> 
-
-
-<div style="color: red;     font-size: 150%; ">
-Summary of proposed changes:
-<ul>
-<li> Drop the term 'account' from prov-dm.
-<li> Instead, introduce the notion of bundle, as defined here.
-<li> Drop the component on annotation.
-<li> Introduce a component on bundles, as described here.
-</ul>
-</div>
-</section> 
-
-
-
-<section id='starting-points'> 
-<h1>PROV Starting Points</h1>
-
-<section > 
-<h3>...</h3>
-</section>
-<section > 
-<h3>...</h3>
-</section>
-<section > 
-<h3>...</h3>
-</section>
-
-<section id="section-provenance-of-provnance"> 
-<h2>Provenance of Provenance</h2>
-
-
-
-
-<p>
-<span class="glossary-ref" data-ref="glossary-bundle"  data-withspan="true">
-</span>
-
-<div class="conceptexample" id="bundle-example">
-<p>
-For users to decide whether they can place their trust in
-a resource, they may want to analyze the resource's provenance, but also determine
-who its provenance is attributed to, and when it was
-generated. In other words, users need to be able to determine the provenance of provenance.
-Hence, provenance is also
-regarded as an entity (of type Bundle), by which provenance of provenance can then be
-expressed.
-</p>
-</div>
-</section>
-
-<section id="section-collections"> 
-<h2>Collections</h2>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-collection"  data-withspan="true"></span> This concept allows for the provenance of the collection itself to be expressed in addition to that of the members.  Many different types of collections exist, such as a <em>set</em>, <em>dictionaries</em>, or <em>lists</em>, all of which involve a membership relationship between the constituents and the collection. </p>
-
-<div class="conceptexample" 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>
-
-
-</section>
-
-
-</section>
-
-
-<section id="prov-dm-example"> 
-<h2>Illustration of PROV-DM by an Example</h2>
-
-<section id="section-example-a"> 
-<h3>...</h3>
-</section>
-
-<section id="section-example-b"> 
-<h3>...</h3>
-</section>
-
-<section id="section-example-c"> 
-<h3>Attribution of Provenance</h3>
-
-<p>The two previous sections  offer two different perspectives on the provenance of a document.  PROV allows for multiple sources to provide the provenance of a subject. For users to decide whether they can place their trust in the document, 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>PROV-DM offers a construct to name a bundle of provenance descriptions. </p>
-
-<pre class="codeexample">
-bundle ex:author-view
-
-  agent(ex:Paolo,   [ prov:type='prov:Person' ])
-  agent(ex:Simon,   [ prov:type='prov:Person' ])
-
-
-...
-
-endBundle
-</pre>
-
-Likewise, the process view can be expressed as a separate named bundle.
-<pre class="codeexample">
-bundle ex:process-view
-
-   agent(w3:Consortium, [ prov:type='prov:Organization' ])
-
-...
-
-endBundle
-</pre>
-
-<p>To express their respective provenance, these bundles must be seen as entities, and all PROV constructs are now available to express their provenance. In the example below, <span class="name">ex:author-view</span> is attributed to the agent  <span class="name">ex:Simon</span>, whereas <span class="name">ex:process-view</span> to  <span class="name">w3:Consortium</span>.
-
-<pre class="codeexample">
-entity(ex:author-view, [prov:type='prov:Bundle' ])
-wasAttributedTo(ex:author-view, ex:Simon)
-
-entity(ex:process-view, [prov:type='prov:Bundle' ])
-wasAttributedTo(ex:process-view, w3:Consortium)
-</pre>
-
-<div class="note">
-<p>TODO: full details of bundles can be found at  <a href="examples/w3c-publication1.pn">ex:process-view</a> and <a href="examples/w3c-publication3.pn">ex:author-view</a>.</p>
-</div>
-
-
-</section>
-
-</section>
-
-</section>
-
-<section id="data-model-components"> 
-
-<h2>PROV-DM Types and Relations</h2>
-
-<section id="component1"> 
-<h3>Component 1: Entities and Activities</h3>
-</section>
-
-<section id="component2"> 
-<h3>Component 2: Agents and Responsibility</h3>
-</section>
-
-<section id="component3"> 
-<h3>Component 3: Derivations</h3>
-</section>
-
-<section id="component4"> 
-<h3>Component 4: Alternate Entities</h3>
-</section>
-
-<section id="component5"> 
-<h3>Component 5: Collections</h3>
-</section>
-
-<section id="component6"> 
-<h3>Component 6: Bundles</h3>
-
-
-
-
-
-
-
-
-<section id="term-bundle"> 
-
-<h3>Bundle Declaration</h3>
-
-
-<p>
-<span class="glossary-ref" data-ref="glossary-bundle" >
-</span>
- </p>
-
-
-
-
-<p>
-<div class="attributes" id="attributes-bundle">
- A <dfn title="dfn-bundle" id="dfn-bundle-declaration">bundle declaration</dfn>, written <span class="pnExpression">bundle id description_1 ... description_n endBundle</span>, consists of:
-<ul>
-<li><span class='attribute' id="bundle.declaration.id">id</span>:  an identifier for the bundle;</li>
-<li><span class='attribute' id="bundle.declaration.descriptions">descriptions</span>: a set of provenance descriptions <span class="name">
-description_1</span>, ..., <span class="name">description_n</span>.</li>
-</ul>
-<p>A bundle's identifier <span class="name">id</span> identifies a unique set of descriptions.</p>
-</section>
-
-
-
-
-
-<section id="term-bundle-entity"> 
-
-<h3>Bundle Description</h3>
-
-<p>As a named bundle is a set of descriptions, it is also an entity so that its provenance can be described.  </p>
-
-PROV defines the following type for bundles:
-<ul>
-<li><span class="name">prov:Bundle</span> is the type that denotes <a title="bundle">bundles</a>.
-</ul>
-
-
-<p>
-A  bundle description is of the form <span class="pnExpression">entity(id,[prov:type='prov:Bundle', attr1=val1, ...])</span>
-where <span class='name'>id</span> is  an identifier denoting a bundle,
- a type <span>prov:Bundle</span> and
-an OPTIONAL set of attribute-value  pairs ((<span class="name">attr1</span>, <span class="name">val1</span>), ...) representing additional information about this bundle.
-</p>
-
-
-<p>The provenance of provenance can then be described using PROV constructs, as illustrated by the following example. </p>
-
-<div class="anexample" id="anexample-provenance-of-provenance">
-<p>Let us consider an example consisting of two entities <span class="name">ex:report1</span> and <span class="name">ex:report2</span>.</p>
-<pre class="codeexample"> 
-entity(ex:report1, [ prov:type="report", ex:version=1 ])
-wasGeneratedBy(ex:report1, -, 2012-05-24T10:00:01)
-entity(ex:report2, [ prov:type="report", ex:version=2])
-wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-wasDerivedFrom(ex:report2, ex:report1)
-</pre>
-
-<p>Let us assume that Bob observed the creation of <span class="name">ex:report1</span>.
-A first bundle can be expressed.</p>
-<pre class="codeexample"> 
-bundle bob:bundle1
-  entity(ex:report1, [ prov:type="report", ex:version=1 ])
-  wasGeneratedBy(ex:report1, -, 2012-05-24T10:00:01)
-endBundle
-</pre>
-
-<p>In contrast,
-Alice observed the creation of <span class="name">ex:report2</span> and its derivation from <span class="name">ex:report1</span>.
-A separate bundle can also be expressed.</p>
-<pre class="codeexample"> 
-bundle alice:bundle2
-  entity(ex:report1)
-  entity(ex:report2, [ prov:type="report", ex:version=2 ])
-  wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-  wasDerivedFrom(ex:report2, ex:report1)
-endBundle
-</pre>
-
-<p>The first bundle contains the descriptions corresponding to  Bob observing the creation of <span class="name">ex:report1</span>. Its provenance can be described as follows.</p>
-<pre class="codeexample"> 
-entity(bob:bundle1, [prov:type='prov:Bundle'])
-wasGeneratedBy(bob:bundle1, -, 2012-05-24T10:30:00)
-wasAttributedTo(bob:bundle1, ex:Bob)
-</pre>
-
-<p>In contrast, the second bundle is attributed to Alice who
-observed the derivation of <span class="name">ex:report2</span> from <span class="name">ex:report1</span>.</p>
-<pre class="codeexample"> 
-entity(alice:bundle2, [ prov:type='prov:Bundle' ])
-wasGeneratedBy(alice:bundle2, -, 2012-05-25T11:15:00)
-wasAttributedTo(alice:bundle2, ex:Alice)
-</pre>
-</div>
-
-<div class="anexample" id="anexample-provenance-aggregation">
-<p>A provenance aggregator could merge two bundles, resulting in a novel bundle, whose provenance is described as follows.</p>
-<pre class="codeexample"> 
-bundle uuid:03
-  entity(ex:report1, [ prov:type="report", ex:version=1 ])
-  wasGeneratedBy(ex:report1, -, 2012-05-24T10:00:01)
-
-  entity(ex:report2, [ prov:type="report", ex:version=2 ])
-  wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-  wasDerivedFrom(ex:report2, ex:report1)
-endBundle
-
-entity(agg:bundle3, [ prov:type='prov:Bundle' ])
-agent(ex:aggregator01, [ prov:type='ex:Aggregator' ])
-wasAttributedTo(agg:bundle3, ex:aggregator01)
-wasDerivedFrom(agg:bundle3, bob:bundle1)
-wasDerivedFrom(agg:bundle3, alice:bundle2)
-</pre>
-<p>The new bundle is given a new identifier <span class="name">agg:bundle3</span> and is attributed to the <span class="name">ex:aggregator01</span> agent.
-</div>
-
-
-</section>
-
-<section id="term-hasProvenanceIn"> 
-
-<h3>Provenance Locator</h3>
-
-
-In <a href="#anexample-provenance-of-provenance">Example anexample-provenance-of-provenance</a>, we initially presented a scenario involving two entities <span class="name">report1</span> and <span class="name">report2</span>, and showed how the descriptions can be organized into two bundles.  There is no explicit indication that the second bundle "continues" the description offered by the first bundle.  Given that bundles may be retrieved separately [[PROV-AQ]], it is not obvious for a provenance consumer to navigate descriptions across bundles.  To aid consumers,
- Alice may wish to express that there is further provenance information about <span class="name">report1</span> in bundle <span class="name">bob:bundle1</span>.  To this end, PROV introduces the notion of provenance locator, inspired by [[PROV-AQ]].
-
-
-<p><div class="glossary-ref" data-ref="glossary-provenance-locator"></div></p>
-
-
-<div class="attributes" id="attributes-hasProvenanceIn">
-A <dfn title="hasProvenanceIn">provenance locator</dfn>,
-written
-<span class="pnExpression">hasProvenanceIn(id, subject, bundle, target, service, prov, attrs)</span>, has:
-<ul>
-<li><span class='attribute' id="prov.localtor.id">id</span>: an identifier for a provenance locator; </li>
-<li><span class='attribute' id="prov.locator.subject">subject</span>:  an identifier denoting something (entity, activity, agent, or relatation instance);</li>
-<li><span class='attribute' id="prov.locator.bundle">bundle</span>:  an OPTIONAL identifier (<span class="name">bundle</span>) for a bundle;
-<li><span class='attribute' id="prov.locator.target">target</span>:  an OPTIONAL identifier (<span class="name">target</span>) denoting  something described in another set of descriptions (referred to as <a href="http://www.w3.org/TR/prov-aq/#dfn-target-uri">Target-URI</a> in [[PROV-AQ]]);
-<li><span class='attribute' id="prov.locator.service">service</span>:  an OPTIONAL URI (<span class="name">service</span>) denoting a <a href="http://www.w3.org/TR/prov-aq/#dfn-provenance-service">provenance service</a> from which provenance can be retrieved (referred to as <a href="http://www.w3.org/TR/prov-aq/#dfn-service-uri">Service-URI</a> in [[PROV-AQ]]);
-<li><span class='attribute' id="prov.locator.provenance">provenance</span>:  an OPTIONAL URI (<span class="name">prov</span>), which when dereferenced, allows access to provenance descriptions (referred to as <a href="http://www.w3.org/TR/prov-aq/#dfn-provenance-uri">Provenance-URI</a> in [[PROV-AQ]]);
-<li><span class='attribute' id="prov.locator.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this locator.</li>
-</ul>
-<p>In <span class="pnExpression">hasProvenanceIn(id, subject, bundle, target, service, prov, attrs)</span>, <span class="name">service</span> and <span class="name">prov</span> are both optional and mutually exclusive: if specified, either <span class="name">service</span> or <span class="name">prov</span> is provided.</p>
-</div>
-
-<p>A provenance locator specifies a context, referred to
-as <em>located context</em> in which further descriptions can be found
-about something.</p>
-
-<p>When the subject and optional target denote entities,
-a provenance locator not only provides a located context, but it also expresses an <a>alternate</a> relation between the entity denoted by <span class="name">subject</span> and the  entity described in the located context. This is a alternate since the entity denoted by <span class="name">subject</span> in the current context presents other aspects than the entity in the located one.</p>
-
-<div class="anexample" id="anexample-provenance-locator">
-<p>According to the following provenance locator, provenance descriptions about <span class="name">ex:report1</span> can be found in bundle <span class="name">bob:bundle1</span>.</p>
-<pre class="codeexample"> 
-hasProvenanceIn(ex:report1, bob:bundle1, -, -, -)
-</pre>
-<p>According to the following provenance locator, provenance descriptions about <span class="name">ex:report1</span> can be found in bundle <span class="name">bob:bundle1</span>, which is available from the provenance service identified by the provided URI.</p>
-<pre class="codeexample"> 
-hasProvenanceIn(ex:report1, bob:bundle1, -, "http://example.com/service"^xsd:anyURI, -)
-</pre>
-<p>According to the following provenance locator, provenance descriptions about <span class="name">ex:report1</span> can be found in resource identified by the provided URI.</p>
-<pre class="codeexample"> 
-hasProvenanceIn(ex:report1, -, -, -, "http://example.com/some-provenance.pn"^xsd:anyURI)
-</pre>
-</div>
-
-
-<div class="anexample" id="anexample-provenance-locator2">
-<p>Let us again consider the same scenario involving two entities <span class="name">ex:report1</span> and <span class="name">ex:report2</span>.</p>
-<p>The first bundle can be expressed with all Bob's observations about the creation of <span class="name">ex:report1</span>.
-</p>
-<pre class="codeexample"> 
-bundle bob:bundle4
-  entity(ex:report1, [ prov:type="report", ex:version=1 ])
-  wasGeneratedBy(ex:report1, -, 2012-05-24T10:00:01)
-endBundle
-</pre>
-
-<p>Likewise, Alice's observation about the derivation of  <span class="name">ex:report2</span>  from <span class="name">ex:report1</span>, is expressed in a separate bundle.</p>
-<pre class="codeexample"> 
-bundle alice:bundle5
-  entity(ex:report1)
-  hasProvenanceIn(ex:report1, bob:bundle4, -, -, -)
-  entity(ex:report2, [ prov:type="report", ex:version=2 ])
-  wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-  wasDerivedFrom(ex:report2, ex:report1)
-endBundle
-</pre>
-<p>In bundle <span class="name">alice:bundle5</span>, there is a description for entity <span class="name">ex:report1</span>, and 
-a provenance locator pointing to bundle <span class="name">bob:bundle4</span>.  
-The locator indicates that some provenance description for <span class="name">ex:report1</span> can be found in bundle <span class="name">bob:bundle4</span>. The purpose of the locator is twofold. First, it allows for <a href="http://www.w3.org/TR/prov-aq/#incremental-provenance-retrieval">incremental navigation</a> of provenance [[PROV-AQ]].  Second, it makes entity <span class="name">ex:report1</span> described in <span class="name">alice:bundle5</span> an <a>alternate</a> of <span class="name">ex:report1</span> described in <span class="name">bob:bundle4</span>.
-</p>
-</div>
-
-
-<div class="anexample" id="anexample-provenance-locator3">
-<p>Alternatively, Alice may have decided to use a different identifier for <span class="name">ex:report1</span>.</p>
-<pre class="codeexample"> 
-bundle alice:bundle6
-  entity(alice:report1)
-  hasProvenanceIn(alice:report1, bob:bundle4, ex:report1, -, -)
-  entity(ex:report2, [ prov:type="report", ex:version=2 ])
-  wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-  wasDerivedFrom(ex:report2, alice:report1)
-endBundle
-</pre>
-<p>Alice can specify the <a href="#prov.locator.target">target</a> in the provenance locator to be  <span class="name">ex:report1</span>.
-With such a statement, Alice states that provenance information about <span class="name">alice:report1</span> can be found in bundle
-<span class="name">bob:bundle4</span> under the name <span class="name">ex:report1</span>.  In effect, <span class="name">alice:report1</span> and <span class="name">ex:report1</span> are declared to be alternate.</p>
-</div>
-
-<div class="anexample" id="aexample-note">
-<p>Consider that the following bundle of descriptions, in which derivation and generations have been identified.
-<pre class="codeexample"> 
-bundle obs:bundle7
-  entity(ex:report1, [prov:type="report", ex:version=1])
-  wasGeneratedBy(ex:g1; ex:report1,-,2012-05-24T10:00:01)
-  entity(ex:report2, [prov:type="report", ex:version=2])
-  wasGeneratedBy(ex:g2; ex:report2,-,2012-05-25T11:00:01)
-  wasDerivedFrom(ex:d; ex:report2, ex:report1)
-endBundle
-entity(obs:bundle7, [ prov:type='prov:Bundle' ])
-wasAttributedTo(obs:bundle7, ex:observer01)
-</pre>
-Bundle <span class="name">obs:bundle7</span> is rendered by a visualisation tool.  It may useful for the tool configuration for this bundle to be shared along with the provenance descriptions, so that other users can render provenance as it was originally rendered.  The original  bundle obviously cannot be changed. However, one can create a new bundle, as follows.
-<pre class="codeexample"> 
-bundle tool:bundle8
-  entity(tool:bundle8, [ prov:type='viz:Configuration', prov:type='prov:Bundle' ])
-  wasAttributedTo(tool:bundle8, viz:Visualizer)
-
-  entity(ex:report1, [viz:color="orange"])
-  hasProvenanceIn(ex:report1, obs:bundle7, -, -, -)
-
-  entity(ex:report2, [viz:color="blue"])
-  hasProvenanceIn(ex:report2, obs:bundle7, -, -, -)
-
-  wasDerivedBy(ex:d; ex:report2, ex:report1, [viz:style="dotted"])
-  hasProvenanceIn(ex:d, obs:bundle7, -, -, -)
-endBundle
-</pre>
-
-<p>In bundle <span class="name">tool:bundle8</span>, the prefix <span class="name">viz</span> is used for naming visualisation-specific attributes, types or values.</p>
-
-<p>Bundle <span class="name">tool:bundle8</span> is given type <span class="name">viz:Configuration</span> to indicate that it consists of descriptions that pertain to the configuration of the visualisation tool. This type attribute can be used for searching bundles containing visualization-related descriptions.
-</p>
-
-<p>Alternates of the entities <span class="name">ex:report1</span> and <span class="name">ex:report2</span> have a visualization attribute for the color to be used when rendering these entities. 
-Likewise, the derivation has a style attribute. To be able to express this alternate of the derivation, it is necessary for it to have an identifier in the first place (<span class="name">ex:d</span>).</p>
-</div>
-
-</section>
-</div>
-</section> 
-</section> 
-
-
-
-
-<section id="valid-provenance">
-<h4>Creating Valid Provenance</h4>
-
-
-<ul>
-
-<li>
-
-
-<li>
-
-<li> 
-<p>The idea of bundling provenance 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.
-Descriptions in bundles are expected to satisfy constraints specified in the companion specification [[PROV-CONSTRAINTS]].</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>
-
-<section class="appendix"> 
-      <h2>Acknowledgements</h2> 
-      <p> 
-        WG membership to be listed here.
-      </p> 
-    </section> 
-
- </body>
-</html>
--- a/model/working-copy/wd6-collections-constraints.html	Mon Sep 10 07:56:57 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,539 +0,0 @@
-<!DOCTYPE html
->
-
-<html><head> 
-    <title>PROV-DM: The PROV 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('data-ref');
-          var span=$(this).attr('data-withspan')
-          $(this).removeAttr('data-withspan');
-          $(this).removeAttr('data-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-CONSTRAINTS":
-          "James Cheney, Paolo Missier, and Luc Moreau (eds.) "+
-          "<a href=\"http://www.w3.org/TR/prov-constraints/\"><cite>Constraints of the PROV Data Model</cite></a>. "+
-          "2011, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-constraints/\">http://www.w3.org/TR/prov-constraints/</a>",
-
-        "PROV-N":
-          "Luc Moreau and Paolo Missier (eds.)"+
-          "<a href=\"http://www.w3.org/TR/prov-n/\"><cite>PROV-N: The Provenance Notation</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   :  "working towards WD6 (<a href=\"diff.html\">Diffs since last release</a>)",
-
- 
-          // if you wish the publication date to be other than today, set this
-//          publishDate:  "2012-05-03",
- 
-          // if the specification's copyright date is a range of years, specify
-          // the start date here:
-          copyrightStart: "2011",
- 
-          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
-          // and its maturity status
-          previousPublishDate:  "2012-05-03",
-          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-dm.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: "Reza B'Far",
-                company: "Oracle Corporation" },
-              { name: "Stephen Cresswell",
-                company: "legislation.gov.uk"},
-              { name: "Yolanda Gil",
-                company: "Invited Expert", url:"http://www.isi.edu/~gil/"},
-              { 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: "Curt Tilmes", 
-                company: "National Aeronautics and Space Administration" },
-          ],
-          
-          // name of the WG
-          wg:           "Provenance Working Group",
-          
-          // URI of the public WG page
-          wgURI:        "http://www.w3.org/2011/prov/",
-          
-          // name (with the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "public-prov-wg",
-          
-          // URI of the patent status for this WG, for Rec-track documents
-          // !!!! IMPORTANT !!!!
-          // This is important for Rec-track documents, do not copy a patent URI from a random
-          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
-          // Team Contact.
-          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/46974/status",
-
-          // Add extraReferences to bibliography database
-          preProcess: [addExtraReferences],
-      };
-    </script> 
-  </head> 
-  <body> 
-
-    <section id="abstract">
-<p>
-PROV-DM, the PROV data model, is a data model for provenance that describes
-the entities, people and activities involved in
-producing a piece of data or thing. 
-PROV-DM distinguishes core structures, forming the essence of provenance descriptions, from
-extended structures catering for more advanced uses of provenance. 
-PROV-DM is organized in six components, respectively dealing with: 
-(1) entities and activities, and the time at which they were created, used, or ended;
-(2) agents bearing responsibility for entities that were generated and activities that happened;
-(3) derivations of entities from entities;
-(4) properties to link entities that refer to the same thing;
-(5) notion of bundle, a mechanism to support provenance of provenance;
-(6) collections forming a logical structure for its members.
-</p>
-
-<p>This document introduces the provenance concepts found in
-PROV and defines PROV-DM types and
-relations. PROV data model is domain-agnostic, but is equipped with
-extensibility points allowing domain-specific information to be included. </p>
-
-<p>Two further documents complete the specification of PROV-DM.
-First, a companion document specifies the set of constraints that
-provenance descriptions should follow.  Second, 
-a separate document describes a provenance notation for expressing 
-instances of provenance for human consumption; this notation is used in examples in
-this document. </p>
-
-    </section> 
-
-<section id="sotd">
-<h4>PROV Family of Specifications</h4>
-This document is part of the PROV family of specifications, a set of specifications defining various aspects that are necessary to achieve the vision of inter-operable
-interchange of provenance information in heterogeneous environments such as the Web.  The specifications are:
-<ul>
-<li> PROV-DM, the PROV data model for provenance (this document);</li>
-<li> PROV-CONSTRAINTS, a set of constraints applying to the PROV data model;</li>
-<li> PROV-N, a notation for provenance aimed at human consumption;</li>
-<li> PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF;</li>
-<li> PROV-AQ, the mechanisms for accessing and querying provenance; </li>
-<li> PROV-PRIMER, a primer for the PROV data model;</li>
-<li> PROV-SEM, a formal semantics for the PROV data model;</li>
-<li> PROV-XML, an XML schema for the PROV data model.</li>
-</ul>
-<h4>How to read the PROV Family of Specifications</h4>
-<ul>
-<li>The primer is the entry point to PROV offering an introduction to the provenance model.</li>
-<li>The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL-RL ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. PROV-SEM provides a mathematical semantics.</li>
-<li>The XML community should focus on PROV-XML defining an XML schema for PROV. Further details can also be found in PROV-DM, PROV-CONSTRAINTS, and PROV-SEM.</li>
-<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
-<li>Readers seeking to implement other PROV serializations
-should focus on PROV-DM and PROV-CONSTRAINTS.  PROV-O, PROV-N, PROV-XML offer examples of mapping to RDF, text, and XML, respectively.</li>
-</ul>
-
-
-<h4>Fourth Public Working Draft</h4>
-<p>This is the fourth public release of the PROV-DM document. Following feedback, the Working Group has decided to reorganize this document substantially, separating the data model from its contraints and the notation used to illustrate it. The PROV-DM release is synchronized with the release of the PROV-O, PROV-PRIMER, PROV-N, and PROV-CONSTRAINTS documents. We are now clarifying the entry path to the PROV family of specifications.</p>
-</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="dictionaries-and-contents-2">
-
-  
-<h4>Collections and Contents</h4>
-
-The interpretation of Collection statements is defined by the following axioms. 
-
-Function Contents: C &rarr; &weierp;(E) maps a collection entity c &isin; C to a finite set {e1, &hellip; en} &sub; E of entities, where C is the set of all Entities of type Collection, and E  is the set of all Entities.
-<ol>
-<li><span class="name">entity(c, [prov:type='prov:EmptyCollection'])</span> &rArr; Contents(c) = &empty;
-
-<li> <span class="name">derivedByInsertionFrom(c2, c1, E)</span>   &rArr; Contents(c) = Contents(c1) &cup; E;
-
-<li> <span class="name">derivedByRemovalFrom(c2, c1, E)</span>    &rArr; Contents(c) = Contents(c1) \ E;
-
-<li> <span class="name">memberOf(c, E)</span> &rArr; Contents(c) &sup; E
-
-<li> <span class="name">memberOf(c, E, true)</span> &rArr; Contents(c) = E
-  
-</ol>
-
-<h4>Some consequences of these axioms</h4>
-
-The following examples illustrate how these axioms can be used, and  in particular one can decide whether or not  a set of statements is consistent.  
-
-<div class="anexample">
-A chain of insertions and removals that starts from statements of the form (1) or (5) leads to a complete characterisation of the contents of the final collection.
-
-<pre class="codeexample">
- entity(c, [prov:type='prov:EmptyCollection']),
- derivedByInsertionFrom(c1, c, E1),
- derivedByInsertionFrom(c2, c1, E2) 
-</pre>
-From these statements, one entails: Contents(c2) = E1 &cup; E2
-
-
-<p/>Similarly: <p/>
-<pre class="codeexample">
- entity(c, [prov:type='prov:EmptyCollection'])
- memberOf(c, E, true)
- derivedByInsertionFrom(c1, c, E1)
- derivedByInsertionFrom(c2, c1, E2) 
-</pre>
-Contents(c2) = E &cup; E1 &cup; E2
-
-</div>
-
-<div class="anexample">
-Incomplete characterisation  of the contents of the final collection:
-<pre class="codeexample">
- entity(c, [prov:type='prov:Collection'])
- memberOf(c, E)
- derivedByInsertionFrom(c1, c, E1)
-</pre>
-This entails:
-        Contents(c1) &sup; E &cup; E1
-</div>
-
-
-<div class="anexample">
-Use of multiple memberOf statements, with no complete flag: 
-
-<pre class="codeexample">
-memberOf(c, E1)
-memberOf(c, E2)
-</pre>
-Contents(c) &sup; E1 &cup; E2
-</div>
-
-<div class="anexample">
-Use of multiple memberOf statements, with one or more complete flags: 
-
-<pre class="codeexample">
-1) memberOf(c, E1, true)  
-2) memberOf(c, E2)
-</pre>
-From (1): Contents(c) = E1   <br/>
-From (2): Contents(c) &sup; E2  <p/>
-
-This is inconsistent unless E2 &sub; E1. In other words, any memberOf statement that adds to an existing "complete" memberOf statement must be contained by the latter. 
-
-<p/>Example:
-
-<pre class="codeexample">
-memberOf(todays-us-supreme-court, {<http://dbpedia.org/resource/John_Glover_Roberts,_Jr.>})   # todays-us-supreme-court  contains at least JGR Jr
-memberOf(todays-us-supreme-court, {Paolo}, true)   # todays-us-supreme-court  contains at least Paolo
-</pre>
-this is inconsistent.  <p/>
-
-<pre class="codeexample">
-(1) memberOf(todays-us-supreme-court, {<http://dbpedia.org/resource/John_Glover_Roberts,_Jr.>})                # todays-us-supreme-court  contains at least JGR Jr
-(2) memberOf(todays-us-supreme-court, {<http://dbpedia.org/resource/John_Glover_Roberts,_Jr.>, Paolo}, true)   # todays-us-supreme-court  contains  Paolo and another dude
-</pre>
-this is consistent because (2) contains (1).<p/>
-</div>
-
-<div class="anexample">
-Multiple derivation statements regarding the same collection.<p/>
-
-Case 1: the deriving collection is the same in both statements. This leads to an inconsistency (except in the trivial case in which the inserted sets are identical).
-
-<pre class="codeexample">
-(1) derivedByInsertionFrom(c1, c, E1)
-(2) derivedByInsertionFrom(c1, c, E2) 
-</pre>
-From (1): Contents(c1) = c &cup; E1   <br/>
-From (2): Contents(c1) = c &cup; E2  <p/>
-
-Case 2: two different deriving collections:
-
-<pre class="codeexample">
-(1) derivedByInsertionFrom(c3, c1, E1)
-(2) derivedByInsertionFrom(c3, c2, E2) 
-</pre>
-From (1): Contents(c3) = c1 &cup; E1   <br/>
-From (2): Contents(c3) = c2 &cup; E2  <p/>
-
- This is not necessarily an inconsistency.
-</section>
-
-<section id="dictionaries-and-contents">
-
-<!-- PM commented out to avoid confusion to readers in the group 9/6/12 
-  
-<h4>Dictionaries and Contents</h4>
-
-<p>We model the contents of a dictionary  with a function contents that has the following signature
- Dictionary x Value -> Entity U {&#8869,?}.</p>
-
-<p>Given a dictionary <span class="name">d</span>, a value <span class="name">k</span>, contents is interpreted as follows:</p>
-<ul>
-<li>contents(d,<em>k</em>)=<em>e</em>:  there is an entry with key <em>k</em> and entity <em>e</em> in <span class="name">d</span>;
-<li>contents(d,<em>k</em>)=&#8869:  there is no entry with key <em>k</em> in <span class="name">d</span>;
-
-<li>contents(d,<em>k</em>)=?:  it is not known if there is an entry with key <em>k</em> in <span class="name">d</span>.
-</ul>
-
-<p id="contents-empty-dictionary_text">The contents of an EmptyDictionary  is defined as the empty set.</p>
-
-       <div class='inference' id="contents-empty-dictionary">
-<p>
-    For any dictionary <span class="name">d</span>, 
-<span class='conditional'>IF</span>
-<span class="name">entity(d, [prov:type='prov:EmptyDictionary'])</span>,
- <span class='conditional'>THEN</span>:</p>
-<ul>
-<li> <span class="name">contents(d,<em>k</em>)=&#8869</span> for any <em>k</em>.
-</ul>
-</div> 
-
-
-<p id="contents-unspecified-dictionary_text">By default, the contents of a dictionary is unknown.</p>
-
-       <div class='inference' id="contents-unspecified-dictionary">
-<p>
-    For any dictionary <span class="name">d</span>, 
-<span class='conditional'>IF</span>
-<span class="name">entity(d, [prov:type='prov:Dictionary'])</span>,
- <span class='conditional'>THEN</span>:</p>
-<ul>
-<li> <span class="name">contents(d,<em>k</em>)=?</span> for any <em>k</em>.
-</ul>
-</div> 
-
-<p id="contents-after-insertion_text">The contents of a dictionary after insertion is defined as follows.</p>
-    
-       <div class='inference' id="contents-after-insertion">
-<p>
-    For any dictionaries <span class="name">d1</span> and <span class="name">d2</span>, 
-<span class='conditional'>IF</span>
-<span class="name">derivedByInsertionFrom(d2, d1, {(<em>k1</em>, <em>e1</em>) ... (<em>kn</em>, <em>en</em>)})</span>,
- <span class='conditional'>THEN</span>:</p>
-<ul>
-<li> <span class="name">contents(d2,<em>k</em>)=contents(d1,<em>k</em>)</span> if <em>k</em> is not in <em>k1</em>, ..., <em>kn</em>;
-<li> <span class="name">contents(d2,<em>ki</em>)=<em>ei</em></span>  if <em>k</em> is in <em>k1</em>, ..., <em>kn</em>;
-</ul>
-</div> 
-
-
-<p id="contents-after-removal_text">The contents of a dictionary after removal is defined as follows.</p>
-    
-       <div class='inference' id="contents-after-removal">
-<p>
-    For any dictionaries <span class="name">d1</span> and <span class="name">d2</span>, 
-<span class='conditional'>IF</span>
-<span class="name">derivedByRemovalFrom(d2, d1, {<em>k1</em> ... <em>kn</em>})</span>,
- <span class='conditional'>THEN</span>:</p>
-<ul>
-<li> <span class="name">contents(d2,<em>k</em>)=contents(d1,<em>k</em>)</span> if <em>k</em> is not in <em>k1</em>, ..., <em>kn</em>;
-<li> <span class="name">contents(d2,<em>ki</em>)=&#8869</span>  if <em>k</em> is in <em>k1</em>, ..., <em>kn</em>.
-</ul>
-</div> 
-
-
-<p id="contents-after-membership_text">The contents of a dictionary after membership is defined as follows.</p>
-    
-       <div class='inference' id="contents-after-membership">
-<p>
-    For any dictionary <span class="name">d</span>, 
-<span class='conditional'>IF</span>
-<span class="name">memberOf(d, {(<em>k1</em>, <em>e1</em>) ... (<em>kn</em>, <em>en</em>)})</span>,
- <span class='conditional'>THEN</span>:</p>
-<ul>
-<li> <span class="name">contents(d,<em>k</em>)=?</span> if <em>k</em> is not in <em>k1</em>, ..., <em>kn</em>;
-<li> <span class="name">contents(d,<em>ki</em>)=<em>ei</em></span>  if <em>k</em> is in <em>k1</em>, ..., <em>kn</em>.
-</ul>
-</div> 
-
-
-
-<p id="contents-after-complete-membership_text">The contents of a dictionary after complete membership is defined as follows.</p>
-    
-       <div class='inference' id="contents-after-complete-membership">
-<p>
-    For any dictionary <span class="name">d</span>, 
-<span class='conditional'>IF</span>
-<span class="name">memberOf(d, {(<em>k1</em>, <em>e1</em>) ... (<em>kn</em>, <em>en</em>)}, true)</span>,
- <span class='conditional'>THEN</span>:</p>
-<ul>
-<li> <span class="name">contents(d,<em>k</em>)=&#8869</span> if <em>k</em> is not in <em>k1</em>, ..., <em>kn</em>;
-<li> <span class="name">contents(d,<em>ki</em>)=<em>ei</em></span>  if <em>k</em> is in <em>k1</em>, ..., <em>kn</em>.
-</ul>
-</div> 
-
-
-
-
-<p id="contents-after-complete-membership_text">Succcessfully looking up a key in a dictionary results in an entity, which is an alternate of an entity known to be in the dictionary. </p>
-    
-       <div class='inference' id="lookup-and-membership">
-<p>
-<span class='conditional'>IF</span>
-<span class="name">wasDerivedFrom(e2,d,[prov:key=<em>k</em>, prov:type='prov:Lookup'])</span>, and
-<span class="name">contents(d,<em>k</em>)=e1</em></span>
- <span class='conditional'>THEN</span>: <span class="name">alternateOf(e2,e1)</span>.
-
-</div> 
-
-
-
-
-
-
-</section>
-
-
-</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>
-
-<section class="appendix"> 
-      <h2>Acknowledgements</h2> 
-      <p> 
-        WG membership to be listed here.
-      </p> 
-    </section> 
-
- </body>
-</html>
--- a/model/working-copy/wd6-contextualization.html	Mon Sep 10 07:56:57 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,521 +0,0 @@
-<!DOCTYPE html
->
-
-<html><head> 
-    <title>PROV-DM: The PROV 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('data-ref');
-          var span=$(this).attr('data-withspan')
-          $(this).removeAttr('data-withspan');
-          $(this).removeAttr('data-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-CONSTRAINTS":
-          "James Cheney, Paolo Missier, and Luc Moreau (eds.) "+
-          "<a href=\"http://www.w3.org/TR/prov-constraints/\"><cite>Constraints of the PROV Data Model</cite></a>. "+
-          "2011, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-constraints/\">http://www.w3.org/TR/prov-constraints/</a>",
-
-        "PROV-N":
-          "Luc Moreau and Paolo Missier (eds.)"+
-          "<a href=\"http://www.w3.org/TR/prov-n/\"><cite>PROV-N: The Provenance Notation</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   :  "working towards WD6 (<a href=\"diff.html\">Diffs since last release</a>)",
-
- 
-          // if you wish the publication date to be other than today, set this
-//          publishDate:  "2012-05-03",
- 
-          // if the specification's copyright date is a range of years, specify
-          // the start date here:
-          copyrightStart: "2011",
- 
-          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
-          // and its maturity status
-          previousPublishDate:  "2012-05-03",
-          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-dm.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: "Reza B'Far",
-                company: "Oracle Corporation" },
-              { name: "Stephen Cresswell",
-                company: "legislation.gov.uk"},
-              { name: "Yolanda Gil",
-                company: "Invited Expert", url:"http://www.isi.edu/~gil/"},
-              { 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: "Curt Tilmes", 
-                company: "National Aeronautics and Space Administration" },
-          ],
-          
-          // name of the WG
-          wg:           "Provenance Working Group",
-          
-          // URI of the public WG page
-          wgURI:        "http://www.w3.org/2011/prov/",
-          
-          // name (with the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "public-prov-wg",
-          
-          // URI of the patent status for this WG, for Rec-track documents
-          // !!!! IMPORTANT !!!!
-          // This is important for Rec-track documents, do not copy a patent URI from a random
-          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
-          // Team Contact.
-          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/46974/status",
-
-          // Add extraReferences to bibliography database
-          preProcess: [addExtraReferences],
-      };
-    </script> 
-  </head> 
-  <body> 
-
-    <section id="abstract">
-<p>
-PROV-DM, the PROV data model, is a data model for provenance that describes
-the entities, people and activities involved in
-producing a piece of data or thing. 
-PROV-DM distinguishes core structures, forming the essence of provenance descriptions, from
-extended structures catering for more advanced uses of provenance. 
-PROV-DM is organized in six components, respectively dealing with: 
-(1) entities and activities, and the time at which they were created, used, or ended;
-(2) agents bearing responsibility for entities that were generated and activities that happened;
-(3) derivations of entities from entities;
-(4) properties to link entities that refer to the same thing;
-(5) notion of bundle, a mechanism to support provenance of provenance;
-(6) collections forming a logical structure for its members.
-</p>
-
-<p>This document introduces the provenance concepts found in
-PROV and defines PROV-DM types and
-relations. PROV data model is domain-agnostic, but is equipped with
-extensibility points allowing domain-specific information to be included. </p>
-
-<p>Two further documents complete the specification of PROV-DM.
-First, a companion document specifies the set of constraints that
-provenance descriptions should follow.  Second, 
-a separate document describes a provenance notation for expressing 
-instances of provenance for human consumption; this notation is used in examples in
-this document. </p>
-
-    </section> 
-
-<section id="sotd">
-<h4>PROV Family of Specifications</h4>
-This document is part of the PROV family of specifications, a set of specifications defining various aspects that are necessary to achieve the vision of inter-operable
-interchange of provenance information in heterogeneous environments such as the Web.  The specifications are:
-<ul>
-<li> PROV-DM, the PROV data model for provenance (this document);</li>
-<li> PROV-CONSTRAINTS, a set of constraints applying to the PROV data model;</li>
-<li> PROV-N, a notation for provenance aimed at human consumption;</li>
-<li> PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF;</li>
-<li> PROV-AQ, the mechanisms for accessing and querying provenance; </li>
-<li> PROV-PRIMER, a primer for the PROV data model;</li>
-<li> PROV-SEM, a formal semantics for the PROV data model;</li>
-<li> PROV-XML, an XML schema for the PROV data model.</li>
-</ul>
-<h4>How to read the PROV Family of Specifications</h4>
-<ul>
-<li>The primer is the entry point to PROV offering an introduction to the provenance model.</li>
-<li>The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL-RL ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. PROV-SEM provides a mathematical semantics.</li>
-<li>The XML community should focus on PROV-XML defining an XML schema for PROV. Further details can also be found in PROV-DM, PROV-CONSTRAINTS, and PROV-SEM.</li>
-<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
-<li>Readers seeking to implement other PROV serializations
-should focus on PROV-DM and PROV-CONSTRAINTS.  PROV-O, PROV-N, PROV-XML offer examples of mapping to RDF, text, and XML, respectively.</li>
-</ul>
-
-
-<h4>Fourth Public Working Draft</h4>
-<p>This is the fourth public release of the PROV-DM document. Following feedback, the Working Group has decided to reorganize this document substantially, separating the data model from its contraints and the notation used to illustrate it. The PROV-DM release is synchronized with the release of the PROV-O, PROV-PRIMER, PROV-N, and PROV-CONSTRAINTS documents. We are now clarifying the entry path to the PROV family of specifications.</p>
-</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="component4"> 
-<h3>Component 4: Alternate Entities</h3>
-
-
-<p>The fourth component of PROV-DM is concerned with
-relations <a>specialization</a> and <a>alternate</a> between entities.
- <a href="#figure-component4">Figure 8</a> depicts
-the fourth component with a single class and two associations.
-</p>
-
-
-<div style="text-align: center;">
-<figure>
-<!-- <img src="images/Alternates.png" alt="alternates"/> -->
-<img src="../uml/component4.svg" alt="alternates"/>
-<figcaption id="figure-component4">Figure 8: Alternates Component Overview</figcaption>
-</figure>
-</div>
-
-
-
-<p>Two provenance descriptions about the same thing may emphasize differents aspects of that thing.</p>
-<div class="anexample" id="entity-example1">
-<p>User Alice writes an article. In its provenance, she wishes to refer to the precise version of the article with a date-specific URI, as she might edit the article later. Alternatively, user Bob refers to the article in general, independently of its variants over time.</p>
-</div>
-<p>
-The PROV data model introduces relations, called specialization and alternate,
-that allow entities  to be linked together. They are defined as follows. </p>
-
-
-<section id="term-specialization">
-
-<h4>Specialization</h4>
-
-
-<span class="glossary-ref" data-ref="glossary-specialization"></span> 
-
-
-<p>
-Examples of constraints  include a time period, an abstraction, and a context associated with the entity.</p>
-
-
-
-
-<p>
-<div class="attributes" id="attributes-specialization">A <dfn title="specializationOf">specialization</dfn>  relation<span class="withPn">, written <span class="pnExpression">specializationOf(infra, supra)</span> in PROV-N,</span> has:
-
-<ul>
-<li><span class='attribute' id="specialization.specialization">specialization</span>: an identifier (<span class="name">infra</span>) of the specialized entity;</li>
-<li><span class='attribute' id="specialization.generalEntity">generalEntity</span>: an identifier (<span class="name">supra</span>) of the entity that is being specialized.</li>
-</ul>
-</div>
-
-<div class="anexample" id="anexample-specialization">
-<p>
-The BBC news home page on 2012-03-23 <span class="name">ex:bbcNews2012-03-23</span>
-is a specialization of the BBC news page in general
- <a href="http://www.bbc.co.uk/news/">bbc:news/</a>. This can be expressed as follows.
-<pre class="codeexample">
-specializationOf(ex:bbcNews2012-03-23, bbc:news/)
-</pre>
-We have created a new qualified name,  <span class="name">ex:bbcNews2012-03-23</span>, in the namespace <span class="name">ex</span>, to identify the specific page carrying this day's news, which would otherwise be the generic  <span class="name">bbc:news/</span> page.
-</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>
--->
-
-
-
-</section>
-
-<section id="term-alternate">
-
-<h4>Alternate</h4>
-
-
-<span class="glossary-ref" data-ref="glossary-alternate"></span>
-
-
-  
-
-<p><div class="attributes" id="attributes-alternate">An <dfn title="alternateOf">alternate</dfn> relation<span class="withPn">, written <span class="pnExpression">alternateOf(e1, e2)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="alternate.alternate1">alternate1</span>: an identifier (<span class="name">e1</span>) of the first of the two entities;</li>
-<li><span class='attribute' id="alternate.alternate2">alternate2</span>: an identifier (<span class="name">e2</span>) of the second of the two entities.</li>
-</ul>
-</div>
-
-<div class="anexample" id="anexample-alternate">
-<p>
-A given news item on the BBC News site 
- <a href="http://www.bbc.co.uk/news/science-environment-17526723">bbc:news/science-environment-17526723</a> for desktop
-is an alternate of a 
- <a href="http://www.bbc.co.uk/news/mobile/science-environment-17526723">bbc:news/mobile/science-environment-17526723</a> for mobile devices.</p>
-<pre class="codeexample">
-entity(bbc:news/science-environment-17526723, [ prov:type="a news item for desktop"])
-entity(bbc:news/mobile/science-environment-17526723, [ prov:type="a news item for mobile devices"])
-alternateOf(bbc:news/science-environment-17526723, bbc:news/mobile/science-environment-17526723)
-</pre>
-<p>They are both specialization of an (unspecified) entity. </p>
-</div>
-
-
-<div class="anexample" id="anexample-alternate2">
-<p>
-Considering again the two versions of the technical report <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). They are alternate of each other.
-<pre class="codeexample">
-entity(tr:WD-prov-dm-20111018)
-entity(tr:WD-prov-dm-20111215)
-alternateOf(tr:WD-prov-dm-20111018,tr:WD-prov-dm-20111215)
-</pre>
-<p>They are both specialization of the page <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a>.</p>
-</div>
-
-</section>
-
-
-
-
-
-
-<section id="term-contextualization">
-
-<h4>Contextualization</h4>
-
-<p><em>
-Something that is a <dfn id="concept-contextualiation">contextualization</dfn> of another presents all aspects of the latter in a given context specified by descriptions found in a bundle.
-</em></p>
-
-
-<p><div class="attributes" id="attributes-contextualization">A <dfn title="contextualizationOf">contextualization</dfn> relation<span class="withPn">, written <span class="pnExpression">contextualizationOf(i2, i1, b)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="contextualization.contextualization2">contextualization2</span>: an identifier (<span class="name">i2</span>) for something presenting the aspects of <span class="name">i1</span> in bundle <span class="name">b</span> ;</li>
-<li><span class='attribute' id="contextualization.contextualization2">contextualization1</span>: an identifier (<span class="name">i1</span>) of something identifiable in some bundle <span class="name">b</span>;</li>
-<li><span class='attribute' id="contextualization.context">bundle</span>: an identifier (<span class="name">b</span>) for a bundle.</li>
-</ul>
-</div>
-
-
-<div class="anexample" id="anexample-contextualization1">
-<p>In the following example, two bundles <span class="name">ex:run1</span> and <span class="name">ex:run2</span> refer to an agent <span class="name">ex:Bob</span> that controlled two activities <span class="name">ex:a1</span> and <span class="name">ex:a2</span>. </p>
-
-<pre class="codeexample">
-bundle ex:run1
-    activity(ex:a1, 2011-11-16T16:00:00,2011-11-16T17:00:00)  //duration: 1hour
-    wasAssociatedWith(ex:a1,ex:Bob,[prov:role="controller"])
-endBundle
-
-bundle ex:run2
-    activity(ex:a2, 2011-11-17T10:00:00,2011-11-17T17:00:00)  //duration: 7hours
-    wasAssociatedWith(ex:a2,ex:Bob,[prov:role="controller"])
-endBundle
-</pre> 
-<p>A performance rating tool reads these bundles, and rates the performance of the agent described in these bundles. The performance rating tool creates a new bundle <span class="name">tool:analysis01</span> containing the following. A new agent <span class="name">tool:Bob1</span> is declared as a contextualization of <span class="name">ex:Bob</span> as described in context <span class="name">ex:run1</span>, and likewise for  <span class="name">tool:Bob2</span> with respect to <span class="name">ex:run2</span>. The tool then defines two specializations of these contextualized agents with an associated rating. The performance of the agent in the first bundle is judged to be good since the duration of <span class="name">ex:a1</span> is one hour, whereas it is judged to be bad in the second bundle since <span class="name">ex:a2</span>'s duration is seven hours.
-
-<pre class="codeexample">
-bundle tool:analysis01
-    agent(tool:Bob1)
-    contextualizationOf(tool:Bob1, ex:Bob, ex:run1)
-    agent(tool:ratedBob1, [perf:rating="good"])
-    specialization(tool:ratedBob1, tool:Bob1)
-
-    agent(tool:Bob2)
-    contextualizationOf(tool:Bob2, ex:Bob, ex:run2)
-    agent(tool:ratedBob2, [perf:rating="bad"])
-    specialization(tool:ratedBob2, tool:Bob2)
-endBundle
-</pre>
-</div>
-
-
-<div class="anexample" id="aexample-contextualization-viz">
-<p>Consider the following bundle of descriptions, in which derivation and generations have been identified.
-<pre class="codeexample"> 
-bundle obs:bundle7
-  entity(ex:report1, [prov:type="report", ex:version=1])
-  wasGeneratedBy(ex:g1; ex:report1,-,2012-05-24T10:00:01)
-  entity(ex:report2, [prov:type="report", ex:version=2])
-  wasGeneratedBy(ex:g2; ex:report2,-,2012-05-25T11:00:01)
-  wasDerivedFrom(ex:d; ex:report2, ex:report1)
-endBundle
-entity(obs:bundle7, [ prov:type='prov:Bundle' ])
-wasAttributedTo(obs:bundle7, ex:observer01)
-</pre>
-Bundle <span class="name">obs:bundle7</span> is rendered by a visualisation tool.  It may useful for the tool configuration for this bundle to be shared along with the provenance descriptions, so that other users can render provenance as it was originally rendered.  The original  bundle obviously cannot be changed. However, one can create a new bundle, as follows.
-<pre class="codeexample"> 
-bundle tool:bundle8
-  entity(tool:bundle8, [ prov:type='viz:Configuration', prov:type='prov:Bundle' ])
-  wasAttributedTo(tool:bundle8, viz:Visualizer)
-
-  entity(tool:report1, [viz:color="orange"])         // is it appropriate to add viz attributes to tool:report1 or should we specialize it?
-  contextualizationOf(tool:report1, obs:bundle7, ex:report1)
-
-  entity(tool:report2, [viz:color="blue"])              
-  contextualizationOf(tool:report2, obs:bundle7, ex:report2)
-
-
-  wasDerivedBy(tool:d; tool:report2, tool:report1, [viz:style="dotted"])
-  contextualizationOf(tool:d, obs:bundle7, ex:d)
-endBundle
-</pre>
-
-<p>In bundle <span class="name">tool:bundle8</span>, the prefix <span class="name">viz</span> is used for naming visualisation-specific attributes, types or values.</p>
-
-<p>Bundle <span class="name">tool:bundle8</span> is given type <span class="name">viz:Configuration</span> to indicate that it consists of descriptions that pertain to the configuration of the visualisation tool. This type attribute can be used for searching bundles containing visualization-related descriptions.
-</p>
-
-<p>The visualisation tool
- created  new identifiers <span class="name">tool:report1</span>,
-<span class="name">tool:report2</span>, and
-<span class="name">tool:d</span>.
-They denote entities which are alternates of with <span class="name">ex:report1</span> and <span class="name">ex:report2</span>, described in bundle <span class="name">obs:bundle7</span>, with visualization attribute for the color to be used when rendering these entities.  
-Likewise, the derivation has a style attribute. </p>
-
-<p>According to their definition,
-derivations have an <a href="#derivation.id">optional identifier</a>. 
-To express an alternate for a derivation, we need to be able to reference it, by means of an identifier. Hence, it is necessary for it to have an identifier in the first place (<span class="name">ex:d</span>).</p>
-</div>
-
-
-
-</section>
-</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>
-
-<section class="appendix"> 
-      <h2>Acknowledgements</h2> 
-      <p> 
-        WG membership to be listed here.
-      </p> 
-    </section> 
-
- </body>
-</html>
--- a/model/working-copy/wd6-prov-constraints.html	Mon Sep 10 07:56:57 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,2330 +0,0 @@
-<!DOCTYPE html>
-
-<html><head> 
-    <title>Constraints of the Provenance Data Model</title> 
-    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 
-    <!-- 
-      === NOTA BENE ===
-      For the three scripts below, if your spec resides on dev.w3 you can check them
-      out in the same tree and use relative links so that they'll work offline,
-     -->
-<!-- PM -->
-    <style type="text/css">
-      .note { font-size:small; margin-left:50px }
-     </style>
-
-    <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script> 
-    <script src="http://www.w3.org/2007/OWL/toggles.js" class="remove"></script> 
-
-    <script class="remove"> 
-      var addExtraReferences = function() {
-          for (var k in extraReferences)
-              berjon.biblio[k] = extraReferences[k];
-      };
-      var extraReferences = {
-        "CLOCK":
-         "Lamport, L. "+
-         "<a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\"><cite>Time, clocks, and the ordering of events in a distributed system</cite></a>."+
-         "Communications of the ACM 21 (7): 558–565. 1978. "+
-         "URL: <a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\">http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf</a> " +
-         "DOI: doi:10.1145/359545.359563.",
-        "CSP":
-         "Hoare, C. A. R. "+
-         "<a href=\"http://www.usingcsp.com/cspbook.pdf\"><cite>Communicating Sequential Processes</cite></a>."+
-         "Prentice-Hall. 1985"+
-         "URL: <a href=\"http://www.usingcsp.com/cspbook.pdf\">http://www.usingcsp.com/cspbook.pdf</a>",
-        "Logic":
-          "W. E. Johnson"+
-          "<a href=\"http://www.ditext.com/johnson/intro-3.html\"><cite>Logic: Part III</cite></a>."+
-          "1924. "+
-          "URL: <a href=\"http://www.ditext.com/johnson/intro-3.html\">http://www.ditext.com/johnson/intro-3.html</a>",
-        "PROV-SEM":
-          "James Cheney "+
-          "<a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\"><cite>Formal Semantics Strawman</cite></a>. "+
-          "2011, Work in progress. "+
-          "URL: <a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\">http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman</a>",
-
-        "PROV-PRIMER":
-          "Yolanda Gil and Simon Miles (eds.) Khalid Belhajjame, Helena Deus, Daniel Garijo, Graham Klyne, Paolo Missier, Stian Soiland-Reyes, and Stephan Zednik "+
-          "<a href=\"http://www.w3.org/TR/prov-primer/\"><cite>Prov Model Primer</cite></a>. "+
-          "2011, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-primer/\">http://www.w3.org/TR/prov-primer/</a>",
-
-
-        "PROV-DM":
-          "Luc Moreau and Paolo Missier (eds.) Khalid Belhajjame, Reza B'Far, Stephen Cresswell, Yolanda Gil, Paul Groth, Graham Klyne, Jim McCusker, Simon Miles, James Myers, Satya Sahoo, and Curt Tilmes"+
-          "<a href=\"http://www.w3.org/TR/prov-dm/\"><cite>PROV-DM: The PROV Data Model</cite></a>. "+
-          "2012, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-dm/\">http://www.w3.org/TR/prov-dm/</a>",
-
-        "PROV-N":
-          "Luc Moreau and Paolo Missier (eds.)"+
-          "<a href=\"http://www.w3.org/TR/prov-n/\"><cite>PROV-N: The Provenance Notation</cite></a>. "+
-          "2011, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-n/\">http://www.w3.org/TR/prov-n/</a>",
-
-
-        "PROV-O":
-          "Satya Sahoo and Deborah McGuinness (eds.) Khalid Belhajjame, James Cheney, Daniel Garijo, Timothy Lebo, Stian Soiland-Reyes, and Stephan Zednik "+
-          "<a href=\"http://www.w3.org/TR/prov-o/\"><cite>Provenance Formal Model</cite></a>. "+
-          "2011, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-o/\">http://www.w3.org/TR/prov-o/</a>",
-
-        "PROV-AQ":
-          "Graham Klyne and Paul Groth (eds.) Luc Moreau, Olaf Hartig, Yogesh Simmhan, James Meyers, Timothy Lebo, Khalid Belhajjame, and Simon Miles "+
-          "<a href=\"http://www.w3.org/TR/prov-aq/\"><cite>Provenance Access and Query</cite></a>. "+
-          "2011, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-aq/\">http://www.w3.org/TR/prov-aq/</a>",
-      };
-      var respecConfig = {
-          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
-          specStatus:           "ED",
-          
-          // the specification's short name, as in http://www.w3.org/TR/short-name/
-          shortName:            "prov-constraints",
- 
-          // if your specification has a subtitle that goes below the main
-          // formal title, define it here
-          subtitle   :  "towards second working draft --- Working Copy",
-
-
-          // if you wish the publication date to be other than today, set this
-        //          publishDate:  "2012-05-03",
- 
-          // if the specification's copyright date is a range of years, specify
-          // the start date here:
-          copyrightStart: "2012",
- 
-          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
-          // and its maturity status
-          previousPublishDate:  "2012-05-03",
-          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-constraints.html",
- 
-          // if this is a LCWD, uncomment and set the end of its review period
-          // lcEnd: "2009-08-05",
- 
-          // if you want to have extra CSS, append them to this list
-          // it is recommended that the respec.css stylesheet be kept
-          extraCSS:             ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css", "../extra.css"],
- 
-          // editors, add as many as you like
-          // only "name" is required
-          editors:  [
-              { name: "James Cheney", url:
-          "http://homepages.inf.ed.ac.uk/jcheney", company:
-          "University of Edinburgh" },
-              { name: "Paolo Missier", url: "http://www.cs.ncl.ac.uk/people/Paolo.Missier",
-                company: "Newcastle University" },
-              { name: "Luc Moreau", url: "http://www.ecs.soton.ac.uk/~lavm/",
-                company: "University of Southampton" },
-          ],
- 
-          // authors, add as many as you like. 
-          // This is optional, uncomment if you have authors as well as editors.
-          // only "name" is required. Same format as editors.
- 
-      //authors:  ,
-//          authors:  [
-//              { name: "TBD" },
-//         ],
-          
-          // name of the WG
-          wg:           "Provenance Working Group",
-          
-          // URI of the public WG page
-          wgURI:        "http://www.w3.org/2011/prov/",
-          
-          // name (with the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "public-prov-wg",
-          
-          // URI of the patent status for this WG, for Rec-track documents
-          // !!!! IMPORTANT !!!!
-          // This is important for Rec-track documents, do not copy a patent URI from a random
-          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
-          // Team Contact.
-          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/46974/status",
-
-          // Add extraReferences to bibliography database
-          preProcess: [addExtraReferences],
-      };
-    </script> 
-  </head> 
-  <body> 
-
-    <section id="abstract">
-<p>
-PROV-DM, the PROV data model, is a data model for provenance that describes
-the entities, people and activities involved in
-producing a piece of data or thing. 
-PROV-DM is structured in six components, dealing with: 
-(1) entities and activities, and the time at which they were created, used, or ended;
-(2) agents bearing responsibility for entities that were generated and activities that happened;
-(3) derivations of entities from entities;
-(4) properties to link entities that refer to a same thing;
-(5) collections forming a logical structure for its members;
-(6) a simple annotation mechanism.
-</p>
-
-
-<p> This document introduces a further set of concepts useful for
-  understanding the PROV data model and defines <i>inferences</i>
-  that are allowed on provenance statements and <i>validity
-  constraints</i> that PROV instances should
-  follow. These inferences and constraints are useful for readers who
-  develop applications that generate provenance or reason over
-  provenance.
-</p>
-</section>
-
-<section id="sotd">
-<h4>PROV Family of Specifications</h4>
-This document is part of the PROV family of specifications, a set of specifications defining various aspects that are necessary to achieve the vision of inter-operable
-interchange of provenance information in heterogeneous environments such as the Web.  The specifications are:
-<ul>
-<li> PROV-DM, the PROV data model for provenance;</li>
-<li> PROV-CONSTRAINTS, a set of constraints applying to the PROV data model  (this document);</li>
-<li> PROV-N, a notation for provenance aimed at human consumption;</li>
-<li> PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF;</li>
-<li> PROV-AQ, the mechanisms for accessing and querying provenance; </li>
-<li> PROV-PRIMER, a primer for the PROV data model;</li>
-<li> PROV-SEM, a formal semantics for the PROV data model;</li>
-<li> PROV-XML, an XML schema for the PROV data model.</li>
-</ul>
-<h4>How to read the PROV Family of Specifications</h4>
-<ul>
-<li>The primer is the entry point to PROV offering an introduction to the provenance model.</li>
-<li>The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL-RL ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. PROV-SEM provides a mathematical semantics.</li>
-<li>The XML community should focus on PROV-XML defining an XML schema for PROV-DM. Further details can also be found in PROV-DM, PROV-CONSTRAINTS, and PROV-SEM.</li>
-<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
-<li>Readers seeking to implement other PROV serializations
-should focus on PROV-DM and PROV-CONSTRAINTS.  PROV-O, PROV-N, PROV-XML offer examples of mapping to RDF, text, and XML, respectively.</li>
-</ul>
-
-<h4>First Public Working Draft</h4>
- <p>This is the first public release of the PROV-CONSTRAINTS
-document. Following feedback, the Working Group has decided to
-reorganize the PROV-DM document substantially, separating the data model,
-from its constraints, and the notation used to illustrate it. The
-PROV-CONSTRAINTS release is synchronized with the release of the PROV-DM, PROV-O,
-PROV-PRIMER, and PROV-N documents.
-</p>
-</section>
-
-
-
-
-    <section id="introduction"> 
-      <h2>Introduction<br>
-</h2> 
-
-<p> Provenance is a record that describes the people, institutions,
-  entities, and activities, involved in producing, influencing, or
-  delivering a piece of data or a thing.  This document complements
-  the PROV-DM specification [[PROV-DM]] that defines a data model for
-  provenance on the Web.  </p>
-
-
-
-    <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 id="purpose">
-
-<h3>Purpose of this document</h3>
-
-<p> PROV-DM is a conceptual data model for provenance (realizable
-using different serializations such as PROV-N, PROV-O, or PROV-XML).
-However, nothing in the PROV-DM specification [[PROV-DM]] forces sets
-of PROV
-statements (or <a>instances</a>) to be meaningful, that is, to correspond to a consistent
-history of objects and interactions.  Furthermore, nothing in the
-PROV-DM specification enables applications to perform inferences over
-PROV <a>instances</a>.  </p>
-
-<p> This document specifies <em>inferences</em> over PROV instances that
-applications MAY employ, including definitions of some provenance
-statements in terms of others, and also defines a class of <em>valid</em>
-PROV instances by specifying <em>constraints</em> that valid PROV instances must
-satisfy. Applications SHOULD produce valid provenance and
-MAY reject provenance that is not valid in order to increase
-the usefulness of provenance and reliability of applications that
-process it.  <a href="#compliance"
-class="sectionRef"></a>
-summarizes the requirements for compliance with this document, which
-are specified in detail in the rest of the document.
-</p>
-
-<p> This specification lists inferences and definitions together in one
-section (<a href="#inferences" class="sectionRef"></a>), defines the
-induced notion of <a>equivalence</a> (<a href="#equivalence"
-class="sectionRef"></a>), and then
-considers two kinds of validity constraints (<a href="#constraints"
-class="sectionRef"></a>): <em>structural constraints</em> that
-prescribe properties of PROV instances that can be checked directly
-by inspecting the syntax, and <em>event ordering</em> constraints that
-require that the records in a PROV <a>instance</a> are consistent with a
-sensible ordering of events relating the activities, entities and
-agents involved.  In separate sections we consider additional
-constraints specific to collections and accounts (<a
- href="#collection-constraints" class="sectionRef"></a> and <a
- href="#account-constraints" class="sectionRef"></a>).  </p>
-
-
-<p>
-Finally, the specification includes a section (<a
- href="#rationale" class="sectionRef"></a>) describing the rationale
-for the inferences and constraints in greater detail, particularly
-background on events, attributes, the role of inference, and
-accounts. A formal mathematical model that further justifies the
-constraints and inferences is found in [[PROV-SEM]].
-</p>
-
-</section>
-<section id="audience">
-<h3> Audience </h3>
-
-<p> The audience for this document is the same as for [[PROV-DM]]: developers
-and users who wish to create, process, share or integrate provenance
-records on the (Semantic) Web.  Not all PROV-compliant applications
-need to check validity when processing provenance, but many
-applications could benefit from the inference rules specified here.
-Conversely, applications that create or transform provenance should
-try to produce valid provenance, to make it more useful to other
-applications.
-</p>
-
-<p>This document assumes familiarity with [[PROV-DM]].
-</p>
-</section>
-
-</section> 
-
-<section id="compliance">
-<h2>Compliance with this document</h2>
-
-<div class="note">
-TODO: Add collection and account constraint sections to the compliance
-  list as appropriate.
-  </div>
-  For the purpose of compliance, the normative sections of this document
-  are <a href="#compliance"
-class="sectionRef"></a>, <a href="#inferences"
-class="sectionRef"></a>, <a href="#equivalence"
-class="sectionRef"></a>, and <a href="#constraints"
-class="sectionRef"></a>.
- To be compliant:
-  <ol><li>When processing provenance, an
-    application MAY apply the inferences and definitions in <a
-    href="#inferences" class='sectionRef'></a>.</li>
-    <li>When determining whether two PROV instances are
-  <a>equivalent</a>, an application MUST determine whether their
-  normal forms are equal, as specified in <a href="#equivalence" class="sectionRef"></a>.
-    <li>When determining whether a PROV instance is <a>valid</a>, an
-    application MUST check that all of the
-    constraints of <a href="#constraints" class="sectionRef"></a> are
-  satisfied  on the <a>normal form</a> of the instance.</li>
-    <li> When producing provenance meant for other applications to
-    use, the application SHOULD produce <a>valid</a> provenance. </li>
-  </ol>
-  <div class="note">
-    Should we specify a way for PROV instances to say whether they
-    are meant to be validated or not?  Seems outside the scope of this
-    document, may require changes to PROV-N.
-  </div>
-  
-</section>
-
-
-
-<section id="inferences">
-<h2>Inferences and Definitions</h2>
-
-<p>
-In this section, we describe <a title="inference">inferences</a> and <a title="definition">definitions</a> that MAY be used on
-  provenance data, and a notion of <a
-title="equivalence">equivalence</a> on PROV instances.  
-An  <dfn id="inference">inference</dfn> is a rule that can be applied
-  to PROV instances to add new PROV statements.  A <dfn
-  id="definition">definition</dfn> is a rule that states that a
-  provenance expression is equivalent to some other expressions; thus,
-  defined provenance expressions can be replaced by their definitions,
-and vice versa.
-</p>
-
-<p> Inferences have the following general form:</p>
-<div class='inference' id='inference-example'>
-  <span class='conditional'>IF</span> <span class="name">hyp_1</span> and ... and
-<span class="name">hyp_k</span> <span class='conditional'>THEN</span>
-  there exists <span class="name">a_1</span> and ... and <span
-  class="name">a_m</span> such that <span
-  class="name">conclusion_1</span> and ... and <span class="name">conclusion_n</span>.
-  </div>
- 
-<p>
-  This means that if all of the provenance expressions matching <span class="name">hyp_1</span>... <span class="name">hyp_k</span>
-  can be found in a PROV instance, we can add all of the expressions
-  <span class="name">concl_1</span> ... <span class="name">concl_n</span> to the instance, possibly after generating fresh
-  identifiers <span class="name">a_1</span>,...,<span class="name">a_m</span> for unknown objects.  These fresh
-  identifiers might later be found to be equal to known identifiers;
-  these fresh identifiers play a similar role in PROV constraints to existential variables in logic.
-</p>
-<div class='note'>
-  TODO: Is this re-inventing blank nodes in PROV-DM, and do we want to
-  do this?  A lot of the inferences have existentially quantified
-  conclusions (and there is some theory that supports this).
-
-  TODO: Make sure conjunctive reading of conclusion is clear.
-  </div>
-
-<p> Definitions have the following general form:</p>
-
-<div class='definition' id='definition-example'>
-  <span class="name">defined_exp</span> holds <span class='conditional'>IF AND ONLY IF </span>
-  there exists <span class="name">a_1</span>,..., <span
-  class="name">a_m</span> such that <span
-  class="name">defining_exp_1</span> and  ... and <span class="name">defining_exp_n</span>.
-  </div>
- 
-  <p>
-  This means that a provenance expression defined_exp is defined in
-  terms of other expressions.  This can be viewed as a two-way
-  inference:  If <span class="name">defined_exp</span>
-  can be found in a PROV instance, we can add all of the expressions
-<span class="name">defining_exp_1</span> ... <span class="name">defining_exp_n</span> to the instance, possibly after generating fresh
-  identifiers <span class="name">a_1</span>,...,<span class="name">a_m</span> for unknown objects.  Conversely, if there
-  exist identifiers <span class="name">a_1</span>...<span class="name">a_m</span> such that <span class="name">defining_exp_1</span>
-  and ... and <span class="name">defining_exp_n</span> hold in the instance, we can add the defined
-  expression <span class="name">def_exp</span>.  When an expression is defined in terms of
-  others, it is in a sense redundant; it is safe to replace it with
-  its definition.
-</p>
-  
-
-
-<section>
-  <h3>Component 1: Entities and Activities</h3>
-  
-
-<p>Communication between activities is <a title="definition">defined</a> in terms
-as the existence of an underlying entity generated by one activity and used by the
-other.</p>
-
-<div class='definition' id='wasInformedBy-definition'>Given two activities identified by <span class="name">a1</span> and <span class="name">a2</span>, 
-<span class="name">wasInformedBy(a2,a1)</span>
-holds <span class='conditional'>IF AND ONLY IF</span>
- there is an entity  with some identifier <span class="name">e</span> and some sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
-such that <span class="name">wasGeneratedBy(-,e,a1,-,attrs1)</span> and <span class="name">used(-,a2,e,-,attrs2)</span> hold.
-</div>
-
-<p>The relationship <span class="name">wasInformedBy</span> is not
-transitive. Indeed, consider the following statements.</p>
-<pre class="codeexample">
-wasInformedBy(a2,a1)
-wasInformedBy(a3,a2)
-</pre>
-<p> We cannot infer <span class="name">wasInformedBy(a3,a1)</span> from these expressions. Indeed, 
-from 
-<span class="name">wasInformedBy(a2,a1)</span>, we know that there exists <span class="name">e1</span> such that <span class="name">e1</span> was generated by <span class="name">a1</span>
-and used by <span class="name">a2</span>. Likewise, from <span class="name">wasInformedBy(a3,a2)</span>, we know that there exists  <span class="name">e2</span> such that <span
-class="name">e2</span> was generated by <span class="name">a2</span> and used by <span class="name">a3</span>. The following illustration shows a case for which transitivity cannot hold. The
-horizontal axis represents the event line. We see that <span class="name">e1</span> was generated after <span class="name">e2</span> was used. Furthermore, the illustration also shows that
-<span class="name">a3</span> completes before <span class="name">a1</span>.  So it is impossible for <span class="name">a3</span> to have used an entity generated by <span
-class="name">a1</span>.</p>
-
-<div style="text-align: center;">
-<figure>
-<img src="images/informedByNonTransitive.png" alt="non transitivity of wasInformedBy" />
-<figcaption>Counter-example for transitivity of wasInformedBy</figcaption>
-</figure>
-</div>
-
-
-<p>Start of <span class="name">a2</span> by activity <span
-class="name">a1</span> is <a title="definition">defined</a> as follows.</p>
-
-<div class='definition' id='wasStartedByActivity-definition'>Given two activities with identifiers <span class="name">a1</span> and <span class="name">a2</span>, 
- <span class="name">wasStartedByActivity(a2,a1)</span>
-holds <span class='conditional'>IF AND ONLY IF</span>
- there exists an entity <span class="name">e</span> 
-such that
- <span class="name">wasGeneratedBy(-,e,a1,-,-)</span> 
- and <span class="name">wasStartedBy(-,a2,e,-,-)</span> hold.
-</div>
-
-
-
-
-</section>
-
-<section >
-<h3>Component 2: Agents</h3>
-
-Attribution identifies an agent as responsible for an entity.  An
-agent can only be responsible for an entity if it was associated with
-an activity that generated the entity.  If the activity, generation
-and association events are not explicit in the instance, they can
-be inferred.
-<div class='inference' id='attribution-implication'>
-<span class='conditional'>IF</span>
-<span class="name">wasAttributedTo(e,ag)</span> holds for some identifiers
-<span class="name">e</span> and <span class="name">ag</span>,  
-<span class='conditional'>THEN</span> there exists an activity with some identifier <span class="name">a</span> such that the following statements hold:
-<pre>
-activity(a, -, -,-)
-wasGeneratedBy(-,e, a, -,_)
-wasAssociatedWith(-,a, ag, -, -)
-</pre>
-</div>
-
-<p> Responsibility relates agents where one agent acts on behalf of
-another, in the context of some activity.  The supervising agent
-delegates some responsibility for part of the activity to the
-subordinate agent, while retaining some responsibility for the overall
-activity.  </p>
-
-
-<div class="note">
-  @@TODO: Could this be an inference? Does it imply that
-  a1 is associated with all activities a2 is associated with?
-  </div>
-
-
-</section>
-
- <section> 
-<h3>Component 3: Derivations</h3>
-
-
- <p>Derivations with an explicit activity and no usage admit the
-  following inference: </p>
-<div class='inference' id='derivation-use'>
-<p>Given an activity <span class="name">a</span>, entities  denoted by <span class="name">e1</span> and <span class="name">e2</span>, 
-<span class='conditional'>IF</span> <span class="name">wasDerivedFrom(-,e2,e1, a, -)</span> and <span class="name">wasGeneratedBy(-,e2,a,-,-)</span> hold, <span
-class='conditional'>THEN</span> <span class="name">used(-,a,e1,-,-)</span> also holds.
-</div>
-<p>This inference is justified by the fact that the entity denoted by <span class="name">e2</span> is generated by at most one activity in a given account
-(see <a href="#generation-uniqueness">generation-uniqueness</a>). Hence,  this activity is also the one referred to by the usage of <span class="name">e1</span>. 
-</p>
-
-<div class="note">
-  There is some redundancy in the following discussion.
-  </div>
-
-<p>The converse inference does not hold.
-From <span class="name">wasDerivedFrom(e2,e1)</span> and <span class="name">used(a,e1,-)</span>, one cannot
-derive <span class="name">wasGeneratedBy(e2,a,-)</span> because identifier <span class="name">e1</span> may occur in usages performed by many activities, which may have not generated the entity denoted by <span class="name">e2</span>.</p>
-
-  <p>
-Note that derivation cannot in general be inferred from the existence
-of related usage and generation events. Indeed, when a generation <span class="name">wasGeneratedBy(g, e2, a, -, attrs2)</span>
-<a>precedes</a> <span class="name">used(u, a, e1, -, attrs1)</span>, for
-some <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">attrs1</span>, <span class="name">attrs2</span>, and <span class="name">a</span>, one
-cannot infer derivation <span class="name">wasDerivedFrom(e2, e1, a, g, u)</span>
-or <span class="name">wasDerivedFrom(e2,e1)</span> since 
- <span class="name">e2</span> cannot possibly be derived from
- <span class="name">e1</span>, given the creation of <span class="name">e2</span> <a>precedes</a> the use
-of <span class="name">e1</span>.  That is, if <span class="name">e1</span> is generated
-by an activity before <span class="name">e2</span> is used, then
-obviously  <span class="name">e2</span> cannot have been derived from
-<span class="name">e1</span>.  However, even if  <span
-class="name">e2</span> happens used before   <span class="name">e1</span>
-is generated, it is not safe to assume that  <span
-class="name">e2</span> was derived from  <span class="name">e1</span>.
-</p>
-
-<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>
-
-  
-
-
-
-<p>A revision admits the following inference, linking the two entities
-  by a derivation, and stating them to be alternates.</p>
-
-<div class='inference' id='wasRevision'>
-Given two identifiers <span class="name">e1</span> and <span class="name">e2</span> identifying two entities, and an identifier <span class="name">ag</span> identifying an agent,
-<span class='conditional'>IF</span> <span class="name">wasRevisionOf(-,e2,e1,ag)</span> holds, <span class='conditional'>THEN</span> the following 
-hold:
-<pre>
-wasDerivedFrom(-,e2,e1,-)
-alternateOf(e1,e2)
-wasAttributedTo(e2,ag)
-</pre>
-</div>
-
-<div class="note">
-  The following doesn't make sense because wasRevisionOf and
-  wasDerivedFrom have different types.
-  </div>
-<p><span class="name">wasRevisionOf</span> is a strict sub-relation
- of <span class="name">wasDerivedFrom</span> since two entities <span class="name">e2</span> and <span class="name">e1</span>
- may satisfy <span class="name">wasDerivedFrom(e2,e1)</span> without being a variant of
- each other.
-</p>
-
-
-  <div class="note">
-  Motivation for quotation inference
-  </div>
-<div class='inference' id='quotation-implication'>
-<span class='conditional'>IF</span>
-<span class="name">wasQuotedFrom(e2,e1,ag2,ag1,attrs)</span> holds for some identifiers
-<span class="name">e2</span>, <span class="name">e1</span>, <span class="name">ag2</span>, <span class="name">ag1</span>, 
-<span class='conditional'>THEN</span> the following hold:
-<pre>
-wasDerivedFrom(e2,e1)
-wasAttributedTo(e2,ag2)
-wasAttributedTo(e1,ag1)
-</pre>
-</div>
-
-<p>
-
-
-
-<p>Traceability allows an entity to be transitively linked to another entity it is derived from, to an agent it is attributed to, or another agent having some responsibility, or a trigger of an activity that generated it.</p>
-
-<p>Traceability can be inferred from existing statements, or can be asserted stating that a dependency path exists without its individual steps being expressed. This is captured 
-by the following inferences:
-
-<div class='inference' id='traceability-inference'>
-Given two identifiers <span class="name">e2</span> and  <span class="name">e1</span> for entities, 
-the following statements hold:
-
-<ol> 
-<li><span class='conditional'>IF</span>  <span class="name">wasDerivedFrom(e2,e1,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span
-class="name">u1</span>, <span class='conditional'>THEN</span>  <span class="name">tracedTo(e2,e1)</span> also holds.</li>
-<li><span class='conditional'>IF</span>  <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>THEN</span>  <span class="name">tracedTo(e2,e1)</span> also
-holds.</li>
-<li><span class='conditional'>IF</span>  <span
-class="name">wasAttributedTo(e2,ag1,aAttr)</span> holds, <span
-class='conditional'>THEN</span>  <span
-class="name">tracedTo(e2,ag1)</span> also holds.
-</li>
-<li>
-<span class='conditional'>IF</span>  <span class="name">wasAttributedTo(e2,ag2,aAttr)</span>, <span class="name">wasGeneratedBy(-,e2,a,-,gAttr)</span>,  and <span
-class="name">actedOnBehalfOf(ag2,ag1,a,rAttr)</span> hold, for some  <span class="name">a</span>, <span class="name">ag2</span>, <span class="name">ag1</span>, <span class="name">aAttr</span>,  <span class="name">gAttr</span>, and <span class="name">rAttr</span>, <span
-class='conditional'>THEN</span>  <span class="name">tracedTo(e2,ag1)</span> also holds.</li>
-
-<li><span class='conditional'>IF</span> <span
-class="name">wasGeneratedBy(e2,a,gAttr)</span> and <span
-class="name">wasStartedBy(a,e1,sAttr)</span> hold, for some  <span
-class="name">a</span>, <span class="name">gAttr</span> , <span
-class="name">sAttr</span>  then <span
-class="name">tracedTo(e2,e1)</span> holds.</li>
-<li><span class='conditional'>IF</span>  <span class="name">tracedTo(e2,e)</span> and  <span class="name">tracedTo(e,e1)</span> hold for some  <span class="name">e</span>, <span
-class='conditional'>THEN</span>  <span class="name">tracedTo(e2,e1)</span> also holds.</li>
-</ol>
-</div>
-
-<p>We note that the inference rule <a
-href="#traceability-inference">traceability-inference</a> does not
-allow us to infer anything about the attributes of the related
-entities, agents or events.
-</p>
-
-
-</section>
-
-
- <section> 
-<h3>Component 4: Alternate Entities</h3>
-<div class="note">TODO: There is currently no consensus what inferences on
-  alternate or specialization should be assumed.  The following
-  section lists possible inferences that may or may not be adopted. Section is under review, pending ISSUE-29.
-</div>
-
-
-  <p>The relation <span class='name'>alternateOf</span> is an equivalence relation: <a>reflexive</a>,
-  <a>transitive</a> and <a>symmetric</a>.</p>
-  
-  <div class='inference' id="alternate-reflexive">
-    For any entity <span class='name'>e</span>, we have <span class='name'>alternateOf(e,e)</span>.
-    </div>
-
-
-       <div class='inference' id="alternate-transitive">
-    For any entities <span class='name'>e1</span>, <span
-    class='name'>e2</span>, <span class='name'>e3</span>, <span class="conditional">IF</span> <span class='name'>alternateOf(e1,e2)</span> and
-   <span class='name'>alternateOf(e2,e3)</span> <span class="conditional">THEN</span> <span class='name'>alternateOf(e1,e3)</span>.
-    </div>
-   <div class='inference' id="alternate-symmetric">
-    For any entity <span class='name'>e1</span>, <span class='name'>e2</span>, <span class='conditional'>IF</span>  <span class='name'>alternateOf(e1,e2)</span> <span class='conditional'>THEN</span> <span class='name'>alternateOf(e2,e1)</span>.
-    </div>
-
-<p>Similarly, specialization is a strict partial order: it is <a>irreflexive</a>,
-    <a>anti-symmetric</a> and
-    <a>transitive</a>.</p>
-
-        <div class='inference' id="specialization-irreflexive">
-    For any entity <span class='name'>e</span>, it is not the case that
-    have <span class='name'>specializationOf(e,e)</span>.
-    </div>
-
-<div class='inference' id="specialization-antisymmetric">
-  For any
-    entities <span class='name'>e1</span>, <span
-  class='name'>e2</span>,
-it is not the case that 
-  <span class='name'>specializationOf(e1,e2)</span>
-    and
-	 <span class='name'>specializationOf(e2,e1)</span>.
-</div> 
-       <div class='inference' id="specialization-transitive">
-    For any
-    entities <span class='name'>e1</span>, <span class='name'>e2</span>, <span class='name'>e3</span>, <span class='conditional'>IF</span> <span class='name'>specializationOf(e1,e2)</span>
-    and
-	 <span class='name'>specializationOf(e2,e3)</span> <span class='conditional'>THEN</span> <span class='name'>specializationOf(e1,e3)</span>.
-    </div> 
-
-
-
-    <p>Finally, if one entity specializes another, then they are also
-    alternates:</p>
-    
-       <div class='inference' id="specialization-alternate">
-    For any entities  <span class='name'>e1</span>, <span class='name'>e2</span>, <span class='conditional'>IF</span> <span class='name'>specializationOf(e1,e2)</span> <span class='conditional'>THEN</span> <span class='name'>alternateOf(e1,e2)</span>.
-    </div> 
-
-
-   <div class="note">TODO: Possible inferences about attributes,
-  generation, invalidation?
-  </div>
-
-
-  <div class="note">
-    The following sections are retained from an older version, and are
-    not consistent with the above constraints.  This will be revised
-    once the consensus on ISSUE-29 is clearer.
-    </div>
-    
-  <section id="term-Specialization">
-<h3>Specialization</h3>
-
-
-<p>Specialization is <em>neither symmetric nor anti-symmetric</em>.
-</p>
-
-<div class="anexample" id="anexample-not-symmetric">
-"Alice's toyota car on fifth Avenue" is a specialization of "Alice's toyota car", but the converse does not hold.
-</div>
-
-<div class="anexample" id="anexample-specialization-not-anti-symmetric">
-anti-symmetric counter-example???
-</div>
-
-
-<p>Specialization is <em>transitive</em>. Indeed if <span
-class="name">specializationOf(e1,e2)</span> holds, then there is some
-common thing, say <span class="name">T1-2</span> they both refer to,
-and  <span class="name">e1</span> is a more specific aspect of this
-thing than <span class="name">e2</span>. Likewise, if <span
-class="name">specializationOf(e2,e3)</span> holds, then there is some
-common thing, say <span class="name">T2-3</span> they both refer to, and  <span class="name">e2</span> is a more specific aspect of this
-thing than <span class="name">e3</span>.  The things <span
-class="name">T1-2</span> and <span class="name">T2-3</span> are the
-same since <span class="name">e2</span> is an aspect of both of them,
-so <span
-class="name">specializationOf(e1,e3)</span> follows since <span class="name">e1</span> and <span class="name">e3</span>
-are aspects fo the same thing and <span class="name">e1</span> is more specific than <span class="name">e3</span>. </p>
-
-
-<div class="anexample" id="anexample-specialization-is-transitive">
-A specialization of "this  email message" would be, for example, the "printed version on my desk", which is a specialization of "my thoughts on this email thread".  So, the "printed version on my desk" is also a specialization   "my thoughts on this email thread".
-</div>
-
-
-</section> 
-
-<section id="term-Alternate">
-<h3>Alternate</h3>
-</section> 
-
-
-<p>Alternate not is <em>reflexive</em>. Indeed, <span class="name">alternate(e,e)</span> does not hold for any arbitrary entity <span class="name">e</span> since  <span class="name">e</span> may not be a specialization of another entity.</p>
-
-
-<p>Alternate is <em>symmetric</em>. Indeed, if <span class="name">alternate(e1,e2)</span> holds,
-then there exists an unspecified entity <span class="name">e</span>, such that
-both <span class="name">e1</span> and <span class="name">e2</span> are specialization of <span class="name">e</span>.
-Therefore, <span class="name">alternate(e2,e1)</span> also holds.
-</p>
-
-
-
-<p>Alternate is <em>not transitive</em>. Indeed, if <span class="name">alternate(e1,e2)</span> holds,
-then there exists an unspecified entity <span class="name">e1-2</span>, such that
-both <span class="name">e1</span> and <span class="name">e2</span> are specialization of <span class="name">e1-2</span>.
-Likewise, if <span class="name">alternate(e2,e3)</span> holds,
-then there exists an unspecified entity <span class="name">e2-3</span>, such that
-both <span class="name">e2</span> and <span class="name">e3</span> are specialization of <span class="name">e2-3</span>.
-It does not imply that there is a common entity <span class="name">e1-3</span>
-that both  <span class="name">e1</span> and <span class="name">e3</span> specialize.
-</p>
-
-
-<div class="anexample" id="anexample-alternate-not-transitive1">
-<p>At 6pm, the customer in a chair is a woman in a red dress, who happens to be Alice. After she leaves, another customer arrives at 7pm, a man with glasses, who happens to be Bob.  Transitivity does not hold since the <span class="name">womanInRedDress\</span> is not alternate of <span class="name">customerInChairAt7pm</span>.
-<pre>
-alternate(womanInRedDress,customerInChairAt6pm)
-specialization(customerInChairAt6pm,Alice)
-specialization(womanInRedDress,Alice)
-
-alternate(manWithGlasses,customerInChairAt7pm)
-specialization(customerInChairAt7pm,Bob)
-specialization(manWithGlasses,Bob)
-
-alternate(customerInChairAt6pm, customerInChairAt7pm)
-specialization(customerInChairAt6pm, customerInChair)
-specialization(customerInChairAt7pm, customerInChair)
-</pre>
-</div>
-
-<p>The above example shows that  <span class="name">customerInChairAt6pm</span> and <span class="name">customerInChairAt7pm</span> are two alternate entities that have no overlap, while <span class="name">womanInRedDress</span> and <span class="name">customerInChairAt6pm</span> do overlap.
-The following example   illustrates another case of non-overlapping alternate entities.
-</p>
-
-<div class="anexample">Two copies of the same book, where copy A was destroyed before copy B was made.</div>
-
-
-</section>
-
-</section>
-
-
-
-  <section id="equivalence">
-<h2>Equivalence</h2>
-
-
-  For the purpose of checking inferences and constraints, we define a
-notion of <a>equivalence</a> of PROV s.  Equivalence has the following characteristics:
-
-
-<ul>
-  <li>Missing attributes that are interpreted as omitted values are
-  handled by generating a fresh
-  identifier for the omitted value.
-  </li>
-  <li> Redundant expressions are merged according to uniqueness
-  constraints. </li>
-  <li>
-  The order of provenance expressions is irrelevant to the meaning of
-  a PROV instance.  That is, a
-  PROV instance is equivalent to any other instance obtained by
-  permuting its expressions.
-  </li>
-  <li>
-  Inference rules and definitions preserve equivalence.  That is, a <a>PROV
-  instance</a> is equivalent to the instance obtained by applying any
-  inference rule.
-  </li>
-  <li>Equivalence is reflexive, symmetric, and transitive.</li>
-</ul>
-
-  <section id="optional-attributes">
-  <h3>Optional Attributes</h3>
-  
-<div class="note">
-  TODO: Clarify how optional attributes are handled; clarify merging.  The following is
-  not very explicit about the difference between "not present" and
-  "omitted but inferred".
-  </div>
-<div id="optional-attributes1">PROV-DM allows for some attributes to
-  be optionally expressed. Unless otherwise specified, when an
-  optional attribute is not present in a statement, some value
-  SHOULD be assumed to exist for this attribute, though it is not
-  known which.
-
-  The only exceptions are:
-  <ul>
-   <li><span id="optional-attributes2">Activities also allow for an
-  optional start time attribute.  If both are specified, they MUST be
-  the same, as expressed by the following constraint.</span></li>
-    <li><span id="optional-attributes3">Activities also allow for an optional end time attribute.  If both are specified, they MUST be the same, as expressed by the following constraint.</span></li>
-    <li>
-    <div id="optional-attributes6">In a quotation of the form <span class="name">wasQuotedFrom(e2,e1,-,-,attrs)</span>, the absence of an agent means: either no agent exists, or an agent exists but it is not identified.</div>
-</li>
-<li><div id="optional-attributes4">In an association of the form
-  <span class="name">wasAssociatedWith(a, ag, -, attr)</span>, the
-  absence of a plan means: either no plan exists, or a plan exists but
-  it is not identified.</div></li>
-  <li><div id="optional-attributes5">
-In an association of the form <span class="name">wasAssociatedWith(a, -, pl, attr)</span>, an agent exists but it is not identified.</div>
-</li>
-<li><div id="optional-activity">
-In a a delegation of the form <span class="name">actedOnBehalfOf(a,
-  ag2, ag1, -, attr)</span>, the absence of an activity means that
-  <span class="name">a2</span> acts on behalf of <span
-  class="name">a1</span> for all activities with which <span
-  class="name">a2</span> is
-  associated.
-</div></li>
-   </ul>
-</div>
-
-</section>
-
-<section id="normalization">
-<h3>Normalization</h3>
-
-
-<p>
-We define the <dfn>normal form</dfn> of a PROV instance as the set
-of provenance expressions resulting from merging all of the overlapping
-expressions in the instance and applying all possible inference rules
-to this set.  Formally, we say that two PROV  instances are
-<dfn>equivalent</dfn> if they have the same normal form (that is,
-after applying all possible inference rules, the two instances produce
-the same set of PROV-DM expressions.)
-</p>
-
-<div class="note">
-  We should check that normal forms exist, i.e. that applying rules
-  and definitions eventually terminates.  More clarity is needed about
-  enforcing uniqueness via merging vs. constraint checking.
-  </div>
-
-<p> An application that processes PROV-DM data SHOULD handle
-equivalent instances in the same way. (Common exceptions to this rule
-include, for example, pretty printers that seek to preserve the
-original order of statements in a file and avoid expanding
-inferences.)  </p>
-
-</section>
-  
-</section> <!-- inferences -->
-
-<section id="constraints">
-<h2>Validity Constraints</h2>
-
-
-
-
-<p>
-This section defines a collection of constraints on PROV instances.  A PROV instance is <dfn id="dfn-valid">valid</dfn>
-  if, after applying all possible inference and definition rules from
-  <a href="#inferences">Section 2</a>, the resulting instance
-  satisfies all of the constraints specified in this section.
- </p>
-
-  <p> There are two kinds of constraints:
-  <ul><li><em>uniqueness constraints</em> that say that a <a>PROV
-  instance</a> can contain at most one expression or that multiple
-  expressions about the same objects need to have the same values (for
-  example, if we describe the same generation event twice, then the
-  two expressions should have the same times);
-    </li>
-    <li> and <em>event ordering constraints</em> that say that it
-  should be possible to arrange the 
-  events (generation, usage, invalidation, start, end) described in a
-  PROV instance into a partial order that corresponds to a sensible
-  "history" (for example, an entity should not be generated after it
-  is used).
-    </li>
-    </ul>
-
-<p>The PROV data model is implicitly based on a notion of <dfn
-  id="dfn-event">instantaneous event</dfn>s (or just <a
-  title="instantaneous event">event</a>s), that mark
-transitions in the world.  Events include generation, usage, or
-invalidation of entities, as well as starting or ending of activities.  This
-notion of event is not first-class in the data model, but it is useful
-for explaining its other concepts and its semantics [[PROV-SEM]].
-Thus, events help justify  <i>inferences</i> on provenance as well as
-<i>validity</i> constraints indicating when provenance is self-consistent. In <a href="#section-event-time" class="sectionRef"></a> we
-discuss the motivation for <a title="instantaneous event">instantaneous events</a>
-and their relationship to time in greater detail.</p>
-
-<p>  PROV-DM
-identifies five kinds of <a title="instantaneous event">instantaneous events</a>, namely <a>entity generation
-event</a>, <a>entity usage event</a>, <a>entity invalidation event</a>, <a>activity start event</a>
-and <a>activity end event</a>.  PROV-DM adopts Lamport's clock
-assumptions [[CLOCK]] in the form of a reflexive, transitive partial order <a>follows</a>
-(and its inverse <a>precedes</a>) between <a title="instantaneous event">instantaneous events</a>.  Furthermore,
-PROV-DM assumes the existence of a mapping from <a title="instantaneous event">instantaneous events</a> to time clocks,
-though the actual mapping is not in scope of this specification.</p>
-
-    
-<div class="note">
-  TODO: More about what it means for constraints to be satisfied;
-  constraint template(s)
-  </div>
-  
-    <section id="structural-constraints">
-<h3>Uniqueness Constraints</h3>
-
-<div class="note">
-Attribute uniqueness constraints?
-</div>
-
-  <p> We assume that the various identified objects of PROV-DM have
-  unique statements describing them within a PROV instance.
-  </p>
-  <div class='constraint' id='entity-unique'>
-<p>Given an entity identifier <span class="name">e</span>, there is at
-  most one expression 
-<span class="name">entity(e,attrs)</span>, where <span
-  class="name">attrs</span> is some set of attribute-values.</p>
-    </div>
-  <div class='constraint' id='activity-unique'>
-<p>Given an activity identifier <span class="name">a</span>, there is
-  at most one expression 
-<span class="name">activity(a,t1,t2,attrs)</span>, where <span
-  class="name">attrs</span> is some set of attribute-values.</p>
-    </div>
-    <div class="note">TODO: Same goes for all other objects:
-  agent, note, generation, usage, invalidation, start, end,
-  communication, start by, attribution, association, responsibility, 
-  derivation, revision, quotation.  We should find a
-  way of saying this once concisely.
-      </div>
-  
-<p>We assume that an entity has exactly one generation and
-invalidation event (either or both may, however, be left implicit).
-So, PROV-DM allows for two distinct <a>generations</a>  <span class="name">g1</span> and <span class="name">g2</span> referencing the same entity provided they occur
-<em>simultaneously</em>. 
-This implies that the two generation events are actually the same and
-caused by the same <em>activity</em>, though  provenance may contain
-several  statements for the same world activity. 
-</p>
-
-
-<div class='constraint' id='generation-uniqueness'>Given an entity denoted by <span class="name">e</span>, two activities denoted by <span class="name">a1</span> and <span
-class="name">a2</span>, two time instants  <span class="name">t1</span> and <span
-class="name">t2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
-<span class='conditional'>IF</span> <span class="name">wasGeneratedBy(id1, e, a1, t1, attrs1)</span> and <span class="name">wasGeneratedBy(id2, e, a2, t2, attrs2)</span> exist,
-<span class='conditional'>THEN</span> <span class="name">id1</span>=<span class="name">id2</span>, <span class="name">a1</span>=<span class="name">a2</span>, <span class="name">t1</span>=<span class="name">t2</span>  and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
-</div> 
-
-<div class="note">
-Wouldn't the above constraint violate uniqueness?
-</div>
-
-<div class="note">
-Invalidation uniqueness?
-</div>
-
-<p>A generation can be used to indicate a generation time without having to specify the involved activity.  A generation time is unique, as specified by the following constraint.<p> 
-<div class="note">
-Seems redundant given generation-uniqueness
-</div>
-<div class='constraint' id='unique-generation-time'>
-Given an entity denoted by <span class="name">e</span> and 
-two time instants  <span class="name">t1</span> and <span
-class="name">t2</span>,
-<span class='conditional'>IF</span> <span class="name">wasGeneratedBy(e, -, t1)</span> and <span class="name">wasGeneratedBy(e, -, t2)</span> hold, <span class='conditional'>THEN</span> <span class="name">t1</span>=<span class="name">t2</span>.
-</div> 
-
-<p>An <a>activity start event</a> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity starts. It allows for an optional time attribute.  <span id="optional-start-time">Activities also allow for an optional start time attribute.  If both are specified, they MUST be the same, as expressed by the following constraint.</span>
-</p>
-
-<div class='constraint' id='unique-startTime'>
-<span class='conditional'>IF</span> <span class="name">activity(a,t1,t2,-)</span> and <span class="name">wasStartedBy(id,a,e,t,-)</span>,  <span class='conditional'>THEN</span> <span class="name">t</span>=<span class="name">t1</span>.
-</div> 
-
-<p>An <a>activity end event</a> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity ends. It allows for an optional time attribute.  <span id="optional-end-time">Activities also allow for an optional end time attribute.  If both are specified, they MUST be the same, as expressed by the following constraint.</span>
-</p>
-
-<div class='constraint' id='unique-endTime'>
-<span class='conditional'>IF</span> <span
-  class="name">activity(a,t1,t2,-)</span> and <span
-  class="name">wasEndedBy(id,a,e,t,-)</span>,  <span
-  class='conditional'>THEN</span> <span class="name">t</span> = <span class="name">t2</span>.
-</div> 
-
-
-
-
-</section> <!-- uniqueness-constraints--> 
-
-<section id="event-ordering-constraints">
-<h3>Event Ordering Constraints</h3>
-
-
-<p>Given that provenance consists of a description of past entities
-and activities, <a>valid</a> provenance instances MUST
-satisfy <em>ordering constraints</em> between instantaneous events, which we introduce in
-this section.  For instance, an entity can only be used after it was
-generated; hence, we say that an entity's <a title="entity generation
-event">generation event</a> precedes any of this
-entity's <a title="entity usage event">usage events</a>.  Should this
-ordering constraint be violated, the associated generation and
-usage could not be credible.  The rest of this section defines
-the <dfn>temporal interpretation</dfn> of provenance instances as a
-set of instantaneous event ordering constraints. </p>
-
-
-<p>To allow for minimalistic clock assumptions, like Lamport
-[[CLOCK]], PROV-DM relies on a notion of relative ordering of <a title="instantaneous event">instantaneous events</a>,
-without using physical clocks. This specification assumes that a partial order exists between <a title="instantaneous event">instantaneous events</a>.
-</p>
-
-
-<p>Specifically, <dfn id="dfn-precedes">precedes</dfn> is a partial
-order between <a title="instantaneous event">instantaneous events</a>.  When we say
-<span class="name">e1</span> precedes <span class="name">e2</span>,
-this means that either the two events are equal or <span
-class="name">e1</span> happened before <span class="name">e2</span>.
-For symmetry, <dfn id="dfn-follows">follows</dfn> is defined as the
-inverse of <a title="precedes">precedes</a>; that is, when we say
-<span class="name">e1</span> follows <span class="name">e2</span>,
-this means that either the two events are equal or <span
-class="name">e1</span> happened after <span
-class="name">e2</span>. Both relations are partial orders, meaning
-that they are reflexive, transitive, and antisymmetric.</p>
-
-<div class="note"> Do we want to allow an event to
-  "precede" itself?  Perhaps precedes should be strict.
-</div>
-
-<div class="note">
-  The following discussion is unclear: what is being said here, and why?
-  </div>
-
-<p>PROV-DM also allows for time observations to be inserted in
-specific provenance statements, for each of the five kinds
-of <a title="instantaneous event">instantaneous events</a> introduced in this specification.  The
-presence of a time observation for a given <a>instantaneous event</a> fixes the
-mapping of this <a>instantaneous event</a> to the timeline. The presence of time
-information in a provenance statement instantiates the ordering constraint with
-that time information. It is expected that such instantiated
-constraints can help corroborate provenance information. We anticipate
-that verification algorithms could be developed, though this
-verification is outside the scope of this specification.
-</p>
-
-<p>The following figure summarizes the ordering constraints in a
-graphical manner. For each subfigure, an event time line points to the
-right. Activities are represented by rectangles, whereas entities are
-represented by circles. Usage, generation and derivation are
-represented by the corresponding edges between entities and
-activities.  The five kinds of <a title="instantaneous event">instantaneous events</a> are represented by vertical
-dotted lines (adjacent to the vertical sides of an activity's
-rectangle, or intersecting usage and generation edges).  The ordering
-constraints are represented by triangles: an occurrence of a triangle between two <a title="instantaneous event">instantaneous event</a> vertical dotted lines represents that the event denoted by the left
-line precedes the event denoted by the right line.</p>
-
-
-  
-<div style="text-align: center;">
-<figure>
-<figcaption id="ordering-activity-fig">Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints for activities</figcaption>
-<img src="images/ordering-activity.png" alt="constraints between events" />
-</figure>
-</div>
-
-<!-- Constraint template: 
-<span class="conditional">IF</span>
-<span class="name">blah</span> 
-and
-<span class="name">blah</span> 
-<span class="conditional">THEN</span>
-<span class="name">XX</span> 
-<a>precedes</a>
-<span class="name">YY</span>.
--->
-
-<section>
-<h3>Activity constraints</h3>
-
-<p>
-In this section we discuss constraints from the perspective of
-the <a>lifetime</a> of an activity.  An activity starts, then during
-its lifetime uses, generates entities and communicates with  or starts
-other
-activities, and finally ends.  The following constraints amount to
-checking that all of the events associated with an activity take place
-within the activity's lifetime, and the start and end events mark the
-start and endpoints of its lifetime.
-</p>
-
-<hr />
-
-<p>The existence of an activity implies that the <a>activity start event</a> always <a>precedes</a> the corresponding <a>activity end
-event</a>.  This is
-illustrated by Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a> (a) and  expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p> 
-<div class='constraint' id='start-precedes-end'>
-<span class="conditional">IF</span>
-<span class="name">wasStartedBy(start,a,-,-)</span> 
-and
-<span class="name">wasEndedBy(end,a,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">start</span> 
-<a>precedes</a>
-<span class="name">end</span>.
-</div>
-
-<hr />
-
-<p>A usage implies ordering of <a title="instantaneous event">events</a>, since the <a title="entity usage event">usage event</a> had to occur during the associated activity. This is
-illustrated by Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a> (b) and  expressed by constraint <a href="#usage-within-activity">usage-within-activity</a>.</p>
-
-<div class='constraint' id='usage-within-activity'>
-<ol>
-    <li>
-  <span class="conditional">IF</span>
-<span class="name">used(use,a,e,-,-)</span> 
-and
-<span class="name">wasStartedBy(start,a,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">start</span> 
-<a>precedes</a>
-<span class="name">use</span>.
-  </li>
-  <li>
-  <span class="conditional">IF</span>
-<span class="name">used(use,a,e,-,-)</span> 
-and
-<span class="name">wasEndedBy(end,a,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">use</span> 
-<a>precedes</a>
-<span class="name">end</span>.
-  </li>
-  </ol>
-</div>
-
-<hr />
-
-
-<p>A generation implies ordering of <a title="instantaneous event">events</a>, since the <a title="entity generation event">generation event</a> had to occur during the associated activity. This is
-illustrated by Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a> (c) and  expressed by constraint <a href="#generation-within-activity">generation-within-activity</a>.</p> 
-
-<div class='constraint' id='generation-within-activity'>
-   <ol>
-    <li>
-  <span class="conditional">IF</span>
-<span class="name">wasGeneratedBy(gen,a,e,-,-)</span> 
-and
-<span class="name">wasStartedBy(start,a,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">start</span> 
-<a>precedes</a>
-<span class="name">gen</span>.
-  </li>
-  <li>
-  <span class="conditional">IF</span>
-<span class="name">wasGeneratedBy(gen,a,e,-,-)</span> 
-and
-<span class="name">wasEndedBy(end,a,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">gen</span> 
-<a>precedes</a>
-<span class="name">end</span>.
-  </li>
-  </ol>
-</div> 
-
-<hr />
-
-<p>Communication between two activities <span class="name">a1</span> and <span class="name">a2</span> also implies ordering of <a
-title="instantaneous event">events</a>, since some entity must have been generated by the former and used by the latter, which implies that the start event of  <span class="name">a1</span>
-cannot follow the end event of  <span class="name">a2</span>. This is
-illustrated by Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a> (d) and  expressed by constraint <a href="#wasInformedBy-ordering">wasInformedBy-ordering</a>.</p>
-
-<div class='constraint' id='wasInformedBy-ordering'>
- <span class="conditional">IF</span>
-<span class="name">wasInformedBy(a2,a1)</span> 
-and
-<span class="name">wasStartedBy(start,a1,-,-)</span> 
-and
-<span class="name">wasEndedBy(end,a2,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">start</span> 
-<a>precedes</a>
-<span class="name">end</span>.
-
-</div>
-
-<hr />
-
-<p>Start of <span class="name">a2</span> by activity <span class="name">a1</span> also implies ordering of <a
-title="instantaneous event">events</a>, since  <span class="name">a1</span> must have been active before   <span class="name">a2</span> started. This is
-illustrated by Subfigure <a href="#ordering-activity-fig">ordering-activity-fig</a> (e) and  expressed by constraint <a href="#wasStartedByActivity-ordering">wasStartedByActivity-ordering</a>.</p>
-
-
-<div class='constraint' id='wasStartedByActivity-ordering'>
-   <span class="conditional">IF</span>
-<span class="name">wasStartedByActivity(a2,a1)</span> 
-and
-<span class="name">wasStartedBy(start1,a1,-,-)</span> 
-and
-<span class="name">wasStartedBy(start2,a2,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">start1</span> 
-<a>precedes</a>
-<span class="name">start2</span>.
-
-</div>
-
-</section>
-
-<section>
-<h3> Entity constraints</h3>
-
-<p>
-As with activities, entities have lifetimes: they are generated, then
-can be used, revised, or other entities can be derived from them, and
-finally are invalidated.
-</p>
-
-
-  
-<div style="text-align: center;">
-<figure>
-<figcaption id="ordering-entity-fig">Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints for entities</figcaption>
-<img src="images/ordering-entity.png" alt="ordering constraints for entities" />
-</figure>
-</div>
-
-
-<hr />
-
-<p>Generation of an entity precedes its invalidation. (This
-follows from other constraints if the entity is used, but we state it
-explicitly to cover the case of an entity that is generated and
-invalidated without being used.)</p>
-
-<div class='constraint' id='generation-precedes-invalidation'>
- <span class="conditional">IF</span>
-<span class="name">wasGeneratedBy(gen,e,_,_)</span> 
-and
-<span class="name">wasInvalidatedBy(inv,e,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">gen</span> 
-<a>precedes</a>
-<span class="name">inv</span>. 
-</div>
-<hr />
-
-<p> A usage and a generation for a given entity implies ordering of <a title="instantaneous event">events</a>, since the <a title="entity generation
-event">generation event</a> had to precede the <a title="entity usage event">usage event</a>. This is
-illustrated by Subfigure <a href="#ordering-entity-fig">ordering-entity-fig</a> (a) and  expressed by constraint <a href="#generation-precedes-usage">generation-precedes-usage</a>.</p>
-
-<div class='constraint' id='generation-precedes-usage'>
-  <span class="conditional">IF</span>
-<span class="name">wasGeneratedBy(gen,e,_,_)</span> 
-and
-<span class="name">used(use,_,e,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">gen</span> 
-<a>precedes</a>
-<span class="name">use</span>.  
-</div>
-
-<hr />
-
-<p>All usages of an entity precede its invalidation, which is captured by constraint <a href="#usage-precedes-invalidation">usage-precedes-invalidation</a> (without any explicit graphical representation).</p> 
-
-<div class='constraint' id='usage-precedes-invalidation'>
-    <span class="conditional">IF</span>
-<span class="name">used(use,_,e,-)</span> 
-and
-<span class="name">wasInvalidatedBy(inv,e,_,_)</span> 
-<span class="conditional">THEN</span>
-<span class="name">use</span> 
-<a>precedes</a>
-<span class="name">inv</span>.  
-</div>
-
-
-
-<hr />
-
-
-
-
-
-
-<p>If there is a derivation between <span class="name">e2</span> and <span class="name">e1</span>, then 
-this means that the entity <span class="name">e1</span> had some form of influence on the entity <span class="name">e2</span>; for this to be possible, some event ordering must be satisfied.
-First, we consider derivations, where the activity and usage are known. In that case, the <a title="entity usage event">usage</a> of <span class="name">e1</span> has to precede the <a title="entity generation
-event">generation</a> of <span class="name">e2</span>.
-This is
-illustrated by Subfigure <a href="#ordering-entity-fig">ordering-entity-fig</a> (b) and  expressed by constraint <a
-href="#derivation-usage-generation-ordering">derivation-usage-generation-ordering</a>.</p>
-
-
-<div class='constraint' id='derivation-usage-generation-ordering'>
-      <span class="conditional">IF</span>
-<span class="name">wasDerivedFrom(d,e2,e1,a,g2,u1,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">u1</span> 
-<a>precedes</a>
-<span class="name">g2</span>.  
-
-</div>
-<hr />
-
-<p>When the usage is unknown, a similar constraint exists, except that the constraint refers to its
-generation event, as
-illustrated by Subfigure <a href="#ordering-entity-fig">ordering-entity-fig</a> (c) and  expressed by constraint <a
-href="#derivation-generation-generation-ordering">derivation-generation-generation-ordering</a>.</p>
-
-<div class='constraint'
-  id='derivation-generation-generation-ordering'>
- <span class="conditional">IF</span>
-<span class="name">wasDerivedFrom(e2,e1,attrs)</span>
-  and
-<span class="name">wasGeneratedBy(gen1,e1,_,_)</span>
-  and
-<span class="name">wasGeneratedBy(gen2,e2,_,_)</span>
-<span class="conditional">THEN</span>
-<span class="name">gen1</span> 
-<a>precedes</a>
-<span class="name">gen2</span>.  
-  </div>
-
-<p>Note that event ordering is between generations of <span class="name">e1</span>
-and <span class="name">e2</span>, as opposed to derivation where usage is known,
-which implies ordering ordering between the usage of <span class="name">e1</span> and
-generation of <span class="name">e2</span>.  </p>
-
-<hr />
-
-<p>The entity that triggered the start of an activity must exist before the activity starts.
-This is
-illustrated by Subfigure <a href="#ordering-entity-trigger-fig">ordering-entity-trigger-fig</a> (a) and  expressed by constraint <a href="#wasStartedBy-ordering">wasStartedBy-ordering</a>.</p>
-
-
-<div class='constraint' id='wasStartedBy-ordering'>
- <ol>
-    <li>
-    <span class="conditional">IF</span>
-<span class="name">wasStartedBy(start,a,e,-)</span> 
-and
-<span class="name">wasGeneratedBy(gen,e,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">gen</span> 
-<a>precedes</a>
-<span class="name">start</span>.
-  </li><li>
-    <span class="conditional">IF</span>
-<span class="name">wasStartedBy(start,a,e,-)</span> 
-and
-<span class="name">wasInvalidatedBy(inv,e,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">start</span> 
-<a>precedes</a>
-<span class="name">inv</span>.
-  </li>
-  </ol>
-</div>
-<hr />
-
-<p> Similarly,  the entity that triggered the end of an activity must exist before the activity ends, as illustrated by Subfigure <a href="#ordering-entity-trigger-fig">ordering-entity-trigger-fig</a> (b).</p> 
-
-
-<div class='constraint' id='wasEndedBy-ordering'>
- <ol>
-      <li>
-    <span class="conditional">IF</span>
-<span class="name">wasEndedBy(end,a,e,-)</span> 
-and
-<span class="name">wasGeneratedBy(gen,e,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">gen</span> 
-<a>precedes</a>
-<span class="name">end</span>.
-  </li><li>
-    <span class="conditional">IF</span>
-<span class="name">wasEndedBy(end,a,e,-)</span> 
-and
-<span class="name">wasInvalidatedBy(inv,e,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">end</span> 
-<a>precedes</a>
-<span class="name">inv</span>.
-  </li>
-  </ol>
-</div>
-
-<div style="text-align: center;">
-<figure>
-<figcaption id="ordering-entity-trigger-fig">Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints for trigger entities</figcaption>
-<img src="images/ordering-entity-trigger.png" alt="ordering constraints for trigger entities" />
-</figure>
-</div>
-
-
-</section>
-
-<section>
-<h3> Agent constraints</h3>
-
-<p>
-Like entities and activities, agents have lifetimes that follow a
-familiar pattern: an agent is generated, can participate in
-interactions such as starting, ending or association with an
-activity, attribution, or delegation, and finally the agent is invalidated.
-</p>
-<p>Further constraints associated with agents appear in Figure <a href="#ordering-agents">ordering-agents</a> and are discussed below.</p>
-
-<div style="text-align: center;">
-<figure>
-<figcaption id="ordering-agents">Summary of <a title="instantaneous event">instantaneous event</a> ordering constraints (continued)</figcaption>
-<img src="images/ordering-agents.png" alt="ordering constraints for agents" />
-</figure>
-</div>
-
-<hr />
-
-
-<p>An activity that was associated with an agent must have some overlap with the agent. The agent may be generated, or may only become associated with the activity, after the activity start: so, the agent is required to exist before the activity end. Likewise, the agent may be destructed, or may terminate its association with the activity, before the activity end: hence, the agent invalidation is required to happen after the activity start.
-This is
-illustrated by Subfigure <a href="#ordering-agents">ordering-agents</a> (a) and  expressed by constraint <a href="#wasAssociatedWith-ordering">wasAssociatedWith-ordering</a>.</p>
-
-
-<div class='constraint' id='wasAssociatedWith-ordering'>
-  <ol>    <li>
-    <span class="conditional">IF</span>
-<span class="name">wasAssociatedWith(a,ag)</span> 
-and
-<span class="name">wasStartedBy(start,a,-,-)</span> 
-and
-<span class="name">wasInvalidatedBy(inv,ag,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">start</span> 
-<a>precedes</a>
-<span class="name">inv</span>.
-  </li><li>
-    <span class="conditional">IF</span>
-<span class="name">wasAssociatedWith(a,ag)</span> 
-and
-<span class="name">wasGeneratedBy(gen,ag,-,-)</span> 
-and
-<span class="name">wasEndedBy(end,a,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">gen</span> 
-<a>precedes</a>
-<span class="name">end</span>.
-  </li>
-  </ol>
-</div>
-
-<hr />
-
-<p>An entity that was attributed to an agent must have some overlap
-with the agent. The agent is required to exist before the entity
-invalidation. Likewise, the entity generation must precede the agent destruction.
-This is
-illustrated by Subfigure <a href="#ordering-agents">ordering-agents</a> (b) and  expressed by constraint <a href="#wasAttributedTo-ordering">wasAttributedTo-ordering</a>.</p>
-
-
-
- 
-<div class='constraint' id='wasAttributedTo-ordering'>
-      <ol> <li>
-    <span class="conditional">IF</span>
-<span class="name">wasAttributedTo(e,ag)</span> 
-and
-<span class="name">wasGeneratedBy(gen,e,-,-)</span> 
-and
-<span class="name">wasInvalidatedBy(inv,ag,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">gen</span> 
-<a>precedes</a>
-<span class="name">inv</span>.
-  </li><li>
-    <span class="conditional">IF</span>
-<span class="name">wasAttributedTo(e,ag)</span> 
-and
-<span class="name">wasGeneratedBy(gen,ag,-,-)</span> 
-and
-<span class="name">wasInvalidatedBy(inv,e,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">gen</span> 
-<a>precedes</a>
-<span class="name">inv</span>.
-  </li>
-  </ol>
-</div>
-
-<hr />
-
-<p>For responsibility, two agents need to have some overlap in their lifetime.</p>
-
-
-<div class='constraint' id='actedOnBehalfOf-ordering'>
-  <span class="conditional">IF</span>
-<span class="name">actedOnBehalfOf(ag2,ag1)</span> 
-and
-<span class="name">wasGeneratedBy(gen,ag1,-,-)</span> 
-and
-<span class="name">wasInvalidatedBy(inv,ag2,-,-)</span> 
-<span class="conditional">THEN</span>
-<span class="name">gen</span> 
-<a>precedes</a>
-<span class="name">inv</span>.
-
-</div>
-
-</section>
-
-</section> <!--event-ordering-constraints--> 
-
-</section> <!-- constraints -->
-
-<section id="collection-constraints">
-<h2>Collection Constraints</h2>
-<div class="note">
-  Work on collections and on these constraints is deferred until after
-  the next working draft, so this section may not be stable.
-  </div>
-  
-<p>Membership is a convenience notation, since it can be expressed in terms of an insertion into some collection. The membership definition is formalized by constraint <a href="#membership-as-insertion">membership-as-insertion</a>.</p>
-
-<div class='definition' id='membership-as-insertion'>
- <span class="name">memberOf(c, {(k1, v1), ...})</span> holds
-<span class='conditional'>IF AND ONLY IF</span> there exists a collection <span class="name">c0</span>, such that
-<span class="name">derivedByInsertionFrom(c, c0, {(k1, v1), ...})</span>.
-</div>
-
-<p>A collection may be obtained by insertion or removal, or said to satisfy the membership relation.
-To provide an interpretation of collections, PROV-DM 
- restricts one collection to be involved in a single derivation by insertion or removal, or to one membership relation.
-PROV-DM does not provide an interpretation for statements that consist of two (or more) insertion, removal, membership relations that result in the same collection.</p>
-
-
-
-<p>The following constraint ensures unique derivation.</p>
-
-
-<div class='note'> The following constraint is unclear.</div>
-<div class='constraint' id='collection-unique-derivation'>
-A collection MUST NOT be derived through multiple insertions, removal,
-  or membership relations. 
-</div>
-
-<div class="anexample">
-Consider the following statements about three collections.
-  <pre class="codeexample">
-entity(c1, [prov:type="prov:Collection"  %% xsd:QName])
-entity(c2, [prov:type="prov:Collection"  %% xsd:QName])
-entity(c3, [prov:type="prov:Collection"  %% xsd:QName])
-
-
-derivedByInsertionFrom(c3, c1, {("k1", e1), ("k2", e2)})
-derivedByInsertionFrom(c3, c2, {("k3", e3)})
-</pre>
-<p>There is no interpretation for such statements since <span class="name">c3</span> is derived multiple times by insertion.</p>
-</div>
-
-
-<div class="anexample">
-<p>As a particular case, collection <span class="name">c</span> is derived multiple times from the same <span class="name">c1</span>. </p>
-<pre class="codeexample">
-derivedByInsertionFrom(id1, c, c1, {("k1", e1), ("k2", e2)})
-derivedByInsertionFrom(id2, c, c1, {("k3", e3), ("k4", e4)})
-</pre>
-<p>The interpretation of such statements is also unspecified. </p>
-<p>To describe the insertion of the 4 key-entity pairs, one would instead write:</p>
-<pre class="codeexample">
-derivedByInsertionFrom(id1, c, c1, {("k1", e1), ("k2", e2), ("k3", e3), ("k4", e4)})
-</pre>  
-</div>
-
-The same is true for any combination of insertions, removals, and membership relations:
-<div class="anexample">
-<p>The following statements</p>
-<pre class="codeexample">
-derivedByInsertionFrom(c, c1, {("k1", e1)})
-derivedByRemovalFrom(c, c2, {"k2"})
-</pre>
-have no interpretation.
-Nor have the following:
-<pre class="codeexample">
-derivedByInsertionFrom(c, c1, {("k1", e1)})
-memberOf(c, {"k2"}).
-</pre>
-</div>
-
-
-
-<section id="collection-branching">
-<h4>Collection branching</h4>
-
-It is allowed to have multiple derivations from a single root collection, as long as the resulting entities are distinct, as shown in the following example.
-
-<div class="anexample">
-<pre class="codeexample">
-entity(c0, [prov:type="prov:EmptyCollection" %% xsd:QName])    // c0 is an empty collection
-entity(c1, [prov:type="prov:Collection" %% xsd:QName])
-entity(c2, [prov:type="prov:Collection" %% xsd:QName])
-entity(c3, [prov:type="prov:Collection" %% xsd:QName])
-entity(e1)
-entity(e2)
-entity(e3)
-
-derivedByInsertionFrom(c1, c0, {("k1", e1)})      
-derivedByInsertionFrom(c2, c0, {("k2", e2)})       
-derivedByInsertionFrom(c3, c1, {("k3", e3)})       
-</pre>
-From this set of statements, we conclude:
-<pre class="codeexample">
-  c1 = { ("k1", e1) }
-  c2 = { ("k2", e2) }
-  c3 = { ("k1", e1), ("k3", e3)}
-</pre>
-</div>
-
-</section>
-
-  
-
-<section id="collections-and-derivation">
-
-  
-<h4>Collections and Weaker Derivation Relation</h4>
-
-<p>The state of a collection is only known to the extent that a chain
-of derivations starting from an empty collection can be found. Since a
-set of statements regarding a collection's evolution may be
-incomplete, so is the reconstructed state obtained by querying those
-statements. In general, all statements reflect partial knowledge regarding a sequence of data transformation events. In the particular case of collection evolution, in which some of the state changes may have been missed, the more generic derivation relation should be used to signal that some updates may have occurred, which cannot be expressed as insertions or removals. The following  example illustrates this.</p>
-
-
- 
- <div class="anexample">
-In the example, the state of <span class="name">c2</span> is only partially known because the collection is constructed from partially known other collections.
- <pre class="codeexample">
-entity(c0, [prov:type="prov:EmptyCollection" %% xsd:QName])    // c0 is an empty collection
-entity(c1, [prov:type="prov:Collection" %% xsd:QName])    
-entity(c2, [prov:type="prov:Collection" %% xsd:QName])    
-entity(c3, [prov:type="prov:Collection" %% xsd:QName])    
-entity(e1)
-entity(e2)
-
-derivedByInsertionFrom(c1, c0, {("k1", e1)})       
-wasDerivedFrom(c2, c1)                       
-derivedByInsertionFrom(c3, c2, {("k2", e2)})       
- </pre>
-From this set of statements, we conclude:
-<ul>
-<li>    <span class="name">c1 = { ("k1", e1) }</span>
-<li>    <span class="name">c2</span> is somehow derived from <span class="name">c1</span>, but the precise sequence of updates is unknown
-<li>    <span class="name">c3</span>  includes  <span class="name">("k2", e2)</span> but the earlier "gap" leaves uncertainty regarding  <span class="name">("k1", e1)</span>  (it may have been removed) or any other pair that may have been added as part of the derivation activities.
-</ul>
- </div>
-
-</section>
-
-
-<div class='note'>
-  Do the insertion/removal derivation steps imply wasDerivedFrom,
-  wasVersionOf, alternateOf?
-  </div>
- 
-</section> <!-- collection-constraints -->
-
-<section id="account-constraints">
-<h2>Account Constraints</h2>
-
-<div class="note">
-Work on accounts has been deferred until after the next working draft,
-so this section is very unstable
-</div>
-
-<p>PROV-DM allows for multiple descriptions of entities (and in general any identifiable object) to be expressed. </p>
-
-<div class="anexample" id="example-two-entities-one-id">
-<p>Let us consider two statements about the same entity, which we have taken from two different contexts. A working draft published by the <span class="name">w3:Consortium</span>:</p>
-<pre class="codeexample">
-entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
-</pre>
-The second version of a document edited by some authors:
-<pre class="codeexample">
-entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
-</pre>
-<p>Both statements are about the same entity identified  by
-<span class="name">tr:WD-prov-dm-20111215</span>, but they contain different attributes, describing the situation or partial state of the these entities according to the context in which they occur.
-</p>
-</div>
-
-
-
-<p>Two different statements about the same entity cannot co-exist in a PROV instance
- as formalized in <a href="#entity-unique">entity-unique</a>.</p>
-
-<!-- Moved to uniqueness constraints section
-<div class='constraint' id='entity-unique'>
-<p>Given an entity identifier <span class="name">e</span>, there is at most one statement 
-<span class="name">entity(e,attrs)</span> occurring in a given
-  account, where <span class="name">attrs</span> is some set of
-  attribute-values. Other statements concerning the same entity can exist in different accounts.</p>
-
-<p>This constraint similarly applies to all other types and relations,
-  with explicit identity.</p>
-</div>
--->
-
-
-
-<p>In some cases, there may be a requirement  for two different
-  statements concerning the same entity to be included in the same account. To satisfy the constraint <a href="#entity-unique">entity-unique</a>, we can adopt a different identifier for one of them, and relate the two statements with the <span class="name">alternateOf</span> relation. </p>
-
-<div class="anexample" id="merge-with-rename">
-<p>We now reconsider the same two statements of a same entity, but we change the identifier for one of them:</p>
-<pre class="codeexample">
-entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
-entity(ex:alternate-20111215, [ prov:type="document", ex:version="2" ])
-alternateOf(tr:WD-prov-dm-20111215,ex:alternate-20111215)
-</pre>
-</div>
-
-
-<div class='note'>
-  Since we are not specifying ways to take the union of two accounts,
-  we may drop this discussion
-  </div>
-<p> Taking the union of two accounts is another account, 
-formed by the union of the statements they respectively contain.  We note that the resulting union may or may not invalidate some constraints:
-<ul>
-<li> Two entity statements with the same identifier but different sets of attributes exist in each original PROV instance may invalidate <a href="#entity-unique">entity-unique</a> in the union, unless some form of statement merging or renaming (as per <a href="#merge-with-rename">Example</a>) occurs.
-<li> Structurally well-formed
-accounts are not
-closed under union because the
-constraint <a href="#generation-uniqueness">generation-uniqueness</a> may no
-longer be satisfied in the resulting union.  </li>
-</ul>
-<p>How to reconcile such accounts is beyond the scope of this specification.</p>
-
-
-<div class="note">
-  Material transplanted from old structural well-formedness constraints section.
-  
-  This example isn't very clear, since the sub-workflow-ness isn't
-  represented in the data.  According to what was written above, we
-  should conclude that a0 and a2 are equal!
-  </div>
-<div class="anexample">
-<p>
-In the following statements, a workflow execution  <span class="name">a0</span> consists of two sub-workflow executions  <span class="name">a1</span> and <span class="name">a2</span>.
-Sub-workflow execution <span class="name">a2</span> generates entity <span class="name">e</span>, so does <span class="name">a0</span>.</p>
-<pre class="codeexample">
-activity(a0, [prov:type="workflow execution"])
-activity(a1, [prov:type="workflow execution"])
-activity(a2, [prov:type="workflow execution"])
-wasInformedBy(a2,a1)
-
-wasGeneratedBy(e,a0)
-wasGeneratedBy(e,a2)
-</pre>
-<p>So, we have two different <a title="generation">generations</a> for entity <span class="name">e</span>.  Such an example is permitted in PROV-DM if the two activities denoted by <span class="name">a0</span> and <span class="name">a2</span> are a single thing happening  in the world
-but described from different perspectives.</p>
-</div>
-
-<p>While this example is permitted in PROV-DM, it does not make the inter-relation between activities explicit, and  it mixes statements expressed from different perspectives together. 
-While this may acceptable in some specific applications, it becomes challenging for inter-operability. Indeed, PROV-DM does not offer any relation describing the structure of activities.
-  Such instances are said not to be structurally well-formed.</p>
-
-<p>Structurally well-formed provenance can be obtained by partitioning the generations into different accounts. This makes it clear that these generations provide alternative
-descriptions of the same real-world generation event, rather than describing two distinct generation events for the same entity. When accounts are used, the example can be encoded as follows.</p>
-
-
-<div class="anexample">
-<p>
-The same example is now revisited, with the following statements that are structurally well-formed. Two accounts are introduced, and there is a single generation for entity <span
-class="name">e</span> per account.</p>
-
-<p>In a first account, entitled "summary", we find:</p>
-<pre class="codeexample">
-activity(a0,t1,t2,[prov:type="workflow execution"])
-wasGeneratedBy(e,a0,-)
-</pre>
-<p>In a second account, entitled "detail", we find:</p>
-<pre class="codeexample">
-activity(a1,t1,t3,[prov:type="workflow execution"])
-activity(a2,t3,t2,[prov:type="workflow execution"])
-wasInformedBy(a2,a1)
-wasGeneratedBy(e,a2,-)
-</pre>
-</div>
-
-
- 
-<p>Structurally well-formed provenance satisfies some constraints, which force the structure of statements to be exposed by means of accounts. With these constraints satisfied, further
-inferences can be made about structurally well-formed statements.
-The uniqueness of generations in accounts is formulated as follows.
-</p>
-
-
-
-  
-</section> <!-- account-constraints-->
-
-
-
-
-
-
-
-
-  <section id='rationale' class="informative">
-<h2>Rationale for inferences and constraints</h2>
-
-<div class="note"> This section collects all of the explanatory
-  material that I was not certain how to interpret as an unambiguous
-  inference or constraint.  Some of these observations may need to be folded
-  into the explanatory text in respective sections (for example for
-  events, 
-  accounts or collections).
-
-  Editing is also needed to decrease redundancy.
-  </div>
-
-    <section id='section-attributes'> 
-<h4>Entities and Attributes</h4>
-
-<p>When we talk about things in the world in natural language and even when we assign identifiers, we are often imprecise in ways that make it difficult to clearly and unambiguously report
-provenance: a resource with a URL may be understood as referring to a report available at that URL, the version of the report available there today, the report independent of where it is
-hosted over time, etc.
-However, to write precise descriptions of the provenance of things
-that change over time, we need ways of disambiguating which versions
-of things we are talking about.  
-</p>
-
-<p>
-To describe the provenance of things that can change over
-time, PROV-DM uses the concept of <i>entities</i> with fixed
-attributes.  From a provenance viewpoint, it is important to identify
-a partial state of something, i.e. something with some aspects that
-have been fixed, so that it becomes possible to express its provenance
-(i.e. what caused the thing with these specific aspects).  An entity
-encompasses a part of a thing's history during which some of the
-attributes are fixed.  An entity can thus be thought of as a part of a
-thing with some associated partial state.
-Attributes in PROV-DM are used to fix certain aspects of entities.</p>
-
-
-<p>
-An <dfn>entity</dfn> is a thing one wants to provide provenance for
-and whose situation in the world is described by some fixed
-attributes. An entity has a <dfn
-id="dfn-characterization-interval">characterization interval</dfn>,
-or <dfn id="lifetime">lifetime</dfn>,
-defined as the period
-between its <a title="entity generation event">generation event</a>
-and its <a title="entity invalidation event">invalidation event</a>.
-An entity's attributes are established when the entity is
-created and describe the entity's situation and (partial) state
-during an entity's lifetime.</p>
-
-<p>
-A different entity (perhaps representing a different user or
-system perspective) may fix other aspects of the same thing, and its provenance
-may be different.  Different entities that are aspects of the same
-thing are called <em>alternate</em>, and the PROV-DM relations of
-specialization and alternate can be used to link such entities.</p>
-
-
-
-
-
-
-<div class="anexample" id="a-report-example">
-Different users may take different perspectives on a resource with
-a URL. A provenance record might use one (or more)  different
-  entities to talk about different perspectives, such as:
-<ul>
-<li>a report available at a URL: fixes the nature of the thing, i.e. a document, and its location; </li>
-<li>the version of the report available there today: fixes its version number, contents, and its date;</li>
-<li>the report independent of where it is hosted and of its content over time: fixes the nature of the thing as a conceptual artifact.</li></ul>
-The provenance of these three entities may differ, and may be along the following lines: 
-<ul>
-<li>the provenance of a report available at a URL may include: the act of publishing it and making it available at a given location, possibly under some license and access control;</li>
-<li>the provenance of the version of the report available there today may include: the authorship of the specific content, and reference to imported content;</li>
-<li>the provenance of the report independent of where it is hosted over time may include: the motivation for writing the report, the overall methodology for producing it, and the broad team
-involved in it.</li>
-</ul>
-<p>We do not assume that any entity is a better or worse description of
-reality than any other.  That is, we do not assume an absolute ground truth with
-respect to which we can judge correctness or completeness of
-descriptions.  In fact, it is possible to describe the processing that occurred for the report to be commissioned, for
-individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity with attribute-value pairs that fix some aspects of the report appropriately.</p>
-</div>
-
-
-<p>Besides entities, a variety of other PROV-DM objects have
-attributes, including activity, generation, usage, start, end,
-communication, attribution, association, responsibility, and
-derivation. Each object has an associated duration interval (which may
-be a single time point), and attribute-value pairs for a given object
-are expected to be descriptions that hold for the object's duration.
-</p>
-<p>
-However, the attributes of entities have special meaning because they
-are considered to be fixed aspects
-of underlying, changing things.  This motivates constraints on
-<span class="name">alternateOf</span> and <span class="name">specializationOf</span> relating the attribute values of
-different entities.
-</p>
-<div class="note">
-  TODO:
-Constraints on alternateOf/specializationOf for this?
-  </div>
-
-  <div class="note">
-TODO: Further discussion of entities moved from the old "Definitional
-    constraints" section.  Should merge with the surrounding
-    discussion to avoid repetition.
-    </div>
-<p>
-An <dfn>entity</dfn> is a thing one wants to provide provenance for
-and whose situation in the world is described by some attribute-value
-pairs. An entity's attribute-value pairs are established as part of
-the entity statement and their values remain unchanged for the
-lifetime of the entity. An entity's attribute-value pairs are expected
-to describe the entity's situation and (partial) state  during an
-entity's <a title="characterization interval">characterization interval</a>.</p>
-
-<p>If an entity's situation or state changes, this may result in its statement being invalid, because one or more attribute-value pairs no longer hold.  In that case, from the PROV viewpoint, there exists a new entity, which needs to be given a distinct identifier, and associated with the attribute-value pairs that reflect its new situation or state.</p>
-
-
-
-Further considerations:
-<ul>
-<li>In order to describe the provenance of something during an  interval over which
-  relevant attributes of the thing are not fixed, it is required to
-  create multiple entities, each with its own identifier, <a
-  title="characterization interval">characterization interval</a>, and
-  fixed attributes, and express 
-  dependencies between the various entities using events.
-  For example, if we want to describe the provenance of several
-  versions of a document, involving attributes such as authorship that
-  change over time, we need different entities for the versions linked
-  by appropriate generation, usage, revision, and invalidation events.
-</li>
-
-<li>There is no assumption that the set of attributes is complete, nor
-that the attributes are independent or orthogonal of each other.</li>
-<li>There is no assumption that the attributes of an entity uniquely
-identify it.  Two different entities that are aspects of different
-things can have the same attributes.</li>
-<li>A <a title="characterization interval">characterization interval</a> may collapse into a single instant.</li>
-</ul>
-  
-</section>
-
-<section>
-<h3>Activities</h3>
-
-<div class="note">
-  TODO: Further discussion of activities moved from old "Definitional
-  constraints and inferences" section.  Edit to avoid repeating information.
-</div>
-  
-
-<p>An activity is delimited by its <a title="activity start event">start</a> and its <a title="activity end event">end</a> events; hence, it occurs over
-an interval delimited by two <a title="instantaneous event">instantaneous
-events</a>. However, an activity record need not mention start or end time information, because they may not be known.
-An activity's attribute-value pairs are expected to describe the activity's situation during its interval, i.e. an interval between two instantaneous events, namely its <a title="activity start event">start</a> event and its <a title="activity end event">end</a> event.
-</p>
-
-
-<p>Further considerations:</p>
-<ul>
-<li>An activity is not an entity.
-Indeed,  an entity exists in full at
-any point in its lifetime, persists during this
-interval, and preserves the characteristics that makes it
-identifiable.  In contrast, an activity is something that occurs, happens,
-unfolds, or develops through time, but is typically not identifiable by
-the characteristics it exhibits at any point during its duration. 
-This distinction is similar to the distinction between 
-'continuant' and 'occurrent' in logic [[Logic]].</li>
-</ul>
-
-
-
-</section>
-
-
-    <section id="representation-term-assertion-inference"> 
-<h3>Description, Assertion, and Inference</h3>
-
-<p>
-PROV-DM is a provenance data model designed to express <em>descriptions</em> of the world. 
-</p>
-
-<div class="anexample">
-A file at some point during its lifecycle, which includes multiple edits by multiple people, can be described by its type, its location in the file system, a creator, and content.  
-</div>
-
-
-<p>The data model is designed to capture activities that happened in the past, as opposed to activities
-that may or will happen. 
-However, this distinction is not formally enforced.
-Therefore, PROV-DM descriptions are intended to be interpreted as what
-has happened, as opposed to what may or will happen.</p>
-
-
-
-<p> 
-This specification does not prescribe the means by which descriptions can be arrived at; for example, descriptions can be composed on the basis of observations, reasoning, or any other means. 
-</p>
-
-
-<p>
-Sometimes, inferences about the world can be made from descriptions
-conformant to the PROV-DM data model. This
-specification defines some such inferences, allowing new descriptions
-to be inferred from existing ones. Hence, descriptions of the world
-can result either from direct assertion or from inference 
-by application of inference rules defined by this specification.
-</p>
-
-
-</section>
-
-
-
-
-
-    <section id='section-event-time'> 
-<h4>Events and Time</h4>
-
-  
-
-
-<p>Time is critical in the context of provenance, since it can help corroborate provenance claims. For instance, if an entity is claimed to be obtained by transforming another, then the
-latter must have existed before the former. If it is not the case, then there is something wrong with such a provenance claim. </p>
-
-<p> Although time is critical, we should also recognize that
-provenance can be used in many different contexts within individual
-systems and across the Web. Different systems may use different clocks
-which may not be precisely synchronized, so when provenance records
-are combined by different systems, we may not be able to align the
-times involved to a single global timeline.  Hence, PROV-DM is
-designed to minimize assumptions about time.  </p>
-
-
-
-<p>Hence, to talk about the constraints on valid PROV-DM data, we
-refer to <a title="instantaneous event">instantaneous events</a> that correspond to interactions
-between activities and entities.  
-The term "event" is commonly used in process algebra with a similar meaning. For instance, in CSP [[CSP]], events represent communications or interactions; they are assumed to be atomic and
-instantaneous.</p>
-
-
-
-
-
-<section id="event-ordering">
-<h4>Event Ordering</h4>
-
-
-
-<div class="note">
- The following paragraphs are unclear and need to be revised, to
- address review concerns: if
- we aren't saying anything about how events and time relate, and time
- is the only concrete information about event ordering in PROV-DM,
- then how can implementations check that event ordering constraints
- are satisfied?
-  </div>  
-<p> How the <a>precedes</a> partial order is implemented in practice is beyond the scope
-of this specification.  This specification only assumes that
-each <a title="instantaneous event">instantaneous event</a> can be mapped to an instant in some form of
-timeline. The actual mapping is not in scope of this
-specification. Likewise, whether this timeline is formed of a single
-global timeline or whether it consists of multiple Lamport-style
-clocks is also beyond this specification.  The <a>follows</a> and
-<a>precedes</a> orderings of events should be consistent with the
-ordering of their associated times
-over these timelines.
-</p>
-
-
-<p>This specification defines <i>event ordering constraints</i>
-between  <a title="instantaneous event">instantaneous events</a> associated with 
-provenance descriptions.  PROV-DM data MUST satisfy such constraints.  </p>
-
-<p>PROV-DM also allows for time observations to be inserted in
-specific statements, for each recognized <a
- title="instantaneous event">instantaneous event</a> introduced in this
-specification.  The presence of a time observation for a given <a
- title="instantaneous event">instantaneous event</a> fixes the mapping of this <a
- title="instantaneous event">instantaneous event</a> to the timeline. It can also
-help with the verification of associated ordering constraints (though,
-again, this verification is outside the scope of this specification).
-</p>
-
-
-
-</section>
-
-<section id="types-of-events">
-<h4>Types of Events</h4>
-<p>Five kinds of <a title="instantaneous event">instantaneous events</a> are used
-for the PROV-DM data model. The <strong>activity start</strong> and
-<strong>activity end</strong> events delimit the beginning and the end
-of activities, respectively. The <strong>entity usage</strong>,
-<strong>entity generation</strong>, and <strong>entity
-invalidation</strong> events apply to entities, and the generation and
-invalidation events delimit the <a title="characterization interval">characterization interval</a> of
-an entity. More specifically:
-
-</p>
-
-<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity starts.</p>
-
-<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the instant an activity ends.</p>
-
-<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a
-title="instantaneous event">instantaneous event</a> that marks the first instant of
-an entity's consumption timespan by an activity.  Before this instant
-the entity had not begun to be used by the activity.</p>
-
-<p>An <dfn id="dfn-generation-event">entity generation event</dfn> is the <a title="instantaneous event">instantaneous event</a> that marks the  final instant of an entity's creation timespan, after which
-it is available for use.  The entity did not exist before this event.</p>
-
-<p>An <dfn id="dfn-invalidation-event">entity invalidation event</dfn>
-is the <a title="instantaneous event">instantaneous event</a> that
-marks the  initial instant of the destruction, invalidation, or
-cessation of an entity, after which the entity is  no longer available
-for use.  The entity no longer exists after this event.</p>
-
-</section>
-
-
-</section>
-
-
-    <section  id="account-section">
-      <h3>Account</h3>
-
-<div class="note">
-  Some of this discussion may belong in the account constraint section
-  as motivation, or as formal constraints/inferences.  In particular,
-  the MUST, MAY, SHOULD statements should be clarified and put into
-  the normative section.
-  </div>
-
-<p>It is common for multiple provenance records to co-exist. For
-instance, when emailing a file, there could be a provenance record
-kept by the mail client, and another by the mail server. Such
-provenance records may provide different explanations about something
-happening in the world, because they are created by different parties
-or observed by different witnesses. A given party could also create
-multiple provenance records about an execution, to capture different
-levels of details, targeted at different end-users: the programmer of
-an experiment may be interested in a detailed log of execution, while
-the scientists may focus more on the scientific-level description.
-Given that multiple provenance records can co-exist, it is important
-to have details about their origin, who they are attributed to, how
-they were generated, etc.  In other words, an important requirement is
-to be able to express the provenance of provenance. </p>
-
-<div class="note">
-  See ISSUE-343.  
-  </div>
-<p>
-  <span  class="glossary" id="glossary-account">
-An <dfn>account</dfn> is an entity that contains an instance, or set
-  of PROV statements.
-</span>  PROV-DM does not provide an actual mechanism for creating accounts, i.e. for bundling up provenance descriptions and naming them.  Accounts MUST satisfy some properties:
-<ul>
-<li>An account is a bundle of provenance descriptions whose content MAY change over time.</li>
-<li>If an account's  set of statements changes over time, it SHOULD increase monotonically with time. </li>
-<li>A given description of e.g. an entity in a given account, in terms of its identifier and attribute-value pairs, does not change over time. </li>
-</ul>
-
-<div class='note'>
-The last point is important. It indicates that within an account:
-<ul>
-<li>It is always possible to add new provenance statements, e.g. stating that a given entity was used by an activity, or derived from another.  This is very much an open world assumption.
-<li>It is not permitted to add new attributes to a given entity (a
-  form of closed world assumption from the attributes point of view),
-  though it is always permitted to create a new statement describing
-  an entity, which is a "copy" of the original statement extended with novel attributes  (cf Example <a href="#merge-with-rename">merge-with-rename</a>).
-</ul>
-</div>
-
-<p>
-There is no construct in PROV-DM to create such bundles of
-statements. Instead, it is assumed that some mechanism, outside
-PROV-DM can create them.  However, from a provenance viewpoint, such
-accounts are things whose provenance we may want to describe. In order to be able to do so, we need to see accounts as entities, whose origin can be described using PROV-DM vocabulary. Thus, PROV-DM introduces the reserved type <span class="name">Account</span>.
-</p>
-
-    </section>
-</section>
-
-
-
-
-
-
-<section class="appendix"> 
-      <h2>Acknowledgements</h2> 
-      <p> 
-        WG membership to be listed here.
-      </p> 
-    </section> 
-
-<section class="glossary"> 
-      <h2>Glossary</h2> 
-      <ul> 
-       <li> <dfn>anti-symmetric</dfn>: A relation R over X is <a>anti-symmetric</a> if
-      for any elements x, y of X, if x R y and y R x then x = y.
-      Alternatively, for a strict partial order anti-symmetry usually
-      means that for any elements x, y of X, it is impossible that
-      both x R
-      y and y R x hold.</li>
-        <li> <dfn>reflexive</dfn>: A relation R over X is <a>reflexive</a> if
-      for any element x of X, we have x R x.</li>
-       <li> <dfn>symmetric</dfn>: A relation R over X is <a>symmetric</a> if
-      for any elements x, y of X, if x R y then y R x.</li>
-        <li> <dfn>transitive</dfn>: A relation R over X is <a>transitive</a> if
-      for any elements x, y, z of X, if x R y and y R z then x R z.</li>
-     
-     
-      </ul> 
-    </section> 
-
-
- </body></html>
-
-<!--  LocalWords:  px DM RL RDF AQ SEM SOTD Definitional wasInformedBy attrs ag
- -->
-<!--  LocalWords:  wasGeneratedBy wasStartedBy gAttr sAttr wasAttributedTo attr
- -->
-<!--  LocalWords:  wasAssociatedWith dAttrs gAttrs wasDerivedFrom uAttrs eAttrs
- -->
-<!--  LocalWords:  wasRevisionOf specializationOf wasQuotedFrom Traceability WD
- -->
-<!--  LocalWords:  tracedTo aAttr actedOnBehalfOf rAttr traceability TODO xsd
- -->
-<!--  LocalWords:  alternateOf wasEndedBy Lamport's timeline subfigure memberOf
- -->
-<!--  LocalWords:  wasStartedByAgent wasAttributedWith derivedByInsertionFrom
- -->
-<!--  LocalWords:  QName derivedByRemovalFrom EmptyCollection wasVersionOf dm
- -->
-<!--  LocalWords:  RecsWD formedness workflow ness operability CSP versa hyp YY
- -->
-<!--  LocalWords:  disambiguating lifecycle conformant minimalistic Lamport fo
- -->
-<!--  LocalWords:  reflexivity antisymmetry timelines timespan WG concl inv
- -->
-<!--  LocalWords:  continuant occurrent modalities toyota womanInRedDress
- -->
-<!--  LocalWords:  customerInChairAt manWithGlasses customerInChair irreflexive
- -->
-<!--  LocalWords:  wasStartedByActivity antisymmetric wasInvalidatedBy
- -->
--- a/model/working-copy/wd6-prov-dm-with-core.html	Mon Sep 10 07:56:57 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,3166 +0,0 @@
-<!DOCTYPE html
->
-
-<html><head> 
-    <title>PROV-DM: The PROV 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('data-ref');
-          var span=$(this).attr('data-withspan')
-          $(this).removeAttr('data-withspan');
-          $(this).removeAttr('data-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-CONSTRAINTS":
-          "James Cheney, Paolo Missier, and Luc Moreau (eds.) "+
-          "<a href=\"http://www.w3.org/TR/prov-constraints/\"><cite>Constraints of the PROV Data Model</cite></a>. "+
-          "2011, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-constraints/\">http://www.w3.org/TR/prov-constraints/</a>",
-
-        "PROV-N":
-          "Luc Moreau and Paolo Missier (eds.)"+
-          "<a href=\"http://www.w3.org/TR/prov-n/\"><cite>PROV-N: The Provenance Notation</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   :  "working towards WD6 (<a href=\"diff.html\">Diffs since last release</a>)",
-
- 
-          // if you wish the publication date to be other than today, set this
-//          publishDate:  "2012-05-03",
- 
-          // if the specification's copyright date is a range of years, specify
-          // the start date here:
-          copyrightStart: "2011",
- 
-          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
-          // and its maturity status
-          previousPublishDate:  "2012-05-03",
-          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-dm.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: "Reza B'Far",
-                company: "Oracle Corporation" },
-              { name: "Stephen Cresswell",
-                company: "legislation.gov.uk"},
-              { name: "Yolanda Gil",
-                company: "Invited Expert", url:"http://www.isi.edu/~gil/"},
-              { 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: "Curt Tilmes", 
-                company: "National Aeronautics and Space Administration" },
-          ],
-          
-          // name of the WG
-          wg:           "Provenance Working Group",
-          
-          // URI of the public WG page
-          wgURI:        "http://www.w3.org/2011/prov/",
-          
-          // name (with the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "public-prov-wg",
-          
-          // URI of the patent status for this WG, for Rec-track documents
-          // !!!! IMPORTANT !!!!
-          // This is important for Rec-track documents, do not copy a patent URI from a random
-          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
-          // Team Contact.
-          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/46974/status",
-
-          // Add extraReferences to bibliography database
-          preProcess: [addExtraReferences],
-      };
-    </script> 
-  </head> 
-  <body> 
-
-    <section id="abstract">
-<p>
-PROV-DM, the PROV data model, is a data model for provenance that describes
-the entities, people and activities involved in
-producing a piece of data or thing. 
-PROV-DM distinguishes core structures, forming the essence of provenance descriptions, from
-extended structures catering for more advanced uses of provenance. 
-PROV-DM is organized in six components, respectively dealing with: 
-(1) entities and activities, and the time at which they were created, used, or ended;
-(2) agents bearing responsibility for entities that were generated and activities that happened;
-(3) derivations of entities from entities;
-(4) properties to link entities that refer to the same thing;
-(5) notion of bundle, a mechanism to support provenance of provenance;
-(6) collections forming a logical structure for its members.
-</p>
-
-<p>This document introduces the provenance concepts found in
-PROV and defines PROV-DM types and
-relations. PROV data model is domain-agnostic, but is equipped with
-extensibility points allowing domain-specific information to be included. </p>
-
-<p>Two further documents complete the specification of PROV-DM.
-First, a companion document specifies the set of constraints that
-provenance descriptions should follow.  Second, 
-a separate document describes a provenance notation for expressing 
-instances of provenance for human consumption; this notation is used in examples in
-this document. </p>
-
-    </section> 
-
-<section id="sotd">
-<h4>PROV Family of Specifications</h4>
-This document is part of the PROV family of specifications, a set of specifications defining various aspects that are necessary to achieve the vision of inter-operable
-interchange of provenance information in heterogeneous environments such as the Web.  The specifications are:
-<ul>
-<li> PROV-DM, the PROV data model for provenance (this document);</li>
-<li> PROV-CONSTRAINTS, a set of constraints applying to the PROV data model;</li>
-<li> PROV-N, a notation for provenance aimed at human consumption;</li>
-<li> PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF;</li>
-<li> PROV-AQ, the mechanisms for accessing and querying provenance; </li>
-<li> PROV-PRIMER, a primer for the PROV data model;</li>
-<li> PROV-SEM, a formal semantics for the PROV data model;</li>
-<li> PROV-XML, an XML schema for the PROV data model.</li>
-</ul>
-<h4>How to read the PROV Family of Specifications</h4>
-<ul>
-<li>The primer is the entry point to PROV offering an introduction to the provenance model.</li>
-<li>The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL-RL ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. PROV-SEM provides a mathematical semantics.</li>
-<li>The XML community should focus on PROV-XML defining an XML schema for PROV. Further details can also be found in PROV-DM, PROV-CONSTRAINTS, and PROV-SEM.</li>
-<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
-<li>Readers seeking to implement other PROV serializations
-should focus on PROV-DM and PROV-CONSTRAINTS.  PROV-O, PROV-N, PROV-XML offer examples of mapping to RDF, text, and XML, respectively.</li>
-</ul>
-
-
-<h4>Fourth Public Working Draft</h4>
-<p>This is the fourth public release of the PROV-DM document. Following feedback, the Working Group has decided to reorganize this document substantially, separating the data model from its contraints and the notation used to illustrate it. The PROV-DM release is synchronized with the release of the PROV-O, PROV-PRIMER, PROV-N, and PROV-CONSTRAINTS documents. We are now clarifying the entry path to the PROV family of specifications.</p>
-</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 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>
-We
-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  <em>interchanged</em> between systems.
-Thus, heterogeneous systems can export their native 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>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, informally described (this document);
-<li> PROV-CONSTRAINTS (part II): constraints underpinning the data model [[PROV-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: the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF [[PROV-O]];</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>
-<li>PROV-XML: an XML schema for the PROV data model.</li>
-</ul>
-
-
-<p>
-The  PROV data model is a domain-agnostic model, but with clear extensibility points allowing further domain-specific and
-application-specific extensions to be defined.
-The PROV data model is structured according to six components covering various aspects of provenance:</p>
-<ul>
-<li> component 1: entities and activities, and the time at which they were created, used, or ended;
-<li> component 2: agents bearing responsibility for entities that were generated and activities that happened;
-<li> component 3: derivations of entities from others;
-<li> component 4: properties to link entities that refer to a same thing;
-<li> component 5: bundles, a mechanism to support provenance of provenance;
-<li> component 6: collections forming a logical structure for its members.
-</ul>
-
-
-<p>This specification presents the key concepts of the PROV Data Model, and
-provenance types and relations, without specific concern for how they are applied.
-With these, it becomes possible to write useful provenance descriptions, and publish or embed them alongside the data they relate to. </p>
-
-<p>However, if something about which provenance is expressed is subject to change, then it is challenging to express its provenance precisely (e.g. the data from which a daily weather report is derived  changes from day to day).
- To address this challenge, a <em>refinement</em> is proposed to enrich simple provenance, with extra descriptions that  help qualify the specific subject of provenance and provenance itself, with attributes and temporal information, intended to satisfy a comprehensive set of constraints.  These aspects are covered in the companion specification [[PROV-CONSTRAINTS]].
-</p>
-
-
-<section id="structure-of-this-document"> 
-<h3>Structure of this Document</h3>
-
-<p><a href="#section-prov-overview">Section 2</a> provides an overview of the PROV Data Model,  distinguishing a CORE set of types and  relations, commonly found in provenance descriptions, from extended structures catering for advanced uses.</p>
-
-<p><a href="#prov-notation">Section 3</a> overviews the Provenance Notation used to illustrate examples of provenance descriptions.</a>
-
-
-<p><a href="#prov-dm-example">Section 4</a> illustrates how the PROV data model can be used
-to express the provenance of a report published on the Web.</p>
-
-
-<p><a href="#data-model-components">Section 5</a> provides the definitions of PROV concepts, structured according to six components.</p>
-
-
-
-<p><a href="#extensibility-section">Section 6</a> summarizes PROV-DM extensibility points.</p>
-
-<p><a href="#valid-provenance">Section 7</a> introduces the idea that constraints can be applied to the PROV data model to refine provenance descriptions; these are covered in the companion specification [[PROV-CONSTRAINTS]].</p>
-
-
-</section> 
-
-<section id="conventions"> 
-<h3>Notational 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>
-
-
-<p>
-The following namespaces prefixes are used throughout this document.
-
-<div style="text-align: left;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="namespace-table">Table 1: Prefix and Namespaces used in this specification</caption>
-<tr><td><a><b>prefix</b></a></td><td><b>namespace uri</b></td> <td><b>definition</b></td></tr>
-<tr><td><a>prov</a></td><td>http://www.w3.org/ns/prov#</td><td>The PROV namespace (see Section <a href="#term-NamespaceDeclaration">4.7.1</a>)</td></tr>
-<tr><td><a>xsd</a></td><td>http://www.w3.org/2000/10/XMLSchema#</td><td>XML Schema Namespace [[!XMLSCHEMA-2]]</td></tr>
-<tr><td><a>rdf</a></td><td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td><td>The RDF namespace  [[!RDF-CONCEPTS]]</td></tr>
-<tr><td><a>(others)</a></td><td>(various)</td><td>All other namespace prefixes are used in examples only. <br/> In particular, URIs starting with "http://example.com" represent<br/> some application-dependent URI [[!URI]]</td></tr>
-</table>
-</div>
-
-<p> 
-  Examples throughout this document use the PROV-N Provenance
-  Notation, briefly introduced in <a href="#prov-notation">Section 3</a> and specified fully in separate document [[PROV-N]].</p>
-
-
-</section> 
-
-</section> 
-
-
-
-<section id='section-prov-overview'> 
-<h1>PROV Overview</h1>
-
-<p>This section introduces provenance concepts with informal descriptions and illustrative
-examples. PROV distinguishes  <em>core structures</em>, forming the essence of  provenance descriptions, from <em>extended structures</em> catering for more advanced uses of provenance.  Core and extended structures are respectively presented in <a href="#core-structures">Section 2.1</a> and <a href="#section-extended-structures">Section 2.2</a>. Furthermore, the PROV data model is organized according to components, which are thematic groupings of concepts, overviewed in <a href="#section-overview-components">Section 2.3</a>.
-</p>
-
-
-<section id='core-structures'> 
-<h1>PROV Core Structures</h1>
-
-<p>The core of PROV consists of essential provenance structures commonly found in provenance descriptions.
-It is summarized graphically by
-the UML diagram of <a href="#prov-core-structures">Figure 1</a>,
-illustrating  three types (entity, activity, and agent) and how they relate to each other.  In the core of PROV, all relations are binary. </p>
-
-
-<div style="text-align: center; ">
-  <figure style="max-width: 70%; " >
-<!--     <img src="../images/OverviewDiagram.png" alt="PROV Core Structures" style="max-width: 70%; "  /> -->
-<img src="../uml/essentials.svg" alt="PROV Core Structures" style="max-width: 70%; "  />
-<figcaption id="prov-core-structures">Figure 1: PROV Core Structures</figcaption>
-  </figure>
-</div>
-
-<p>The rest of this section introduces the concepts found in PROV Core structures.
-They are summarized in  <a href="#overview-types-and-relations">Table 2</a>, where they are grouped according to
-the types and relations the PROV conceptual data model. 
- The first column lists concepts, the second column indicates whether a concept maps to a type or a relation, whereas the third column contains the corresponding name.    Names of relations have a verbal form in the past tense to express what happened in the past, as opposed to what may or will happen. 
-</p>
-</p>
-
-
-
-
-<div style="text-align: left;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="overview-types-and-relations">Table 2: Mapping of PROV core concepts to  types and relations</caption>
-<tr><td><a><b>PROV Concepts</b></a></td><td><b>PROV-DM types or relations</b></td><td><b>Name</b></td><td><b>Overview</b></td></tr>
-<tr>
-<td><a>Entity</a></td><td rowspan="3" style="text-align: center;">PROV-DM Types</td><td><a title="dfn-Entity">entity</a></td><td style="text-align: center;"><a href="#section-entity-activity">2.1.1</a></td></tr>
-<tr><td><a>Activity</a></td><td><a title="dfn-Activity">activity</a></td><td style="text-align: center;"><a href="#section-entity-activity">2.1.1</a></td></tr>
-<tr><td><a>Agent</a></td><td><a title="dfn-agent">agent</a></td><td style="text-align: center;"><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td></tr>
-<tr>
-<td><a>Generation</a></td><td rowspan="6" style="text-align: center;">PROV-DM Relations</td><td><a title="wasGeneratedBy">wasGeneratedBy</a></td><td style="text-align: center;"><a href="#section-entity-activity">2.1.1</a></td></tr>
-<tr><td><a>Usage</a></td><td><a title="used">used</a></td><td style="text-align: center;"><a href="#section-entity-activity">2.1.1</a></td></tr>
-<tr><td><a>Attribution</a></td><td><a title="wasAttributedTo">wasAttributedTo</a></td><td style="text-align: center;"><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td></tr>
-<tr><td><a>Association</a></td><td><a title="wasAssociatedWith">wasAssociatedWith</a></td><td style="text-align: center;"><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td></tr>
-<tr><td><a>Responsibility</a></td><td><a title="actedOnBehalfOf">actedOnBehalfOf</a></td><td style="text-align: center;"><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td></tr>
-<tr><td><a>Derivation</a></td><td><a title="wasDerivedFrom">wasDerivedFrom</a></td><td style="text-align: center;"><a href="#section-derivation">2.1.3</a></td></tr>
-</table>
-</div>
-
-
-
-
-<!--
-<p><a href="#prov-core-structures">Figure 1</a> is not intended to be complete: it only illustrates  types and relations introduced in this section (<a href="#section-prov-overview">Section 2</a>), exploited in the example discussed in <a href="#prov-dm-example">Section 3</a>, and explained in detail in <a href="#data-model-components">Section 4</a>.
-Names of relations depicted in <a href="#prov-core-structures">Figure 1</a> 
-are listed in
-the third column of <a href="#overview-types-and-relations">Table 2</a>. These names are part of a textual notation to write instances of the PROV data model, which we introduce in the next section. </p>
-
--->
-
-
-
-
-
-<form action="#"><p> 
-<input id="hide-examples" onclick="set_display_by_class('div','conceptexample','none'); set_display_by_id('hide-examples','none'); set_display_by_id('show-examples','');" type="button"
-value="Hide Concept Examples" /> 
-<input id="show-examples" onclick="set_display_by_class('div','conceptexample',''); set_display_by_id('hide-examples',''); set_display_by_id('show-examples','none');" style="display: none"
-type="button" value="Show Concept Examples" /> 
-</p> 
-</form> 
-
-
-
-
-  
-    <section id='section-entity-activity'> 
-<h2>Entity and Activity</h2>
-
-
-<p>In PROV, things we want to describe the provenance of are called <em>entities</em> and have some fixed aspect. The term "things" encompasses a broad diversity of notions, including digital objects such as a file or web page, 
-physical things such as a mountain, a building, a printed book, or a car as well as abstract concepts and ideas. 
-</p>
-
-<p>
-<div class="glossary-ref" data-ref="glossary-entity"  data-withspan="true">
-</div>
-
-
-
-<div class="conceptexample" id="entity-example">
-<p>An entity may be the document at URI <a href="http://www.bbc.co.uk/news/science-environment-17526723">http://www.bbc.co.uk/news/science-environment-17526723</a>, a file in a file system, a car, or an idea.</p>
-</div>
-
-
-
-<p>
-<span class="glossary-ref" data-ref="glossary-activity"  data-withspan="true"></span> Activities that operate on digital entities may for example move, copy, or duplicate them.
-</p>
-
-
-
-<div class="conceptexample" 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, 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, or editing a file.</p>
-</div>
-
-<p>Activities and entities are associated with each other in two different ways: activities utilize entities and activities  produce entities. The act of utilizing or producing an entity may have a duration.  
- The term 'generation' refers to the completion of the act of producing; likewise, the term 'usage' refers to the beginning of the act of utilizing entities. Thus, we define the following notions of generation and usage. </p>
-
-<p>
-<div class="glossary-ref" data-ref="glossary-generation"  data-withspan="true">
-</div>
-
-
-<p>
-<div class="glossary-ref" data-ref="glossary-usage"  data-withspan="true">
-</div>
-
-
-
-
-<div class="conceptexample" id="generation-example">
-<p>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>
-
-
-
-<div class="conceptexample" id="usage-example">
-<p>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); in contrast, the same entity may be used multiple times, possibly by different activities (e.g. a file on a file system can be read indefinitely).
-</div>
-
-
-</section>
-
-
-<section id="section-agents-attribution-association-responsibility"> 
-<h2>Agents and Responsibility</h2>
-
-<p>The motivation for introducing  agents in the model is to express the agent's responsibility for activities that happened and entities that were generated. </p>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-agent"  data-withspan="true">
-</span> An agent MAY be a particular type of entity or activity. This means that the model can be
- used to express provenance of the agents themselves.  
-</p>
-
-
-<!--
-<p>
-The definition of agent intentionally stays away from using concepts such as enabling, causing, initiating, triggering, affecting, etc, because many entities also enable, cause, initiate, and affect in some way
-the activities. (Concepts such as triggers are themselves defined later in relations between entities and activities.)   So the notion of having some degree of responsibility is really what makes an agent.</p>
--->
-
-
-
-<div class="conceptexample" 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. 
-A site selling books on the Web, the services involved in the processing of orders, and the companies hosting them are also agents.
-</p>
-</div>
-
-
-
-
-<p>Agents can be related to entities, activities, and other agents.</p>  
-
-<div class="glossary-ref" data-ref="glossary-attribution" data-withspan="true"></div>
-
-<div class="conceptexample" id="attribution-example">
-<p>A blog post can be attributed to an author, a mobile phone to its manufacturer.</p>
-</div>
-
-<p>
-Agents are defined as having some kind of responsibility for activities. </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" data-ref="glossary-core-association"  data-withspan="true"></span>
-</p>
-
-<div class="conceptexample" id="association-example">
-<p>Examples of association between an activity and an 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>
-</ul>
-</div>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-responsibility"  data-withspan="true">
-</span> The nature of this relation is intended to be broad,  including delegation or 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="conceptexample" id="responsibility-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.  It may not matter which actual
-student published a web page, but it may matter significantly that the department
-told the student to put up the web page.  
-</p>
-</div>
-</section>
-
-    <section id="section-derivation"> 
-<h2>Derivation</h2>
-
-
-
-<p>Activities utilize entities and produce entities. In some cases, utilizing 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" data-ref="glossary-derivation"  data-withspan="true"></span>
-
-
-
-<div class="conceptexample" 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>
-
-<section id="section-extended-structures"> 
-<h2>PROV Extended Structures</h2>
-
-<p>While the core of PROV focuses on essential provenance structures commonly found in provenance descriptions, extended structures 
-are designed to support more advanced uses of provenance. 
-The purpose of this section is twofold. First, mechanisms to specify these extended structures are introduced.  Second,  two further categories of provenance structures are overviewed: they cater for provenance of provenance and collections,  respectively.</p>
-
-
-
-
-<section id="section-prov-extended-mechanisms"> 
-<h2>Mechanisms to Define Extended Structures</h2>
-
-<p>Extended structures are defined by a variety of mechanisms 
-outlined in this section: subtyping, expanded relations, optional
-identification, and new relations.</p>
-
-
-<section id="section-prov-extended-approach-subtyping"> 
-<h2>Subtyping</h2>
-
-<p>Subtyping can be applied to core types. For example, a software agent is special kind of agent, defined as follows.</p>
-
-<span class="glossary-ref" data-ref="glossary-software-agent"  data-withspan="true">
-</span>
-
-
-<p>Subtyping can also be applied to  core relations. For example, a revision is a special kind of derivation, defined as follows.</p>
-
-
-<p><span class="glossary-ref" data-ref="glossary-revision" data-withspan="true"></span></p>
-
-</section>
-
-<section id="section-prov-extended-approach-expanded-relation"> 
-<h2>Expanded Relations</h2>
-
-<p><a href="#core-structures">Section 2.1</a> shows that six concepts are mapped to binary relations in the core of PROV.  However, some advanced uses of these concepts cannot be captured by a binary relation, but require relations to be expanded to n-ary relations.</p>
-
-
-<p>To illustrate expanded relations, we consider the concept of
-association, described
-in <a href="#section-agents-attribution-association-responsibility">section
-2.1.2</a>.  Agents may adopt sets of actions or steps to achieve their
-goals in the context of an activity: this is captured by the notion of
-a plan.  Thus, an activity may reflect the execution of a plan that was
-designed in advance to guide the execution.  Hence, an expanded
-association relation allows a plan be linked to an
-activity. Plan is defined by subtyping and full association by an expanded relation, as follows. </p>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-plan"  data-withspan="true">
-</span>
-There exist no
-prescriptive requirement on 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> 
-
-
-<p>
-<span class="glossary-ref" data-ref="glossary-activityAssociation"  data-withspan="true"></span>
-</p>
-
-
-<div class="conceptexample" id="association-example2">
-<p>An example of association between an activity and an agent involving a plan is:
-an XSLT transform launched by a user based on an XSL style sheet (a plan).
-
-</div>
-</section>
-
-
-<section id="section-prov-extended-approach-optional-identification-new-relation"> 
-<h2>Optional Identification and New Relations</h2>
-
-<p>Some concepts exhibit both a core use, expressed as
-binary relation, and an extended use, expressed as n-ary relation.  In
-some cases, mapping the concept to a relation, whether binary or
-n-ary, is not sufficient: instead, it may be required to able to
-identify an instance of such concept.</p>
-
-<p>In such circumstances, PROV-DM allows an optional identifier to be
-expressed to identify an instance of an association between two or
-more elements.  This optional identifier can then be used to refer to
-an instance as part of other concepts.</p>
-
-<div class="conceptexample" id="identifier-example">
-<p>A service may read a same configuration file on two different occasions. Each  usage can be identifed by its own identifier, allowing them to be distinguished. 
-</div>
-
-<p>Finally, PROV-DM supports further relations that are not subtypes or expanded versions of existing relations.</p>
-
-
-
-
-</section>
-
-
-
-</section>
-
-
-
-<section id="section-provenance-of-provnance"> 
-<h2>Provenance of Provenance</h2>
-
-
-
-
-<p>
-<span class="glossary-ref" data-ref="glossary-bundle"  data-withspan="true">
-</span>
-
-<div class="conceptexample" id="bundle-example">
-<p>
-For users to decide whether they can place their trust in
-a resource, they may want to analyze the resource's provenance, but also determine
-who its provenance is attributed to, and when it was
-generated. In other words, users need to be able to determine the provenance of provenance.
-Hence, provenance is also
-regarded as an entity (of type Bundle), by which provenance of provenance can then be
-expressed.
-</p>
-</div>
-</section>
-
-<section id="section-collections"> 
-<h2>Collections</h2>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-collection"  data-withspan="true"></span> This concept allows for the provenance of the collection itself to be expressed in addition to that of the members.  Many different types of collections exist, such as a <em>sets</em>, <em>dictionaries</em>, or <em>lists</em>, all of which involve a membership relationship between the constituents and the collection. </p>
-
-<div class="conceptexample" 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>
-
-
-</section>
-
-
-
-
-
-</section>
-
-<section id="section-overview-components"> 
-<h2>Modular Organization</h2>
-
-<p>Besides the separation between core and extended structures, PROV-DM
-is further organized according to components, grouping concepts in a
-thematic manner. </p>
-
-<p> <a href="#components-overview">Table 3</a> enumerates the six components, five of which have already been implicitly overviewed in this section. All components offer extended structures, whereas the first three only offer core structures.
-
-<div id="components-overview-div" style="text-align: center;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="components-overview">Table 3: Components Overview</caption>
-<tr><td></td><td>Component</td><td>Core <br>Structures</td><td>Overview</td><td>Specification</td><td>Description</td></tr> 
-<tr><td>1</td><td style="text-align: left;">Entities and Activities</td><td>&#10004;</td><td><a href="#section-entity-activity">2.1.1</a></td><td><a href="#component1">5.1</a></td><td  style="text-align: left;">about entities and activities, and their interrelations</td></tr> 
-<tr><td>2</td><td style="text-align: left;">Agent and Responsibility</td><td>&#10004;</td><td><a href="#section-agents-attribution-association-responsibility">2.1.2</a></td><td><a href="#component2">5.2</a></td><td style="text-align: left;">about agents and concepts ascribing responsibility to them</td></tr> 
-<tr><td>3</td><td style="text-align: left;">Derivation</td><td>&#10004;</td><td><a href="#section-derivation">2.1.3</a></td><td><a href="#component3">5.3</a></td><td  style="text-align: left;">about derivations and its subtypes</td></tr> 
-<tr><td>4</td><td style="text-align: left;">Alternate</td><td></td><td>&mdash;</td><td><a href="#component4">5.4</a></td><td  style="text-align: left;">about relations linking entities referring the same thing</td></tr> 
-<tr><td>5</td><td style="text-align: left;">Bundles</td><td></td><td><a href="#section-provenance-of-provnance">2.2.2</a></td><td><a href="#component5">5.5</a></td><td style="text-align: left;">about bundles, a mechanism to support provenance of provenance</td></tr> 
-<tr><td>6</td><td style="text-align: left;">Collections</td><td></td><td><a href="#section-collections">2.2.3</a></td><td><a href="#component6">5.6</a></td><td style="text-align: left;">about collections and concepts capturing their transformation, such as insertion and removal</td></tr> 
-</table>
-</div>
-
-</section>
-
-</section>
-
-
-<section id="prov-notation"> 
-<h2>The Provenance Notation</h2>
-
-
-<p>To illustrate the application of PROV concepts to a concrete example (see <a href="#prov-dm-example">Section 4</a>) and to provide examples of concepts (see <a href="#data-model-components">Section 5</a>),
-we introduce PROV-N, a notation for writing instances of the PROV data model. For full details, the reader is referred to the companion specification [[PROV-N]].
-PROV-N is a notation  aimed at human consumption, with the following characteristics:</p>
-<ul>
-<li>PROV-N expressions adopt a <em>functional notation</em> consisting
-of a name and a list of arguments in parentheses.</li>
-
-<li>The interpretation of PROV-N arguments is defined according to their <em>position</em> in the list of arguments. This convention allows for a compact notation. </li>
-
-<li>
-PROV-N <em>optional arguments</em> need not be specified:
-the general rule for optional arguments is that, if none of them are used in the expression, then they are simply omitted, resulting in a simpler expression. However, it may be the case that only some of the optional arguments need to be specified. Because the position of the arguments in the expression matters, in this case an additional marker must be used to indicate that a particular term is not available. The syntactic marker  '<span class="name">-</span>' is used for this purpose.
-</li>
-
-<li>Most expressions 
-include an identifier 
-and a set of attribute-value pairs; both are optional unless otherwise specified. By convention, the identifier occurs in the <em>first position</em>, and the set of attribute-value pairs in the <em>last position</em>.
-Consistent with the convention on arguments, the marker  <span class="name">-</span> can be used when the identifier is not available, or can be omitted altogether with no ambiguity arising.
-</li>
-</ul>
-
-<div class="anexample">
-<p>
-An activity with identifier <span class="name">a1</span> and an attribute <span class="name">type</span> with value <span class="name">createFile</span>.
-<pre class="codeexample" >
-activity(a1, [prov:type="createFile"])
-</pre>
-Two entities with identifiers <span class="name">e1</span> and <span class="name">e2</span>.
-<pre class="codeexample" >
-entity(e1)
-entity(e2)
-</pre>
-The activity  <span class="name">a1</span> used  <span class="name">e1</span>, and <span class="name">e2</span> was generated by <span class="name">a1</span>.
-<pre class="codeexample" >
-used(a1,e1)
-wasGeneratedBy(e2,a1)
-</pre>
-The same description, but with an explicit identifier <span class="name">u1</span> for the usage, and the syntactic marker <span class="name">-</span> to mark the absence of identifier in the generation.
-<pre class="codeexample" >
-used(u1;a1,e1)
-wasGeneratedBy(-;e2,a1)
-</pre>
-</div>
-
-
-
-</section>
-
-
-<section id="prov-dm-example"> 
-<h2>Illustration of PROV-DM by an Example</h2>
-
-<p><a href="#section-prov-overview">Section 2</a> has introduced some provenance concepts, and how they are expressed as types or relations in the PROV data model. The purpose of this section is to put these concepts into practice in order to express the provenance of some document published on the Web.  
-With this realistic example, PROV concepts are  composed together,  and a graphical illustration shows a provenance description forming a directed graph, rooted at the entity we want to explain the provenance of, and pointing to the entities, activities, and agents it depended on. This example also shows that, sometimes, multiple provenance descriptions about the same entity can co-exist, which then justifies the need for provenance of provenance.</p>
-
-
-<p>In this example, we consider one of the many documents published by the World Wide Web Consortium, and describe its provenance. 
-Specifically, we consider the document identified by
-<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: first,  provenance can take the authors' viewpoint; second, it can be concerned with the W3C process. Then, attribution of these two provenance descriptions is provided.</p>
-
-
-<section id="section-example-one"> 
-<h3>The Authors View</h3>
-
-
-<p style="font-style:italic; " ><b>Description:</b> A document
-is edited by some editor, using contributions from various
-contributors.
-</p>
-
-
-
-<p>In this perspective, provenance of the document
-<a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">http://www.w3.org/TR/2011/WD-prov-dm-20111215</a> is concerned with the 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>
-
-
-
-
-<p>We paraphrase some PROV-DM descriptions, express them with the PROV-N notation, and then depict them with a graphical illustration (see <a href="#prov-a-document1">Figure 1</a>).
-Full details of the provenance record can be found <a href="examples/w3c-publication3.pn">here</a>.</p>
-
-<ul>
-<li>There was a document <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, which from the author's perspective was a document in its second version. 
-<pre>
-entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
-</pre>
-</li>
-
-<li>There was an editing activity.
-<pre>
-activity(ex:edit1,[prov:type="edit"])
-</pre>
-</li>
-
-<li>The document was generated by the editing activity: this was a <a title="concept-generation">Generation</a>.
-<pre>
-wasGeneratedBy(tr:WD-prov-dm-20111215, ex:edit1, -)
-</pre>
-</li>
-
-
-<li>There were 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>
-
-<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 descriptions.  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 pentagonal shapes, respectively.  Usage,
-Generation, Derivation, and Association are represented as directed edges.</p>
-
-<p>Entities are laid out according to the ordering of their generation.  We endeavor to show time progressing from left to right. This means that edges for Usage, Generation,
-Derivation, Association typically point leftwards</p>
-
-
-<div style="text-align: center; ">
-  <figure>
-  <img src="images/w3-publication3.png" alt="Provenance of a Document (1)" style="max-width: 98%; "/>
-<figcaption id="prov-a-document1">Figure 2: Provenance of a Document (1)</figcaption>
-  </figure>
-</div>
-
-</section>
-
-<section id="section-example-two"> 
-<h3>The Process View</h3>
-
-
-<p style="font-style:italic; " ><b>Description:</b> The World Wide Web
-Consortium publishes documents 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 document must also be 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 document, the policy according to which they were published, and the associated requests.
-</p>
-
-<p>
-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 refer archived email messages, available to W3C Members).</p>
-
-<ul>
-<li> Two versions of a document were 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 (<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> was <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> was <span class="name">ex:act1</span>;
-</li>
-
-<li> The document <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> was 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">email:2011Oct/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">chairs:2011OctDec/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">email:2011Dec/0111</a></span>);</li>
-<li> Documents were published according to the process rules (<span class="name"><a href="http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance">process:rec-advance</a></span>), a plan in PROV-DM terminology.</li>
-</ul>
-
-<p>
-We now paraphrase some PROV descriptions, and express them with the PROV-N notation, and then depict them with a graphical illustration (see <a href="#prov-a-document2">Figure 2</a>). Full details of the provenance record can be found <a href="examples/w3c-publication1.pn">here</a>.
-
-<ul>
-<li>There was a document, a working draft (<a href="http://www.w3.org/2001/02pd/rec54#WD">rec54:WD</a>), which is an entity so that we can describe its provenance. Similar descriptions exist for all entities.
-<pre>
-entity(tr:WD-prov-dm-20111215, [ prov:type='rec54:WD' ])
-</pre>
-</li>
-<li>There was a publication activity.
-<pre>
-activity(ex:act2,[prov:type="publish"])
-</pre>
-</li>
-
-<li>The document was generated by the publication activity: this was a <a title="concept-Generation">Generation</a>.
-<pre>
-wasGeneratedBy(tr:WD-prov-dm-20111215, ex:act2, -)
-</pre>
-</li>
-
-
-<li>The second draft of the document was derived from the first draft: this was 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 was a <a title="concept-Usage">Usage</a>.
-<pre>
-used(ex:act2, email:2011Dec/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, process:rec-advance)
-</pre>
-</li>
-</ul>
-
-
-
-
-
-
-
-<div style="text-align: center;">
-  <figure>
-  <img src="images/w3-publication1.png" alt="Provenance of a Document (2)" style="max-width: 90%; "/>
-<figcaption id="prov-a-document2">Figure 3: Provenance of a Document (2)</figcaption>
-  </figure>
-</div>
-
-
-<p> This simple example has shown a variety of PROV concepts, such as Entity, Agent, Activity, Usage, Generation, Derivation, and Association. 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 documents, since each URI denotes a specific version of a document. It then becomes easy to relate the various versions with  PROV-DM relations. We note that an Association is a ternary relation (represented by a multi-edge labeled wasAssociatedWith) from an activity to an agent and a plan.</p>
-
-
-</section>
-
-
-<section id="section-example-c"> 
-<h3>Attribution of Provenance</h3>
-
-<p>The two previous sections  offer two different perspectives on the provenance of a document.  PROV allows for multiple sources to provide the provenance of a subject. For users to decide whether they can place their trust in the document, 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>PROV-DM offers a construct to name a bundle of provenance descriptions. </p>
-
-<pre class="codeexample">
-bundle ex:author-view
-
-  agent(ex:Paolo,   [ prov:type='prov:Person' ])
-  agent(ex:Simon,   [ prov:type='prov:Person' ])
-
-
-...
-
-endBundle
-</pre>
-
-Likewise, the process view can be expressed as a separate named bundle.
-<pre class="codeexample">
-bundle ex:process-view
-
-   agent(w3:Consortium, [ prov:type='prov:Organization' ])
-
-...
-
-endBundle
-</pre>
-
-<p>To express their respective provenance, these bundles must be seen as entities, and all PROV constructs are now available to express their provenance. In the example below, <span class="name">ex:author-view</span> is attributed to the agent  <span class="name">ex:Simon</span>, whereas <span class="name">ex:process-view</span> to  <span class="name">w3:Consortium</span>.
-
-<pre class="codeexample">
-entity(ex:author-view, [prov:type='prov:Bundle' ])
-wasAttributedTo(ex:author-view, ex:Simon)
-
-entity(ex:process-view, [prov:type='prov:Bundle' ])
-wasAttributedTo(ex:process-view, w3:Consortium)
-</pre>
-
-<div class="note">
-<p>TODO: full details of bundles can be found at  <a href="examples/w3c-publication1.pn">ex:process-view</a> and <a href="examples/w3c-publication3.pn">ex:author-view</a>.</p>
-</div>
-
-
-</section>
-
-</section>
-
-
-<section id="data-model-components"> 
-
-<h2>PROV-DM Types and Relations</h2>
-
-<p>Provenance concepts, expressed as PROV-DM types and relations, are structured according to six components that are introduced in this section.
-The components and their dependencies are illustrated in <a href="#prov-dm-components">Figure 4</a>. A component that relies on concepts defined in another also sits above it in this figure.
-PROV-DM consists of the following components.</p>
-
-<div id="prov-dm-components-ul">
-<ul>
-<li><b>Component 1: entities and activities.</b> The first component consists of entities, activities, and concepts linking them, such as generation, usage, start, end. The first component is the only one comprising time-related concepts. </li>
-<li><b>Component 2: agents and responsibility.</b> The second component consists of agents and concepts ascribing responsibility to agents.</li>
-<li><b>Component 3: derivations.</b>  The third component is formed with derivations and derivation subtypes.</li>
-<li><b>Component 4: alternate.</b> The fourth component consists of relations linking entities referring to the same thing. </li>
-<li><b>Component 5: bundles.</b> The fifth component is concerned with bundles, a mechanism to support provenance of provenance.</li>
-<li><b>Component 6: collections.</b> The sixth component is about collections and concepts capturing their transformation, such as insertion and removal. </li>
-</ul>
-</div>
-
-<!-- TODO: update map for linking -->
-
-<div style="text-align: center;">
-<figure style="max-width: 90%; ">
-<img  usemap="#componentMap" src="../images/components-dependencies.png" alt="PROV-DM Components"  style="max-width: 90%; " />
-<map id="componentMap" name="componentMap">
-<area title="collections" href="#component5" coords="220,0,440,70"  alt="collections" shape="rect"/>
-<area title="alternate"   href="#component4" coords="450,0,510,140" alt="alternate"   shape="rect"/>
-<area title="annotations" href="#component6" coords="530,0,590,220" alt="annotations" shape="rect"/>
-<area title="activities/entities" href="#component1" coords="80,150,510,220" alt="activities/entities" shape="rect"/>
-<area title="derivations" href="#component3" coords="80,0,210,70"   alt="derivations" shape="rect"/>
-<area title="agents/responsibility" href="#component2" coords="0,0,70,220"   alt="agents/responsibility" shape="rect"/>
-</map>
-<figcaption id="prov-dm-components">Figure 4: PROV-DM Components</figcaption>
-</figure>
-</div>
-
-<p>
-While  not all PROV-DM relations are binary, they all involve two primary elements. Hence, <a href="#relations-at-a-glance">Table 3</a> indexes all relations according to their two primary elements.  The table adopts the same color scheme as <a href="#prov-dm-components">Figure 4</a>, allowing components to be readily identified.
-Note that for simplicity, this table  does not include bundle-oriented and collection-oriented relations.
-Relation names appearing in bold correspond to the core structures introduced
-in <a href="#core-structures">Section 2.1</a>.</p>
-</p>
-
-<div id="relations-at-a-glance-div" style="text-align: center;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="relations-at-a-glance">Table 3: PROV-DM Relations At a Glance</caption>
-<tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td></tr> 
-<tr><td>Entity</td><td><div class="component3-color"><a class="essential">wasDerivedFrom</a><br><a>wasRevisionOf</a><br><a>wasQuotedFrom</a><br><a>hadOriginalSource</a></div><div class="component4-color"><a>alternateOf</a><br><a>specializationOf</a></div></td><td class="component1-color"><a class="essential"
-title="wasGeneratedBy">wasGeneratedBy</a><br><a
-title="wasInvalidatedBy">wasInvalidatedBy</a></td><td class="component2-color"><a class="essential">wasAttributedTo</a></td></tr>
-<tr><td>Activity</td><td><div class="component1-color"><a class="essential">used</a><br><a>wasStartedBy</a><br><a>wasEndedBy</a></div></td><td class="component1-color"><a>wasInformedBy</a></td><td class="component2-color"><a class="essential">wasAssociatedWith</a></td></tr>
-<tr><td>Agent</td><td>&mdash;</td><td>&mdash;</td><td class="component2-color"><a class="essential">actedOnBehalfOf</a></td></tr>
-</table>
-</div>
-
-<p><a href="#prov-dm-types-and-relations">Table 4</a> is a complete index of all the types and relations of PROV-DM, color-coded according to the component they belong to.  In the first column,  concept names  link to their informal definition, whereas, in the second column, representations link to the information used to represent the concept. Concept names appearing in bold are the core structures introduced in <a href="#core-structures">Section 2.1</a>.</p>
-
-
-<div id="prov-dm-types-and-relations-fig" style="text-align: left;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="prov-dm-types-and-relations">Table 4: PROV-DM Types and Relations</caption>
-<tr><td><a><b>Type or Relation Name</b></a></td><td><b>Representation in the PROV-N notation</b></td><td><b>Component</b></td></tr>
-<tr class="component1-color"><td class="essential"><a>Entity</a></td><td><a title="dfn-Entity" class="essential">entity(id, [ attr1=val1, ...])</a></td><td rowspan="8">Component 1: entities/activities</td></tr>
-<tr class="component1-color"><td class="essential"><a>Activity</a></td><td><a title="dfn-Activity" class="essential">activity(id, st, et, [ attr1=val1, ...])</a></td></tr>
-<tr class="component1-color"><td class="essential"><a>Generation</a></td><td><a title="wasGeneratedBy"><span class="essential">wasGeneratedBy(</span>id;<span class="essential">e,a</span>,t,attrs<span class="essential">)</span></a></td></tr>
-<tr class="component1-color"><td class="essential"><a>Usage</a></td><td><a title="used"><span class="essential">used(</span>id;<span class="essential">a,e</span>,t,attrs<span class="essential">)</span></a></td></tr>
-<tr class="component1-color"><td><a>Start</a></td><td><a title="wasStartedBy">wasStartedBy(id;a2,e,a1,t,attrs)</a></td></tr>
-<tr class="component1-color"><td><a>End</a></td><td><a title="wasEndedBy">wasEndedBy(id;a2,e,a1,t,attrs)</a></td></tr>
-<tr class="component1-color"><td><a>Invalidation</a></td><td><a title="wasInvalidatedBy">wasInvalidatedBy(id;e,a,t,attrs)</a></td></tr>
-<tr class="component1-color"><td><a>Communication</a></td><td><a title="wasInformedBy">wasInformedBy(id;a2,a1,attrs)</a></td></tr>
-<tr class="component2-color"><td  class="essential"><a>Agent</a></td><td><a title="dfn-agent" class="essential">agent(id, [ attr1=val1, ...])</a></td><td  rowspan="4">Component 2: agents/responsibility</td></tr>
-<tr class="component2-color"><td class="essential"><a>Attribution</a></td><td><a title="wasAttributedTo"><span class="essential">wasAttributedTo(</span>id;<span class="essential">e,ag</span>,attr<span class="essential">)</span></a></td></tr>
-<tr class="component2-color"><td class="essential"><a>Association</a></td><td><a title="wasAssociatedWith"><span class="essential">wasAssociatedWith(</span>id;<span class="essential">a,ag</span>,pl,attrs<span class="essential">)</span></a></td></tr>
-<tr class="component2-color"><td class="essential"><a>Responsibility</a></td><td><a title="actedOnBehalfOf"><span class="essential">actedOnBehalfOf(</span>id;<span class="essential">ag2,ag1</span>,a,attrs<span class="essential">)</span></a></td></tr>
-<tr class="component3-color"><td class="essential"><a>Derivation</a></td><td><a title="wasDerivedFrom"><span class="essential">wasDerivedFrom(</span>id; <span class="essential">e2, e1</span>, a, g2, u1, attrs<span class="essential">)</span></a></td><td  rowspan="5">Component 3: derivation</td></tr>
-<tr class="component3-color"><td><a>Revision</a></td><td><a title="wasRevisionOf">wasRevisionOf(id; e2, e1, a, g2, u1, attrs)</a></td></tr>
-<tr class="component3-color"><td><a>Quotation</a></td><td><a title="wasQuotedFrom">wasQuotedFrom(id; e2, e1, a, g2, u1, attrs)</a></td></tr>
-<tr class="component3-color"><td><a>Original Source</a></td><td><a title="hadOriginalSource">hadOriginalSource(id; e2, e1, a, g2, u1, attrs)</a></td></tr>
-<tr class="component3-color"><td><a>Trace</a></td><td><a title="tracedTo">tracedTo(id;e2,e1,attrs)</a></td></tr>
-<tr class="component4-color"><td><a>Alternate</a></td><td><a title="alternateOf">alternateOf(alt1, alt2)</a></td><td  rowspan="2">Component 4: alternate</td></tr>
-<tr class="component4-color"><td><a>Specialization</a></td><td><a title="specializationOf">specializationOf(sub, super)</a></td></tr>
-<tr class="component6-color"><td><a title="bundle">Bundle constructor</a></td><td><a title="dfn-bundle">bundle id description_1 ... description_n endBundle</a></td><td  rowspan="3">Component 5: bundles</td></tr>
-<tr class="component6-color"><td><a title="bundle">Bundle description</a></td><td><a>Bundle</a></td></tr>
-<tr class="component6-color"><td><a>Provenance Locator</a></td><td><a title="hasProvenanceIn">hasProvenanceIn(id, subject, bundle, target, service, prov, attrs)</a></td></tr>
-<tr class="component5-color"><td><a>Collection</a></td><td><a>Collection</a></td><td  rowspan="5">Component 6: Collections</td></tr>
-<tr class="component5-color"><td><a>Dictionary</a></td><td><a>Dictionary</a></td></tr>
-<tr class="component5-color"><td><a>Insertion</a></td><td><a title="derivedByInsertionFrom">derivedByInsertionFrom(id; c2, c1, {(key_1, e_1), ..., (key_n, e_n)}, attrs)</a></td></tr>
-<tr class="component5-color"><td><a>Removal</a></td><td><a title="derivedByRemovalFrom">derivedByRemovalFrom(id; c2, c1, {key_1, ... key_n}, attrs)</a></td></tr>
-<tr class="component5-color"><td><a>Membership</a></td><td><a title="memberOf">memberOf(c, {(key_1, e_1), ..., (key_n, e_n)})</a></td></tr>
-</table>
-</div>
-
-<p>
-In the rest of the section, each type and relation is defined informally,
- followed by a summary of the information used to represent the concept, and
- illustrated with PROV-N examples.</p>
-
-
-<section id="component1"> 
-<h3>Component 1: Entities and Activities</h3>
-
-<p>The first component of PROV-DM is concerned with <a title="entity">entities</a> and <a title="activity">activities</a>, and their interrelations: <a>Usage</a>, <a>Generation</a>, <a>Start</a>, <a>End</a>, <a>Invalidation</a>, and <a>Communication</a>.  <a href="#figure-component1">Figure 5</a> uses UML to depict the first component.
-Core structures are displayed in the yellow area, consisting of two classes (<a>Entity</a>, <a>Activity</a>) and two binary associations between them (<a>Usage</a>, <a>Generation</a>). The rest of the figure displays extended structures, including UML associations classes (represented in gray) to express expanded n-ary relations (for <a>Usage</a>, <a>Generation</a>, <a>Invalidation</a>, <a>Start</a>, <a>End</a>,  <a>Communication</a>). The figure also makes explicit <em>time</em> attributes for these concepts (time being represented as a primitive).
-</p>
-
-<div style="text-align: center;">
-<figure>
-<!--<img src="images/Entities-Activities.png" alt="entities and activities"/> -->
-
-<img src="../uml/component1.svg" alt="entities and activities"/>
-<figcaption id="figure-component1">Figure 5: Entities and Activities Component Overview</figcaption>
-</figure>
-</div>
-
-
-
-
-
-   <section id="term-Entity"> 
-      
-<h4>Entity</h4>
-
-
-<div class="glossary-ref" data-ref="glossary-entity"></div>
-
-
-<p><div class="attributes" id="attributes-entity">An <dfn title="dfn-Entity" id="dfn-entity">entity</dfn><span class="withPn">, written <span class="pnExpression" id="pn-entity">entity(id, [attr1=val1, ...])</span> in PROV-N, </span> has:
-<ul>
-<li><span class='attribute' id="entity.id">id</span>: an identifier for an entity; </li>
-<li><span class='attribute' id="entity.attributes">attributes</span>: an OPTIONAL set of attribute-value  pairs ((<span class="name">attr1</span>, <span class="name">val1</span>), ...) representing additional information about this entity.</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 attribute <span class="name">ex:version</span> is application specific, whereas the attribute <span
-class="name">type</span> (see <a href="#term-attribute-type">Section 4.7.4.4</a>) is reserved in the <a title="prov-namespace">PROV namespace</a>.
-<!--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 namespace.-->
-</div>
-
-
-
-
-    </section> 
-
-    <section id="term-Activity"> 
-      
-<h3>Activity</h3>
-
-<div class="glossary-ref" data-ref="glossary-activity"></div>
-
-<p><div class="attributes" id="attributes-activity"> An <dfn title="dfn-Activity" id="dfn-activity">activity</dfn><span class="withPn">, written <span class="pnExpression" id="pn-activity">activity(id, st, et, [attr1=val1, ...])</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="activity.id">id</span>: an identifier for an activity;</li>
-<li><span class='attribute' id="activity.startTime">startTime</span>: an OPTIONAL time (<span class="name">st</span>) for the start of the activity;</li>
-<li><span class='attribute' id="activity.endTime">endTime</span>: an OPTIONAL time (<span class="name">et</span>) for the end of the activity;</li>
-<li><span class='attribute' id="activity.attributes">attributes</span>:  an OPTIONAL set of attribute-value pairs ((<span class="name">attr1</span>, <span class="name">val1</span>), ...) representing additional information about 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' ])
-</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  (see <a href="#term-attribute-type">Section 4.7.4.4</a>).</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-Generation">
-<h4>Generation</h4>
-
-<div class="glossary-ref" data-ref="glossary-generation"></div>
-
-<p>
-<div class="attributes" id="attributes-generation"><dfn title="wasGeneratedBy">Generation</dfn><span class="withPn">, written <span class="pnExpression">wasGeneratedBy(id;e,a,t,attrs)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="generation.id">id</span>:  an OPTIONAL identifier for a generation;</li> 
-<li><span class='attribute' id="generation.entity">entity</span>:  an identifier (<span class="name">e</span>) for a created entity; </li>
-<li><span class='attribute' id="generation.activity">activity</span>:  an OPTIONAL identifier (<span class="name">a</span>) for the activity that creates the entity;</li>
-
-<li><span class='attribute' id="generation.time">time</span>: an OPTIONAL "generation time" (<span class="name">t</span>), the time at which the entity was completely created;</li>
-
-<li><span class='attribute' id="generation.attributes">attributes</span>:  an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this generation.</li>
-</ul></div>
-<p>While each of <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"])
-  wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p2"])
-</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  on port <span class="name">p1</span>, whereas the other is available on port <span class="name">p2</span>.  The semantics of <span class="name">port</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 element 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" data-ref="glossary-usage"></div>
-
-
-<p><div class="attributes" id="attributes-usage"><dfn title="used">Usage</dfn><span class="withPn">, written <span class="pnExpression">used(id;a,e,t,attrs)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="usage.id">id</span>:  an OPTIONAL identifier for a usage;</li> 
-<li><span class='attribute' id="usage.activity">activity</span>: an identifier (<span class="name">a</span>) for the consuming activity;</li>
-<li><span class='attribute' id="usage.entity">entity</span>: an identifier (<span class="name">e</span>) for the consumed entity;</li>
-<li><span class='attribute' id="usage.time">time</span>: an OPTIONAL "usage time" (<span class="name">t</span>), the time at which the entity started to be used;</li>
-<li><span class='attribute' id="usage.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this usage.</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> used 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>
-
-
-
-
-
-
-</section>
-
-
-<section id="term-Start">
-<h4>Start</h4>
-
-<div class="glossary-ref" data-ref="glossary-start"></div>
-
-
-<p><div class="attributes" id="attributes-start">An activity <dfn title="wasStartedBy">start</dfn><span class="withPn">, written <span class="pnExpression">wasStartedBy(id; a2, e, a1, t, attrs)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="start.id">id</span>:  an OPTIONAL identifier for the activity start;</li> 
-<li><span class='attribute' id="start.activity">activity</span>: an identifier (<span class="name">a2</span>) for the started activity;</li> 
-<li><span class='attribute' id="start.trigger">trigger</span>: an OPTIONAL identifier (<span class="name">e</span>) for the entity triggering the activity;</li> 
-<li><span class='attribute' id="start.starter">starter</span>: an OPTIONAL identifier (<span class="name">a1</span>) for the activity that generated the (possibly unspecified) entity (<span class="name">e</span>);</li> 
-<li><span class='attribute' id="start.time">time</span>: the OPTIONAL time (<span class="name">t</span>) at which the activity was started; </li> 
-<li><span class='attribute' id="start.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this activity start.
-</ul>
-</div>
-
-<div class="anexample">
-<p>
-The following example contains the description of an activity <span class="name">a1</span> (a discussion), which was started at a specific time, and was triggered by an email message <span class="name">e1</span>.</p>
-<pre class="codeexample">
-entity(e1, [prov:type="email message"] )
-activity(a1, [ prov:type="Discuss" ])
-wasStartedBy(a1, e1, -, 2011-11-16T16:05:00)
-</pre>
-Furthermore, if the message is also an input to the activity, this can be described as follows:
-<pre class="codeexample">
-used(a1, e1, -)
-</pre>
-<p>Alternatively, one can also describe the activity that generated the email message.</p>
-<pre class="codeexample">
-activity(a0, [ prov:type="Write" ])
-wasGeneratedBy(e1, a0)
-wasStartedBy(a1, e1, a0, 2011-11-16T16:05:00)
-</pre>
-</div>
-
-<div class="anexample">
-<p>
-In the following example, a race is started by a bang, and responsibility for this trigger is attributed to an agent 
- <span class="name">ex:Bob</span>.
-<pre class="codeexample">
-activity(ex:foot_race)
-entity(ex:bang)
-wasStartedBy(ex:foot_race, ex:bang, -, 2012-03-09T08:05:08-05:00)
-agent(ex:Bob)
-wasAttributedTo(ex:bang, ex:Bob)
-</pre>
-</div>
-
-<div class="anexample">
-<p>
-In this example, filling fuel was started as a consequence of
-observing the low fuel. The trigger entity is unspecified, it could
-for instance have been the low fuel warning light, the fuel tank
-indicator needle position, or the engine not running properly.
-
-
-<pre class="codeexample">
-activity(ex:filling-fuel)
-activity(ex:observing-low-fuel)
-
-agent(ex:driver, [ prov:type='prov:Person'  )
-wasAssociatedWith(ex:filling-fuel, ex:driver)
-wasAssociatedWith(ex:observing-low-fuel, ex:driver)
-
-wasStartedBy(ex:filling-fuel, -, ex:observing-low-fuel, -)
-</pre>
-</div>
-
-<p>The relations wasStartedBy and used are orthogonal, and thus need to be expressed independently, according to the situation being described.</p>
-
-</section>
-
-<section id="term-End">
-<h4>End</h4>
-
-<div class="glossary-ref" data-ref="glossary-end"></div>
-
-
-<p><div class="attributes" id="attributes-end">An activity <dfn title="wasEndedBy">end</dfn><span class="withAsn">, written <span class="pnExpression">wasEndedBy(id;a2,e,a1,t,attrs)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="end.id">id</span>:  an OPTIONAL identifier for the activity end;</li> 
-<li><span class='attribute' id="end.activity">activity</span>: an identifier (<span class="name">a2</span>) for the ended activity;
-<li><span class='attribute' id="end.trigger">trigger</span>: an OPTIONAL identifier (<span class="name">e</span>) for the entity triggering the activity ending;
-<li><span class='attribute' id="end.ender">ender</span>: an OPTIONAL identifier (<span class="name">a1</span>) for the activity that generated the (possibly unspecified) entity (<span class="name">e</span>);</li> 
-<li><span class='attribute' id="end.time">time</span>: the OPTIONAL time (<span class="name">t</span>) at which the activity was ended; </li> 
-<li><span class='attribute' id="end.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this activity end.
-</ul>
-</div>
-
-<div class="anexample">
-<p>
-The following example is a description of an activity <span class="name">a1</span> (editing) that was ended following an approval document <span class="name">e1</span>.</p>
-<pre class="codeexample">
-entity(e1,[prov:type="approval document"])
-activity(a1,[prov:type="Editing"])
-wasEndedBy(a1,e1)
-</pre>
-</div>
-
-
-</section>
-
-<section id="term-Invalidation">
-<h4>Invalidation</h4>
-
-
-<div class="glossary-ref" data-ref="glossary-invalidation"></div>
-
-
-
-<p>
-Entities have a duration. Generation marks the beginning of an entity. An entity's lifetime can end for different reasons:</p>
-<ul>
-<li> an entity was destroyed: e.g. a painting was destroyed by fire; a Web page is taken out of a site;
-<li> an entity was consumed: e.g. Bob ate all his soup, Alice ran out of gas when driving to work;
-<li> an entity expires: e.g. a "buy one beer, get one free" offer is valid during happy hour (7-8pm);
-<li> an entity is time limited: e.g. the BBC news site on April 3rd, 2012;
-<li> an entity attribute is changing: e.g. the traffic light changed from green to red.
-</ul>
-<p>In the first two cases, the entity has physically disappeared after its termination: there is no more soup, or painting.  In the last three cases, there may be an "offer voucher" that still exists, but it is no longer valid; likewise, on April 4th, the BBC news site still exists but it is not the same entity as BBC news Web site on April 3rd; or the traffic light became red and therefore is regarded as a different entity to the green light.
-</p>
-
-
-
-<p>
-<div class="attributes" id="attributes-invalidation"><dfn title="wasInvalidatedBy">Invalidation</dfn><span class="withPn">, written <span class="pnExpression">wasInvalidatedBy(id;e,a,t,attrs)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute'>id</span>:  an OPTIONAL identifier for a invalidation;</li> 
-<li><span class='attribute'>entity</span>:  an identifier for the invalidated entity; </li>
-<li><span class='attribute'>activity</span>:  an OPTIONAL identifier for the activity that invalidated the entity;</li>
-
-<li><span class='attribute'>time</span>: an OPTIONAL "invalidation time", the time at which the entity began to be invalidated;</li>
-
-<li><span class='attribute'>attributes</span>:  an OPTIONAL set of attribute-value pairs representing additional information about this invalidation.</li>
-</ul></div>
-<p>While each of <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" id="anexample-invalidation1">
-<p>
-The Painter, a Picasso painting, is known to have been destroyed in a <a href="http://en.wikipedia.org/wiki/Lost_artworks#20th_century">plane accident</a>.
-
-<pre class="codeexample">
-entity(ex:The-Painter)
-agent(ex:Picasso)
-wasAttributedTo(ex:The-Painter, ex:Picasso)
-activity(ex:crash)
-wasInvalidatedBy(ex:The-Painter, ex:crash, 1998-09-02, [ex:circumstances="plane accident"])
-</pre>
-</div>
-
-<div class="anexample" id="anexample-invalidation2">
-<p>
-The BBC news home page on 2012-04-03 <span class="name">ex:bbcNews2012-04-03</span>
-contained a reference to a given news item
- <a href="http://www.bbc.co.uk/news/uk-17595024">bbc:news/uk-17595024</a>,
-but the BBC news home page on the next day did not.
-<pre class="codeexample">
-entity(ex:bbcNews2012-04-03)
-memberOf(ex:bbcNews2012-04-03,{("item1", bbc:news/uk-17595024)})
-wasGeneratedBy  (ex:bbcNews2012-04-03,-,2012-04-03T00:00:01)
-wasInvalidatedBy(ex:bbcNews2012-04-03,-,2012-04-03T23:59:59)
-</pre>
-We refer to example <a href="#anexample-specialization">anexample-specialization</a> for further descriptions of the BBC Web site, and to Section <a>Membership</a> for a description of the relation <a>memberOf</a>.
-</div>
-
-
-<div class="anexample" id="anexample-invalidation3">
-<p>
-In this example, the  "buy one beer, get one free" offer expired at the end of the happy hour.</p>
-<pre class="codeexample">
-entity(buy_one_beer_get_one_free_offer_during_happy_hour)
-wasAttributedTo(proprietor)
-wasInvalidatedBy(buy_one_beer_get_one_free_offer_during_happy_hour,
-                 -,2012-03-10T18:00:00)
-</pre>
-<p>In contrast, in the following descriptions, Bob redeemed the offer 45 minutes before it expired, and got two beers.  
-</p>
-<pre class="codeexample">
-entity(buy_one_beer_get_one_free_offer_during_happy_hour)
-wasAttributedTo(proprietor)
-activity(redeemOffer)
-entity(twoBeers)
-
-wasAssociatedWith(redeemOffer,bob)
-used(buy_one_beer_get_one_free_offer_during_happy_hour,
-     redeemOffer, 2012-03-10T17:15:00)
-wasInvalidatedBy(buy_one_beer_get_one_free_offer_during_happy_hour,
-                 redeemOffer, 2012-03-10T17:15:00)
-wasGeneratedBy(twoBeers,redeemOffer)
-</pre>
-<p>We see that the offer was both used to be converted into <span class="name">twoBeers</span> and invalidated by the <span class="name">redeemOffer</span> activity: in other words, the combined usage and invalidation indicate consumption of the offer.</p>
-</div>
-
-
-</section>
-
-
-<section id="term-wasInformedBy">
-<h3>Communication</h3>
-
-<div class="glossary-ref" data-ref="glossary-communication"></div>
-
-
-<p>A communication implies that activity  <span class="name">a2</span> is dependent on another <span class="name">a1</span>, by way of some unspecified entity that is generated by <span class="name">a1</span> and used by <span class="name">a2</span>.</p>
-
-
-
-
-<p><div class="attributes" id="attributes-wasInformedBy">
-A <dfn title="wasInformedBy">communication</dfn><span class="withPn">, written as 
-<span class="pnExpression">wasInformedBy(id;a2,a1,attrs)</span> in PROV-N,</span> has: 
-<ul>
-<li><span class='attribute' id="wasInformedBy.id">id</span>:  an OPTIONAL identifier  identifying the relation;</li> 
-<li><span class='attribute' id="wasInformedBy.informed">informed</span>: the identifier (<span class="name">a2</span>) of the informed activity;
-<li><span class='attribute' id="wasInformedBy.informant">informant</span>: the identifier (<span class="name">a1</span>) of the informant activity;
-<li><span class='attribute' id="wasInformedBy.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this communication.</li>
-</ul>
-</div>
-
-
-
-<div class="anexample">
-<p>
-Consider two activities  <span class="name">a1</span> and <span class="name">a2</span>, the former performed by a government agency, and the latter by a driver caught speeding. 
-<pre class="codeexample">
-activity(a1, [prov:type="traffic regulations enforcing"])
-activity(a2, [prov:type="fine paying, check writing, and mailing"])
-wasInformedBy(a2,a1)
-</pre>
-The last line indicates that some implicit entity was generated by  <span class="name">a1</span> and used by  <span class="name">a2</span>; this entity may be a traffic ticket that had a notice of fine, amount, and payment mailing details.
-</div>
-</section>
-
-
-
-</section>
-
-<section id="component2"> 
-<h3>Component 2: Agents and Responsibility</h3>
-
-<p>The second component of PROV-DM, depicted in  <a href="#figure-component2">Figure 6</a>, is concerned with <a title="agent">agents</a> and the notions of
-<a>Attribution</a>, <a>Association</a>, <a>Responsibility</a>, relating agents to entities, activities, and agents, respectively.
- Core structures are displayed in the yellow area and include three classes and three binary associations. Outside the yellow area, extended structures comprise the subclass <a>Plan</a> and UML association classes to express expanded n-ary relations.
-</p>
-
-
-<div style="text-align: center;">
-<figure>
-<!-- <img src="images/Agents-Responsibility.png" alt="agents and responsibilities"/> -->
-<img src="../uml/component2.svg" alt="agents and responsibilities"/>
-<figcaption id="figure-component2">Figure 6: Agents and Responsibilities Component Overview</figcaption>
-</figure>
-</div>
-
-<section id="term-Agent">
-<h3>Agent</h3>
-
-<div class="glossary-ref" data-ref="glossary-agent"></div>
-
-
-<p><div class="attributes" id="attributes-agent">An <dfn title="dfn-agent" id="dfn-agent">agent</dfn><span class="withPn">, written <span class="pnExpression" id="pn-agent">agent(id, [attr1=val1, ...])</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="agent.id">id</span>: an identifier for an agent;</li>
-<li><span class='attribute' id="agent.attributes">attributes</span>: a set of attribute-value pairs ((<span class="name">attr1</span>, <span class="name">val1</span>), ...) representing additional information about this agent.
-</li>
-</ul></div>
-
-
-<p>
-
-It is useful to define some basic categories of agents from an interoperability perspective.
-There are three types of agents that are common across most anticipated domains of use; it is acknowledged that these types do not cover all kinds of agent. </p>
-<ul>
-<li><span class="name">SoftwareAgent</span>
-<div class="glossary-ref" data-ref="glossary-software-agent"></div>
-
-<p></li>
-
-<li><span class="name">Organization</span>
-
-<div class="glossary-ref" data-ref="glossary-organization"></div>
-
-<p></li>
-
-<li><span class="name">Person</span>
-
-<div class="glossary-ref" data-ref="glossary-person"></div></li> 
-</ul>
-
-
-
-
-
-<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' ])
-</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>
-
-</section>
-
-<section id="term-attribution">
-<h3>Attribution</h3> 
-
-<div class="glossary-ref" data-ref="glossary-attribution"></div>
-
-<p>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 unspecified activity that 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>
-
-<p><div class="attributes" id="attributes-attribution">An <dfn title="wasAttributedTo">attribution</dfn> relation<span class="withPn">, written <span class="pnExpression">wasAttributedTo(id;e,ag,attrs)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="attribution.id">id</span>: an OPTIONAL identifier for the relation;</li> 
-<li><span class='attribute' id="attribution.entity">entity</span>: an entity identifier (<span class="name">e</span>);</li>
-<li><span class='attribute' id="attribution.agent">agent</span>: the identifier (<span class="name">ag</span>) of the agent whom the entity is ascribed to;</li>
-<li><span class='attribute' id="attribution.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this attribution.</li>
-</ul>
-</div>
-
-<div class="anexample" id="anexample-attribution">
-<p>
-Revisiting the example of <a href="#section-example-one">Section 3.1</a>,
-we can ascribe <span class="name">tr:WD-prov-dm-20111215</span> to some agents without an explicit activity. The reserved attribute <span class="name">role</span> (see <a href="#term-attribute-role">Section 4.7.4.3</a>) allows for role of the agent in the attribution to be specified.
-<pre class="codeexample">
-agent(ex:Paolo, [ prov:type="Person" ])
-agent(ex:Simon, [ prov:type="Person" ])
-entity(tr:WD-prov-dm-20111215, [ prov:type='rec54:WD'  ])
-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-ActivityAssociation">
-<h4>Association</h4>
-
-<div class="glossary-ref" data-ref="glossary-activityAssociation"></div>
-
-<p></p>
-<div class="glossary-ref" data-ref="glossary-plan"></div>
-
-
-<p><div class="attributes" id="attributes-activity-association">An <dfn title="wasAssociatedWith">activity association</dfn><span class="withPn">, written <span class="pnExpression">wasAssociatedWith(id;a,ag,pl,attrs)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="association.id">id</span>:  an OPTIONAL identifier for the association between an activity and an agent;</li> 
-<li><span class='attribute' id="association.activity">activity</span>: an identifier (<span class="name">a</span>) for the activity;</li>
-<li><span class='attribute' id="association.agent">agent</span>: an OPTIONAL identifier (<span class="name">ag</span>) for the agent associated with the activity;</li>
-<li><span class='attribute' id="association.plan">plan</span>: an OPTIONAL identifier (<span class="name">pl</span>) for the plan adopted by the agent in the context of this activity;
-<li><span class='attribute' id="association.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this association of this activity with this agent.</li>
-</ul></div>
-
-<div class="anexample" id="anexample-wasAssociateWith">
-<p>In the following example, a designer agent and an operator agent are associated with an activity. The designer's goals are achieved by a workflow <span class="name">ex:wf</span>, described as an an entity of type <span class="name"><a>plan</a></span>.   </p>
-<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' , 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="anexample" id="anexample-wasAssociateWith-2">
-<p>In some cases, one wants to indicate a plan was followed, without having to specify which agent was involved.</p>
-<pre class="codeexample">
-activity(ex:a,[prov:type="workflow execution"])
-wasAssociatedWith(ex:a,-,ex:wf)
-entity(ex:wf,[prov:type='prov:Plan', ex:label="Workflow 1", 
-              ex:url="http://example.org/workflow1.bpel" %% xsd:anyURI])
-</pre>
-In this case, it is assumed that an agent exists, but it has not been specified.
-</div>
-
-
-
-
-</section>  <!-- end wasAssociatedWith -->
-
-<section id="term-responsibility">
-
-<h4>Responsibility</h4>
-
-<div class="glossary-ref" data-ref="glossary-responsibility"></div>
-
-<p>PROV offers a mild version of responsibility
-in the form of a relation to represent when an agent acted on another
-agent's behalf.  So for example someone running a mail program,
-the program and the person are both
-agents of the activity; furthermore, the mail software
-agent is running on the person's behalf.  In another example, the
-student acted on behalf of his supervisor, who acted on behalf of the
-department chair, who acted on behalf of the university; all those
-agents are responsible in some way for the activity that took place but
-we do not say explicitly who bears responsibility and to what
-degree. </p>
-
-
-<p>
-<div class="attributes" id="attributes-responsibility">
-A <dfn title="actedOnBehalfOf">responsibility</dfn> link<span class="withPn">, written <span class="pnExpression">actedOnBehalfOf(id;ag2,ag1,a,attrs)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="responsibility.id">id</span>:  an OPTIONAL identifier for the responsibility link between subordinate and responsible;</li> 
-<li><span class='attribute' id="responsibility.subordinate">subordinate</span>: an identifier (<span class="name">ag2</span>) for the agent associated with an activity, acting on behalf of the responsible
-agent;</li>
-<li><span class='attribute' id="responsibility.responsible">responsible</span>: an identifier (<span class="name">ag1</span>) for the agent,  on behalf of which the subordinate agent acted;</li>
-<li><span class='attribute' id="responsibility.activity">activity</span>: an OPTIONAL identifier (<span class="name">a</span>) of an activity for which the responsibility link holds;</li>
-<li><span class='attribute' id="responsibility.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this responsibility link.</li>
-</ul></div>
-
-
-<div class="anexample">
-<p>The following fragment describes three agents: a programmer, a researcher, and a funder.  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 a contractual agreement with the researcher. The terms
-'delegation' and 'contact' used in this example are domain specific.</p>
-<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)
-wasAssociatedWith(a,ag3)
-actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])
-actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
-</pre>
-</div>
-
-
-<!-- too strong, move to part 2.
-<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>
-
-<section id="component3"> 
-<h3>Component 3: Derivations</h3>
-
-
-
-<p>The third component of PROV-DM is concerned with <a title="derivation">derivations</a> of <a title="entity">entities</a> from others, and derivation subtypes <a>Revision</a>, <a>Quotation</a>, <a>Original Source</a>, and <a>Trace</a>.
- <a href="#figure-component3">Figure 7</a> depicts the third component with three  classes (Entity, Activity, and Agent) and associations between them. As before, the yellow are includes PROV core structures, whereas extended structures are found outside this area. UML association classes express expanded n-ary relations.
-</p>
-
-
-<div style="text-align: center;">
-<figure>
-<!-- <img src="images/Derivation.png" alt="derivation"/> -->
-<img src="../uml/component3.svg" alt="derivation"/>
-<figcaption id="figure-component3">Figure 7: Derivation Component Overview</figcaption>
-</figure>
-</div>
-
-<section id="Derivation-Relation">
-<h4>Derivation</h4>
-
-
-
-
-
-<div class="glossary-ref" data-ref="glossary-derivation"></div>
-
-
-
-
-<p>According to <a href="#section-prov-overview">Section 2</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 represent further information about the derivation.  If the derivation is the result of a single known activity, then this activity can also be optionally expressed. To provide a completely accurate description of the derivation, the generation and usage of the generated and used entities, respectively, can be provided.  Optional information such as activity, generation, and usage can be linked to derivations to aid analysis of provenance and to facilitate provenance-based reproducibility. </p>
-
-
-<p><div class="attributes" id="attributes-derivation">A <dfn title="wasDerivedFrom">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> has:
-<ul>
-<li><span class='attribute' id="derivation.id">id</span>:  an OPTIONAL identifier  for a derivation;</li> 
-<li><span class='attribute' id="derivation.generatedEntity">generatedEntity</span>: the identifier (<span class="name">e2</span>) of the entity generated by the derivation;</li>
-<li><span class='attribute' id="derivation.usedEntity">usedEntity</span>: the identifier (<span class="name">e1</span>) of the entity used by the derivation;</li>
-<li><span class='attribute' id="derivation.activity">activity</span>: an OPTIONAL identifier (<span class="name">a</span>) for the activity using and generating the above entities;</li>
-<li><span class='attribute' id="derivation.generation">generation</span>: an OPTIONAL identifier (<span class="name">g2</span>) for the generation involving the generated entity (<span class="name">e2</span>) and activity;</li> 
-<li><span class='attribute' id="derivation.usage">usage</span>: an OPTIONAL identifier (<span class="name">u1</span>) for the usage involving the used entity (<span class="name">e1</span>) and activity;</li> 
-<li><span class='attribute' id="derivation.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this derivation.</li>
-</ul>
-</div>
-
-
-
-<div class="anexample">
-<p>The following descriptions 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>
-<pre class="codeexample">
-wasDerivedFrom(e2, e1)
-wasDerivedFrom(e2, e1, [prov:type="physical transform"])
-</pre>
-<p>The following 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>.</p>
-<pre class="codeexample">
-wasDerivedFrom(e2, e1, a, g2, u1)
-wasGeneratedBy(g2; e2, a, -)
-used(u1; a, e1, -)
-</pre>
-<p>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>
-
-
-
-
-</section>
-
-<section id="term-Revision">
-<h3>Revision</h3>
-
-<p><span class="glossary-ref" data-ref="glossary-revision"></span></p>
-
-<p>Revision is a particular case of <a>derivation</a> of an entity into its revised version.</p>
-
-<p> A <dfn title="wasRevisionOf">revision</dfn> relation<span class="withPn">, written <span class="pnExpression">wasRevisionOf(id; e2, e1, a, g2, u1, attrs)</span> in PROV-N,</span> has:</p>
-<ul>
-<li><span class='attribute' id="revision.id">id</span>: an OPTIONAL identifier for the relation;</li> 
-<li><span class='attribute' id="revision.newer">newer</span>: the identifier (<span class="name">e2</span>) of the revised  entity;
-<li><span class='attribute' id="revision.older">older</span>: the identifier (<span class="name">e1</span>) of the older entity;
-<li><span class='attribute' id="revision.activity">activity</span>: an OPTIONAL identifier (<span class="name">a</span>) for the activity using and generating the above entities;</li>
-<li><span class='attribute' id="revision.generation">generation</span>: an OPTIONAL identifier (<span class="name">g2</span>) for the generation involving the generated entity (<span class="name">e2</span>) and activity;</li> 
-<li><span class='attribute' id="revision.usage">usage</span>: an OPTIONAL identifier (<span class="name">u1</span>) for the usage involving the used entity (<span class="name">e1</span>) and activity;</li> 
-<li><span class='attribute' id="revision.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this relation.</li>
-</ul>
-
-
-
-<div class="anexample" id="anexample-revision">
-<p>
-Revisiting the example of <a href="#section-example-two">Section 3.2</a>,
-we can now state that the report 
- <span class="name">tr:WD-prov-dm-20111215</span> was a revision of 
- the report <span class="name">tr:WD-prov-dm-20111018</span>.
-<pre class="codeexample">
-entity(tr:WD-prov-dm-20111215, [ prov:type='rec54:WD'  ])
-entity(tr:WD-prov-dm-20111018, [ prov:type='rec54:WD'  ])
-wasRevisionOf(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018)
-</pre>
-</div>
-
-
-
-</section>  <!-- end revision -->
-
-<section id="term-quotation">
-<h3>Quotation</h3>
-
-<p> 
-<span class="glossary-ref" data-ref="glossary-quotation"></span>
-</p>
-
-<p>Quotation
- is a particular case of  <a>derivation</a> in which entity <span class="name">e2</span> is derived from an original entity <span class="name">e1</span> by copying, or "quoting", some or all of it.
-  A <dfn title="wasQuotedFrom">quotation</dfn> relation<span class="withPn">, written <span class="pnExpression">wasQuotedFrom(id; e2, e1, a, g2, u1, attrs)</span> in PROV-N,</span> has:</p>
-<ul>
-<li><span class='attribute' id="quotation.id">id</span>: an OPTIONAL identifier for the relation;</li> 
-<li><span class='attribute' id="quotation.quote">quote</span>:  an identifier (<span class="name">e2</span>) for the entity that represents the quote (the partial copy);
-<li><span class='attribute' id="quotation.original">original</span>: an identifier (<span class="name">e1</span>) for the original entity being quoted;
-<li><span class='attribute' id="quotation.activity">activity</span>: an OPTIONAL identifier (<span class="name">a</span>) for the activity using and generating the above entities;</li>
-<li><span class='attribute' id="quotation.generation">generation</span>: an OPTIONAL identifier (<span class="name">g2</span>) for the generation involving the generated entity (<span class="name">e2</span>) and activity;</li> 
-<li><span class='attribute' id="quotation.usage">usage</span>: an OPTIONAL identifier (<span class="name">u1</span>) for the usage involving the used entity (<span class="name">e1</span>) and activity;</li> 
-<li><span class='attribute' id="quotation.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this relation.</li>
-
-</ul>
-
-<div class="anexample" id="anexample-quotation">
-<p>
-The following paragraph is a quote from one of  <a href="http://thinklinks.wordpress.com/2012/03/07/thoughts-from-the-dagstuhl-principles-of-provenance-workshop/">the author's blogs</a>.
-<blockquote id="bl-dagstuhl"><em>
-"During the workshop, it became clear to me that the consensus based models (which are often graphical in nature) can not only be formalized but also be directly connected to these database focused formalizations. I just needed to get over the differences in syntax.  This could imply that we could have nice way to trace provenance across systems and through databases and be able to understand the mathematical properties of this interconnection."</em>
-</blockquote>
-<p>If <a href="http://thinklinks.wordpress.com/2012/03/07/thoughts-from-the-dagstuhl-principles-of-provenance-workshop/"><span class="name">wp:thoughts-from-the-dagstuhl-principles-of-provenance-workshop/</span></a> denotes the original blog by agent <span class="name">ex:Paul</span>, and 
- <a href="#bl-dagstuhl"><span class="name">dm:bl-dagstuhl</span></a> denotes the above paragraph, then the following descriptions express that the above paragraph is copied by agent <span class="name">ex:Luc</span> from a part of the blog, attributed to the agent <span class="name">ex:Paul</span>.</p>
-<pre class="codeexample">
-entity(wp:thoughts-from-the-dagstuhl-principles-of-provenance-workshop/)
-agent(ex:Luc)
-agent(ex:Paul)
-wasQuotedFrom(dm:bl-dagstuhl,wp:thoughts-from-the-dagstuhl-principles-of-provenance-workshop/)
-wasAttributedTo(dm:bl-dagstuhl, ex:Luc)
-wasAttributedTo(wp:thoughts-from-the-dagstuhl-principles-of-provenance-workshop/, ex:Paul)
-</pre>
-
-</div>
-
-
-</section>  <!-- end quotation -->
-
-
-<section id="term-original-source">
-<h3>Original Source</h3>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-original-source"></span>
-</p>
-
-<p>An <dfn>original source</dfn> relation is a particular case of <a>derivation</a> 
-that aims to give
-credit to the source that originated some information. It is recognized that it may be
-hard to determine which entity constitutes an original source. This definition is inspired by
-<span class="name">original-source</span> as defined in
-<a href="http://googlenewsblog.blogspot.com/2010/11/credit-where-credit-is-due.html">http://googlenewsblog.blogspot.com/2010/11/credit-where-credit-is-due.html</a>.</p>
-
-
-<p> An <dfn title="hadOriginalSource">original source</dfn> relation<span class="withPn">, written <span class="pnExpression">hadOriginalSource(id; e2, e1, a, g2, u1, attrs)</span>,</span> has:</p>
-<ul>
-<li><span class='attribute' id="originalSource.id">id</span>:  an OPTIONAL identifier for the relation;</li> 
-<li><span class='attribute' id="originalSource.derived">derived</span>: an identifier (<span class="name">e2</span>) for the derived entity; </li>
-<li><span class='attribute' id="originalSource.source">source</span>: an identifier (<span class="name">e1</span>) for the original source entity;</li>
-<li><span class='attribute' id="originalSource.activity">activity</span>: an OPTIONAL identifier (<span class="name">a</span>) for the activity using and generating the above entities;</li>
-<li><span class='attribute' id="originalSource.generation">generation</span>: an OPTIONAL identifier (<span class="name">g2</span>) for the generation involving the generated entity (<span class="name">e2</span>) and activity;</li> 
-<li><span class='attribute' id="originalSource.usage">usage</span>: an OPTIONAL identifier (<span class="name">u1</span>) for the usage involving the used entity (<span class="name">e1</span>) and activity;</li> 
-<li><span class='attribute' id="originalSource.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this relation.</li>
-</ul>
-
-<div class="anexample">
-<p>
-Let us consider the concept introduced in the current section, identified as <a href="#concept-original-source"><span class="name">dm:concept-original-source</span></a>, and
-the Google page <a href="http://googlenewsblog.blogspot.com/2010/11/credit-where-credit-is-due.html"><span class="name">go:credit-where-credit-is-due.html</span></a>, where the notion original-source was originally described (to the knowledge of the authors).
-<pre class="codeexample">
-entity(dm:concept-original-source)
-entity(go:credit-where-credit-is-due.html)
-hadOriginalSource(dm:concept-original-source,go:credit-where-credit-is-due.html)
-</pre>
-</div>
-
-
-</section>  <!-- end original source -->
-
-<section id="term-trace">
-<h3>Trace</h3>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-trace"></span>
-</p>
-
-
-<p> A trace relation 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> may have been 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 <dfn title="tracedTo">Trace</dfn> relation<span class="withPn">, written <span class="pnExpression">tracedTo(id;e2,e1,attrs)</span> in PROV-N,</span> has:</p>
-<ul>
-<li><span class='attribute' id="trace.id">id</span>:  an OPTIONAL identifier identifying the relation;</li> 
-<li><span class='attribute' id="trace.entity">entity</span>:  an identifier (<span class="name">e2</span>) for an entity;
-<li><span class='attribute' id="trace.ancestor">ancestor</span>: an identifier (<span class="name">e1</span>) for an ancestor entity that the former depends on;
-<li><span class='attribute' id="trace.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this relation.</li>
-</ul>
-<p>We note that the ancestor is allowed to be an agent since agents are entities. </p>
-
-<p>
-<a>Derivation</a> and <a>attribution</a> are particular cases of  trace.
-</p>
-
-<div class="anexample">
-<p>We refer to the example of <a href="#section-example-two">Section 3.1</a>, and specifically to <a href="#prov-a-document2">Figure 3</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> and to
-<span class="name">process: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,process:rec-advance)
-</pre>
-</div>
-
-
-
-
-</section>
-
-</section>
-
-<section id="component4"> 
-<h3>Component 4: Alternate Entities</h3>
-
-
-<p>The fourth component of PROV-DM is concerned with
-relations <a>specialization</a> and <a>alternate</a> between entities.
- <a href="#figure-component4">Figure 8</a> depicts
-the fourth component with a single class and two associations.
-</p>
-
-
-<div style="text-align: center;">
-<figure>
-<!-- <img src="images/Alternates.png" alt="alternates"/> -->
-<img src="../uml/component4.svg" alt="alternates"/>
-<figcaption id="figure-component4">Figure 8: Alternates Component Overview</figcaption>
-</figure>
-</div>
-
-
-
-<p>Two provenance descriptions about the same thing may emphasize differents aspects of that thing.</p>
-<div class="anexample" id="entity-example1">
-<p>User Alice writes an article. In its provenance, she wishes to refer to the precise version of the article with a date-specific URI, as she might edit the article later. Alternatively, user Bob refers to the article in general, independently of its variants over time.</p>
-</div>
-<p>
-The PROV data model introduces relations, called specialization and alternate,
-that allow entities  to be linked together. They are defined as follows. </p>
-
-
-<section id="term-specialization">
-
-<h4>Specialization</h4>
-
-
-<span class="glossary-ref" data-ref="glossary-specialization"></span> 
-
-
-<p>
-Examples of constraints  include a time period, an abstraction, and a context associated with the entity.</p>
-
-
-
-
-<p>
-<div class="attributes" id="attributes-specialization">A <dfn title="specializationOf">specialization</dfn>  relation<span class="withPn">, written <span class="pnExpression">specializationOf(infra, supra)</span> in PROV-N,</span> has:
-
-<ul>
-<li><span class='attribute' id="specialization.specialization">specialization</span>: an identifier (<span class="name">infra</span>) of the specialized entity;</li>
-<li><span class='attribute' id="specialization.generalEntity">generalEntity</span>: an identifier (<span class="name">supra</span>) of the entity that is being specialized.</li>
-</ul>
-</div>
-
-<div class="anexample" id="anexample-specialization">
-<p>
-The BBC news home page on 2012-03-23 <span class="name">ex:bbcNews2012-03-23</span>
-is a specialization of the BBC news page in general
- <a href="http://www.bbc.co.uk/news/">bbc:news/</a>. This can be expressed as follows.
-<pre class="codeexample">
-specializationOf(ex:bbcNews2012-03-23, bbc:news/)
-</pre>
-We have created a new qualified name,  <span class="name">ex:bbcNews2012-03-23</span>, in the namespace <span class="name">ex</span>, to identify the specific page carrying this day's news, which would otherwise be the generic  <span class="name">bbc:news/</span> page.
-</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>
--->
-
-
-
-</section>
-
-<section id="term-alternate">
-
-<h4>Alternate</h4>
-
-
-<span class="glossary-ref" data-ref="glossary-alternate"></span>
-
-
-  
-
-<p><div class="attributes" id="attributes-alternate">An <dfn title="alternateOf">alternate</dfn> relation<span class="withPn">, written <span class="pnExpression">alternateOf(e1, e2)</span> in PROV-N,</span> has:
-<ul>
-<li><span class='attribute' id="alternate.alternate1">alternate1</span>: an identifier (<span class="name">e1</span>) of the first of the two entities;</li>
-<li><span class='attribute' id="alternate.alternate2">alternate2</span>: an identifier (<span class="name">e2</span>) of the second of the two entities.</li>
-</ul>
-</div>
-
-<div class="anexample" id="anexample-alternate">
-<p>
-A given news item on the BBC News site 
- <a href="http://www.bbc.co.uk/news/science-environment-17526723">bbc:news/science-environment-17526723</a> for desktop
-is an alternate of a 
- <a href="http://www.bbc.co.uk/news/mobile/science-environment-17526723">bbc:news/mobile/science-environment-17526723</a> for mobile devices.</p>
-<pre class="codeexample">
-entity(bbc:news/science-environment-17526723, [ prov:type="a news item for desktop"])
-entity(bbc:news/mobile/science-environment-17526723, [ prov:type="a news item for mobile devices"])
-alternateOf(bbc:news/science-environment-17526723, bbc:news/mobile/science-environment-17526723)
-</pre>
-<p>They are both specialization of an (unspecified) entity. </p>
-</div>
-
-
-<div class="anexample" id="anexample-alternate2">
-<p>
-Considering again the two versions of the technical report <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). They are alternate of each other.
-<pre class="codeexample">
-entity(tr:WD-prov-dm-20111018)
-entity(tr:WD-prov-dm-20111215)
-alternateOf(tr:WD-prov-dm-20111018,tr:WD-prov-dm-20111215)
-</pre>
-<p>They are both specialization of the page <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a>.</p>
-</div>
-
-</section>
-</section>
-
-
-<section id="component5"> 
-<h3>Component 5: Bundles</h3>
-
-
-<p>The fifth component of PROV-DM is concerned with bundles, a mechanism to support provenance of provenance. 
-<a href="#figure-component5">Figure 9</a>  depict a UML class diagram for the fifth component.  It comprises a <a>Bundle</a> class, a subclass of <a>Entity</a> and a novel n-ary relation, <a>Provenance Locator</a>.
-</p>
-
-<div style="text-align: center;">
-<figure>
-
-<img src="../uml/component5.svg" alt="bundles"/>
-<figcaption id="figure-component5">Figure 9: Bundle Component Overview</figcaption>
-</figure>
-</div>
-
-
-
-
-<section id="term-bundle"> 
-
-<h3>Bundle constructor</h3>
-
-
-<p>
-<span class="glossary-ref" data-ref="glossary-bundle" >
-</span>
- </p>
-
-
-
-
-<p>
-<div class="attributes" id="attributes-bundle">
- A <dfn title="dfn-bundle" id="dfn-bundle-declaration">bundle constructor</dfn>  allows the content and the name of a bundle to be specified; it is written <span class="pnExpression">bundle id description_1 ... description_n endBundle</span> and consists of:
-<ul>
-<li><span class='attribute' id="bundle.declaration.id">id</span>:  an identifier for the bundle;</li>
-<li><span class='attribute' id="bundle.declaration.descriptions">descriptions</span>: a set of provenance descriptions <span class="name">
-description_1</span>, ..., <span class="name">description_n</span>.</li>
-</ul>
-<p>A bundle's identifier <span class="name">id</span> identifies a unique set of descriptions.</p>
-</section>
-
-
-
-
-
-<section id="term-bundle-entity"> 
-
-<h3>Bundle Description</h3>
-
-<p>A  bundle is a named set of descriptions, but also it is also an entity so that its provenance can be described.  </p>
-
-PROV defines the following type for bundles:
-<ul>
-<li><span class="name">prov:Bundle</span> is the type that denotes <a title="bundle">bundles</a>.
-</ul>
-
-
-<p>
-A  bundle description is of the form <span class="pnExpression">entity(id,[prov:type='prov:Bundle', attr1=val1, ...])</span>
-where <span class='name'>id</span> is  an identifier denoting a bundle,
- a type <span>prov:Bundle</span> and
-an OPTIONAL set of attribute-value  pairs ((<span class="name">attr1</span>, <span class="name">val1</span>), ...) representing additional information about this bundle.
-</p>
-
-
-<p>The provenance of provenance can then be described using PROV constructs, as illustrated by the following example. </p>
-
-<div class="anexample" id="anexample-provenance-of-provenance">
-<p>Let us consider an example consisting of two entities <span class="name">ex:report1</span> and <span class="name">ex:report2</span>.</p>
-<pre class="codeexample"> 
-entity(ex:report1, [ prov:type="report", ex:version=1 ])
-wasGeneratedBy(ex:report1, -, 2012-05-24T10:00:01)
-entity(ex:report2, [ prov:type="report", ex:version=2])
-wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-wasDerivedFrom(ex:report2, ex:report1)
-</pre>
-
-<p>Let us assume that Bob observed the creation of <span class="name">ex:report1</span>.
-A first bundle can be expressed.</p>
-<pre class="codeexample"> 
-bundle bob:bundle1
-  entity(ex:report1, [ prov:type="report", ex:version=1 ])
-  wasGeneratedBy(ex:report1, -, 2012-05-24T10:00:01)
-endBundle
-</pre>
-
-<p>In contrast,
-Alice observed the creation of <span class="name">ex:report2</span> and its derivation from <span class="name">ex:report1</span>.
-A separate bundle can also be expressed.</p>
-<pre class="codeexample"> 
-bundle alice:bundle2
-  entity(ex:report1)
-  entity(ex:report2, [ prov:type="report", ex:version=2 ])
-  wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-  wasDerivedFrom(ex:report2, ex:report1)
-endBundle
-</pre>
-
-<p>The first bundle contains the descriptions corresponding to  Bob observing the creation of <span class="name">ex:report1</span>. Its provenance can be described as follows.</p>
-<pre class="codeexample"> 
-entity(bob:bundle1, [prov:type='prov:Bundle'])
-wasGeneratedBy(bob:bundle1, -, 2012-05-24T10:30:00)
-wasAttributedTo(bob:bundle1, ex:Bob)
-</pre>
-
-<p>In contrast, the second bundle is attributed to Alice who
-observed the derivation of <span class="name">ex:report2</span> from <span class="name">ex:report1</span>.</p>
-<pre class="codeexample"> 
-entity(alice:bundle2, [ prov:type='prov:Bundle' ])
-wasGeneratedBy(alice:bundle2, -, 2012-05-25T11:15:00)
-wasAttributedTo(alice:bundle2, ex:Alice)
-</pre>
-</div>
-
-<div class="anexample" id="anexample-provenance-aggregation">
-<p>A provenance aggregator could merge two bundles, resulting in a novel bundle, whose provenance is described as follows.</p>
-<pre class="codeexample"> 
-bundle agg:bundle3
-  entity(ex:report1, [ prov:type="report", ex:version=1 ])
-  wasGeneratedBy(ex:report1, -, 2012-05-24T10:00:01)
-
-  entity(ex:report2, [ prov:type="report", ex:version=2 ])
-  wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-  wasDerivedFrom(ex:report2, ex:report1)
-endBundle
-
-entity(agg:bundle3, [ prov:type='prov:Bundle' ])
-agent(ex:aggregator01, [ prov:type='ex:Aggregator' ])
-wasAttributedTo(agg:bundle3, ex:aggregator01)
-wasDerivedFrom(agg:bundle3, bob:bundle1)
-wasDerivedFrom(agg:bundle3, alice:bundle2)
-</pre>
-<p>The new bundle is given a new identifier <span class="name">agg:bundle3</span> and is attributed to the <span class="name">ex:aggregator01</span> agent.
-</div>
-
-
-</section>
-
-<section id="term-hasProvenanceIn"> 
-
-<h3>Provenance Locator</h3>
-
-
-In <a href="#anexample-provenance-of-provenance">Example anexample-provenance-of-provenance</a>, we initially presented a scenario involving two entities <span class="name">report1</span> and <span class="name">report2</span>, and showed how the descriptions can be organized into two bundles.  There is no explicit indication that the second bundle "continues" the description offered by the first bundle.  Given that bundles may be retrieved separately [[PROV-AQ]], it is not obvious for a provenance consumer to navigate descriptions across bundles.  To aid consumers,
- Alice may wish to express that there is further provenance information about <span class="name">report1</span> in bundle <span class="name">bob:bundle1</span>.  To this end, PROV introduces the notion of provenance locator, inspired by [[PROV-AQ]].
-
-
-<p><div class="glossary-ref" data-ref="glossary-provenance-locator"></div></p>
-
-
-<div class="attributes" id="attributes-hasProvenanceIn">
-A <dfn title="hasProvenanceIn">provenance locator</dfn>,
-written
-<span class="pnExpression">hasProvenanceIn(id, subject, bundle, target, service, prov, attrs)</span>, has:
-<ul>
-<li><span class='attribute' id="prov.locator.id">id</span>: an identifier for a provenance locator; </li>
-<li><span class='attribute' id="prov.locator.subject">subject</span>:  an identifier denoting something (entity, activity, agent, or relation instance);</li>
-<li><span class='attribute' id="prov.locator.bundle">bundle</span>:  an OPTIONAL identifier (<span class="name">bundle</span>) for a bundle;
-<li><span class='attribute' id="prov.locator.target">target</span>:  an OPTIONAL identifier (<span class="name">target</span>) denoting  something described in another set of descriptions (referred to as <a href="http://www.w3.org/TR/prov-aq/#dfn-target-uri">Target-URI</a> in [[PROV-AQ]]);
-<li><span class='attribute' id="prov.locator.service">service-uri</span>:  an OPTIONAL URI (<span class="name">service</span>) denoting a <a href="http://www.w3.org/TR/prov-aq/#dfn-provenance-service">provenance service</a> from which provenance can be retrieved (referred to as <a href="http://www.w3.org/TR/prov-aq/#dfn-service-uri">Service-URI</a> in [[PROV-AQ]]);
-<li><span class='attribute' id="prov.locator.provenance">provenance-uri</span>:  an OPTIONAL URI (<span class="name">prov</span>), which when dereferenced, allows access to provenance descriptions (referred to as <a href="http://www.w3.org/TR/prov-aq/#dfn-provenance-uri">Provenance-URI</a> in [[PROV-AQ]]);
-<li><span class='attribute' id="prov.locator.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this locator.</li>
-</ul>
-<p>In <span class="pnExpression">hasProvenanceIn(id, subject, bundle, target, service, prov, attrs)</span>, <span class="name">service</span> and <span class="name">prov</span> are both optional and mutually exclusive: if specified, either <span class="name">service</span> or <span class="name">prov</span> is provided.</p>
-</div>
-
-<p>A provenance locator specifies a context, referred to
-as <em>located context</em> in which further descriptions can be found
-about something.</p>
-
-<div class="note">
-It is suggested that prov:service-uri and prov:provenance-uri should be made optional reserved attributes.
-In the target is not specified, it is assumed that the target is the same identifier as subject.
-</div>
-
-<p>When the subject and optional target denote entities,
-a provenance locator not only provides a located context, but it also expresses an <a>alternate</a> relation between the entity denoted by <span class="name">subject</span> and the  entity described in the located context. This is a alternate since the entity denoted by <span class="name">subject</span> in the current context presents other aspects than the entity in the located one.</p>
-
-<div class="anexample" id="anexample-provenance-locator">
-<p>According to the following provenance locator, provenance descriptions about <span class="name">ex:report1</span> can be found in bundle <span class="name">bob:bundle1</span>.</p>
-<pre class="codeexample"> 
-hasProvenanceIn(ex:report1, bob:bundle1, -, -, -)
-</pre>
-<p>According to the following provenance locator, provenance descriptions about <span class="name">ex:report1</span> can be found in bundle <span class="name">bob:bundle1</span>, which is available from the provenance service identified by the provided URI.</p>
-<pre class="codeexample"> 
-hasProvenanceIn(ex:report1, bob:bundle1, -, "http://example.com/service"^xsd:anyURI, -)
-</pre>
-<p>According to the following provenance locator, provenance descriptions about <span class="name">ex:report1</span> can be found in resource identified by the provided URI.</p>
-<pre class="codeexample"> 
-hasProvenanceIn(ex:report1, -, -, -, "http://example.com/some-provenance.pn"^xsd:anyURI)
-</pre>
-</div>
-
-
-<div class="anexample" id="anexample-provenance-locator2">
-<p>Let us again consider the same scenario involving two entities <span class="name">ex:report1</span> and <span class="name">ex:report2</span>.</p>
-<p>The first bundle can be expressed with all Bob's observations about the creation of <span class="name">ex:report1</span>.
-</p>
-<pre class="codeexample"> 
-bundle bob:bundle4
-  entity(ex:report1, [ prov:type="report", ex:version=1 ])
-  wasGeneratedBy(ex:report1, -, 2012-05-24T10:00:01)
-endBundle
-</pre>
-
-<p>Likewise, Alice's observation about the derivation of  <span class="name">ex:report2</span>  from <span class="name">ex:report1</span>, is expressed in a separate bundle.</p>
-<pre class="codeexample"> 
-bundle alice:bundle5
-  entity(ex:report1)
-  hasProvenanceIn(ex:report1, bob:bundle4, -, -, -)
-  entity(ex:report2, [ prov:type="report", ex:version=2 ])
-  wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-  wasDerivedFrom(ex:report2, ex:report1)
-endBundle
-</pre>
-<p>In bundle <span class="name">alice:bundle5</span>, there is a description for entity <span class="name">ex:report1</span>, and 
-a provenance locator pointing to bundle <span class="name">bob:bundle4</span>.  
-The locator indicates that some provenance description for <span class="name">ex:report1</span> can be found in bundle <span class="name">bob:bundle4</span>. The purpose of the locator is twofold. First, it allows for <a href="http://www.w3.org/TR/prov-aq/#incremental-provenance-retrieval">incremental navigation</a> of provenance [[PROV-AQ]].  Second, it makes entity <span class="name">ex:report1</span> described in <span class="name">alice:bundle5</span> an <a>alternate</a> of <span class="name">ex:report1</span> described in <span class="name">bob:bundle4</span>.
-</p>
-</div>
-
-
-<div class="anexample" id="anexample-provenance-locator3">
-<p>Alternatively, Alice may have decided to use a different identifier for <span class="name">ex:report1</span>.</p>
-<pre class="codeexample"> 
-bundle alice:bundle6
-  entity(alice:report1)
-  hasProvenanceIn(alice:report1, bob:bundle4, ex:report1, -, -)
-  entity(ex:report2, [ prov:type="report", ex:version=2 ])
-  wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
-  wasDerivedFrom(ex:report2, alice:report1)
-endBundle
-</pre>
-<p>Alice can specify the <a href="#prov.locator.target">target</a> in the provenance locator to be  <span class="name">ex:report1</span>.
-With such a statement, Alice states that provenance information about <span class="name">alice:report1</span> can be found in bundle
-<span class="name">bob:bundle4</span> under the name <span class="name">ex:report1</span>.  In effect, <span class="name">alice:report1</span> and <span class="name">ex:report1</span> are declared to be alternate.</p>
-</div>
-
-<div class="anexample" id="aexample-note">
-<p>Consider that the following bundle of descriptions, in which derivation and generations have been identified.
-<pre class="codeexample"> 
-bundle obs:bundle7
-  entity(ex:report1, [prov:type="report", ex:version=1])
-  wasGeneratedBy(ex:g1; ex:report1,-,2012-05-24T10:00:01)
-  entity(ex:report2, [prov:type="report", ex:version=2])
-  wasGeneratedBy(ex:g2; ex:report2,-,2012-05-25T11:00:01)
-  wasDerivedFrom(ex:d; ex:report2, ex:report1)
-endBundle
-entity(obs:bundle7, [ prov:type='prov:Bundle' ])
-wasAttributedTo(obs:bundle7, ex:observer01)
-</pre>
-Bundle <span class="name">obs:bundle7</span> is rendered by a visualisation tool.  It may useful for the tool configuration for this bundle to be shared along with the provenance descriptions, so that other users can render provenance as it was originally rendered.  The original  bundle obviously cannot be changed. However, one can create a new bundle, as follows.
-<pre class="codeexample"> 
-bundle tool:bundle8
-  entity(tool:bundle8, [ prov:type='viz:Configuration', prov:type='prov:Bundle' ])
-  wasAttributedTo(tool:bundle8, viz:Visualizer)
-
-  entity(ex:report1, [viz:color="orange"])
-  hasProvenanceIn(ex:report1, obs:bundle7, -, -, -)
-
-  entity(ex:report2, [viz:color="blue"])
-  hasProvenanceIn(ex:report2, obs:bundle7, -, -, -)
-
-  wasDerivedBy(ex:d; ex:report2, ex:report1, [viz:style="dotted"])
-  hasProvenanceIn(ex:d, obs:bundle7, -, -, -)
-endBundle
-</pre>
-
-<p>In bundle <span class="name">tool:bundle8</span>, the prefix <span class="name">viz</span> is used for naming visualisation-specific attributes, types or values.</p>
-
-<p>Bundle <span class="name">tool:bundle8</span> is given type <span class="name">viz:Configuration</span> to indicate that it consists of descriptions that pertain to the configuration of the visualisation tool. This type attribute can be used for searching bundles containing visualization-related descriptions.
-</p>
-
-<p>Alternates of the entities <span class="name">ex:report1</span> and <span class="name">ex:report2</span> have a visualization attribute for the color to be used when rendering these entities. 
-Likewise, the derivation has a style attribute. </p>
-
-<p>According to their definition,
-derivations have an <a href="#derivation.id">optional identifier</a>. 
-To express an alternate for a derivation, we need to be able to reference it, by means of an identifier. Hence, it is necessary for it to have an identifier in the first place (<span class="name">ex:d</span>).</p>
-</div>
-
-</section>
-</section> 
-
-
-
-<section id="component6"> 
-<h3>Component 6: Collections</h3>
-
-<p>The fifth component of PROV-DM is concerned with the notion of collections. 
-A collection is an entity that has some members. The members are themselves entities, and therefore their provenance can be expressed. Some applications need to be able to express the provenance of the collection  itself: e.g. who maintains the collection, which members it contains as it evolves, and how it was assembled. The purpose of Component 5 is to define the types and relations that are useful to express the provenance of collections. In PROV, the concept of Collection is implemented by means of dictionaries, which we introduce in this section. </p>
-
-<p><a href="#figure-component6">Figure 10</a> depicts
-the sixth component with three new classes (Collection, Dictionary, and Pair) and three associations (insertion, removal, and memberOf).
-</p>
-
-
-<div style="text-align: center;">
-<figure>
-<!-- <img src="images/Dictionaries.png" alt="dictionaries"/> -->
-<img src="../uml/component6.svg" alt="dictionaries"/>
-
-<figcaption id="figure-component6">Figure 10: Collections Component Overview</figcaption>
-</figure>
-</div>
-
-
-<p>The intent of these relations and types is to express the <em>history of changes that occurred to a collection</em>. 
-Changes to collections are about the insertion of entities in collections and the removal of members from collections.
-Indirectly, such history provides a way to reconstruct the contents of a collection.</p>
-
-<section id="term-collection">
-<h3>Collection</h3>
-
-<span class="glossary-ref" data-ref="glossary-collection"></span>
-
-<p>In PROV, the concept of Collection is  provided as an extensibility point for other kinds of collections. Collections are implemented by means of dictionaries, which are introduced next. </p>
-
-</section>
-
-<section id="term-dictinonary">
-<h3>Dictionary</h3>
-
-
-<p>PROV-DM defines a specific type of collection: a dictionary, specified as follows.</p>
-
-
-<span class="glossary-ref" data-ref="glossary-dictionary"></span>
-
-<p>Conceptually, a dictionary has a logical structure consisting of key-entity pairs. This structure is often referred to as a <em>map</em>, and is a generic indexing mechanism that can abstract 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.</p>
-
-<p>A given dictionary forms a given structure for its members.  A different structure (obtained either by insertion or removal of members) constitutes a different dictionary. Hence,
- for the purpose of provenance, a dictionary entity is viewed as a snapshot of a structure. Insertion and removal operations result in new snapshots, each snapshot forming an identifiable dictionary entity.</p>
-
-
-<p>PROV-DM defines the following types related to dictionaries:</p>
-
-<ul>
-  <li> <span class="name">prov:Dictionary</span>  denotes an entity of type dictionary, i.e. an entity that  can participate in  relations amongst dictionaries;
-
-  <li><span class="name">prov:EmptyDictionary</span> denotes an empty dictionary.
-</ul>
-
-
-
-
-
-<!--
-In addition, the attribute  <span class="name">prov:content</span> is introduced to allow the explicit specification of the dictionary's content. The example below illustrates the syntax.
--->
-
-<div class="anexample">
-<pre class="codeexample">
-entity(d0, [prov:type='prov:EmptyDictionary' ])  // d0 is an empty dictionary
-entity(d1, [prov:type='prov:Dictionary'  ])      // d1 is a dictionary, with unknown content
-</pre>
-</div>
-
-
-
-</section>  <!-- end of dictionary-types -->
-
-
-<section id="term-dictionary-insertion">
-<h3>Insertion</h3>
-
-<span class="glossary-ref" data-ref="glossary-insertion"></span>
-
-
-
-
-
-<p><div class="attributes" id="attributes-derivedByInsertionFrom">
-<p>An <dfn title="derivedByInsertionFrom">Insertion</dfn> relation<span class="withPn">, written <span class="pnExpression">derivedByInsertionFrom(id; d2, d1, {(key_1, e_1), ..., (key_n, e_n)}, attrs)</span>,</span> has:</p>
-<ul>
-<li><span class='attribute' id="derivedByInsertionFrom.id">id</span>:  an OPTIONAL identifier identifying the relation;</li>
-<li><span class='attribute' id="derivedByInsertionFrom.after">after</span>: an identifier (<span class="name">d2</span>) for the dictionary <em>after</em> insertion; </li>
-<li><span class='attribute' id="derivedByInsertionFrom.before">before</span>: an identifier (<span class="name">d1</span>) for the dictionary <em>before</em> insertion;</li>
-<li><span class='attribute' id="derivedByInsertionFrom.key-entity-set">key-entity-set</span>: the inserted key-entity pairs <span class="name">(key_1, e_1)</span>, ..., <span class="name">(key_n, e_n)</span> in which each <span class="name">key_i</span> is a <a>value</a>, and <span class="name">e_i</span> is an identifier  for the entity that has been inserted with the key;
- each <span class="name">key_i</span> is expected to be unique for the key-entity-set;
-</li>
-<li><span class='attribute' id="derivedByInsertionFrom.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this relation.</li>
-</ul>
-</div>
-
-<p>
-An Insertion relation <span class="name">derivedByInsertionFrom(id; d2, d1,  {(key_1, e_1), ..., (key_n, e_n)})</span> states that  <span class="name">d2</span> is the state of the dictionary
-following the insertion of pairs <span class="name">(key_1, e_1)</span>, ..., <span class="name">(key_n, e_n)</span> into dictionary  <span class="name">d1</span>.</p>
-
-
-
-
-
-
-<div class="anexample">
-<pre class="codeexample">
-entity(d0, [prov:type='prov:EmptyDictionary' ])    // d0 is an empty dictionary
-entity(e1)
-entity(e2)
-entity(e3)
-entity(d1, [prov:type='prov:Dictionary' ])
-entity(d2, [prov:type='prov:Dictionary' ])
-
-derivedByInsertionFrom(d1, d0, {("k1", e1), ("k2", e2)})       
-derivedByInsertionFrom(d2, d1, {("k3", e3)})    
-</pre>
-From this set of descriptions, we conclude:
-<ul>
-<li>   <span class="name">d0</span> is the set <span class="name">{  }</span>
-<li>   <span class="name">d1</span> is the set <span class="name">{ ("k1", e1), ("k2", e2) }</span>
-<li>   <span class="name">d2</span> is the set <span class="name">{ ("k1", e1), ("k2", e2), ("k3", e3) }</span>
-</ul>
-</div>
-
-<p>Insertion provides an "update semantics" for the keys that are already present in a dictionary,
-since a new pair replaces an existing pair with the same key in the new dictionary. This is illustrated by the following example.</p>
-
-<div class="anexample">
-<pre class="codeexample">
-entity(d0, [prov:type='prov:EmptyDictionary' ])    // d0 is an empty dictionary
-entity(e1)
-entity(e2)
-entity(e3)
-entity(d1, [prov:type='prov:Dictionary' ])
-entity(d2, [prov:type='prov:Dictionary' ])
-
-derivedByInsertionFrom(d1, d0, {("k1", e1), ("k2", e2)})       
-derivedByInsertionFrom(d2, d1, {("k1", e3)})    
-</pre>
-   This is a case of <em>update</em> of <span class="name">e1</span> to <span class="name">e3</span> for the same key, <span class="name">"k1"</span>. <br/>
-  From this set of descriptions, we conclude:
-<ul>
-<li>   <span class="name">d0</span> is the set <span class="name">{  }</span>
-<li>   <span class="name">d1</span> is the set <span class="name">{ ("k1", e1), ("k2", e2) }</span>
-<li>   <span class="name">d2</span> is the set <span class="name">{ ("k1", e3), ("k2", e2) }</span>
-</ul>
-</div>
-
-</section>  <!-- insertion -->
-
-
-<section id="term-dictionary-removal">
-<h3>Removal</h3>
-
-<span class="glossary-ref" data-ref="glossary-removal"></span>
-
-
-
-
-<p>
-<div class="attributes" id="attributes-derivedByRemovalFrom">
-<p> A <dfn title="derivedByRemovalFrom">Removal</dfn> relation, written <span class="pnExpression">derivedByRemovalFrom(id; d2, d1, {key_1, ... key_n}, attrs)</span>, has:</p>
-<ul>
-<li><span class='attribute' id="derivedByRemovalFrom.id">id</span>:  an OPTIONAL identifier identifying the relation;</li>
-<li><span class='attribute' id="derivedByRemovalFrom.after">after</span>: an identifier (<span class="name">d2</span>) for the dictionary  <em>after</em> the deletion; </li>
-<li><span class='attribute' id="derivedByRemovalFrom.before">before</span>: an identifier (<span class="name">d1</span>)  for the dictionary <em>before</em> the deletion;</li>
-<li><span class='attribute' id="derivedByRemovalFrom.key-set">key-set</span>: a set of deleted keys  <span class="name">key_1</span>, ..., <span class="name">key_n</span>, for which each <span class="name">key_i</span> is a <a>value</a>;</li>
-<li><span class='attribute' id="derivedByRemovalFrom.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this relation.</li>
-</ul>
-</div>
-
-<p>A Removal relation <span class="name">derivedByRemovalFrom(id; d2,d1, {key_1, ..., key_n})</span> states that  <span class="name">d2</span> is  the  state of the dictionary following the removal of the set of pairs corresponding to keys  <span class="name">key_1...key_n</span> from  <span class="name">d1</span>.
-
-<div class="anexample">
-<pre class="codeexample">
-entity(d0, [prov:type="prov:EmptyDictionary"])    // d0 is an empty dictionary
-entity(e1)
-entity(e2)
-entity(e3)
-entity(d1, [prov:type="prov:Dictionary"])
-entity(d2, [prov:type="prov:Dictionary"])
-
-derivedByInsertionFrom(d1, d0, {("k1", e1), ("k2",e2)})       
-derivedByInsertionFrom(d2, d1, {("k3", e3)})
-derivedByRemovalFrom(d3, d2, {"k1", "k3"})   
-</pre>
-From this set of descriptions, we conclude:
-<ul>
-<li><span class="name">d0</span> is the set <span class="name">{  }</span>
-<li><span class="name">d1</span> is the set <span class="name">{ ("k1", e1), ("k2", e2)  }</span>
-<li><span class="name">d2</span> is the set <span class="name">{ ("k1", e1), ("k2", e2), ("k3", e3) }</span>
-<li><span class="name">d3</span> is the set <span class="name">{ ("k2", e2) }</span>
-</ul>
-
-  
-</div>
-
-</section>  <!-- removal -->
-
-
-<section id="term-dictionary-membership">
-<h3>Membership</h3>
-
-
-<span class="glossary-ref" data-ref="glossary-membership"></span>
-
-<p>
-The insertion and removal  relations make insertions and removals explicit as part of the history of a dictionary. This, however, requires explicit mention of the state of the dictionary prior to each operation. The membership relation removes this need, allowing the state of a dictionary <span class="name">c</span> to be expressed without having to introduce a prior state.</p>
-
-<p>
-<div class="attributes" id="attributes-memberOf">
- A <dfn title="memberOf">membership</dfn> relation, written <span class="pnExpression">memberOf(id; c, {(key_1, e_1), ..., (key_n, e_n)}, cplt, attrs)</span>, has:
-<ul>
-<li><span class='attribute' id="memberOf.id">id</span>:  an OPTIONAL identifier identifying the relation;</li>
-<li><span class='attribute' id="memberOf.after">after</span>: an identifier (<span class="name">c</span>) for the dictionary whose members are asserted; </li>
-<li><span class='attribute' id="memberOf.key-entity-set">key-entity-set</span>: a set of key-entity pairs <span class="name">(key_1, e_1)</span>, ..., <span class="name">(key_n, e_n)</span> that are members of the dictionary;</li>
-<li><span class='attribute' id="memberOf.complete">complete</span>: an OPTIONAL boolean 
-<a title="value">Value</a> (<span class="name">cplt</span>); if true, it indicates that no other member belongs to the dictionary;  if false, it indicates that other members belong to the dictionary; if unspecified, other members MAY belong to the dictionary.
-<li><span class='attribute' id="memberOf.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this relation.</li>
-</ul>
-</div>
-
-
-
-
-<p>The description <span class="name">memberOf(c, {(key_1, e_1), ..., (key_n, e_n)})</span> states that  <span class="name">c</span> is known to include <span class="name">(key_1, e_1)</span>, ..., <span class="name">(key_n, e_n)}</span>, without having to introduce a previous state. </p>
-
-<div class="anexample">
-<pre class="codeexample">
-entity(d1, [prov:type='prov:Dictionary'  ])    // d1 is a dictionary, with unknown content
-entity(d2, [prov:type='prov:Dictionary'  ])    // d2 is a dictionary, with unknown content
-
-entity(e1)
-entity(e2)
-
-memberOf(d1, {("k1", e1), ("k2", e2)} )  
-memberOf(d2, {("k1", e1), ("k2", e2)}, true)  
-
-entity(e3)
-entity(d3, [prov:type='prov:Dictionary'  ])
-
-derivedByInsertionFrom(d3, d1, {("k3", e3)})     
-</pre>
-From these descriptions, we conclude:
-<ul>
-<li> <span class="name">d1</span>  has  the following pairs as members: <span class="name">("k1", e1), ("k2", e2)</span>, and may contain others.
-<li> <span class="name">d2</span>  exactly has  the following pairs as members: <span class="name">("k1", e1), ("k2", e2)</span>, and does not contain any other.
-<li> <span class="name">d3</span> has  the following pairs as members: <span class="name">("k1", e1), ("k2", e2), ("k3", v3)</span>, and may contain others.
-</ul>
-<p> Thus, the states of <span class="name">d1</span> and <span class="name">d3</span> are only partially known.</p>
-</div>
-
-<!-- To go to part 2
-
-
-  Note that the following one cannot have at the same time an empty dictionary and membership relations for it, i.e., the following example is invalid:
-<pre class="codeexample">
-  <span class="name"> entity(c, [prov:type="EmptyDictionary"])</span>
-   memberOf(c, {("k1", e1), ("k2", v2)} )  
-  </pre>
-
-
--->
-
-</section>  <!-- Membership -->
-
-
-
-<p>Further considerations: </p>
-
-<ul>
-
-<li>The state of a dictionary (i.e., the set of key-entity 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">emptyDictionary</span> can be used in this context as it marks the start of a sequence of dictionary operations.</li>
-
-
-<li>The representation of a dictionary through these relations makes no assumption regarding the underlying data structure used to store and manage dictionaries. 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 dictionaries. This is reflected in the constraints listed in [[PROV-CONSTRAINTS]].  </li>
-</ul>
-
-  
-</section>   <!-- end dictionaries-->
-
-
-
-
-
-<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 [[!IRI]]. In PROV-DM, attributes, identifiers, and values 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. </p>
-
-<p>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 <dfn title="prov-namespace">PROV namespace</dfn> is identified by the URI <a href="http://www.w3.org/ns/prov#">http://www.w3.org/ns/prov#</a>.</p>
-
-</section>
-
-<section id="term-qualified-name">
-<h4>Qualified Name</h4>
-
-
-<span class="glossary-ref" data-ref="glossary-qualifiedName"></span>
-
-<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-identifier">
-<h4>Identifier</h4>
-
-<p>
-An <dfn id="dfn-identifier">identifier</dfn> is a <a>qualified
- name</a>. 
-</p>
-
-</section>
-
-<section id="term-attribute">
-<h4>Attribute</h4>
-
-<p>An <dfn title="dfn-attribute" id="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 title="prov-namespace">PROV namespace</a>, which we define below. 
-This specification does not provide any interpretation for any attribute declared in any other namespace.</p>
-
-<div id="attributes-at-a-glance-div" style="text-align: left;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="attributes-at-a-glance">Table 5: PROV-DM Attributes At a Glance</caption>
-<tr><td><b>Attribute</b></td><td><b>value</b></td><td><b>Section</b></td></tr> 
-<tr><td>prov:label</td><td>xsd:string</td><td>Section <a href="#term-attribute-label">4.7.4.1</a> </td></tr>
-<tr><td>prov:location</td><td><a title="value">Value</a></td><td>Section <a href="#term-attribute-location">4.7.4.2</a> </td></tr>
-<tr><td>prov:role</td><td><a title="value">Value</a></td><td>Section <a href="#term-attribute-role">4.7.4.3</a> </td></tr>
-<tr><td>prov:type</td><td><a title="value">Value</a></td><td>Section <a href="#term-attribute-type">4.7.4.4</a> </td></tr>
-<tr><td>prov:value</td><td><a title="value">Value</a></td><td>Section <a href="#term-attribute-value">4.7.4.5</a> </td></tr>
-</table>
-</div>
-
-
-
-
-
-<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="anexample">
-<p>The following entity is provided with a label attribute.</p>
-<pre class="codeexample">
- entity(ex:e1, [prov:label="This is a label"])
-</pre>
-</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 a reserved attribute. </p> 
-
-
-<p>
-The attribute <span class="name">prov:location</span> is an OPTIONAL attribute of entity, activity, usage, and generation.  The value associated with the  attribute <span class="name">prov:location</span> MUST be a PROV-DM <a title="value">Value</a>, 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 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 <a>usage</a>, <a>generation</a>,
- <a>association</a>,  <a>start</a>, and  <a>end</a>. 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="value">Value</a>.</p>
-
-<div class="anexample">
-<p>The following activity is associated with an agent acting as the operator. </p>
-<pre class="codeexample">
- wasAssociatedWith(a, ag, [prov:role="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 <a title="value">Value.</a> 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' ])
-</pre>
-</div>
-
-<p>The following types are pre-defined in PROV, and are valid values for the <span class="name">prov:type</span> attribute.</p>
-<ul>
-<li><span class="name">prov:Plan</span></li>
-
-<li><span class="name">prov:Account</span></li>
-
-<li><span class="name">prov:SoftwareAgent</span></li>
-
-<li><span class="name">prov:Organization</span></li>
-
-<li><span class="name">prov:Person</span></li>
-
-<li><span class="name">prov:Collection</span></li>
-
-<li><span class="name">prov:Dictionary</span></li>
-
-<li><span class="name">prov:EmptyDictionary</span></li>
-
-</ul>
-
-</section>
-
-
-<section id="term-attribute-value">
-<h4>prov:value</h4>
-
-<p>The attribute <dfn title="dfn-value"><span class="name">prov:value</span></dfn>  provides a <a title="value">Value</a> associated with an entity.</p>
-
-
-<p>The attribute <span class="name">prov:value</span> is an OPTIONAL attribute of entity.  The value associated with the  attribute <span class="name">prov:value</span> MUST be a PROV-DM <a title="value">Value</a>. The attribute <span class="name">prov:value</span> MAY occur at most once in a set of attribute-value pairs.</p>
-
-<div class="anexample">
-<p>The following example illustrates the provenance of the number <span class="name">4</span> obtained by an activity that computed the length of an input string <span class="name">"abcd"</span>.
-The input and the output are expressed as entities <span class="name">ex:in</span> and <span class="name">ex:out</span>, respectively. They each have a <span class="name">prov:value</span> attribute associated with the corresponding value.
-</p>
-<pre class="codeexample">
-entity(ex:in, [prov:value="abcd"]) 
-entity(ex:out, [prov:value=4]) 
-activity(ex:len, [prov:type="string-length"])
-used(ex:len,ex:in)
-wasGeneratedBy(ex:out,ex:len)
-wasDerivedFrom(ex:out,ex:in)
-</pre>
-</div>
-
-<div class="note">Should we also have prov:encoding?</div>
-
-</section>
-
-
-
-
-
-
-
-
-</section>
-
-<section id="term-value">
-<h4>Value</h4>
-
-<p>
-By means of attribute-value pairs, the PROV data model can refer to <dfn title="value">values</dfn> such as strings, numbers, time, qualified names, and IRIs.  
-The interpretation of such values is outside the scope of PROV-DM.</p>
-<p>Each kind of such values is called a <em>datatype</em>. The datatypes are taken from 
-the set of XML Schema Datatypes, version 1.1 [[!XMLSCHEMA-2]] and the RDF specification [[!RDF-CONCEPTS]]. The normative definitions of these datatypes are provided by the respective specifications. 
-Each datatype is identified by its XML <a href="http://www.w3.org/TR/xmlschema-2/#QName">xsd:QName</a>.</p>
-
-<p>
-</p>
-
-<p>We note that PROV-DM <dfn title="dfn-time">time instants</dfn> are defined according to xsd:dateTime [[!XMLSCHEMA-2]].</p> 
-
-
-
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="prov-dm-data-types">Table 6: PROV-DM Data Types</caption>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#decimal">xsd:decimal</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#double">xsd:double</a></td>  <td><a href="http://www.w3.org/TR/xmlschema-2/#dateTime">xsd:dateTime</a></td> </tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#integer">xsd:integer</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#float">xsd:float</a></td><td><a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-XMLLiteral">rdf:XMLLiteral</a></td>  </tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#nonNegativeInteger">xsd:nonNegativeInteger</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#string">xsd:string</a></td> <td><a href="http://www.w3.org/TR/prov-n/#prod-QUALNAME">prov:QUALNAME</a></td> </tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#nonPositiveInteger">xsd:nonPositiveInteger</a></td><td><a href="http://www.w3.org/TR/xmlschema-2/#normalizedString">xsd:normalizedString</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#positiveInteger">xsd:positiveInteger</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#token">xsd:token</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#negativeInteger">xsd:negativeInteger</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#language">xsd:language</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#long">xsd:long</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#Name">xsd:Name</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#int">xsd:int</a></td>  <td><a href="http://www.w3.org/TR/xmlschema-2/#NCName">xsd:NCName</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#short">xsd:short</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#NMTOKEN">xsd:NMTOKEN</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#byte">xsd:byte</a></td>  <td><a href="http://www.w3.org/TR/xmlschema-2/#boolean">xsd:boolean</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#unsignedLong">xsd:unsignedLong</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#hexBinary">xsd:hexBinary</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#unsignedInt">xsd:unsignedInt</a></td>  <td><a href="http://www.w3.org/TR/xmlschema-2/#base64Binary">xsd:base64Binary</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#unsignedShort">xsd:unsignedShort</a></td><td><a href="http://www.w3.org/TR/xmlschema-2/#anyURI">xsd:anyURI</a></td> <td></td></tr>
-<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#unsignedByte">xsd:unsignedByte</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#QName">xsd:QName</a></td><td></td></tr>
-</table>
-
-
-
-
-
-
-<div class="anexample" id="anexample-value">
-<p>
-The following examples respectively are 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 value 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>
-
-
-
-<div class="anexample" id="anexample-time">
-<p>
-In the following example, the generation time of entity <span class="name">e1</span> is expressed according to 
-<a href="http://www.w3.org/TR/xmlschema-2/#dateTime">xsd:dateTime</a>  [[!XMLSCHEMA-2]].</p>
-<pre class="codeexample"> 
-  wasGeneratedBy(e1,a1, 2001-10-26T21:32:52)
-</pre>
-</div>
-
-<div class="note">
-We need to check that we are including all xsd types that are the latest versions of XML Schema/RDF.
-</div>
-</section>
-</section>
- 
-
-
-</section>
-
-
-<!-- end sec. 5 -->
-
-    <section id="extensibility-section"> 
-<h2>PROV-DM Extensibility Points</h2>
-
-
-<p>The PROV data model provides extensibility points that allow designers to specialize it for specific applications or domains. We summarize these extensibility points here:
-
-<ul>
-<li> Attribute-value lists occur in all types and relations of the data model.  Applications designers are free to introduce further application-specific attributes. 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 title="prov-namespace">PROV namespace</a> declares a set of reserved attributes catering for extensibility: <a href="#term-attribute-type"><span class="name">prov:type</span></a>, <a href="#term-attribute-role"><span class="name">prov:role</span></a>, <a href="#term-attribute-location"><span
-class="name">prov:location</span></a>.</li>
-
-<li>Sub-types and sub-relations can be expressed by means of the reserved attribute 
-<a href="#term-attribute-type"><span class="name">prov:type</span></a>.
-
-<div class="anexample" id="anexample-sub-relation">
-<p>
-In the following example,  <span class="name">e2</span> is a translation of <span class="name">e1</span>,
-expressed as a sub-type of derivation.
-<pre class="codeexample"> 
-  wasDerivedFrom(e2,e1, [prov:type='ex:Translation' ])
-</pre>
-</div>
-
-<div class="anexample" id="anexample-sub-type">
-<p>
-In the following example,  <span class="name">e</span> is described as a Car, a type of entity.
-<pre class="codeexample"> 
-  entity(e, [prov:type='ex:Car' ])
-</pre>
-</div>
-
-
-
-
-</li>
-
-
-
-
-
-<li>New namespaces and associated prefixes can be declared, allowing attributes and names to be qualified. </li>
-
-<li>Notes allow arbitrary metadata to be associated with anything identifiable in PROV-DM. Notes consist of attribute-value pairs.  Attributes are qualified by a
-namespace.</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 this document and in [[PROV-CONSTRAINTS]]. </p>
-
-
-
-    </section> 
-
-
-
-<section id="valid-provenance">
-<h4>Creating Valid Provenance</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 constraints have been defined for PROV-DM and
-can be found in a companion specification [[PROV-CONSTRAINTS]].
-They SHOULD be used by developers to compose provenance descriptions that are valid, and
-by implementers of reasoning engines aiming to check whether provenance descriptions have problems. </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> denotes the latest version of a document. One needs to ensure that provenance descriptions for the latter resource remain valid as the resource state changes. </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 allow provenance descriptions to be refined, they can also be found in the companion specification [[PROV-CONSTRAINTS]].</p>
-
-
-</li>
-
-
-<li>
-<p>The idea of bundling provenance 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.
-Descriptions in bundles are expected to satisfy constraints specified in the companion specification [[PROV-CONSTRAINTS]].</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>
-
-<section class="appendix"> 
-      <h2>Acknowledgements</h2> 
-      <p> 
-        WG membership to be listed here.
-      </p> 
-    </section> 
-
- </body>
-</html>
--- a/model/working-copy/wd6-prov-dm.html	Mon Sep 10 07:56:57 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,2812 +0,0 @@
-<!DOCTYPE html
->
-
-<html><head> 
-    <title>PROV-DM: The PROV 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('data-ref');
-          var span=$(this).attr('data-withspan')
-          $(this).removeAttr('data-withspan');
-          $(this).removeAttr('data-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-CONSTRAINTS":
-          "James Cheney, Paolo Missier, and Luc Moreau (eds.) "+
-          "<a href=\"http://www.w3.org/TR/prov-constraints/\"><cite>Constraints of the PROV Data Model</cite></a>. "+
-          "2011, Working Draft. "+
-          "URL: <a href=\"http://www.w3.org/TR/prov-constraints/\">http://www.w3.org/TR/prov-constraints/</a>",
-
-        "PROV-N":
-          "Luc Moreau and Paolo Missier (eds.)"+
-          "<a href=\"http://www.w3.org/TR/prov-n/\"><cite>PROV-N: The Provenance Notation</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   :  "working towards WD6 --- Working Copy",
-
- 
-          // if you wish the publication date to be other than today, set this
-//          publishDate:  "2012-05-03",
- 
-          // if the specification's copyright date is a range of years, specify
-          // the start date here:
-          copyrightStart: "2011",
- 
-          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
-          // and its maturity status
-          previousPublishDate:  "2012-05-03",
-          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-dm.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: "Reza B'Far",
-                company: "Oracle Corporation" },
-              { name: "Stephen Cresswell",
-                company: "legislation.gov.uk"},
-              { name: "Yolanda Gil",
-                company: "Invited Expert", url:"http://www.isi.edu/~gil/"},
-              { 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: "Curt Tilmes", 
-                company: "National Aeronautics and Space Administration" },
-          ],
-          
-          // name of the WG
-          wg:           "Provenance Working Group",
-          
-          // URI of the public WG page
-          wgURI:        "http://www.w3.org/2011/prov/",
-          
-          // name (with the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "public-prov-wg",
-          
-          // URI of the patent status for this WG, for Rec-track documents
-          // !!!! IMPORTANT !!!!
-          // This is important for Rec-track documents, do not copy a patent URI from a random
-          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
-          // Team Contact.
-          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/46974/status",
-
-          // Add extraReferences to bibliography database
-          preProcess: [addExtraReferences],
-      };
-    </script> 
-  </head> 
-  <body> 
-
-    <section id="abstract">
-<p>
-PROV-DM, the PROV data model, is a data model for provenance that describes
-the entities, people and activities involved in
-producing a piece of data or thing. 
-PROV-DM is structured in six components, dealing with: 
-(1) entities and activities, and the time at which they were created, used, or ended;
-(2) agents bearing responsibility for entities that were generated and activities that happened;
-(3) derivations of entities from entities;
-(4) properties to link entities that refer to the same thing;
-(5) collections forming a logical structure for its members;
-(6) a simple annotation mechanism.
-</p>
-
-<p>This document introduces the provenance concepts found in
-PROV and defines PROV-DM types and
-relations. PROV data model is domain-agnostic, but is equipped with
-extensibility points allowing domain-specific information to be included. </p>
-
-<p>Two further documents complete the specification of PROV-DM.
-First, a companion document specifies the set of constraints that
-provenance descriptions should follow.  Second, 
-a separate document describes a provenance notation for expressing 
-instances of provenance for human consumption; this notation is used in examples in
-this document. </p>
-
-    </section> 
-
-<section id="sotd">
-<h4>PROV Family of Specifications</h4>
-This document is part of the PROV family of specifications, a set of specifications defining various aspects that are necessary to achieve the vision of inter-operable
-interchange of provenance information in heterogeneous environments such as the Web.  The specifications are:
-<ul>
-<li> PROV-DM, the PROV data model for provenance (this document);</li>
-<li> PROV-CONSTRAINTS, a set of constraints applying to the PROV data model;</li>
-<li> PROV-N, a notation for provenance aimed at human consumption;</li>
-<li> PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF;</li>
-<li> PROV-AQ, the mechanisms for accessing and querying provenance; </li>
-<li> PROV-PRIMER, a primer for the PROV data model;</li>
-<li> PROV-SEM, a formal semantics for the PROV data model;</li>
-<li> PROV-XML, an XML schema for the PROV data model.</li>
-</ul>
-<h4>How to read the PROV Family of Specifications</h4>
-<ul>
-<li>The primer is the entry point to PROV offering an introduction to the provenance model.</li>
-<li>The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL-RL ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. PROV-SEM provides a mathematical semantics.</li>
-<li>The XML community should focus on PROV-XML defining an XML schema for PROV. Further details can also be found in PROV-DM, PROV-CONSTRAINTS, and PROV-SEM.</li>
-<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
-<li>Readers seeking to implement other PROV serializations
-should focus on PROV-DM and PROV-CONSTRAINTS.  PROV-O, PROV-N, PROV-XML offer examples of mapping to RDF, text, and XML, respectively.</li>
-</ul>
-
-
-<h4>Fourth Public Working Draft</h4>
-<p>This is the fourth public release of the PROV-DM document. Following feedback, the Working Group has decided to reorganize this document substantially, separating the data model from its contraints and the notation used to illustrate it. The PROV-DM release is synchronized with the release of the PROV-O, PROV-PRIMER, PROV-N, and PROV-CONSTRAINTS documents. We are now clarifying the entry path to the PROV family of specifications.</p>
-</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 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>
-We
-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  <em>interchanged</em> between systems.
-Thus, heterogeneous systems can export their native 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>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, informally described (this document);
-<li> PROV-CONSTRAINTS (part II): constraints underpinning the data model [[PROV-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: the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF [[PROV-O]];</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>
-<li>PROV-XML: an XML schema for the PROV data model.</li>
-</ul>
-
-
-<p>
-The  PROV data model is a domain-agnostic model, but with clear extensibility points allowing further domain-specific and
-application-specific extensions to be defined.
-The PROV data model is structured according to six components covering various aspects of provenance:</p>
-<ul>
-<li> component 1: entities and activities, and the time at which they were created, used, or ended;
-<li> component 2: agents bearing responsibility for entities that were generated and activities that happened;
-<li> component 3: derivations of entities from others;
-<li> component 4: properties to link entities that refer to a same thing;
-<li> component 5: collections forming a logical structure for its members;
-<li> component 6: a simple annotation mechanism.
-</ul>
-
-
-<p>This specification presents the key concepts of the PROV Data Model, and
-provenance types and relations, without specific concern for how they are applied.
-With these, it becomes possible to write useful provenance descriptions, and publish or embed them along side the data they relate to. </p>
-
-<p>However, if something about which provenance is expressed is subject to change, then it is challenging to express its provenance precisely (e.g. the data from which a daily weather report is derived  changes from day to day).
- To address this challenge, a <em>refinement</em> is proposed to enrich simple provenance, with extra descriptions that  help qualify the specific subject of provenance and provenance itself, with attributes and temporal information, intended to satisfy a comprehensive set of constraints.  These aspects are covered in the companion specification [[PROV-CONSTRAINTS]].
-</p>
-
-
-<section id="structure-of-this-document"> 
-<h3>Structure of this Document</h3>
-
-<p><a href="#starting-points">Section 2</a> provides  starting points for the PROV Data Model, listing a set of types and  relations, which allows users to make initial provenance descriptions.</p>
-
-<p><a href="#prov-dm-example">Section 3</a> illustrates how the PROV data model can be used
-to express the provenance of a report published on the Web.</p>
-
-<p><a href="#data-model-components">Section 4</a> provides the definitions of PROV concepts, structured according to six components.</p>
-
-<p><a href="#extensibility-section">Section 5</a> summarizes PROV-DM extensibility points.</p>
-
-<p><a href="#valid-provenance">Section 6</a> introduces the idea that constraints can be applied to the PROV data model to refine provenance descriptions; these are covered in the companion specification [[PROV-CONSTRAINTS]].</p>
-
-
-</section> 
-
-<section id="conventions"> 
-<h3>Notational 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>
-
-
-<p>
-The following namespaces prefixes are used throughout this document.
-
-<div style="text-align: left;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="namespace-table">Table 1: Prefix and Namespaces used in this specification</caption>
-<tr><td><a><b>prefix</b></a></td><td><b>namespace uri</b></td> <td><b>definition</b></td></tr>
-<tr><td><a>prov</a></td><td>http://www.w3.org/ns/prov#</td><td>The PROV namespace (see Section <a href="#term-NamespaceDeclaration">4.7.1</a>)</td></tr>
-<tr><td><a>xsd</a></td><td>http://www.w3.org/2000/10/XMLSchema#</td><td>XML Schema Namespace [[!XMLSCHEMA-2]]</td></tr>
-<tr><td><a>rdf</a></td><td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td><td>The RDF namespace  [[!RDF-CONCEPTS]]</td></tr>
-<tr><td><a>(others)</a></td><td>(various)</td><td>All other namespace prefixes are used in examples only. <br/> In particular, URIs starting with "http://example.com" represent<br/> some application-dependent URI [[!URI]]</td></tr>
-</table>
-</div>
-
-</section> 
-
-</section> 
-
-
-
-<section id='starting-points'> 
-<h1>PROV Starting Points</h1>
-
-<p>
-This section introduces provenance concepts with informal descriptions and illustrative
-examples.  Since PROV-DM is a conceptual data
-model, Section 2.5 maps the concepts to various types and relations,
-which are illustrated graphically in
-a simplified UML diagram in <a href="#prov-dm-overview">Figure 1</a>.  Section 2.6
-then summarizes the PROV notation allowing instances of PROV-DM to be
-written down.
-</p>
-
-<form action="#"><p> 
-<input id="hide-examples" onclick="set_display_by_class('div','conceptexample','none'); set_display_by_id('hide-examples','none'); set_display_by_id('show-examples','');" type="button"
-value="Hide Concept Examples" /> 
-<input id="show-examples" onclick="set_display_by_class('div','conceptexample',''); set_display_by_id('hide-examples',''); set_display_by_id('show-examples','none');" style="display: none"
-type="button" value="Show Concept Examples" /> 
-</p> 
-</form> 
-
-
-
-
-  
-    <section id='section-entity-activity'> 
-<h2>Entity and Activity</h2>
-
-
-<p>Things we want to describe  the provenance of are called <em>entities</em> in PROV. The term "things" encompasses a broad diversity of notions, 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. </p>
-
-<p>
-<div class="glossary-ref" data-ref="glossary-entity"  data-withspan="true">
-</div>
-
-
-
-<div class="conceptexample" id="entity-example">
-<p>An entity may be the document at URI <a href="http://www.bbc.co.uk/news/science-environment-17526723">http://www.bbc.co.uk/news/science-environment-17526723</a>, a file in a file system, a car, or an idea.</p>
-</div>
-
-
-
-<p>
-<span class="glossary-ref" data-ref="glossary-activity"  data-withspan="true"></span> Activities that operate on digital entities may for example move, copy, or duplicate them.
-</p>
-
-
-
-<div class="conceptexample" 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, 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, or editing a file.</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 utilize entities and activities  produce entities. The act of utilizing or producing an entity may have a duration.  
- The term 'generation' refers to the completion of the act of producing; likewise, the term 'usage' refers to the beginning of the act of utilizing entities. Thus, we define the following notions of generation and usage. </p>
-
-<p>
-<div class="glossary-ref" data-ref="glossary-generation"  data-withspan="true">
-</div>
-
-
-<p>
-<div class="glossary-ref" data-ref="glossary-usage"  data-withspan="true">
-</div>
-
-
-
-
-<div class="conceptexample" id="generation-example">
-<p>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>
-
-
-
-<div class="conceptexample" id="usage-example">
-<p>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); in contrast, the 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 utilize entities and producer entities. In some cases, utilizing 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" data-ref="glossary-derivation"  data-withspan="true"></span>
-
-
-
-<div class="conceptexample" 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-agents-attribution-association-responsibility"> 
-<h2>Agents, Attribution, Association, and Responsibility</h2>
-
-<p>The motivation for introducing  agents in the model is to express the agent's responsibility for activities that happened and entities that were generated. </p>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-agent"  data-withspan="true">
-</span> An agent MAY be a particular type of entity. This means that the model can be
- used to express provenance of the agents themselves.  
-</p>
-
-
-<!--
-<p>
-The definition of agent intentionally stays away from using concepts such as enabling, causing, initiating, triggering, affecting, etc, because many entities also enable, cause, initiate, and affect in some way
-the activities. (Concepts such as triggers are themselves defined later in relations between entities and activities.)   So the notion of having some degree of responsibility is really what makes an agent.</p>
--->
-
-
-
-<div class="conceptexample" 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. 
-A site selling books on the Web, the services involved in the processing of orders, and the companies hosting them are also agents.
-</p>
-</div>
-
-
-<p>Agents may adopt sets of actions or steps to achieve their goals. This is captured by the notion of plan. </p>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-plan"  data-withspan="true">
-</span>
-There exist no
-prescriptive requirement on 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="conceptexample" 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>Agents can be related to entities, activities, and other agents.</p>  
-
-<div class="glossary-ref" data-ref="glossary-attribution" data-withspan="true"></div>
-
-<div class="conceptexample" id="attribution-example">
-<p>A blog post can be attributed to an author, a mobile phone to its manufacturer.</p>
-</div>
-
-<p>
-Agents are defined as having some kind of responsibility for activities. In some  
-cases, those activities reflect the execution of a plan that was  
-designed in advance to guide the execution.  Thus,
-a plan may also be linked to an activity.  </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" data-ref="glossary-activityAssociation"  data-withspan="true"></span>
-</p>
-
-<div class="conceptexample" id="association-example">
-<p>Examples of association between an activity and an 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 launched by a user based on an XSL style sheet (a plan).</li>
-</ul>
-</div>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-responsibility"  data-withspan="true">
-</span> The nature of this relation is intended to be broad,  including delegation or 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="conceptexample" id="responsibility-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-types-entities-agents"> 
-<h2>Further Entities: Collections and Accounts</h2>
-
-<p>There are two further types of entities, collections and accounts, which are now introduced. </p>
-
-<p>
-<span class="glossary-ref" data-ref="glossary-collection"  data-withspan="true"></span> This concept allows for the provenance of the collection itself to be expressed in addition to that of the members.  Many different types of collections exist, such as a <em>set</em>, <em>dictionaries</em>, or <em>lists</em>, all of which involve a membership relationship between the constituents and the collection. </p>
-
-<div class="conceptexample" 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" data-ref="glossary-account"  data-withspan="true">
-</span>Making an account an entity allows for provenance of provenance to be expressed.
-
-<div class="conceptexample" id="account-example">
-<p>
-For users to decide whether they can place their trust in
-a resource, they may want to analyze the resource's provenance, but also determine
-who its provenance is attributed to, and when it was
-generated. In other words, users need to be able to determine the provenance of provenance.
-Hence, provenance is also
-regarded as an entity (of type Account), by which provenance of provenance can then be
-expressed.
-</p>
-</div>
-
-</section>
-
-
-
-
-    <section id="section-UML"> 
-<h2>Simplified Overview Diagram</h2>
-
-<p>So far, we have introduced a series of concepts underpinning provenance.   PROV-DM  is a conceptual data model consisting of types and relations between these.  <a href="#overview-types-and-relations">Table 2</a> shows how provenance concepts can be mapped to types and relations in PROV-DM: the first column lists concepts introduced in this section, the second column indicates whether a concept maps to a type or a relation, whereas the third column contains the corresponding name.    Names of relations have a verbal form in the past tense to express what happened in the past, as opposed to what may or will happen. 
-</p>
-
-
-<div style="text-align: left;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="overview-types-and-relations">Table 2: Mapping of Provenance concepts to  types and relations</caption>
-<tr><td><a><b>PROV Concepts</b></a></td><td><b>PROV-DM types or relations</b></td><td><b>Name</b></td></tr>
-<tr>
-<td><a>Entity</a></td><td rowspan="3">PROV-DM Types</td><td><a title="dfn-Entity">entity</a></td></tr>
-<tr><td><a>Activity</a></td><td><a title="dfn-Activity">activity</a></td></tr>
-<tr><td><a>Agent</a></td><td><a title="dfn-agent">agent</a></td></tr>
-<tr>
-<td><a>Generation</a></td><td rowspan="6">PROV-DM Relations</td><td><a title="wasGeneratedBy">wasGeneratedBy</a></td></tr>
-<tr><td><a>Usage</a></td><td><a title="used">used</a></td></tr>
-<tr><td><a>Attribution</a></td><td><a title="wasAttri