--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/Makefile Thu Feb 23 22:00:02 2012 +0000
@@ -0,0 +1,63 @@
+
+HGID.OLD=`hg -q id`
+HGID=`hg parents --template='{node|short}'`
+OUT.JS=glossary.js
+IN.HTML=glossary.html
+
+make.glossary.js: glossary.html Makefile
+ @$(MAKE) OUT.JS=$(OUT.JS) documentation
+ @$(MAKE) OUT.JS=$(OUT.JS) hgGlossaryId
+ @echo "glossary_string= " >> $(OUT.JS)
+ cat $(IN.HTML) | awk '{ print "'\''" $$0 " '\'' + " }' >> $(OUT.JS)
+ echo "' ' ;" >> $(OUT.JS)
+
+hgGlossaryId:
+ @echo "glossary_hg='http://dvcs.w3.org/hg/prov/file/$(HGID)/model/working-copy/glossary.html';" >> $(OUT.JS)
+
+documentation:
+ @echo "//Automatically generated file, don't edit!" > $(OUT.JS)
+ @echo "//Include this $(OUT.JS) file in your specification" >> $(OUT.JS)
+ @echo "// with <script src=\"$(OUT.JS)\" class=\"remove\"></script>" >> $(OUT.JS)
+ @echo "//Insert glossary definitions with the following " >> $(OUT.JS)
+ @echo "// <div class=\"glossary-ref\" ref=\"glossary-generation\"></div>" >> $(OUT.JS)
+
+
+# uses html2xhtml
+# http://www.it.uc3m.es/jaf/html2xhtml/downloads/html2xhtml-1.1.2-2.tar.gz
+
+WORKDIR=generated
+
+xsl:
+ html2xhtml -t 1.1 towards-wd4.html -o $(WORKDIR)/towards-wd4.xhtml
+ html2xhtml -t 1.1 prov-dm-constraints.html -o $(WORKDIR)/prov-dm-constraints.xhtml
+ grep -v mdash $(WORKDIR)/towards-wd4.xhtml | grep -v "/html" > $(WORKDIR)/towards-wd4-2.xhtml
+ cat $(WORKDIR)/prov-dm-constraints.xhtml | sed -e "s/&le/le/g" | sed -e "s/&cup/cup/g" | sed -e "s/&ge/ge/g" | grep -v "/html" > $(WORKDIR)/prov-dm-constraints-2.xhtml
+ csplit -f $(WORKDIR)/out $(WORKDIR)/towards-wd4-2.xhtml /body/
+ echo "<html>" > $(WORKDIR)/all-divs.html
+ xpath $(WORKDIR)/out01 .//div[@class] >> $(WORKDIR)/all-divs.html
+ csplit -f $(WORKDIR)/out $(WORKDIR)/prov-dm-constraints-2.xhtml /body/
+ xpath $(WORKDIR)/out01 .//div[@class] >> $(WORKDIR)/all-divs.html
+ xpath $(WORKDIR)/out01 .//span[@class] >> $(WORKDIR)/all-divs.html
+ echo "</html>" >> $(WORKDIR)/all-divs.html
+ cat $(WORKDIR)/all-divs.html | sed -e "s/\'/\\\'/g" > $(WORKDIR)/all-divs2.html
+ $(MAKE) make.all-divs.js
+
+make.all-divs.js: $(WORKDIR)/all-divs2.html Makefile
+ $(MAKE) OUT.JS=all-divs.js IN.HTML=$(WORKDIR)/all-divs2.html make.divs.js
+
+hgDivsId:
+ @echo "divs_hg='http://dvcs.w3.org/hg/prov/file/$(HGID)/model/working-copy/towards-wd4.html';" >> $(OUT.JS)
+
+make.divs.js:
+ @$(MAKE) OUT.JS=$(OUT.JS) documentation
+ @$(MAKE) OUT.JS=$(OUT.JS) hgDivsId
+ @echo "divs_string= " >> $(OUT.JS)
+ cat $(IN.HTML) | awk '{ print "'\''" $$0 " '\'' + " }' >> $(OUT.JS)
+ echo "' ' ;" >> $(OUT.JS)
+
+
+
+
+
+// xpath towards-wd4.xhtml //div[@class='anexample']
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/prov-asn.html Thu Feb 23 22:00:02 2012 +0000
@@ -0,0 +1,1172 @@
+<!DOCTYPE html>
+
+<html><head>
+ <title>PROV-DM Part 3: PROV-ASN: The Provenance Abstract Syntax Notation</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+<!-- PM -->
+ <style type="text/css">
+ .note { font-size:small; margin-left:50px }
+ </style>
+
+ <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
+ <script src="http://www.w3.org/2007/OWL/toggles.js" class="remove"></script>
+ <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js" class="remove"></script>
+
+ <script class="remove">
+ function updateGlossaryRefs() {
+ $('.glossary-ref').each(function(index) {
+ var ref=$(this).attr('ref');
+ $('#'+ref+'.glossary').contents().clone().appendTo($(this));
+ $(this).children('dfn').replaceWith(function(){return $('<span>').addClass('dfn').append($(this).contents())});
+ });
+ }
+ $(document).ready(updateGlossaryRefs);
+ function glossary_include(doc, content) {
+ window.setTimeout(updateGlossaryRefs, 1000);
+ return content;
+ }
+ </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-RDF":
+ "James Cheney"+
+ "<a href=\"http://www.w3.org/2011/prov/wiki/ProvRDF\"><cite>PROV-RDF Mapping </cite></a>"+
+ "2012, Working in Progress. "+
+ "URL: <a href=\"http://www.w3.org/2011/prov/wiki/ProvRDF\">http://www.w3.org/2011/prov/wiki/ProvRDF</a>",
+
+ "PROV-XML":
+ "James Cheney"+
+ "<a href=\"http://www.w3.org/2011/prov/wiki/ProvXML\"><cite>PROV-XML Mapping </cite></a>"+
+ "2012, Working in Progress. "+
+ "URL: <a href=\"http://www.w3.org/2011/prov/wiki/ProvXML\">http://www.w3.org/2011/prov/wiki/ProvXML</a>",
+
+
+ "PROV-DM":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-dm/\"><cite>PART 1: PROV-DM ...</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-dm/\">http://www.w3.org/TR/prov-dm/</a>",
+
+ "PROV-DM-CONSTRAINTS":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-dm-constraints/\"><cite>PROV-DM Constraints</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-dm-constraints/\">http://www.w3.org/TR/prov-dm-constraints/</a>",
+
+
+ "PROV-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-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 : "Some speculative write-ups, for discussion before integration in the data model",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2011-10-18",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ //previousPublishDate: "2011-12-15",
+ //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/working-copy/prov-asn.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css", "./extra.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Luc Moreau", url: "http://www.ecs.soton.ac.uk/~lavm/",
+ company: "University of Southampton" },
+ { name: "Paolo Missier", url: "http://www.cs.ncl.ac.uk/people/Paolo.Missier",
+ company: "Newcastle University" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+
+ // 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>
+<b>Editors' working copy can change at any time. </b>
+</p>
+ </section>
+
+<section id="sotd">
+<b>Editors' working copy can change at any time. </b>
+</section>
+
+
+
+
+
+
+
+
+
+
+
+<section id="introduction">
+<h2>Introduction</h2>
+
+<p> Provenance is defined as a record that describes the people,
+institutions, entities, and activities, involved in producing,
+influencing, or delivering a piece of data or a thing in the world. Two
+companion specifications respectively define PROV-DM, a data model for
+provenance, allowing such descriptions to be expressed [[PROV-DM]] and a set of constraints that provenance descriptions are expectively to satisfy [[PROV-DM-CONSTRAINTS]].
+</p>
+
+
+<p>In this context, PROV-ASN was introduced as a notation to write instances of the data model, as close to its abstract syntax as possible. PROV-ASN is primarily aimed at human consumption. PROV-ASN allows
+serializations of PROV-DM instances to be written in a technology independent manner.
+So far, PROV-ASN has been used in the following ways:</p>
+<ul>
+<li> PROV-ASN is used to provide technology independent illustrations in [[PROV-DM]] and in the definition of PROV-DM constraints [[PROV-DM-CONSTRAINTS]];</li>
+<li> PROV-ASN is instrumental in defining the mapping mapping of PROV-DM to concrete syntaxes. Mappings translate each PROV-ASN expression to RDF [[PROV-RDF]] and to XML [[PROV-XML]];</li>
+<li> PROV-ASN is the basis for a
+formal semantics, in which each PROV-ASN expression is provided with an interpretation [[PROV-SEM]].
+</ul>
+
+<p>PROV-ASN was designed to be as close as possible to PROV-DM without the syntactic bias and modelling constraints that concrete technologies bring with them, e.g., XML's choice between attribute and element, RDF's reliance on triples, or JSON's usage of dictionaries. </p>
+
+<p>The purpose of this document is solely to define the syntax of PROV-ASN.
+For each construct of PROV-DM, a corresponding ASN expression is introduced, by way of a production in the PROV-ASN grammar presented in this document. </p>
+
+
+<p>This specification is one of several specifications, referred to as the PROV family of specifications, defining the various aspects
+that are necessary to achieve the vision of inter-operable exchange of provenance:</p>
+<ul>
+<li>A data model for provenance, which is presented in three documents:
+<ul>
+<li> PROV-DM (part I): the provenance data model itself, expressed in natural language [[PROV-DM]];
+<li> PROV-DM-CONSTRAINTS (part II): constraints underpinning the data model [[PROV-DM-CONSTRAINTS]];
+<li> PROV-ASN (part III): a notation to express instances of that data model for human consumption (this document);
+</ul>
+</li>
+
+<li>PROV-O: a normative serialization of PROV-DM in RDF [[!PROV-O]], specified by means of a mapping to the OWL2 Web Ontology Language [[!OWL2-SYNTAX]];</li>
+<li>PROV-AQ: the mechanisms for accessing and querying provenance [[PROV-AQ]];</li>
+<li>PROV-PRIMER: a primer for the PROV approach [[PROV-PRIMER]];</li>
+<li>PROV-SEM: semantics of the PROV-DM data model [[PROV-SEM]];</li>
+</ul>
+
+ <section id="structure-of-this-document">
+<h3>Structure of this Document</h3>
+
+<div class='note'>TODO</div>
+
+
+ </section>
+
+
+<section id="prov-dm-namespace">
+ <h3>PROV-DM Namespace</h3>
+
+
+<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
+
+<p> All the elements, relations, reserved names and attributes introduced in this specification belong to the PROV-DM namespace.</p>
+
+<div class="issue">
+There is a desire to use a single namespace that all specifications of the PROV family can share to refer to common provenance terms. This is <a href="http://www.w3.org/2011/prov/track/issues/224">ISSUE-224</a>.
+</div>
+
+</section>
+
+ <section id="conventions">
+<h3>Conventions</h3>
+
+
+
+<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [[!RFC2119]].</p>
+ </section>
+
+</section>
+
+
+
+</section>
+
+
+ <section id="grammar-notation">
+<h3>Grammar Notation</h3>
+
+<p>This specification includes a grammar for PROV-ASN expressed using the Extended Backus-Naur Form (EBNF) notation.</p>
+
+<div class="grammar">
+<p> Each production rule (or <dfn>production</dfn>, for short) in the grammar defines one non-terminal symbol, in the form:</p>
+<p>
+<span class="nonterminal">E</span> ::= <em>expression</em>
+</p>
+
+
+Within the expression on the right-hand side of a rule, the following expressions are used to match strings of one or more characters:
+<ul>
+<li>
+<span class="nonterminal">E</span>: matches term satisfying rule for symbol E.
+</li>
+
+<li>
+<span class="name">abc</span>: matches the literal string inside the single quotes.
+</li>
+
+
+<li>
+<span class="optional"><em>expression</em></span>: matches <em>expression</em> or nothing; optional <em>expression</em>.
+</li>
+
+<li>
+<span class="plus"><em>expression</em></span>: matches one or more occurrences of <em>expression</em>.
+</li>
+
+<li>
+<span class="star"><em>expression</em></span>: matches zero or more occurrences of <em>expression</em>.
+</li>
+
+</ul>
+</div>
+
+</section>
+
+
+<section id="data-model-concepts">
+
+<h2>PROV-DM Core</h2>
+
+<p>Instances of the PROV-DM data model are expressed in PROV-ASN by a text conformant with the toplevel <a>production</a> <span class="nonterminal">expression</span> of the grammar. These <span
+class="nonterminal">expression</span>s are grouped in two categories:
+<span class="nonterminal">elementExpression</span> (see section <a href="#expression-element">Element</a>) and
+<span class="nonterminal">relationExpression</span> (see section <a href="#expression-relation">Relation</a>).</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">expression</span> ::=
+<span class="nonterminal">elementExpression</span>
+| <span class="nonterminal">relationExpression</span>
+<br/>
+<!-- -->
+<br/>
+<span class="nonterminal">elementExpression</span> ::=
+<span class="nonterminal">entityExpression</span>
+| <span class="nonterminal">activityExpression</span>
+| <span class="nonterminal">agentExpression</span>
+| <span class="nonterminal">noteExpression</span> <br/>
+<!-- -->
+<br/>
+<span class="nonterminal">relationExpression</span> ::=
+<span class="nonterminal">generationExpression</span>
+| <span class="nonterminal">usageExpression</span>
+| <span class="nonterminal">derivationExpression</span>
+| <span class="nonterminal">activityAssociationExpression</span>
+| <span class="nonterminal">responsibilityExpression</span>
+| <span class="nonterminal">startExpression</span>
+| <span class="nonterminal">endExpression</span>
+| <span class="nonterminal">alternateExpression</span>
+| <span class="nonterminal">specializationExpression</span>
+| <span class="nonterminal">annotationExpression</span>
+</div>
+
+
+
+
+<section id="expression-element">
+<h3>Element</h3>
+
+<p>PROV-DM elements can be entities, activities, agents, or notes. This section defines a production for the textual representation of each of these element types. </p>
+
+ <section id="expression-Entity">
+
+<h4>Entity</h4>
+
+
+<div class="withAsn">
+<p>
+An entity's text matches the <span class="nonterminal">entityExpression</span> production.
+</p>
+
+<div class='grammar'>
+<span class="nonterminal">entityExpression</span> ::=
+<span class="name">entity</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/><br/>
+<!-- -->
+<span class="nonterminal">optional-attribute-values</span> ::=
+<span class="optional"><span class="name">,</span>
+<span class="name">[</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">]</span>
+</span><br/>
+<span class="nonterminal">attribute-values</span> ::=
+<span class="nonterminal">attribute-value</span>
+| <span class="nonterminal">attribute-value</span> <span class="name">,</span> <span class="nonterminal">attribute-values</span>
+<br/>
+<span class="nonterminal">attribute-value</span> ::=
+<span class="nonterminal">attribute</span>
+<span class="name">=</span>
+<span class="nonterminal">Literal</span>
+<br/>
+</div>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215)
+entity(tr:WD-prov-dm-20111215, [ prov:type="document" ])
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version=2 ])
+</pre>
+</div>
+
+
+ </section>
+
+ <section id="expression-Activity">
+
+<h3>Activity</h3>
+
+
+<div class="withAsn">
+<p>An activity's text matches the <span class='nonterminal'>activityExpression</span> production.</p>
+
+
+
+<div class='grammar'>
+<span class="nonterminal">activityExpression</span> ::=
+<span class="name">activity</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="optional"><span class="nonterminal">time</span></span>
+<span class="name">,</span>
+<span class="optional"><span class="nonterminal">time</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+activity(ex:edit1,,)
+activity(ex:edit1,,,[prov:type="edit"])
+activity(ex:a0, 2011-11-16T16:00:00,,[prov:type="createFile"])
+activity(ex:a0, 2011-11-16T16:00:00, 2011-11-16T16:00:01, [prov:type="createFile"])
+</pre>
+</div>
+
+
+</section>
+
+<section id="expression-Agent">
+<h3>Agent</h3>
+
+
+<div class="withAsn">
+<p>An agent's text matches the <span class="nonterminal">agentExpression</span> production.
+</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">agentExpression</span> ::=
+<span class="name">agent</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+agent(ag4)
+agent(ag4, [ prov:type="prov:Human" %% xsd:QName, ex:name="David" ])
+</pre>
+</div>
+
+
+</section>
+
+ <section id="expression-note">
+
+<h4>Note</h4>
+
+<div class="withAsn">
+<p>A note's text matches the <span class="nonterminal">noteExpression</span> production.
+</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">noteExpression</span> ::=
+<span class="name">note</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">attribute-values</span>
+<span class="name">)</span><br/>
+<!-- -->
+</div>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+note(ann1,[ex:color="blue", ex:screenX=20, ex:screenY=30])
+</pre>
+</div>
+
+ </section>
+
+</section>
+
+
+<section id="expression-relation">
+<h3>Relation</h3>
+
+<p>
+PROV-DM relations can be generation, usage, derivation, activity association, responsibility chain, activity start, activity end, alternate, specialization, or annotations. This section defines a production for the textual representation of each of these relation types. </p>
+
+
+
+<section id="expression-Generation">
+<h4>Generation</h4>
+
+
+<div class="withAsn">
+<p>A generation's text matches the <span class='nonterminal'>generationExpression</span> production.</p>
+
+<div class='grammar'>
+<span class="nonterminal">generationExpression</span> ::=
+<span class="name">wasGeneratedBy</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>
+<span class="name">,</span> </span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="optional"><span class="nonterminal">aIdentifier</span></span>
+<span class="optional"><span class="name">,</span>
+<span class="nonterminal">time</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/>
+</div>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+wasGeneratedBy(tr:WD-prov-dm-20111215, ex:edit1)
+wasGeneratedBy(tr:WD-prov-dm-20111215, ex:edit1, 2011-11-16T16:00:00)
+wasGeneratedBy(ex:g1, tr:WD-prov-dm-20111215, ex:edit1)
+wasGeneratedBy(e2, a1, [ex:fct="save"])
+</pre>
+</div>
+
+
+</section>
+
+
+<section id="expression-Usage">
+<h3>Usage</h3>
+
+
+
+<p>A usage's text matches the <span class='nonterminal'>usageExpression</span> production.</p>
+
+<div class='grammar'>
+<span class="nonterminal">usageExpression</span> ::=
+<span class="name">used</span>
+<span class="name">(</span>
+<span class="optional">
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="optional">
+<span class="name">,</span>
+ <span class="nonterminal">time</span>
+</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/>
+</div>
+
+
+<div class="anexample">
+<pre class="codeexample">
+used(ex:pub2, ar3:0111)
+used(ex:pub2, ar3:0111, 2011-11-16T16:00:00)
+used(ex:u1, ex:pub2, ar3:0111)
+used(a1,e1,[ex:fct="load"])
+</pre>
+</div>
+
+</section>
+
+
+
+
+
+
+<section id="expression-ActivityAssociation">
+<h4>Activity Association</h4>
+
+
+<p>An activity association's text matches the <span class="nonterminal">activityAssociationExpression</span> productions of the grammar defined in this specification
+document.</p>
+
+<div class='grammar'>
+<span class="nonterminal">activityAssociationExpression</span> ::=
+<span class="name">wasAssociatedWith</span>
+<span class="name">(</span>
+<span class="optional"><span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">aIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>
+<span class="optional">,<span class="nonterminal">eIdentifier</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+</div>
+
+
+<div class="anexample">
+<pre class="codeexample">
+wasAssociatedWith(ex:pub2, w3:Consortium)
+wasAssociatedWith(ex:pub2, w3:Consortium @ pr:rec-advance)
+wasAssociatedWith(ex:pub2, w3:Consortium @ pr:rec-advance, [prov:role="funder"])
+</pre>
+
+
+</section>
+
+<section id="expression-Start-End">
+<h4>Activity Start and End</h4>
+
+
+<p>Activity start and end texts match the <span class="nonterminal">startExpression</span> and <span class="nonterminal">endExpression</span> productions of the grammar defined in this
+specification document.
+</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">startExpression</span> ::=
+<span class="name">wasStartedBy</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">aIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/>
+<span class="nonterminal">endExpression</span> ::=
+<span class="name">wasEndedBy</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">aIdentifier</span>,
+<span class="nonterminal">agIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+
+</section>
+
+
+
+
+
+
+
+<section id="expression-responsibility">
+
+<h4>Responsibility Chain</h4>
+
+
+
+<div class='grammar'>
+<span class="nonterminal">responsibilityExpression</span> ::=
+<span class="name">actedOnBehalfOf</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">agIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">agIdentifier</span>
+<span class="name">,</span>
+<span class="optional"><span class="nonterminal">aIdentifier</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+actedOnBehalfOf(ag1,ag2)
+actedOnBehalfOf(ag1,ag2,a)
+actedOnBehalfOf(ag1,ag2,[prov:type="delegation"])
+actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
+</pre>
+</div>
+
+</section>
+
+<section id="Derivation-Relation">
+<h4>Derivation</h4>
+
+
+
+<p>A derivation record's text matches the <span class='nonterminal'>derivationExpression</span> production.</p>
+
+<div class='grammar'>
+<span class="nonterminal">derivationExpression</span> ::=
+<span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">aIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">gIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">uIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span><br/>
+|
+<span class="name">wasDerivedFrom</span>
+<span class="name">(</span>
+<span class="optional"> <span class="nonterminal">identifier</span>,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="optional"><span class="name">,</span>
+<span class="nonterminal">time</span></span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+<p>
+The first clause of the alternative, where the activity, generation and usage record identifiers are present formalizes a derivation record is precise-1. The second clause of the alternative, with optional time formalizes imprecise records. The distinction between imprecise-1 and imprecise-n is made by the
+attribute <span class="name">prov:steps</span>.
+</p>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+wasDerivedFrom(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018)
+wasDerivedFrom(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018)
+wasDerivedFrom(e2, e1, a, g2, u1)
+</pre>
+
+
+
+
+<!--
+<p>In PROV-DM, the effective placeholder for an entity generation time is the <a>generation record</a>. The presence of
+time information in imprecise derivation records is merely a convenience notation for a timeless derivation record and a generation record with this generation time information. </p>
+
+<div class='syntax' id="derivation-time-elimination">
+<span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1,t,attrs)</span> holds, <span class='conditional'>then</span> the following records also hold:
+<span class="name">wasDerivedFrom(e2,e1,attrs)</span> and <span class="name">wasGeneratedBy(e2,t)</span>.
+</div>
+
+
+
+<div class='pending'>Should derivation have a time? Which time? This is <a href="http://www.w3.org/2011/prov/track/issues/43">ISSUE-43</a>.<em>This is now addressed in this text. Optional time in derivation is generation time. See also <a href="http://www.w3.org/2011/prov/track/issues/205">ISSUE-205</a>.</em></div>
+
+-->
+
+</section>
+
+
+<section id="expression-alternate-specialization">
+
+<h4>Alternate and Specialization</h4>
+
+
+
+<p>An alternate relation's text matches the <span class="nonterminal">alternateExpression</span> production.</p>
+
+<div class='grammar'>
+ <span class="nonterminal">alternateExpression</span> ::=
+ <span class="name">alternateOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">)</span>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+alternateOf(tr:WD-prov-dm-20111215,ex:alternate-20111215)
+</pre>
+</div>
+
+
+<p>A specialization relation's text matches the <span class="nonterminal">specializationExpression</span>production.</p>
+
+<div class='grammar'>
+ <span class="nonterminal">specializationExpression</span> ::=
+ <span class="name">specializationOf</span>
+<span class="name">(</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">,</span>
+<span class="nonterminal">eIdentifier</span>
+<span class="name">)</span>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+specializationOf(tr:WD-prov-dm-20111215,tr:prov-dm)
+</pre>
+</div>
+
+
+
+
+</section>
+
+
+
+
+
+
+<section id="expression-annotation">
+<h4>Annotation</h4>
+
+
+<p>A note's text matches the <span class="nonterminal">noteExpression</span> production.
+</p>
+
+<div class='grammar'>
+<span class="nonterminal">annotationExpression</span> ::=
+<span class="name">hasAnnotation</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="nonterminal">nIdentifier</span>
+<span class="nonterminal">optional-attribute-values</span>
+<span class="name">)</span>
+</div>
+</div>
+
+<div class="anexample">
+<pre class="codeexample">
+hasAnnotation(tr:WD-prov-dm-20111215,ex2:n1)
+</pre>
+</div>
+
+
+
+</section>
+</section>
+
+
+<section id="subexpressions">
+<h3>Further Expressions</h3>
+
+This section defines further expressions of PROV-ASN.
+
+
+<section id="expression-NamespaceDeclaration">
+<h3>Namespace Declaration</h3>
+
+
+<div class='grammar'>
+<span class="nonterminal">namespaceDeclarations</span> ::=
+ | <span class="group"><span class="nonterminal">defaultNamespaceDeclaration</span> | <span class="nonterminal">namespaceDeclaration</span></span> <span class="star"> <span
+class="nonterminal">namespaceDeclaration</span></span><br>
+<span class="nonterminal">namespaceDeclaration</span> ::=
+<span class="name">prefix</span> <span class="nonterminal">prefix</span> <span class="nonterminal">IRI</span><br/>
+<span class="nonterminal">defaultNamespaceDeclaration</span> ::=
+ <span class="name">default</span> <span class="nonterminal">IRI</span> <br/>
+</div>
+
+<p>In PROV-ASN, the prefix <span class="name">prov</span> is reserved and denotes the PROV namespace.</p>
+</section>
+
+
+<section id="expression-identifier">
+<h4>Identifier</h4>
+
+
+<div class='grammar'>
+<span class="nonterminal">identifier</span> ::= <span class="nonterminal">qualifiedName</span><br/>
+<span class="nonterminal">eIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an entity)</em><br/>
+<span class="nonterminal">aIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an activity)</em><br/>
+<span class="nonterminal">agIdentifier</span> ::= <span class="nonterminal">identifier</span> <em>(intended to denote an agent)</em><br/>
+<span class="nonterminal">gIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a generation)</em><br/>
+<span class="nonterminal">uIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a usage)</em><br/>
+<span class="nonterminal">nIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote a note)</em><br/>
+<span class="nonterminal">accIdentifier</span>::= <span class="nonterminal">identifier</span> <em>(intended to denote an account)</em>
+<br/>
+<br/>
+<span class="nonterminal">qualifiedName</span> ::= <span class="nonterminal">prefixedName</span> | <span class="nonterminal">unprefixedName</span><br/>
+<span class="nonterminal">prefixedName</span> ::= <span class="nonterminal">prefix</span> <span class="name">:</span> <span class="nonterminal">localPart</span><br/>
+<span class="nonterminal">unprefixedName</span> ::= <span class="nonterminal">localPart</span><br/>
+<span class="nonterminal">prefix</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production
+[[!XML-NAMES]]</em><br/>
+<span class="nonterminal">localPart</span> ::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production
+[[!XML-NAMES]]</em>
+</div>
+
+
+<div class="note">Note that XML NC_NAME don't allow local identifiers to start with a number. Instead, should we use the productions used in SPARQL or TURTLE?</div>
+
+</section>
+
+<section id="expression-attribute">
+<h4>Attribute</h4>
+
+
+<p>An attribute's text matches the <span class="nonterminal">attribute</span> production.</p>
+
+<div class='grammar'>
+<span class="nonterminal">attribute</span> ::= <span class="nonterminal">qualifiedName</span><br/>
+</div>
+
+<p>The reserved attributes in the PROV namespace are the following.</p>
+
+<ol>
+<li> <span class="name">prov:label</span>
+<li> <span class="name">prov:location</span>
+<li> <span class="name">prov:role</span>
+<li> <span class="name">prov:steps</span>
+<li> <span class="name">prov:type</span>
+</ol>
+
+
+</section>
+
+
+
+
+
+<section id="expression-literal">
+<h4>Literal</h4>
+
+<p>A Literal's text matches the <span class="nonterminal">Literal</span> production.</p>
+
+<div class='grammar'>
+<span class="nonterminal">Literal</span> ::= <span class="nonterminal">typedLiteral</span> | <span class="nonterminal">convenienceNotation</span> <br/>
+<span class="nonterminal">typedLiteral</span> ::= <span class="nonterminal">quotedString</span> <span class="name">%%</span> <span class="nonterminal">datatype</span><br/>
+<span class="nonterminal">datatype</span> ::= <span class="nonterminal">qualifiedName</span><br/>
+<span class="nonterminal">convenienceNotation</span> ::= <span class="nonterminal">stringLiteral</span> | <span class="nonterminal">intLiteral</span><br/>
+<span class="nonterminal">stringLiteral</span> ::= <span class="nonterminal">quotedString</span><br/>
+<span class="nonterminal">quotedString</span> ::= <em>a finite sequence of characters in which " (U+22) and \ (U+5C) occur only in pairs of the form \" (U+5C, U+22) and \\ (U+5C,
+U+5C), enclosed in a pair of " (U+22) characters</em><br/>
+<span class="nonterminal">intLiteral</span> ::= <em>a finite-length sequence of decimal digits (#x30-#x39) with an optional leading negative sign (-)</em>
+</div>
+
+<p>The non terminals <span class="nonterminal">stringLiteral</span> and
+<span class="nonterminal">intLiteral</span>
+are syntactic sugar for quoted strings with datatype <span class="name">xsd:string</span> and <span class="name">xsd:int</span>, respectively.
+</p>
+
+<p> In particular, a PROV-DM Literal may be an IRI-typed string (with datatype <span class="name">xsd:anyURI</span>); such IRI has no specific interpretation in the context of PROV-DM.</p>
+
+<section id="expression-types">
+<h4>Reserved Type Values</h4>
+
+<p>The reserved type values in the PROV namespace are the following.</p>
+
+<ol>
+<li> <span class="name">prov:AccountEntity</span>
+<li> <span class="name">prov:ComputingSystem</span>
+<li> <span class="name">prov:Human</span>
+<li> <span class="name">prov:Organization</span>
+<li> <span class="name">prov:Plan</span>
+<li> <span class="name">prov:Collection</span>
+<li> <span class="name">prov:EmptyCollection</span>
+</ol>
+
+</section>
+
+<section id="expression-Time">
+<h4>Time Values</h4>
+
+<p><dfn id="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [[!XMLSCHEMA-2]].</p>
+
+
+
+
+</section>
+
+
+</section>
+
+
+
+
+
+
+
+
+
+
+
+
+
+</section>
+</section>
+
+<section id="common-relations">
+<h2>Common Relations</h2>
+
+<div class="note">
+TO ADD
+</div>
+</section>
+
+
+
+
+
+<section id="ExpressionContainer">
+<h4>Expression Container</h4>
+
+<p>An <dfn id="dfn-ExpressionContainer">expression container</dfn> is a house-keeping construct of PROV-ASN capable of packaging up PROV-ASN <a title="expression">expressions</a> and namespace declarations. An expression container forms a self-contained package of provenance descriptions for the purpose of <em>exchanging</em> them. An expression container may be used
+ to package up PROV-ASN <a title="record">expressions</a> in response to a request for the provenance of something ([[PROV-AQ]]).</p>
+
+<p> Given its status of house keeping construct for the purpose of exchanging provenance expressions, an expression container is not defined as a PROV-ASN expression (<a href="#data-model-concepts">production <span class="nonterminal">expression</span></a>).</p>
+
+
+<p>An expression container, written <span class="name">container decls exprs endContainer</span> in PROV-ASN, contains:
+<ul>
+<li><em>namespaceDeclarations</em>: a set <span class="name">decls</span> of namespace declarations, declaring namespaces and associated prefixes, which can be used in <a
+title="attribute">attributes</a> and <a title="identifier">identifiers</a> occurring inside <span class="name">exprs</span>;</li>
+<li><em>expressions</em>: a non-empty set of expressions <span class="name">exprs</span>.</li>
+</ul>
+
+<p>An expression container's text matches the <span class="nonterminal">expressionContainer</span> production.</p>
+
+
+<div class='grammar'>
+<span class="nonterminal">expressionContainer</span> ::=
+<span class="name">container</span>
+<span class="nonterminal">namespaceDeclarations</span>
+<span class="plus"> <span class="nonterminal">expression</span> </span>
+<span class="name">endContainer</span>
+</div>
+
+
+<div class="anexample">
+<p>
+The following container contains expressions related to the provenance of entity
+<span class="name">e2</span>.
+</p>
+<pre class="codeexample">
+container
+
+ prefix ex: http://example.org/,
+
+ entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice",
+ ex:content="There was a lot of crime in London last month."])
+ activity(a1, 2011-11-16T16:05:00,,[prov:type="edit"])
+ wasGeneratedBy(e2, a1, [ex:fct="save"])
+ wasAssociatedWith(a1, ag2, [prov:role="author"])
+ agent(ag2, [ prov:type="prov:Person" %% xsd:QName, ex:name="Bob" ])
+
+endContainer
+</pre>
+<p>This container could for instance be returned as the result of a query to a provenance store for the provenance of entity <span class="name">e2</span> [[PROV-AQ]].
+</p>
+</div>
+
+
+
+<div class='issue'>
+Clarify what records are. This is <a href="http://www.w3.org/2011/prov/track/issues/208">ISSUE-208</a>. </div>
+</section>
+
+
+<section id="account">
+<h3>Account</h3>
+
+<p>PROV-DM has introduced a notion of account by which a set of provenance descriptions can be bundled up and named. PROV-DM <em>assumes</em> the existence of mechanisms to implement accounts, but such mechanisms remain outside its scope. It is suggested that specific serializations may offer solutions to name bundles of descriptions. </p>
+
+<p>Given that the primary motivation for PROV-ASN is to provide a notation aimed at human consumption, it is therefore appropriate to introduce a notation for accounts, which would include an account name and a bundle of expressions.</p>
+
+
+
+<p>An account, written <span class="name">account(id, exprs)</span> in PROV-ASN, contains:</p>
+<ul>
+<li><em>id</em>: an identifier <span class="name">id</span> that identifies this account;</li>
+<li><em>expressions</em>: a set <span class="name">exprs</span> of expressions;</li>
+</ul>
+
+<p>In PROV-ASN, an account's text matches the <span class="nonterminal">accountExpression</span> production of the grammar.</p>
+
+<div class='grammar'>
+<span class="nonterminal">accountExpression</span> ::=
+<span class="name">account</span>
+<span class="name">(</span>
+<span class="nonterminal">identifier</span>
+<span class="name">,</span>
+<span class="plus">
+<span class="nonterminal">expression</span> </span>
+<span class="name">)</span>
+</div>
+
+<p>It is also useful to package up one or more account expressions in an expression container, for interchange purpose. Hence, <span class="nonterminal">expressionContainer</span> is revised as follows. </p>
+
+<div class='grammar'>
+<span class="nonterminal">expressionContainer</span> ::=
+<span class="name">container</span>
+<span class="nonterminal">namespaceDeclarations</span>
+<span class="plus"> <span class="nonterminal">expression</span> </span>
+<span class="name">endContainer</span> <br/>
+| <span class="name">container</span>
+<span class="nonterminal">namespaceDeclarations</span>
+<span class="plus"> <span class="nonterminal">accountExpression</span> </span>
+<span class="name">endContainer</span>
+</div>
+
+
+
+<div class="anexample">
+<p>
+The following container </p>
+<pre class="codeexample">
+container
+ prefix ex: http://example.org/,
+
+ account(ex:acc1,...)
+ account(ex:acc2,...)
+endContainer
+</pre>
+<p> illustrates how two accounts with identifiers <span class="name">ex:acc1</span> and <span class="name">ex:acc2</span> can be returned in a PROV-ASN serialization of the provenance of
+something.
+</p>
+</div>
+
+
+<div class="anexample">
+<p>
+The following container </p>
+<pre class="codeexample">
+container
+ prefix ex: http://example.org/,
+ ...
+
+ account(ex:acc1,
+ entity(tr:WD-prov-dm-20111018, [ prov:type="pr:RecsWD" %% xsd:QName ])
+ entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+ ...
+ wasAssociatedWith(ex:pub2, w3:Consortium @ pr:rec-advance))
+
+ account(ex:acc2,
+ entity(ex:acc1, [prov:type="prov:AccountEntity" %% xsd:QName ])
+ wasAttributedTo(ex1:acc1,w3:Consortium))
+
+endContainer
+</pre>
+<p> illustrates a first account, with identifier <span class="name">ex:acc1</span>, containing expressions describing the provenance of the technical report <span class="name">tr:WD-prov-dm-20111215</span>, and a second account <span class="name">ex:acc2</span>, describing the provenance of the first. In account <span class="name">ex:acc2</span>, <span class="name">ex:acc1</span> is the identifier of an entity of type <span class="name">prov:AccountEntity</span>.
+</p>
+</div>
+
+</section>
+
+<!-- no longer necessary to say that.
+
+<p>All the records in <span class="name">recs</span> are implictly wrapped in a default account, scoping all the record identifiers they declare directly, and constituting a toplevel
+account, in the hierarchy of accounts. Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a
+container's default account.</p>
+
+-->
+
+
+</section>
+
+
+
+ </body></html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/prov-dm-constraints.html Thu Feb 23 22:00:02 2012 +0000
@@ -0,0 +1,1864 @@
+<!DOCTYPE html>
+
+<html><head>
+ <title>PROV-DM Part II: Constraints of the Provenance Data Model</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+<!-- PM -->
+ <style type="text/css">
+ .note { font-size:small; margin-left:50px }
+ </style>
+
+ <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
+ <script src="http://www.w3.org/2007/OWL/toggles.js" class="remove"></script>
+
+ <script class="remove">
+ var addExtraReferences = function() {
+ for (var k in extraReferences)
+ berjon.biblio[k] = extraReferences[k];
+ };
+ var extraReferences = {
+ "CLOCK":
+ "Lamport, L. "+
+ "<a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\"><cite>Time, clocks, and the ordering of events in a distributed system</cite></a>."+
+ "Communications of the ACM 21 (7): 558–565. 1978. "+
+ "URL: <a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\">http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf</a> " +
+ "DOI: doi:10.1145/359545.359563.",
+ "CSP":
+ "Hoare, C. A. R. "+
+ "<a href=\"http://www.usingcsp.com/cspbook.pdf\"><cite>Communicating Sequential Processes</cite></a>."+
+ "Prentice-Hall. 1985"+
+ "URL: <a href=\"http://www.usingcsp.com/cspbook.pdf\">http://www.usingcsp.com/cspbook.pdf</a>",
+ "Logic":
+ "W. E. Johnson"+
+ "<a href=\"http://www.ditext.com/johnson/intro-3.html\"><cite>Logic: Part III</cite></a>."+
+ "1924. "+
+ "URL: <a href=\"http://www.ditext.com/johnson/intro-3.html\">http://www.ditext.com/johnson/intro-3.html</a>",
+ "PROV-SEM":
+ "James Cheney "+
+ "<a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\"><cite>Formal Semantics Strawman</cite></a>. "+
+ "2011, Work in progress. "+
+ "URL: <a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\">http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman</a>",
+
+ "PROV-PRIMER":
+ "Yolanda Gil and Simon Miles (eds.) Khalid Belhajjame, Helena Deus, Daniel Garijo, Graham Klyne, Paolo Missier, Stian Soiland-Reyes, and Stephan Zednik "+
+ "<a href=\"http://www.w3.org/TR/prov-primer/\"><cite>Prov Model Primer</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-primer/\">http://www.w3.org/TR/prov-primer/</a>",
+
+
+ "PROV-DM":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-dm/\"><cite>PART 1: PROV-DM ...</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-dm/\">http://www.w3.org/TR/prov-dm/</a>",
+
+ "PROV-ASN":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-asn/\"><cite>PROV-ASN ....</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-asn/\">http://www.w3.org/TR/prov-asn/</a>",
+
+
+ "PROV-O":
+ "Satya Sahoo and Deborah McGuinness (eds.) Khalid Belhajjame, James Cheney, Daniel Garijo, Timothy Lebo, Stian Soiland-Reyes, and Stephan Zednik "+
+ "<a href=\"http://www.w3.org/TR/prov-o/\"><cite>Provenance Formal Model</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-o/\">http://www.w3.org/TR/prov-o/</a>",
+
+ "PROV-AQ":
+ "Graham Klyne and Paul Groth (eds.) Luc Moreau, Olaf Hartig, Yogesh Simmhan, James Meyers, Timothy Lebo, Khalid Belhajjame, and Simon Miles "+
+ "<a href=\"http://www.w3.org/TR/prov-aq/\"><cite>Provenance Access and Query</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-aq/\">http://www.w3.org/TR/prov-aq/</a>",
+ };
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "prov-dm-constraints",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ //subtitle : "Initial draft (WD4) for internal discussion",
+
+ // if you wish the publication date to be other than today, set this
+ //publishDate: "2012-02-01",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ copyrightStart: "2011",
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ previousPublishDate: "2012-02-02",
+ previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/prov-dm-constraints.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css", "./extra.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Luc Moreau", url: "http://www.ecs.soton.ac.uk/~lavm/",
+ company: "University of Southampton" },
+ { name: "Paolo Missier", url: "http://www.cs.ncl.ac.uk/people/Paolo.Missier",
+ company: "Newcastle University" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: ,
+
+ // 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>
+<b>Editors' working copy can change at any time. </b>
+</p>
+ </section>
+
+<section id="sotd">
+<b>Editors' working copy can change at any time. </b>
+</section>
+
+
+<div class="buttonpanel">
+<form action="#"><p>
+<input id="hide-bnf" onclick="set_display_by_class('div','grammar','none'); set_display_by_id('hide-bnf','none'); set_display_by_id('show-bnf','');" type="button" value="Hide Grammar" />
+<input id="show-bnf" onclick="set_display_by_class('div','grammar',''); set_display_by_id('hide-bnf',''); set_display_by_id('show-bnf','none');" style="display: none" type="button"
+value="Show Grammar" />
+<input id="hide-examples" onclick="set_display_by_class('div','anexample','none'); set_display_by_id('hide-examples','none'); set_display_by_id('show-examples','');" type="button"
+value="Hide Examples" />
+<input id="show-examples" onclick="set_display_by_class('div','anexample',''); set_display_by_id('hide-examples',''); set_display_by_id('show-examples','none');" style="display: none"
+type="button" value="Show Examples" />
+</p>
+</form>
+</div>
+
+
+ <section id="introduction">
+ <h2>Introduction<br>
+</h2>
+
+<p> Provenance is defined as a record that describes the people,
+institutions, entities, and activities, involved in producing,
+influencing, or delivering a piece of data or a thing in the world. A
+companion specification [[PROV-DM]] defines PROV-DM, a data model for
+provenance, allowing such descriptions to be expressed.
+</p>
+
+
+<p>PROV-DM has essentially be defined without any constraints [[PROV-DM]]. This document introduces a further set of concepts underpinning this data model and defines constraints that well-structured provenance descriptions should follow and that provide an interpretation for these descriptions. </p>
+
+
+<p>This specification is one of several specifications, referred to as the PROV family of specifications, defining the various aspects
+that are necessary to achieve the vision of inter-operable exchange of provenance:</p>
+<ul>
+<li>A data model for provenance, which is presented in three documents:
+<ul>
+<li> PROV-DM (part I): the provenance data model itself, expressed in natural language [[PROV-DM]];
+<li> PROV-DM-CONSTRAINTS (part II): constraints underpinning the data model (this document);
+<li> PROV-ASN (part III): a notation to express instances of that data model for human consumption [[PROV-ASN]];
+</ul>
+</li>
+
+<li>PROV-O: a normative serialization of PROV-DM in RDF [[!PROV-O]], specified by means of a mapping to the OWL2 Web Ontology Language [[!OWL2-SYNTAX]];</li>
+<li>PROV-AQ: the mechanisms for accessing and querying provenance [[PROV-AQ]];</li>
+<li>PROV-PRIMER: a primer for the PROV approach [[PROV-PRIMER]];</li>
+<li>PROV-SEM: semantics of the PROV-DM data model [[PROV-SEM]];</li>
+</ul>
+
+
+ <section id="structure-of-this-document">
+<h3>Structure of this Document</h3>
+
+<div class='note'>TODO</div>
+
+<p>In <a href="#prov-dm-refinement">section 2</a>, further concepts underpinning PROV-DM are introduced.</p>
+
+<p><a href="#data-model-constraints">Section 3</a></p>
+
+
+<p><a href="#definitional-constraints">Section 4</a></p>
+
+<p><a href="#account-constraints">Section 5</a>
+</p>
+
+<p><a href="#interpretation">Section 6</a></p>
+<p><a href="#structural-constraints">Section 7</a></p>
+<p><a href="#collection-constraints">Section 8</a></p>
+<p><a href="#refining-provenance-descriptions">Section 9</a> successively review refined provenance descriptions, and examine their meaning, in light of the constraints introduced in previous sections. </p>
+
+
+
+ </section>
+
+
+
+ <section id="conventions">
+<h3>Conventions</h3>
+
+
+
+<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [[!RFC2119]].</p>
+ </section>
+
+</section>
+
+
+<section id='prov-dm-refinement'>
+<h2>Data Model Refinement</h2>
+
+<p>Underpinning the PROV-DM data model is a notion of event, marking transitions in the world (when entities are generated, used, or destroyed, or activities started or ended). This notion of event is not first-class in the data model, but underpins many of its concepts and its semantics [[PROV-SEM]]. Thus, using this notion of event, we can provide an interpretation for the data model, which in turn can allow creators of provenance assertions to make their assertions more robust. </p>
+
+
+ <section id='section-time-event'>
+<h4>Time and Event</h4>
+
+<p>Time is critical in the context of provenance, since it can help corroborate provenance claims. For instance, if an entity is claimed to be obtained by transforming another, then the
+latter must have existed before the former. If it is not the case, then there is something wrong with such a provenance claim. </p>
+
+<p> Although time is critical, we should also recognize that provenance can be used in many different contexts: in a single system, across the Web, or in spatial data management, to name a
+few. Hence, it is a design objective of PROV-DM to minimize the assumptions about time, so that PROV-DM can be used in varied contexts. </p>
+
+
+<p>Furthermore, consider two activities that started at the same time
+instant. Just by referring to that instant, we cannot distinguish
+which activity start we refer to. This is particularly relevant if we
+try to explain that the start of these activities had different
+reasons. We need to be able to refer to the start of an activity as a
+first class concept, so that we can talk about it and about its
+relation with respect to other similar starts. </p>
+
+
+<p>Hence, in our conceptualization of the world, an <em>instantaneous event</em>, or <dfn id="dfn-event">event</dfn> for short, happens in the world and marks a change in the world, in its
+activities and in its entities.
+The term "event" is commonly used in process algebra with a similar meaning. For instance, in CSP [[CSP]], events represent communications or interactions; they are assumed to be atomic and
+instantaneous.</p>
+
+
+
+
+<section id="types-of-events">
+<h4>Types of Events</h4>
+
+<p>Four kinds of <a title="event">instantaneous events</a> underpin the PROV-DM data model. The <strong>activity start</strong> and <strong>activity end</strong> events demarcate the
+beginning and the end of activities, respectively. The <strong>entity generation</strong> and <strong>entity usage</strong> events demarcate the characterization interval for entities. More
+specifically:
+
+</p>
+
+<p>An <dfn id="dfn-generation-event">entity generation event</dfn> is the <a title="event">instantaneous event</a> that marks the final instant of an entity's creation timespan, after which
+it is no longer available for use.</p>
+
+<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a title="event">instantaneous event</a> that marks the first instant of an entity's consumption timespan by an activity.</p>
+
+<p>An <dfn id="dfn-destruction-event">entity destruction event</dfn> is the <a title="event">instantaneous event</a> that marks the initial instant of an entity's destruction timespan, after which
+it no longer becomes available for use.</p>
+
+<div class='note'>Tentative definition of destruction!</div>
+
+
+<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a title="event">instantaneous event</a> that marks the instant an activity starts.</p>
+
+<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a title="event">instantaneous event</a> that marks the instant an activity ends.</p>
+
+</section>
+
+<section id="event-ordering">
+<h4>Event Ordering</h4>
+
+<p>To allow for minimalistic clock assumptions, like Lamport
+[[CLOCK]], PROV-DM relies on a notion of relative ordering of <a title="event">instantaneous events</a>,
+without using physical clocks. This specification assumes that a partial order exists between <a title="event">instantaneous events</a>.
+</p>
+
+
+<p>Specifically, <dfn id="dfn-follows">follows</dfn> is a partial
+order between <a title="event">instantaneous events</a>, indicating that an <a title="event">instantaneous event</a> occurs at the same time as or after another.
+For symmetry, <dfn id="dfn-precedes">precedes</dfn> is defined as
+the inverse of follows. (Hence, these relations are reflexive and transitive.)</p>
+
+
+<p> How such partial order is realized in practice is beyond the scope
+of this specification. This specification only assumes that
+each <a title="event">instantaneous event</a> can be mapped to an instant in some form of
+timeline. The actual mapping is not in scope of this
+specification. Likewise, whether this timeline is formed of a single
+global timeline or whether it consists of multiple Lamport's style
+clocks is also beyond this specification. It is anticipated
+that <a>follows</a> and <a>precedes</a> correspond to some ordering
+over this timeline.
+</p>
+
+
+<p>This specification introduces a set of "temporal interpretation"
+rules allowing the derivation of <a title="event">instantaneous event</a> ordering constraints from
+provenance descriptions. According to such temporal interpretation,
+descriptions MUST satisfy such constraints. We note that the
+actual verification of such ordering constraints is outside the
+scope of this specification. </p>
+
+<p>PROV-DM also allows for time observations to be inserted in specific
+descriptions, for each recognized <a title="event">instantaneous event</a> introduced
+in this specification. The presence of a time observation for a
+given <a title="event">instantaneous event</a> fixes the mapping of this <a title="event">instantaneous event</a> to the
+timeline. It can also help with the verification of associated
+ordering constraints (though, again, this verification is outside the
+scope of this specification).
+</p>
+
+
+
+</section>
+
+ </section>
+
+
+
+ <section id='section-attributes'>
+<h4>Attributes in Entities and Beyond </h4>
+
+<p>When we talk about things in the world in natural language and even when we assign identifiers, we are often imprecise in ways that make it difficult to clearly and unambiguously report
+provenance: a resource with a URL may be understood as referring to a report available at that URL, the version of the report available there today, the report independent of where it is
+hosted over time, etc.</p>
+
+<p>From a provenance viewpoint, it is important to identify a "<em>partial state</em>" of something, i.e. something with some aspects that have been fixed, so that it becomes possible to express its provenance, and what causes that thing, with these specific aspects to be as such. </p>
+
+<p>It is the purpose of attributes in PROV-DM to help fix some aspect of entities.
+Indeed, we previously defined
+entities as things in the world one wants to provide provenance for;
+we refine this definition as follows, using attribute-values to describe entities' "partial states", and linking them to the very existence of entities.</p>
+
+<p>
+An <dfn>entity</dfn> is a thing in the world one wants to provide provenance for and whose situation in the world is represented by some attribute-value pairs; an entity's attribute-value pairs remain unchanged during an entity's characterization interval, which is defined as the period comprised between its <a title="entity generation event">generation event</a> and its <a title="entity destruction event">destruction event</a>.</p>
+
+<p>An entity fixes some aspects of a thing and its situation in the
+world. An alternative entity may fix other aspects, and its provenance
+may be different.</p>
+
+
+
+
+
+
+<div class="anexample" id="a-report-example">
+Different users may take different perspectives on a resource with
+a URL. For each perspective, an entity may be expressed:
+<ul>
+<li>a report available at a URL: fixes the nature of the thing, i.e. a document, and its location; </li>
+<li>the version of the report available there today: fixes its version number, contents, and its date;</li>
+<li>the report independent of where it is hosted and of its content over time: fixes the nature of the thing as a conceptual artifact.</li></ul>
+The provenance of these three entities may differ, and may be along the following lines:
+<ul>
+<li>the provenance of a report available at a URL may include: the act of publishing it and making it available at a given location, possibly under some license and access control;</li>
+<li>the provenance of the version of the report available there today may include: the authorship of the specific content, and reference to imported content;</li>
+<li>the provenance of the report independent of where it is hosted over time may include: the motivation for writing the report, the overall methodology for producing it, and the broad team
+involved in it.</li>
+</ul>
+</div>
+
+<p>We do not assume that any entity is more important than any other; in fact, it is possible to describe the processing that occurred for the report to be commissioned, for
+individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity with attribute-value pairs that fix some aspect of the report appropriately.</p>
+
+<p>Attributes are not restricted to entities, but they belong to a variety of PROV-DM objects, including activities, activity associations, responsibility chains, generations, usages, derivations, and alternates. Each object has its duration interval, and attribute-value pairs for a given object, are expected to be unchanged for the object's duration.</p>
+</section>
+
+
+
+ <section id="representation-term-assertion-inference">
+<h3>Description, Assertion, and Inference</h3>
+
+<p>
+PROV-DM is a provenance data model designed to express <em>descriptions</em> of the world.
+</p>
+
+<div class="anexample">
+A file at some point during its lifecycle, which includes multiple edits by multiple people, can be described by its type, its location in the file system, a creator, and content.
+</div>
+
+
+<p>The data model is designed to capture activities that happened in the past, as opposed to activities
+that may or will happen.
+However, this distinction is not formally enforced.
+Therefore, all PROV-DM descriptions SHOULD be interpreted as what has happened, as opposed to what may or will happen.</p>
+
+
+
+<p>
+This specification does not prescribe the means by which descriptions can be arrived at; for example, descriptions can be composed on the basis of observations, reasoning, or any other means.
+</p>
+
+
+<p>
+Sometimes, inferences about the world can be made from descriptions
+conformant to the PROV-DM data model. When this is the case, this
+specification defines such inferences, allowing new descriptions
+to be inferred from existing ones. Hence, descriptions of the world
+can result either from direct assertion or from inference
+by application of inference rules defined by this specification.
+</p>
+
+
+
+</section>
+<div class='issue'> We need to refine the definition of entity and activity, and all the concepts in general. This is <a href="http://www.w3.org/2011/prov/track/issues/223">ISSUE-223</a>.</div>
+
+
+
+
+ <section id="account-and-accountEntity">
+ <h3>Account and AccountEntity</h3>
+
+
+<p>It is common for multiple provenance records to co-exist. For
+instance, when emailing a file, there could be a provenance record
+kept by the mail client, and another by the mail server. Such
+provenance records may provide different explanations about something
+happening in the world, because they are created by different parties
+or observed by different witnesses. A given party could also create
+multiple provenance records about an execution, to capture different
+levels of details, targeted at different end-users: the programmer of
+an experiment may be interested in a detailed log of execution, while
+the scientists may focus more on the scientific-level description.
+Given that multiple provenance records can co-exist, it is important
+to have details about their origin, who they are attributed to, how
+they were generated, etc. In other words, an important requirement is
+to be able to express the provenance of provenance. </p>
+
+<p>
+ <span class="glossary" id="glossary-account">
+An <dfn>account</dfn> is a named bundle of provenance descriptions.
+</span> PROV-DM does not provide an actual mechanism for creating accounts, i.e. for bundling up provenance descriptions and naming them. Accounts MUST satisfy some properties:
+<ul>
+<li>An account can be seen as a container of provenance descriptions, hence its content MAY change over time.</li>
+<li>If an account's set of descriptions changes over time, it increases monotonically with time. </li>
+<li>A given description of e.g. an entity in a given account, in terms of its identifier and attribute-value pairs, does not change over time. </li>
+</ul>
+
+<div class='note'>
+The last point is important and needs to be discussed by the Working Group.
+It indicates that within an account:
+<ul>
+<li>It is always possible to add new provenance descriptions, e.g. stating that a given entity was used by an activity. This is very much an open world assumption.
+<li>It is not permitted to add new attributes to a given entity (a form of closed world assumption from the attributes point of view), though it is always permitted to create a new description for an entity, which is a "copy" of the original description extended with novel attributes (cf Example <a href="#merge-with-rename">merge-with-rename</a>).
+</ul>
+</div>
+
+<p>
+There is no construct in PROV-DM to create such named bundles. Instead, it is assumed that some mechanism, outside PROV-DM can create them. However, from a provenance viewpoint, such accounts are things we may want to describe the provenance of. In order to be able to do so, we need to see accounts as entities, whose origin can be described using PROV-DM vocabulary. Thus, PROV-DM introduces the reserved type AccountEntity, defined as follows:
+<span class="glossary" id="glossary-entity">
+ <dfn id="concept-accountEntity">AccountEntity</dfn> is the category of entities that are accounts, i.e. named bundles of provenance descriptions.
+</span>
+</p>
+
+ </section>
+</section>
+
+
+
+<section id="data-model-constraints">
+<h2>Constraints Applicable to PROV-DM </h2>
+
+<p>In [[PROV-DM]], a data model for provenance has been defined without introducing any constraint that this data model has to satisfy. In <a href="#prov-dm-refinement">Section 2</a>, various notions have been introduced, attributes, event, entity interval, activity interval, accounts, which underpin the PROV-DM data model. Using these notion, we explore the constraints
+that the PROV-DM data model has to satisfy. </p>
+
+<div class='note'>
+<p> Overview the kind of constraints</p>
+<ul>
+<li>Definitional constraints (<a href="#definitional-constraints">Section 4</a>)</li>
+<li>Account constraints (<a href="#account-constraints">Section 5</a>)</li>
+<li>Event ordering constraints (<a href="#interpretation">Section 6</a>)</li>
+<li>Structural constraints (<a href="#structural-constraints">Section 7</a>)</li>
+<li>Collection constraints (<a href="#collection-constraints">Section 8</a>)</li>
+</ul>
+</div>
+
+</section>
+
+<section id="definitional-constraints">
+
+<h2>PROV-DM Definitional Constraints and Inferences</h2>
+
+<p>In this section, we revisit elements and relations of PROV-DM, and examine and examine the constraints associated with their definitions. </p>
+
+
+<div class='note'>
+Proposing to remove the subsections in this section, since some have no constraints.
+</div>
+
+
+ <section id="term-element">
+<h3>Element</h3>
+
+<div class="issue">
+There is still some confusion about what the identifiers really denote. For instance, are they entity identifiers or entity record identifiers. This is <a
+href="http://www.w3.org/2011/prov/track/issues/183">ISSUE-183</a>.
+An example and questions appear in <a href="http://www.w3.org/2011/prov/track/issues/215">ISSUE-215</a>. A related issued is also raised in <a
+href="http://www.w3.org/2011/prov/track/issues/145">ISSUE-145</a>.
+</div>
+
+ <section id="term-Entity">
+
+<h4>Entity</h4>
+
+
+<p>
+An <dfn>entity</dfn> is a thing in the world one wants to provide provenance for and whose situation in the world is represented by some attribute-value pairs; an entity's attribute-value pairs remain unchanged during an entity's characterization interval,
+ i.e. a continuous interval between two <a title="event">instantaneous events</a> in the world, namely its <a title="entity generation event">generation event</a> and its <a title="entity destruction event">destruction event</a>.</p>
+
+
+Further considerations:
+<ul>
+<li>In order to describe something over several intervals, it is required to create multiple entities (either by direct
+assertion or by inference), each with its own identifier (so as to allow potential dependencies between the various entity records).
+
+
+</li>
+
+<li>There is no assumption that the set of attributes is complete and that the attributes are independent or orthogonal of each other.</li>
+
+<li>A characterization interval may collapse into a single instant.</li>
+
+
+
+</ul>
+
+
+
+<div class='issue'>The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define alternateOf and specializationOf more precisely.
+Beginning and end of characterization interval could be expressed by attributes (similarly to activities).
+How do we define the end of an entity? This is <a href="http://www.w3.org/2011/prov/track/issues/204">ISSUE-204</a>.
+</div>
+
+
+
+
+ </section>
+
+ <section id="term-Activity">
+
+<h3>Activity</h3>
+
+
+
+<p>An activity is anything that involves entities. An activity is delimited by its <a title="activity start event">start</a> and its <a title="activity end event">end</a> events; hence, it occurs over
+an interval delimited by two <a title="event">instantaneous events</a>. However, an activity need not mention time information, nor duration, because they may not be known.
+An activity's attribute-value pairs remain unchanged during an activity's interval, i.e. an interval between two instantaneous events in the world, namely its <a title="activity start event">start</a> event and its <a title="activity end event">end</a> event.
+</p>
+
+<div class="interpretation-forward">
+For the interpretation of an activity, see <a href="#start-precedes-end">start-precedes-end</a>.
+</div>
+
+</section>
+
+<section id="term-Agent">
+<h3>Agent</h3>
+
+
+
+
+<div class='issue'> Shouldn't we allow for entities (not agent) to be associated with an activity? Should we drop the inference association-agent? <a
+href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.
+
+<p>One can assert an agent record or alternatively, one can infer an agent record
+by its association with an activity. </p>
+
+<div class='inference' id='association-agent'>
+<span class='conditional'>If</span> the records <span class="name">entity(e,attrs)</span>
+and
+<span class="name">wasAssociatedWith(a,e)</span> hold for some identifiers
+<span class="name">a</span>, <span class="name">e</span>, and attribute-values <span class="name">attrs</span>, then
+the record <span class="name">agent(e,attrs)</span> also holds.
+</div>
+
+</div>
+
+</section>
+
+ <section id="term-note">
+
+<h4>Note</h4>
+
+<p>Attribute-value pairs occurring in notes are application specific. Thus, their interpretation is outside the scope of this document, and they are not subject to any of the constraints listed in this document. </p>
+
+
+
+ </section>
+
+</section>
+
+
+<section id="term-relation">
+<h3>PROV-DM Relations</h3>
+
+
+
+<section id="term-Generation">
+<h4>Generation</h4>
+
+
+<p>A <dfn id="dfn-Generation">generation</dfn> is an instantaneous world <a title="entity generation event">event</a>, the completed creation of a new
+entity by an activity. This entity become available for usage after this <a title="event">instantaneous
+event</a>. This entity did not exist before creation.
+ This <a title="event">instantaneous event</a> encompasses a description of the modalities of generation of this entity by this activity, by means of key-value pairs.</p>
+
+
+
+<p>
+A generation's id is OPTIONAL. It MUST be used when annotating generations (see Section <a href="#term-annotation">Annotation</a>) or when defining precise-1
+derivations (see <a href="#Derivation-Relation">Derivation</a>).
+</p>
+
+
+<div class="interpretation-forward">
+For the interpretation of a generation, see <a href="#generation-within-activity">generation-within-activity</a>.
+</div>
+
+
+
+<p></p>
+<div class="structural-forward">
+See <a href="#generation-uniqueness">generation-uniqueness</a> for a structural constraint on generations.
+</div>
+
+
+
+</section>
+
+
+<section id="term-Usage">
+<h3>Usage</h3>
+
+
+
+<p>A <dfn id="dfn-Use">usage</dfn> is an instantaneous world <a title="entity usage event">event</a>: an activity beginning to consume an entity.
+Before this event, the activity had not begun to consume or use to this entity.
+ The description includes the modalities of usage of this entity by this activity.</p>
+
+
+
+
+<p>
+A usage id is OPTIONAL. It MUST be present when annotating usages (see Section <a href="#term-annotation">Annotation</a>) or when defining precise-1 derivations (see
+<a href="#Derivation-Relation">Derivation</a>).</p>
+
+<p>
+A reference to a given entity MAY appear in multiple usages for a given activity identifier.
+</p>
+
+
+<div class="interpretation-forward">
+For the interpretation of a usage, see <a href="#generation-precedes-usage">generation-precedes-usage</a> and <a href="#usage-within-activity">usage-within-activity</a>.
+</div>
+
+
+
+</section>
+
+
+
+
+
+
+<section id="term-ActivityAssociation">
+<h4>Activity Association</h4>
+
+<div class="interpretation-forward">
+For the interpretation of an activity association, see <a href="#wasAssociatedWith-ordering">wasAssociatedWith-ordering</a>.
+</div>
+
+
+<div class='issue'> The activity association record does not allow for a plan to be asserted without an agent.
+This seems over-restrictive. Discussed in the context of <a href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
+
+
+<div class='issue'> Agents should not be inferred. WasAssociatedWith should also work with entities.
+This is <a href="http://www.w3.org/2011/prov/track/issues/206">ISSUE-206</a>.</div>
+
+
+</section>
+
+<section id="term-Start-End">
+<h4>Start and Ends</h4>
+
+
+<div class='issue'>
+Should we define start/end records as representation of activity start/end events.
+Should time be associated with these events rather than with activities. This will be similar to what
+we do for entities. This is issue <a href="http://www.w3.org/2011/prov/track/issues/207">ISSUE-207</a>.</div>
+
+
+</section>
+
+
+
+
+
+
+
+<section id="term-responsibility">
+
+<h4>Responsibility Chain</h4>
+
+
+Nothing here.
+
+</section>
+
+<section id="Derivation-Relation">
+<h4>Derivation</h4>
+
+
+
+<p>A precise-1 derivation is richer than an imprecise-1 derivation, itself, being more informative that an imprecise-n derivation Hence, the following implications
+hold.</p>
+<div class='inference' id='derivation-implications'>
+Given two entities denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the assertion <span class="name">wasDerivedFrom(e2,
+e1, a, g2, u1, attrs)</span>
+ holds for some generation identified by <span class="name">g2</span>, and usage identified by <span class="name">u1</span>, then <span
+class="name">wasDerivedFrom(e2,e1,[prov:steps="single"] ∪ attrs)</span> also holds.<br>
+
+Given two entities denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> the assertion <span class="name">wasDerivedFrom(e2,
+e1, [prov:steps="single"] ∪ attrs)</span>
+ holds, then <span class="name">wasDerivedFrom(e2,e1,attrs)</span> also holds.<br>
+ </div>
+
+<div class="interpretation-forward">
+For the interpretation of a derivation, see <a href="#derivation-usage-generation-ordering">derivation-usage-generation-ordering</a> and <a
+href="#derivation-generation-generation-ordering">derivation-generation-generation-ordering</a>
+</div>
+
+
+<p>The imprecise-1 derivation has the same meaning as the precise-1
+ derivation, except that an activity
+ is known to exist, though it does not need to be
+asserted. This is formalized by the following inference rule,
+referred to as <em>activity introduction</em>:</p>
+<div class='inference' id="activity-introduction">
+<span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> there exist an activity, with identifier <span
+class="name">a</span>, a usage identified by <span class="name">u</span>, and a generation identified by <span class="name">g</span>
+such that:
+<pre class="codeexample">
+activity(a,aAttrs)
+wasGeneratedBy(g,e2,a,gAttrs)
+used(u,a,e1,uAttrs)
+</pre>
+for sets of attribute-value pairs <span class="name">gAttrs</span>, <span class="name">uAttrs</span>, and <span class="name">aAttrs</span>.
+</div>
+
+
+
+
+
+<p>
+Note that inferring derivation from usage and generation does not hold
+in general. Indeed, when a generation <span class="name">wasGeneratedBy(g, e2, a, attrs2)</span>
+<a>precedes</a> <span class="name">used(u, a, e1, attrs1)</span>, for
+some <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">attrs1</span>, <span class="name">attrs2</span>, and <span class="name">a</span>, one
+cannot infer derivation <span class="name">wasDerivedFrom(e2, e1, a, g, u)</span>
+or <span class="name">wasDerivedFrom(e2,e1)</span> since
+of <span class="name">e2</span> cannot possibly be derived from
+ <span class="name">e1</span>, given the creation of <span class="name">e2</span> <a>precedes</a> the use
+of <span class="name">e1</span>.
+</p>
+
+
+<p>The effective placeholder for an entity generation time is <a>generation</a>. The presence of
+time information in imprecise derivations is merely a convenience notation for a timeless derivation and a generation with this generation time information. </p>
+
+<div class='inference' id="derivation-time-elimination">
+<span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1,t,attrs)</span> holds, <span class='conditional'>then</span> the following expressions also hold:
+<span class="name">wasDerivedFrom(e2,e1,attrs)</span> and <span class="name">wasGeneratedBy(e2,t)</span>.
+</div>
+
+<p></p>
+<div class="structural-forward">
+See <a href="#derivation-use">derivation-use</a> for a structural constraint on derivations.
+</div>
+
+
+
+
+
+<div class='issue'>Several points were raised about the attribute steps.
+Its name, its default value <a href="http://www.w3.org/2011/prov/track/issues/180">ISSUE-180</a>.
+ <a href="http://www.w3.org/2011/prov/track/issues/179">ISSUE-179</a>.</div>
+
+<div class='issue'> Emphasize the notion of 'affected by' <a href="http://www.w3.org/2011/prov/track/issues/133">ISSUE-133</a>.</div>
+
+<div class='issue'> Simplify derivation <a href="http://www.w3.org/2011/prov/track/issues/249">ISSUE-249</a>.</div>
+
+
+</section>
+
+
+<section id="term-alternate-specialization">
+
+<h4>Alternate and Specializations</h4>
+
+<p>Nothing to add here</p>
+
+ <div class="note">
+In order to further convey the intended meaning, the following properties are associated to these two relations.
+
+ <ul>
+ <li><span class="name">specializationOf(e2,e1)</span> is <strong>transitive</strong>: <span class="name">specializationOf(e3,e2)</span> and <span
+class="name">specializationOf(e2,e1)</span> implies <span class="name">specializationOf(e3,e1)</span>.
+
+ <li><span class="name">specializationOf(e2,e1)</span> is <strong>anti-symmetric</strong>: <span class="name">specializationOf(e2,e1)</span> implies that <span
+class="name">specializationOf(e1,e2)</span> does not hold.
+ <li><span class="name">alternateOf(e2,e1)</span> is <strong>symmetric</strong>: <span class="name">alternateOf(e2,e1)</span> implies <span class="name">alternateOf(e1,e2)</span>.
+ </ul>
+
+There are proposals to make alternateOf a transitive property. This is still under discussion and the default is for alternateOf <strong>not</strong> to be transitive, and this is what the current text reflects.</div>
+
+
+<div class='issue'>A discussion on alternative definition of these relations has not reached a satisfactory conclusion yet. This is <a
+href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a>. Also <a href="http://www.w3.org/2011/prov/track/issues/96">ISSUE-96</a>.</div>
+
+
+</section>
+
+
+
+
+
+
+
+
+
+
+</section>
+
+
+
+
+ <section id="common-relations">
+<h2>PROV-DM Common Relations</h2>
+
+<p>This section contains constraints associated with PROV-DM common relations.</p>
+
+
+
+
+
+<section id="term-traceability">
+<h3>Traceability</h3>
+
+
+<p>Traceability can be inferred from existing descriptions, or can be asserted stating that a dependency path exists without its individual steps being expressed. This is captured
+by the following inference and constraint, respectively.
+
+<div class='inference' id='traceability-inference'>
+Given two identifiers <span class="name">e2</span> and <span class="name">e1</span> for entities,
+the following statements hold:
+
+<ol>
+<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span
+class="name">u1</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also
+holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr) and wasAssociatedWith(a,e1)</span> hold, for some <span class="name">a</span> and <span
+class="name">gAttr</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span
+class="name">actedOnBehalfOf(e,e1)</span> hold, for some <span class="name">a</span>, <span class="name">e</span>, and <span class="name">gAttr</span>, <span
+class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+<li><span class='conditional'>If</span> <span class="name">wasGeneratedBy(e2,a,gAttr) and wasStartedBy(a,e1,sAttr)</span> hold, for some <span class="name">a</span>, <span
+class="name">e</span>, and <span class="name">gAttr</span>, and <span class="name">sAttr</span>, <span class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also
+holds.</li>
+<li><span class='conditional'>If</span> <span class="name">tracedTo(e2,e)</span> and <span class="name">tracedTo(e,e1)</span> hold for some <span class="name">e</span>, <span
+class='conditional'>then</span> <span class="name">tracedTo(e2,e1)</span> also holds.</li>
+</ol>
+</div>
+
+<p>We note that the inference rule <a href="#traceability-inference">traceability-inference</a> does not allow us to infer attributes, which are application specific. </p>
+
+<div class='constraint' id='traceability-assertion'>
+<span class='conditional'>If</span> <span class="name">tracedTo(r2,r1,attrs)</span> holds for two identifiers <span class="name">r2</span> and <span class="name">r1</span>
+identifying entities, and attribute-value pairs <span class="name">attrs</span>,
+ <span class='conditional'>then</span> there exist
+<span class="name">e<sup>0</sup></span>, <span class="name">e<sup>1</sup></span>, ..., <span class="name">e<sup>n</sup></span> for <span class="name">n≥1</span>, with <span
+class="name">e<sup>0</sup></span>=<span class="name">r2</span> and <span class="name">e<sup>n</sup></span>=<span class="name">r1</span>, and
+for any i such that <span class="name">0≤i≤n-1</span>, at least of the following statements holds:
+<ul>
+<li> <span class="name">wasDerivedFrom(e<sup>i</sup>,e<sup>i+1</sup>,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span class="name">u1</span>,
+or</li>
+<li> <span class="name">wasDerivedFrom(e<sup>i</sup>,e<sup>i+1</sup>)</span> holds, or</li>
+<li> <span class="name">wasBasedOn(e<sup>i</sup>,e<sup>i+1</sup>)</span> holds, or</li>
+<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasAssociatedWith(a,e<sup>i+1</sup>)</span> hold, for some <span class="name">a</span> and <span
+class="name">gAttr</span>, or</li>
+<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span class="name">actedOnBehalfOf(e,e<sup>i+1</sup>)</span> hold,
+for some <span class="name">a</span>, <span class="name">e</span> and <span class="name">gAttr</span>, or</li>
+<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasStartedBy(a,e<sup>i+1</sup>,sAttr)</span> hold, for some <span class="name">a</span>, <span class="name">e</span>, and
+<span class="name">gAttr</span>, and <span class="name">sAttr</span>.</li>
+</ul>
+</div>
+
+<p>We note that the previous constraint is not really an inference <em>rule</em>, since there is nothing that we can actually infer. Instead, this constraint should simply be seen as part
+of the definition of the traceability relation. </p>
+
+
+</section>
+
+<section id="term-OrderingOfActivities">
+<h3>Activity Ordering</h3>
+
+
+
+<p> An information flow ordering relation is formally defined as follows.</p>
+
+<div class='constraint' id='wasInformedBy-Definition'>Given two activities identified by <span class="name">a1</span> and <span class="name">a2</span>,
+ <span class="name">wasInformedBy(a2,a1)</span>
+holds, <span class='conditional'>if and only if</span>
+ there is an entity with some identifier <span class="name">e</span> and some sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
+such that <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">used(a2,e,attrs2)</span> hold.
+</div>
+
+
+<div class="interpretation-forward">
+For the interpretation of an information flow ordering, see <a href="#wasInformedBy-ordering">wasInformedBy-ordering</a>.
+</div>
+
+
+<p>The relationship <span class="name">wasInformedBy</span> is not transitive. Indeed, consider the following fragment.</p>
+<pre class="codeexample">
+wasInformedBy(a2,a1)
+wasInformedBy(a3,a2)
+</pre>
+<p> We cannot infer <span class="name">wasInformedBy(a3,a1)</span> from these expressions. Indeed,
+from
+<span class="name">wasInformedBy(a2,a1)</span>, we know that there exists <span class="name">e1</span> such that <span class="name">e1</span> was generated by <span class="name">a1</span>
+and used by <span class="name">a2</span>. Likewise, from <span class="name">wasInformedBy(a3,a2)</span>, we know that there exists <span class="name">e2</span> such that <span
+class="name">e2</span> was generated by <span class="name">a2</span> and used by <span class="name">a3</span>. The following illustration shows a case for which transitivity cannot hold. The
+horizontal axis represents the event line. We see that <span class="name">e1</span> was generated after <span class="name">e2</span> was used. Furthermore, the illustration also shows that
+<span class="name">a3</span> completes before <span class="name">a1</span>. So it is impossible for <span class="name">a3</span> to have used an entity generated by <span
+class="name">a1</span>.</p>
+
+<div style="text-align: center;">
+<figure>
+<img src="../informedByNonTransitive.png" alt="non transitivity of wasInformedBy" />
+<figcaption>Counter-example for transitivity of wasInformedBy</figcaption>
+</figure>
+</div>
+
+<p>Control ordering between two activities denoted by <span class="name">a2</span> and <span class="name">a1</span> is specified as follows.</p>
+
+<div class='constraint' id='wasStartedBy'>Given two activities with identifiers <span class="name">a1</span> and <span class="name">a2</span>,
+ <span class="name">wasStartedBy(a2,a1)</span>
+holds <span class='conditional'>if and only if</span>
+ there exist an entity with some identifier <span class="name">e</span>
+and some attributes <span class="name">gAttr</span> and <span class="name">sAttr</span>,
+such that
+ <span class="name">wasGeneratedBy(e,a1,gAttr)</span>
+ and <span class="name">wasStartedBy(a2,e,sAttr)</span> hold.
+</div>
+
+<p>We note that an activity start associates an activity with an agent, and is denoted by the name <span class="name">wasStartedBy</span>. A <a>control ordering</a> relation associates an
+activity with another activity, also denoted by the name <span class="name">wasStartedBy</span>. Effectively, by considering both relation types, the relation <span
+class="name">wasStartedBy</span> has a range formed by the union of agents and activities.</p>
+
+
+
+<div class="interpretation-forward">
+For the interpretation of a control flow ordering, see <a href="#wasStartedBy-ordering">wasStartedBy-ordering</a>.
+</div>
+
+
+</section>
+
+<section id="term-Revision">
+<h3>Revision</h3>
+
+
+
+<p>A revision needs to satisfy the following constraint, linking the two entities by a derivation, and stating them to be a specialization of a third entity.</p>
+
+<div class='inference' id='wasRevision'>
+Given two identifiers <span class="name">old</span> and <span class="name">new</span> identifying two entities, and an identifier <span class="name">ag</span> identifying an agent,
+<span class='conditional'>if</span> <span class="name">wasRevisionOf(new,old,ag)</span> holds, <span class='conditional'>then</span>
+there exists an entity with some identifier <span class="name">e</span> and some attribute-values <span class="name">eAttrs</span>, <span class="name">dAttrs</span>, such that the following
+hold:
+<ul>
+<li> <span class="name">wasDerivedFrom(new,old,dAttrs)</span>;
+<li> <span class="name">entity(e,eAttrs)</span>;
+<li> <span class="name">specializationOf(new,e)</span>;
+<li> <span class="name">specializationOf(old,e)</span>.
+</ul>
+The derivation may be imprecise-1 or imprecise-n.
+</div>
+
+<p><span class="name">wasRevisionOf</span> is a strict sub-relation
+ of <span class="name">wasDerivedFrom</span> since two entities <span class="name">e2</span> and <span class="name">e1</span>
+ may satisfy <span class="name">wasDerivedFrom(e2,e1)</span> without being a variant of
+ each other.
+</p>
+
+
+</section>
+
+
+<section id="recod-attribution">
+<h3>Attribution</h3>
+
+
+<div class='inference' id='attribution-implication'>
+<span class='conditional'>If</span>
+<span class="name">wasAttributedTo(e,ag)</span> holds for some identifiers
+<span class="name">e</span> and <span class="name">ag</span>,
+<span class='conditional'>then</span>, there exists an activity with some identifier <span class="name">a</span> such that the following statements hold:
+<pre>
+activity(a,t1,t2,attr1)
+wasGenerateBy(e,a)
+wasAssociatedWith(a,ag,attr2)
+</pre>
+for some sets of attribute-value pairs <span class="name">attr1</span> and <span class="name">attr2</span>, time <span class="name">t1</span>, and <span class="name">t2</span>.
+</div>
+
+</section>
+
+
+<section id="term-quotation">
+<h3>Quotation</h3>
+
+
+<div class='inference' id='quotation-implication'>
+<span class='conditional'>If</span>
+<span class="name">wasQuotedFrom(e2,e1,ag2,ag1,attrs)</span> holds for some identifiers
+<span class="name">e2</span>, <span class="name">e1</span>, <span class="name">ag2</span>, <span class="name">ag1</span>,
+<span class='conditional'>then</span> the following hold:
+<pre>
+wasDerivedFrom(e2,e1)
+wasAttributedTo(e2,ag2)
+wasAttributedTo(e1,ag1)
+</pre>
+</div>
+
+</section>
+
+
+<section id="term-summary">
+<h3>Summary</h3>
+
+<div class='issue'>Drop this relation <a href="http://www.w3.org/2011/prov/track/issues/220">ISSUE-220</a>.</div>
+
+
+
+</section>
+
+<section id="term-orignal-source">
+<h3>Original Source</h3>
+
+<p>Nothing specific.</p>
+
+</section>
+
+
+
+<section id="term-Collection">
+<h3>Collections</h3>
+
+<p>Nothing specific, here, everything in Collection constraint section</p>
+
+</section>
+
+ </section>
+
+</section>
+
+
+
+<section id="account-constraints">
+<h3>PROV-DM Account Constraints</h3>
+
+
+<p>PROV-DM allows for multiple descriptions of entities (and in general any identifiable object) to be expressed. </p>
+
+<div class="anexample" id="example-two-entities-one-id">
+<p>Let us consider two descriptions of a same entity, which we have taken from two different contexts (see example). A working draft published by the <span class="name">w3:Consortium</span>:</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+</pre>
+The second version of a document edited by some authors:
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
+</pre>
+<p>Both descriptions are about the same entity identified by
+<span class="name">tr:WD-prov-dm-20111215</span>, but they contain different attributes, reflecting the context in which they occur.
+</p>
+</div>
+
+
+
+<p>Two different descriptions of a same entity cannot co-exist in a same account
+ as formalized in <a href="#unique-description-in-account">unique-description-in-account</a>.</p>
+
+<div class='constraint' id='unique-description-in-account'>
+<p>Given an entity identifier <span class="name">e</span>, there is at most one description
+<span class="name">entity(e,av)</span> occurring in a given account, where <span class="name">av</span> is some set of attribute-values. Other descriptions of the same entity can exist in different accounts.</p>
+
+<p>This constraint similarly applies to all other types of identifiable entities and relations.</p>
+</div>
+
+<p>
+ <div class="structural-forward">
+ See Section <a href="#structural-constraints">structural-constraints</a> for a structural constraint on accounts
+ </div>
+</p>
+
+<p>In some cases, there may be a requirement for the two descriptions to be included in a same account. To satisfy the constraint <a href="#unique-description-in-account">unique-description-in-account</a>, we can adopt a different identifier for one of them, and relate the two descriptions with the <span class="name">alternateOf</span> relation. </p>
+
+<div class="anexample" id="merge-with-rename">
+<p>We now reconsider the same two descriptions of a same entity, but we change the identifier for one of them:</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+entity(ex:alternate-20111215, [ prov:type="document", ex:version="2" ])
+alternateOf(tr:WD-prov-dm-20111215,ex:alternate-20111215)
+alternateOf(ex:alternate-20111215,tr:WD-prov-dm-20111215)
+</pre>
+</div>
+
+
+</section>
+
+
+ <section id="interpretation">
+<h3>PROV-DM Event Ordering Constraints</h3>
+
+<p>Section <a href="#section-time-event">section-time-event</a>
+introduces a notion of <a title="event">instantaneous event</a>
+marking changes in the world, in its activities and entities. PROV-DM
+identifies five kinds of <a title="event">instantaneous events</a>, namely <a>entity generation
+event</a>, <a>entity usage event</a>, <a>entity destruction event</a>, <a>activity start event</a>
+and <a>activity end event</a>. PROV-DM adopts Lamport's clock
+assumptions [[CLOCK]] in the form of a reflexive, transitive partial order <a>follows</a>
+(and its inverse <a>precedes</a>) between <a title="event">instantaneous events</a>. Furthermore,
+PROV-DM assumes the existence of a mapping from <a title="event">instantaneous events</a> to time clocks,
+though the actual mapping is not in scope of this specification.</p>
+
+<p>Given that provenance consists of a description of past entities
+and activities, to be meaningful provenance descriptions MUST
+satisfy <em>instantaneous event ordering constraints</em>, which we introduce in
+this section. For instance, an entity can only be used after it was
+generated; hence, we say that an entity's <a title="entity generation
+event">generation event</a> precedes any of this
+entity's <a title="entity usage event">usage event</a>. Should this
+ordering constraint be proven invalid, the associated generation and
+usage could not be credible. The rest of this section defines
+the <dfn>temporal interpretation</dfn> of provenance descriptions as a
+set of instantaneous event ordering constraints. </p>
+
+
+<p>PROV-DM also allows for time observations to be inserted in
+specific provenance descriptions, for each of the four kinds
+of <a title="event">instantaneous events</a> introduced in this specification. The
+presence of a time observation for a given <a>instantaneous event</a> fixes the
+mapping of this <a>instantaneous event</a> to the timeline. The presence of time
+information in a provenance description instantiates the ordering constraint with
+that time information. It is expected that such instantiated
+constraint can help corroborate provenance information. We anticipate
+that verification algorithms could be developedm, though this
+verification is outside the scope of this specification.
+</p>
+
+<p>The following figure summarizes the ordering constraints in a
+graphical manner. For each subfigure, an event time line points to the
+right. Activities are represented by rectangles, whereas entities are
+represented by circles. Usage, generation and derivation are
+represented by the corresponding edges between entities and
+activities. The four kind of <a title="event">instantaneous events</a> are represented by vertical
+dotted lines (adjacent to the vertical sides of an activity's
+rectangle, or intersecting usage and generation edges). The ordering
+constraints are represented by triangles: an occurrence of a triangle between two <a title="event">instantaneous event</a> vertical dotted lines represents that the event denoted by the left
+line precedes the event denoted by the right line.</p>
+
+<div style="text-align: center;">
+<figure>
+<img src="../constraints.png" alt="constraints between events" />
+<figcaption id="constraint-summary">Summary of <a title="event">instantaneous event</a> ordering constraints</figcaption>
+</figure>
+</div>
+
+
+<p>The mere existence of an activity entails some <a>event</a> ordering in the world, since an <a>activity start event</a> always <a>precedes</a> the corresponding <a>activity end
+event</a>. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (a) and expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p>
+
+<div class='interpretation' id='start-precedes-end'> The following ordering constraint holds for any activity: the
+<a title="activity start event">start event</a> <a>precedes</a> the <a title="activity end event">end event</a>.</div>
+
+<p> A usage and a generation for a given entity implies ordering of <a title="event">events</a> in the world, since the <a title="entity generation
+event">generation event</a> had to precede the <a title="entity usage event">usage event</a>. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (b) and expressed by constraint <a href="#generation-precedes-usage">generation-precedes-usage</a>.</p>
+
+<div class='interpretation' id='generation-precedes-usage'>For any entity, the following ordering constraint holds: the <a title="entity generation event">generation</a> of an entity always
+<a>precedes</a> any of its <a title="entity usage event">usages</a>.
+</div>
+
+<p>A usage implies ordering of <a title="event">events</a> in the world, since the <a title="entity usage event">usage event</a> had to occur during the associated activity. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (c) and expressed by constraint <a href="#usage-within-activity">usage-within-activity</a>.</p>
+
+<div class='interpretation' id='usage-within-activity'>Given an activity with identifier <span class="name">a</span>, an entity with identifier <span class="name">e</span>, a set
+of attribute-value pairs <span class="name">attrs</span>, and optional time <span class="name">t</span>, <span class='conditional'>if</span>
+ assertion <span class="name">used(a,e,attrs)</span> or <span class="name">used(a,e,attrs,t)</span> holds, <span class='conditional'>then</span> the following ordering constraint holds:
+ the <a title="entity usage event">usage</a> of the entity denoted by <span class="name">e</span> <a>precedes</a> the <a title="activity end event">end</a> of
+activity denoted by <span class="name">a</span> and <a>follows</a> its <a title="activity start event">start</a>.
+</div>
+
+
+
+<p>A generation implies ordering of <a title="event">events</a> in the world, since the <a title="entity generation event">generation event</a> had to occur during the associated activity. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (d) and expressed by constraint <a href="#generation-within-activity">generation-within-activity</a>.</p>
+
+<div class='interpretation' id='generation-within-activity'>Given an activity with identifier <span class="name">a</span>, an entity with identifier <span class="name">e</span>, a set
+of attribute-value pairs <span class="name">attrs</span>, and optional time <span class="name">t</span>, <span class='conditional'>if</span> <span class="name">wasGeneratedBy(e,a,attrs)</span> or <span
+class="name">wasGeneratedBy(e,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following ordering constraint also holds: the <a title="entity generation
+event">generation</a> of the entity denoted by <span class="name">e</span> <a>precedes</a> the <a title="activity end event">end</a>
+of activity <span class="name">a</span> and <a>follows</a> the <a title="activity start event">start</a> of <span class="name">a</span>.
+</div>
+
+
+
+
+<p>If there is a derivation between <span class="name">e2</span> and <span class="name">e1</span>, then
+this means that the entity <span class="name">e1</span> had some form of influence on the entity <span class="name">e2</span>; for this to be possible, some event ordering must be satisfied.
+First, we consider one-activity derivations. In that case, the <a title="entity usage event">usage</a> of <span class="name">e1</span> has to precede the <a title="entity generation
+event">generation</a> of <span class="name">e2</span>.
+This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (e) and expressed by constraint <a
+href="#derivation-usage-generation-ordering">derivation-usage-generation-ordering</a>.</p>
+
+
+<div class='interpretation' id='derivation-usage-generation-ordering'>Given an activity with identifier <span class="name">a</span>, entities with identifier <span
+class="name">e1</span> and <span class="name">e2</span>, a generation identified by <span class="name">g2</span>, and a usage identified by <span class="name">u1</span>, <span
+class='conditional'>if</span> <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
+or <span class="name">wasDerivedFrom(e2,e1,[prov:steps="single"] ∪ attrs)</span> holds, <span class='conditional'>then</span>
+the following ordering constraint holds:
+the <a title="entity usage event">usage</a>
+of entity denoted by <span class="name">e1</span> <a>precedes</a> the <a title="entity generation event">generation</a> of
+the entity denoted by <span class="name">e2</span>.
+</div>
+
+<p>For imprecise-n derivations, a similar constraint exists, but in this case, no usage can be inferred for <span class="name">e1</span>. Instead, the constraint refers to its
+generation event, as
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (f) and expressed by constraint <a
+href="#derivation-generation-generation-ordering">derivation-generation-generation-ordering</a>.</p>
+
+<div class='interpretation' id='derivation-generation-generation-ordering'>
+Given two entities denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class='conditional'>if</span> <span
+class="name">wasDerivedFrom(e2,e1,[prov:steps="any"] ∪ attrs)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraint holds:
+the <a title="entity generation event">generation event</a> of the entity denoted by <span class="name">e1</span> <a>precedes</a> the <a title="entity generation event">generation event</a>
+of
+the entity denoted by <span class="name">e2</span>.
+ </div>
+
+<p>Note that event ordering is between generations of <span class="name">e1</span>
+and <span class="name">e2</span>, as opposed to precise-1 derivation,
+which implies ordering ordering between the usage of <span class="name">e1</span> and
+generation of <span class="name">e2</span>. Indeed, in the case of
+imprecise-n derivation, nothing is known about the usage of <span class="name">e1</span>,
+since there is no associated activity.</p>
+
+<p> Information flow ordering between two activities <span class="name">a1</span> and <span class="name">a2</span> also implies ordering of <a
+title="event">events</a> in the world, since some entity must have been generated by the former and used by the later, which implies that the start event of <span class="name">a1</span>
+cannot follow the end event of <span class="name">a2</span>. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (g) and expressed by constraint <a href="#wasInformedBy-ordering">wasInformedBy-ordering</a>.</p>
+
+<div class='interpretation' id='wasInformedBy-ordering'>
+Given two activities denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> <span
+class="name">wasInformedBy(a2,a1)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraint holds:
+the <a title="activity start event">start event</a> of the activity denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity end event">end event</a> of
+the activity denoted by <span class="name">a2</span>.
+</div>
+
+<p>Control flow ordering between two activities <span class="name">a1</span> and <span class="name">a2</span> also implies ordering of <a
+title="event">events</a> in the world, since <span class="name">a1</span> must have been active before <span class="name">a2</span> started. This is
+illustrated by Subfigure <a href="#constraint-summary">constraint-summary</a> (h) and expressed by constraint <a href="#wasStartedBy-ordering">wasStartedBy-ordering</a>.</p>
+
+
+<div class='interpretation' id='wasStartedBy-ordering'>
+Given two activities denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class='conditional'>if</span> <span
+class="name">wasStartedBy(a2,a1)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraint holds: the
+<a title="activity start event">start</a> event of the activity denoted by <span class="name">a1</span> <a>precedes</a> the <a title="activity start event">start event</a> of
+the activity denoted by <span class="name">a2</span>.
+</div>
+
+<div class='issue'>In the following, we assume that we can talk about the end of an entity (or agent)
+For this, we use the term 'destruction' This is <a href="http://www.w3.org/2011/prov/track/issues/204">ISSUE-204</a>.
+</div>
+
+
+<p>Further constraints appear in Figure <a href="#constraint-summary2">constraint-summary2</a> and are discussed below.</p>
+
+<div style="text-align: center;">
+<figure>
+<img src="../constraints2.png" alt="further constraints between events" />
+<figcaption id="constraint-summary2">Summary of <a title="event">instantaneous event</a> ordering constraints (continued)</figcaption>
+</figure>
+</div>
+
+
+<p>An agent that started an activity must exist when the activity starts.
+This is
+illustrated by Subfigure <a href="#constraint-summary2">constraint-summary2</a> (a) and expressed by constraint <a href="#wasStartedByAgent-ordering">wasStartedByAgent-ordering</a>.</p>
+
+
+<div class='interpretation' id='wasStartedByAgent-ordering'>
+Given an activity denoted by <span class="name">a</span> and an agent denoted by <span class="name">ag</span>, <span class='conditional'>if</span> <span
+class="name">wasStartedBy(a,ag)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraints hold: the
+<a title="activity start event">start</a> event of the activity denoted by <span class="name">a</span> <a>follows</a> the <a title="entity generation event">generation event</a> for agent denoted by <span class="name">ag</span>, and
+<a>precedes</a> the destruction event of
+the same agent.
+</div>
+
+
+<p>An activity that was associated with an agent must have some overlap with the agent. The agent may be generated, or may only become associated with the activity, after its start: so, the agent is required to exist before the activity end. Likewise, the agent may be destructed, or may terminate its association with the activity, before the activity end: hence, the agent destruction is required to happen after the activity start.
+This is
+illustrated by Subfigure <a href="#constraint-summary2">constraint-summary2</a> (b) and expressed by constraint <a href="#wasAssociatedWith-ordering">wasAssociatedWith-ordering</a>.</p>
+
+
+<div class='interpretation' id='wasAssociatedWith-ordering'>
+Given an activity denoted by <span class="name">a</span> and an agent denoted by <span class="name">ag</span>, <span class='conditional'>if</span> <span
+class="name">wasAssociatedWith(a,ag)</span>
+ holds, <span class='conditional'>then</span> the following ordering constraints hold: the
+<a title="activity start event">start</a> event of the activity denoted by <span class="name">a</span>
+precedes the destruction event of
+the agent denoted by <span class="name">ag</span>, and
+ the <a title="entity generation event">generation event</a> for agent denoted by <span class="name">ag</span>
+<a>precedes</a> the activity <a title="activity end event">end</a> event.
+</div>
+
+
+<div class="issue">
+For completeness, we should define ordering constraint for wasAssociatedWith and actedOnBehalfOf.
+For wasAssociatedWith(a,ag), it feels that ag must have some overlap with a.
+For actedOnBehalfOf(ag1,ag2,a), it seem that ag2 should have existed before the overlap between ag1 and a. This is <a href="http://www.w3.org/2011/prov/track/issues/221">ISSUE-221</a>.
+</div>
+
+
+<div class="issue">
+It is suggested that a stronger name for wasAssociatedWith should be adopted.
+This is <a href="http://www.w3.org/2011/prov/track/issues/182">ISSUE-182</a>.
+</div>
+
+</section>
+
+<section id="structural-constraints">
+<h3>PROV-DM Structural Constraints</h3>
+
+<p><a href="#definitional-constraints">Section 4</a> provides definitional constraints for data model concepts.
+<a href="#account-constraints">Section 5</a> introduces constraints on descriptions occurring in accounts.
+<a href="#interpretation">Section 6</a> defines an interpretation of this data model, in terms of event ordering
+constraints.
+This section introduces further constraints on the structure of PROV-DM descriptions. Descriptions that satisfy these constraints are said to be <dfn>structurally well-formed</dfn>. A
+benefit of structurally well-formed provenance descriptions is that further inferences can be made, because descriptions are more precise, and therefore, richer. </p>
+
+<p>According to the definition of a <a>generation</a>, an entity becomes available after this entity's generation event, and does not exist before this event. From this definition,
+we conclude that PROV-DM does not allow for an entity to have two generations occurring at two different instants.
+The rationale for this constraint is as follows.
+ Two distinct <a title="entity generation event">generation events</a> (by a same activity or by two distinct activities), occurring one after the other, necessarily create two distinct
+entities; otherwise, the second <a title="entity generation event">generation event</a> would have resulted in an entity that existed before its creation, which contradicts the definition of
+<a>generation</a>.</p>
+
+<p>So, PROV-DM allows for two distinct <a>generations</a> <span class="name">g1</span> and <span class="name">g2</span> referencing a same entity provided they occur
+<em>simultaneously</em>.
+<!-- (This means that <span class="name">g1</span> <a>precedes</a> <span class="name">g2</span> and <span class="name">g2</span> <a>precedes</a> <span class="name">g1</span>.) -->
+ In practice, for such a simultaneous generation to occur, the generation event has to be unique and caused by a <em>single world activity</em>, though provenance may contain
+several descriptions for the <em>same</em> world activity.
+</p>
+
+<div class="anexample">
+<p>
+In the following assertions, a workflow execution <span class="name">a0</span> consists of two sub-workflow executions <span class="name">a1</span> and <span class="name">a2</span>.
+Sub-workflow execution <span class="name">a2</span> generates entity <span class="name">e</span>, so does <span class="name">a0</span>.</p>
+<pre class="codeexample">
+activity(a0,,,[prov:type="workflow execution"])
+activity(a1,,,[prov:type="workflow execution"])
+activity(a2,,,[prov:type="workflow execution"])
+wasInformedBy(a2,a1)
+
+wasGeneratedBy(e,a0)
+wasGeneratedBy(e,a2)
+</pre>
+<p>So, we have two different <a title="generation">generations</a> for entity <span class="name">e</span>. Such an example is permitted in PROV-DM if the two activities denoted by <span class="name">a0</span> and <span class="name">a2</span> are a single thing happening in the world
+but described from different perspectives.</p>
+</div>
+
+<p>While this example is permitted in PROV-DM, it does not make the inter-relation between activities explicit, and it mixes descriptions expressed from different perspectives together.
+While this may acceptable in some specific applications, it becomes challenging for inter-operability. Indeed, PROV-DM does not offer any relation describing the structure of activities.
+ Such descriptions are said not be structurally well-formed.</p>
+
+<p>Structurally well-formed provenance can be obtained by partitioning the generations into different accounts. This makes it clear that these generations provide alternative
+descriptions of the same real-world generation event, rather than describing two distinct generation events for the same entity. When accounts are used, the example can be encoded as follows.</p>
+
+
+<div class="anexample">
+<p>
+The same example is now revisited, with the following assertions that are structurally well-formed. Two accounts are introduced, and there is a single generation for entity <span
+class="name">e</span> per account.</p>
+
+<p>In a first account, entitled "summary", we find:</p>
+<pre class="codeexample">
+ activity(a0,t1,t2,[prov:type="workflow execution"])
+ wasGeneratedBy(e,a0)
+</pre>
+<p>In a second account, entitled "detail", we find:</p>
+<pre class="codeexample">
+ activity(a1,t1,t3,[prov:type="workflow execution"])
+ activity(a2,t3,t2,[prov:type="workflow execution"])
+ wasInformedBy(a2,a1)
+ wasGeneratedBy(e,a2)
+</pre>
+</div>
+
+
+
+<p>Structurally well-formed provenance satisfies some constraints, which force the structure of descriptions to be exposed by means of accounts. With these constraints satisfied, further
+inferences can be made about structurally well-formed descriptons.
+The uniqueness of generations in accounts is formulated as follows.
+</p>
+
+<div class='constraint' id='generation-uniqueness'>Given an entity denoted by <span class="name">e</span>, two activities denoted by <span class="name">a1</span> and <span
+class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
+<span class='conditional'>if</span> <span class="name">wasGeneratedBy(id1,e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(id2,e,a2,attrs2)</span> exist in the scope of a given
+account,
+<span class='conditional'>then</span> <span class="name">id1</span>=<span class="name">id2</span>, <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
+</div>
+
+
+
+<p>A further inference is permitted from the imprecise-1 derivations: </p>
+<div class='inference' id='derivation-use'>
+<p>Given an activity with identifier <span class="name">a</span>, entities denoted by <span class="name">e1</span> and <span class="name">e2</span>, and a set of attribute-value
+pairs <span class="name">attrs2</span>,
+<span class='conditional'>if</span> <span class="name">wasDerivedFrom(e2,e1, [prov:steps="single"])</span> and <span class="name">wasGeneratedBy(e2,a,attrs2)</span> hold, <span
+class='conditional'>then</span> <span class="name">used(a,e1,attrs1)</span> also holds
+for some set of attribute-value pairs <span class="name">attrs1</span>.
+</div>
+<p>This inference is justified by the fact that the entity denoted by <span class="name">e2</span> is generated by at most one activity in a given account
+(see <a href="#generation-uniqueness">generation-uniqueness</a>). Hence, this activity is also the one referred to by the usage of <span class="name">e1</span>.
+</p>
+
+
+
+<p>We note that the converse inference, does not hold.
+From <span class="name">wasDerivedFrom(e2,e1)</span> and <span class="name">used(a,e1)</span>, one cannot
+derive <span class="name">wasGeneratedBy(e2,a,attrs2)</span> because identifier <span class="name">e1</span> may occur in usages performed by many activities, which may have not generated the entity denoted by <span class="name">e2</span>.</p>
+
+
+<p>
+An account is said to be structurally well-formed if
+it satisfies the constraint <a href="#generation-uniqueness">generation-uniqueness</a>. If an account is structurally well-formed, it support the inference <a
+href="#derivation-use">derivation-use</a>.</p>
+
+<p> Taking the union of two accounts is another account,
+formed by the union of the descriptions they respectively contain. We note that the resulting union may or may not invalidate some constraints:
+<ul>
+<li> Two entity descriptions with a same identifier but different sets of attributes exist in each original account may invalidate <a href="#unique-description-in-account">unique-description-in-account</a> in the union, unless some form of description merging or renaming (as per <a href="#merge-with-rename">Example</a>) occurs.
+<li> Structurally well-formed
+accounts are not
+closed under union because the
+constraint <a href="#generation-uniqueness">generation-uniqueness</a> may no
+longer be satisfied in the resulting union. </li>
+</ul>
+<p>How to reconcile such accounts is beyond the scope of this specification.</p>
+
+<!--
+Indeed, let us reconsider example <a href="#account-example-1">account-example-1</a>, and let us define another account record as follows.</p>
+
+<div class="anexample">
+<pre class="codeexample">
+account(ex:acc2,
+ http://example.org/asserter2,
+ entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+ ...
+ activity(a1,t1,,[prov:type="createFile"])
+ ...
+ wasGeneratedBy(e0,a1,[ex:fct="create"])
+ ... )
+</pre>
+<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by
+entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span
+class="name">a0</span> in the previous account <span class="name">ex:acc0</span>. If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together,
+the resulting set of records violates <a href="#generation-uniqueness">generation-uniqueness</a> if the two activities <span class="name">a0</span> and <span class="name">a1</span> are
+distinct.</p>
+</div>
+-->
+
+<div class="note">
+Can the semantics characterize better what can be achieved with structurally well-formed accounts?
+</div>
+
+
+<div class="note" id="note-related-to-issue-105">
+Satya discussed the example of a sculpture, whose hand and leg are sculpted independently by two different sculptors. He suggested that the sculpture is generated by two distinct activities.
+This section explains that it is not the case. The example can be formulated as follows.
+
+<p><a href="examples/sculpture.prov-asn">Sculpture example in ASN</a></p>
+
+<p><a href="examples/sculpture.png">Sculpture example image</a></p>
+
+<p>
+We see that ex:s_3 (the sculpture in its final state) was derived from ex:l_2 (containment) which was generated by ex:a2. However, ex:s_3 is not directly generated by ex:a2. We may want to
+consider an abbreviation for this: wasGeneratedBy*(ex:s_3,ex:a2).</p>
+</div>
+
+
+</section>
+
+
+
+
+
+<section id="collection-constraints">
+<h3>PROV-DM Collection Constraints</h3>
+
+<div class='note'>
+Raw material taken from prov-dm3. Some further text required.
+</div>
+
+
+<div class='constraint' id='collection-parallel-insertions'>
+<p>One can have multiple assertions regarding the state of a collection following a <em>set</em> of insertions, for example:</p>
+<pre class="codeexample">
+CollectionAfterInsertion(c2, c1, k1, v1)
+CollectionAfterInsertion(c2, c1, k2, v2)
+...
+</pre>
+<p>This is interpreted as <em>" <span class="name">c2</span> is the state that results from inserting <span class="name">(k1, v1)</span>, <span class="name">(k2, v2)</span> etc. into <span class="name">c1</span>"</em></p>
+</div>
+
+<div class='note'>
+Shouldn't we have the same for deletion, and combination of insertion and deletion?
+</div>
+
+
+<div class='constraint' id='collection-branching-derivations'>
+It is possible to have multiple derivations from a single root collection, as shown in the following example.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="EmptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+ entity(v3)
+ entity(c1, [prov:type="Collection"])
+ entity(c2, [prov:type="Collection"])
+ entity(c3, [prov:type="Collection"])
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 = { (k1,v1) }
+ CollectionAfterInsertion(c2, c, k2, v2) // c2 = { (k2 v2) }
+ CollectionAfterInsertion(c3, c1, k3,v3) // c3 = { (k1,v1), (k3,v3) }
+</pre>
+</div>
+</div>
+
+
+
+
+
+
+<div class='constraint' id='collection-unique-ancestor'>
+Given the pair of assertions:
+<pre class="codeexample">
+CollectionAfterInsertion(c, c1, k1, v1)
+CollectionAfterInsertion(c, c2, k2, v2)
+</pre>
+it follows that <span class="name">c1==c2</span>.
+</div>
+
+<div class='note'>
+Original text stated it follows that <span class="name">c1==c2, k1==k2, v1==v2</span>, because one cannot have two different derivations for the same final collection state. This is incompatible with parallel insertion constraint.
+</div>
+
+
+<div class='note'>
+Shouldn't we have the same for deletion, and combination of insertion and deletion?
+</div>
+
+
+
+
+<div class='constraint' id='collection-unique-value-for-key'>
+Given the following set of insertions:
+<pre class="codeexample">
+CollectionAfterInsertion(c1, c, k, v1)
+CollectionAfterInsertion(c1, c, k, v2)
+</pre>
+it follows that <span class="name">v1==v2</span>.
+</div>
+
+
+<p>The state of a collection is only known to the extent that a chain of derivations starting from an empty collection can be found. Since a set of assertions regarding a collection's evolution may be incomplete, so is the reconstructed state obtained by querying those assertions. In general, all assertions reflect the asserter's partial knowledge of a sequence of data transformation events. In the particular case of collection evolution, in which the asserter <em>knows</em> that some of the state changes may have been missed, then the more generic <a href="#Derivation-Relation">derivation</a> relation should be used to signal that some updates may have occurred, which cannot be precisely asserted as insertions or removals. The following two examples illustrate this.</p>
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="collection"]) // e is a collection, possibly not empty
+ entity(v1)
+ entity(v2, [prov:type="collection"]) // v2 is a collection
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 <em>includes</em> { (k1,v1) } but may contain additional unknown pairs
+ CollectionAfterInsertion(c2, c1, k2, v2) // c2 includes { (k1,v1), (k2 v2) } where v2 is a collection with unknown state
+</pre>
+</div>
+ In the example, the state of <span class="name">c2</span> is only partially known because the collection is constructed from partially known other collections.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="emptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 = { (k1,v1) }
+ wasDerivedFrom(c2, c1) // the asserted knows that c2 is somehow derived from c1, but cannot assert the precise sequence of updates
+ CollectionAfterInsertion(c3, c2, k2, v2)
+</pre>
+
+<p>Here <span class="name">c3</span> includes <span class="name">{ (k2 v2) }</span> but the earlier "gap" leaves uncertainty regarding <span class="name">(k1,v1)</span> (it may have been removed) or any other pair that may have been added as part of the derivation activities.</li></p>
+</div>
+
+</section>
+
+
+<!--
+<section id="resource-section">
+<h2>Resources, URIs, Entities, Identifiers, and Scope</h2>
+
+<p>This specification introduces the notion of an identifiable entity in the world. In PROV-DM, an entity record is a representation of such an identifiable entity. An entity record
+includes an identifier identifying this entity. Identifiers are qualified names, which can be mapped to IRIs. </p>
+
+<p>The term 'resource' is used in a general sense
+ for whatever might be identified by a URI [[!RFC3986]]. On the Web, a URI denotes a resource, without any expectation that the resource is accessed. </p>
+
+<p>The purpose of this section is to clarify the relationship between resource and the notions of entity and entity record. </p>
+
+<p>In the context of PROV-DM, a resource is just a thing in the world. One may take multiple perspectives on such a thing and its situation in the world, fixing some its aspects.</p>
+
+<p> We refer to the <a href="#a-report-example">example</a> of section <a href="#conceptualization">2.1</a> for a resource (at some URL) and three different perspectives, referred to as
+entities. Three different entity records can be expressed for this report, which in the PROV-ASN sample below, are expressed within a same account.
+</p>
+
+<pre>
+container
+prefix app http://example.org/app/
+prefix cr http://example.org/crime/
+
+ account(acc1,
+ http://example.org/asserter1,
+
+ entity(app:0, [ prov:type="Document", cr:path="http://example.org/crime.txt" ])
+ entity(app:1, [ prov:type="Document", cr:path="http://example.org/crime.txt", cr:version="2.1", cr:content="...", cr:date="2011-10-07" ])
+ entity(app:2, [ prov:type="Document", cr:author="John" ])
+ ...)
+endContainer
+</pre>
+
+<p>Each entity record contains an identifier that is unique in
+account <span class="name">acc1</span>, and therefore locally
+identifies the entity record it is contained in. In this example,
+three identifiers were minted.</p>
+
+<p>Given that the report is a resource denoted by the URI <span class="name">http://example.org/crime.txt</span>, we could simply use this URI as the identifier of an entity. This would
+avoid us minting new URIs. Hence, the report URI would play a double role: as a URI it denotes a resource accessible at that URI, and as an identifier in a PROV-DM record, it helps identify
+a specific characterization of this report. A given identifier occurring in an entity record must be unique within the scope of an account. Hence, below, all entities records have been given
+the same identifier but appear in the scope of different accounts, so as to satisfy <a href="#identifiable-term-in-account">identifiable-term-in-account</a>.</p>
+
+<pre>
+container
+prefix app http://example.org/
+prefix cr http://example.org/crime/
+
+ account(acc2,
+ http://example.org/asserter1,
+
+ entity(app:crime.txt, [ prov:type="Document", cr:path="http://example.org/crime.txt" ])
+ ...)
+
+ account(acc3,
+ http://example.org/asserter1,
+
+ entity(app:crime.txt, [ prov:type="Document", cr:path="http://example.org/crime.txt", cr:version="2.1", cr:content="...", cr:date="2011-10-07" ])
+ ...)
+
+ account(acc4,
+ http://example.org/asserter1,
+ entity(app:crime.txt, [ prov:type="Document", cr:author="John" ])
+ ...)
+endContainer
+</pre>
+
+<p>In this case, the qualified name <span class="name">app:crime.txt</span> maps to URI <span class="name">http://example.org/crime.txt</span> still denotes the same resource; however, the
+perspectives we take about that resource are expressed by multiple entity records, happening to all contain the same identifier but in different accounts. </p>
+
+<p> Alternatively, if we need to assert the existence of two different perspectives on the report within the same account, then alternate identifiers MUST be used, one of them being allowed
+to be the resource URI.</p>
+
+<pre>
+container
+ prefix app http://example.org/
+ prefix app2 http://example.org/app/
+ prefix cr http://example.org/crime/
+
+ account(acc5,
+ http://example.org/asserter1,
+
+ entity(app:crime.txt, [ prov:type="Document", cr:path="http://example.org/crime.txt" ])
+ entity(app2:1, [ prov:type="Document", cr:path="http://example.org/crime.txt", cr:version="2.1", cr:content="...", cr:date="2011-10-07" ])
+
+ ...)
+endContainer
+
+</pre>
+
+
+</section>
+
+-->
+
+<!--
+<li>For use, generation, and derivation event, the first argument is the 'effect' (i.e. most recent item) and the second argument is the 'cause' (i.e. least recent item). This order is
+compatible with the temporal layout of the graphical notation.
+-->
+
+<section id="refining-provenance-descriptions">
+<h3>Refining Provenance Descriptions</h3>
+
+<div class='note'>Purely tentative</div>
+
+<p>In this section, we successively review refined provenance descriptions, and examine their meaning, in light of the constraints introduced in this specification. </p>
+
+
+<ol>
+<li>First, let us consider a small set of three descriptions, including an entity, an agent, and an attribution relation.
+<pre>
+entity(tr:prov-dm)
+agent(w3:Consortium)
+wasAttributedTo(tr:prov-dm,w3:Consortium)
+</pre>
+<p>The entity denoted by <span class="name">tr:prov-dm</span> does not contain any attribute besides its identifier. Without any further detail, this entity is simply the resource denoted by <span class="name">tr:prov-dm</span>, whatever its state over time. This resource has multiple versions including <span class="name">tr:WD-prov-dm-20111215</span> and <span class="name">tr:WD-prov-dm-20111018</span>.
+Likewise, the second line simply is a description for a resource denoted by <span class="name">w3:Consortium</span>, nothing less, nothing more.</p>
+<p>The third description should be interpreted as: whatever changes entity <span class="name">tr:prov-dm</span> may have gone through, it is always attributed to the <span class="name">w3:Consortium</span> agent.</p>
+</li>
+
+
+<li>Second, the descriptions are bundled up as an account with name <span class="name">ex:acc1</span>:
+<pre>
+entity(tr:prov-dm)
+agent(ex:Simon)
+wasAttributedTo(tr:prov-dm,ex:Simon)
+</pre>
+and provenance details are available for <span class="name">ex:acc1</span>, namely the generation time for the provenance.
+<pre>
+entity(ex:acc1, [prov:type="AccountEntity"])
+wasGeneratedBy(ex:acc1,,2011-12-15T12:00:00)
+</pre>
+<div class='note'>
+What is the meaning here? Is it any different? Are stating anything about newer version of tr:prov-dm that occur after 2011-12-15T12:00:00?
+</div>
+
+<li> A generation event for <span class="name">tr:prov-dm</span> is provided.
+<pre>
+entity(tr:prov-dm)
+agent(ex:Simon)
+wasGeneratedBy(tr:prov-dm,,2011-12-15T12:00:00)
+wasAttributedTo(tr:prov-dm,ex:Simon)
+</pre>
+<div class='note'>
+What is the meaning here? that only the version that was created by this event is attributed to ex:Simon, but not previous ones. This means that it is not specfied whether he was an author in anterior versions.
+</div>
+
+</li>
+
+
+<li> A destruction event for <span class="name">tr:prov-dm</span> is provided.
+<pre>
+entity(tr:prov-dm)
+agent(ex:Simon)
+wasGeneratedBy(tr:prov-dm,,2011-12-15T12:00:00)
+wasDestroyedBy(tr:prov-dm,,2012-02-02T12:00:00)
+wasAttributedTo(tr:prov-dm,ex:Simon)
+</pre>
+<div class='note'>
+Speculative, since we have not defined the destruction event (yet?.
+What is the meaning here? that only the versions that existed during this characterization interval were attributed to ex:Simon.
+</div>
+</li>
+
+</ol>
+
+</section>
+
+<!--
+<section>
+<h3>Stuff to Keep, Maybe?</h3>
+
+
+
+
+<li id='attribute-occurrence-in-entity-record'>The attributes
+occurring in an entity record MUST be declared in the namespace
+referred to by their prefix according to
+<a href="#term-attribute">Section term-attribute</a>. Furthermore,
+for each attribute, a namespace also declares the number of
+occurrences it may have in a list of attributes. An entity record is
+valid if the number of occurrences of any of its attributes is
+compatible with this attribute's declaration it its namespace. This
+property applies to all types of records, and is referred to
+as <a>attribute occurrence validity</a>.</li>
+
+
+</section>
+-->
+
+<section class="appendix">
+ <h2>Acknowledgements</h2>
+ <p>
+ WG membership to be listed here.
+ </p>
+ </section>
+
+ </body></html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/prov-dm.html Thu Feb 23 22:00:02 2012 +0000
@@ -0,0 +1,2249 @@
+<!DOCTYPE html>
+
+<html><head>
+ <title>PROV-DM Part 1: The Provenance Data Model</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+<!-- PM -->
+ <style type="text/css">
+ .note { font-size:small; margin-left:50px }
+ </style>
+
+ <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
+ <script src="http://www.w3.org/2007/OWL/toggles.js" class="remove"></script>
+ <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js" class="remove"></script>
+
+ <script src="glossary.js" class="remove"></script>
+
+ <script class="remove">
+ function updateGlossaryRefs() {
+ $('.glossary-ref').each(function(index) {
+ var ref=$(this).attr('ref');
+ var span=$(this).attr('withspan')
+ $('#'+ref+'.glossary').contents().clone().appendTo($(this));
+ $(this).attr('prov:hadOriginalSource',glossary_hg);
+ if (span) {
+ $(this).children('dfn').replaceWith(function(){return $('<span>').addClass('dfn').append($(this).contents())});
+ }
+ });
+ }
+ $(document).ready(function(){
+ // if glossary is in a string:
+ $('#glossary_div').html(glossary_string)
+ updateGlossaryRefs();
+ });
+
+ </script>
+
+ <script class="remove">
+ var addExtraReferences = function() {
+ for (var k in extraReferences)
+ berjon.biblio[k] = extraReferences[k];
+ };
+ var extraReferences = {
+ "CLOCK":
+ "Lamport, L. "+
+ "<a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\"><cite>Time, clocks, and the ordering of events in a distributed system</cite></a>."+
+ "Communications of the ACM 21 (7): 558–565. 1978. "+
+ "URL: <a href=\"http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf\">http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf</a> " +
+ "DOI: doi:10.1145/359545.359563.",
+ "CSP":
+ "Hoare, C. A. R. "+
+ "<a href=\"http://www.usingcsp.com/cspbook.pdf\"><cite>Communicating Sequential Processes</cite></a>."+
+ "Prentice-Hall. 1985"+
+ "URL: <a href=\"http://www.usingcsp.com/cspbook.pdf\">http://www.usingcsp.com/cspbook.pdf</a>",
+ "Logic":
+ "W. E. Johnson"+
+ "<a href=\"http://www.ditext.com/johnson/intro-3.html\"><cite>Logic: Part III</cite></a>."+
+ "1924. "+
+ "URL: <a href=\"http://www.ditext.com/johnson/intro-3.html\">http://www.ditext.com/johnson/intro-3.html</a>",
+ "PROV-SEM":
+ "James Cheney "+
+ "<a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\"><cite>Formal Semantics Strawman</cite></a>. "+
+ "2011, Work in progress. "+
+ "URL: <a href=\"http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman\">http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman</a>",
+
+ "PROV-PRIMER":
+ "Yolanda Gil and Simon Miles (eds.) Khalid Belhajjame, Helena Deus, Daniel Garijo, Graham Klyne, Paolo Missier, Stian Soiland-Reyes, and Stephan Zednik "+
+ "<a href=\"http://www.w3.org/TR/prov-primer/\"><cite>Prov Model Primer</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-primer/\">http://www.w3.org/TR/prov-primer/</a>",
+
+ "PROV-O":
+ "Satya Sahoo and Deborah McGuinness (eds.) Khalid Belhajjame, James Cheney, Daniel Garijo, Timothy Lebo, Stian Soiland-Reyes, and Stephan Zednik "+
+ "<a href=\"http://www.w3.org/TR/prov-o/\"><cite>Provenance Formal Model</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-o/\">http://www.w3.org/TR/prov-o/</a>",
+
+
+ "PROV-DM":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-dm/\"><cite>PART 1: PROV-DM ...</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-dm/\">http://www.w3.org/TR/prov-dm/</a>",
+
+
+ "PROV-DM-CONSTRAINTS":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-dm-constraints/\"><cite>PROV-DM Constraints</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-dm-constraints/\">http://www.w3.org/TR/prov-dm-constraints/</a>",
+
+ "PROV-ASN":
+ "Luc Moreau and Paolo Missier (eds.) ... "+
+ "<a href=\"http://www.w3.org/TR/prov-asn/\"><cite>PROV-ASN ....</cite></a>. "+
+ "2011, Working Draft. "+
+ "URL: <a href=\"http://www.w3.org/TR/prov-asn/\">http://www.w3.org/TR/prov-asn/</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 : "Some speculative write-ups, for discussion before integration in the data model",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2011-10-18",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ //previousPublishDate: "2011-12-15",
+ //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/working-copy/towards-wd4.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css", "./extra.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Luc Moreau", url: "http://www.ecs.soton.ac.uk/~lavm/",
+ company: "University of Southampton" },
+ { name: "Paolo Missier", url: "http://www.cs.ncl.ac.uk/people/Paolo.Missier",
+ company: "Newcastle University" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+
+ // 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>
+<b>Editors' working copy can change at any time. </b>
+</p>
+ </section>
+
+<section id="sotd">
+<b>Editors' working copy can change at any time. </b>
+</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>
+
+
+
+
+<div class='note' id='changes'>
+<p> Following F2F2 guidance, in this document we try to:
+<ul>
+<li> pitch from the start the idea of an upgrade path, from 'scruffy provenance' (term TBD), to 'precise provenance' (term TBD)
+<li> formulate concepts without referring to things, just in term of entities, the intent is that the semantics only refers to things
+<li> introduce concepts minimally, just to be able to express 'scruffy provenance'
+<li> present the data model
+<li>present the upgrade path
+<li>contemplating the organization of the deliverable in two/three separate documents.</li>
+</ul>
+</div>
+
+
+
+<div class='note' id='editorial-notes'>
+<ul>
+<li> Term 'record' dropped: we no longer refer to 'entity record', 'activity record', etc but simply to 'entity', 'activity', etc
+<li> Aiming to drop the word 'assertion'. This is work in progress.
+<li> Aiming to drop the word 'characterization'.
+</ul>
+</div>
+
+
+ <section id="introduction">
+ <h2>Introduction<br>
+</h2>
+
+<p>
+For the purpose of this specification, <dfn>provenance</dfn> is defined as a record that describes the people,
+institutions, entities, and activities, involved in producing,
+influencing, or delivering a piece of data or a thing in the world.
+In particular, the provenance of information is crucial in deciding
+whether information is to be trusted, how it should be integrated with
+other diverse information sources, and how to give credit to its
+originators when reusing it. In an open and inclusive environment
+such as the Web, where users find information that is often contradictory or
+questionable, provenance can help those users to make trust judgements.
+</p>
+
+
+<p>
+The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to
+consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
+Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it,
+process it, and reason over it.</p>
+
+<p>Thus, the vision is that different provenance-aware systems natively adopt their own model for representing their provenance, but a core provenance data model can be readily adopted as a
+provenance <em>interchange</em> model across such systems.</p>
+
+<p>A set of specifications, referred to as the PROV family of specifications, define the various aspects
+that are necessary to achieve this vision in an interoperable
+way:</p>
+<ul>
+<li>A data model for provenance, which is presented in three documents:
+<ul>
+<li> PROV-DM (part I): the provenance data model itself, expressed in natural language (this document);
+<li> PROV-DM-CONSTRAINTS (part II): constraints underpinning the data model [[PROV-DM-CONSTRAINTS]];
+<li> PROV-ASN (part III): a notation to express instances of that data model for human consumption [[PROV-ASN]];
+</ul>
+</li>
+
+<li>PROV-O: a normative serialization of PROV-DM in RDF [[!PROV-O]], specified by means of a mapping to the OWL2 Web Ontology Language [[!OWL2-SYNTAX]];</li>
+<li>PROV-AQ: the mechanisms for accessing and querying provenance [[PROV-AQ]];</li>
+<li>PROV-PRIMER: a primer for the PROV approach [[PROV-PRIMER]];</li>
+<li>PROV-SEM: semantics of the PROV-DM data model [[PROV-SEM]];</li>
+</ul>
+
+
+<p>
+The PROV-DM data model for provenance consists of a set of core
+concepts, and a few common relations, based on these core concepts. PROV-DM is a domain-agnostic model, but with clear extensibility points allowing further domain-specific and
+application-specific extensions to be defined.</p>
+
+<p>This specification intentionally presents the key concepts of the PROV Data Model, without drilling down into all its subtleties. Using these key concepts, it becomes possible to write useful provenance assertions very quickly, and publish or embed them along side the data they relate to. </p>
+
+<p>However, it becomes challenging for provenance, like for any other form of metadata, when the data it is about changes. To address this challenge, an <em>upgrade path</em> is proposed to enrich simple provenance, with extra-descriptions that help qualify the subject of provenance and provenance itself, with attributes and interval, intended to satisfy a comprehensive set of constraints. These aspects are covered in the companion specification [[PROV-DM-CONSTRAINTS]].
+</p>
+
+
+ <section id="structure-of-this-document">
+<h3>Structure of this Document</h3>
+
+<p><a href="#prov-dm-overview">Section 2</a> provides an overview of PROV-DM listing its core types and their relations.</p>
+
+<p>In <a href="#prov-dm-example">section 3</a>, PROV-DM is
+applied to a short scenario, encoded in PROV-ASN, and illustrated
+graphically.</p>
+
+<p><a href="#data-model-concepts">Section 4</a> provides the definition of PROV-DM.</p>
+
+<p><a href="#common-relations">Section 5</a> introduces further relations offered by PROV-DM, including relations for data collections and domain-independent common relations.</p>
+
+<p><a href="#extensibility-section">Section 6</a> summarizes PROV-DM extensibility points.</p>
+
+<p><a href="#FurtherConsiderations">Section 7</a> introduces constraints that can be applied to the PROV data model
+and that are covered in [[PROV-DM-CONSTRAINTS]].</p>
+
+
+ </section>
+
+<section id="prov-dm-namespace">
+ <h3>PROV-DM Namespace</h3>
+
+
+<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
+
+<p> All the elements, relations, reserved names and attributes introduced in this specification belong to the PROV-DM namespace.</p>
+
+<div class="issue">
+There is a desire to use a single namespace that all specifications of the PROV family can share to refer to common provenance terms. This is <a href="http://www.w3.org/2011/prov/track/issues/224">ISSUE-224</a>.
+</div>
+
+</section>
+
+
+ <section id="conventions">
+<h3>Conventions</h3>
+
+
+
+<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [[!RFC2119]].</p>
+ </section>
+
+</section>
+
+
+
+ <section id='conceptualization'>
+<h1>Overview</h1>
+
+This section provides an overview of the main elements and relations of the PROV data model.
+
+
+
+ <section id='section-entity-activity-agent'>
+<h2>Entity, Activity, Agent</h2>
+
+
+<p>PROV-DM is a data model for describing the provenance of <em>Entities</em>, that is, of things in the world. The term "Things" encompasses a broad diversity of concepts, including digital objects such as a file or web page,
+physical things such as a building or a printed book, or a car as well as abstract concepts and ideas. One can regard any Web resource as an example of Entity in this context. </p>
+
+<p>
+<div class="glossary-ref" ref="glossary-entity">
+</div>
+</p>
+
+
+<div class="anexample" id="entity-example">
+<p>An entity may be the document at URI <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a>, a file in a file system, a car or an idea.</p>
+</div>
+
+
+
+<p>
+<span class="glossary-ref" ref="glossary-activity"></span> Activities that operate on digital entities may for example move, copy, or duplicate them.
+</p>
+
+
+
+<div class="anexample" id="activity-example">
+<p>An activity may be the publishing of a document on the web, sending a twitter message, extracting metadata embedded in a file, or driving a car from Boston to Cambridge, assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a SPARQL query over a triple store, and editing a file.</p>
+</div>
+
+
+<p>
+<span class="glossary-ref" ref="glossary-agent">
+</span>
+</p>
+
+
+<p>The key purpose of agents is to assign responsibility
+ for activities.
+The definition of agent intentionally stays away from using concepts such as enabling, causing, initiating, affecting, etc, because many entities also enable, cause, initiate, and affect in some way
+the activities. So the notion of having some degree of responsibility is really what makes an agent.</p>
+
+
+<p>An agent is a particular type of Entity. This means that the model can be
+ used to express provenance of the agents themselves. </p>
+
+<div class="anexample" id="agent-example">
+<p>
+Software for checking the use of grammar in a document may be defined as an agent of a document preparation activity, and at the same time one can describe its provenance, including for instance the vendor and the version history.</p>
+</div>
+</section>
+
+
+
+ <section id="section-generation-usage-derivation">
+<h2>Generation, Usage, Derivation</h2>
+
+<p>Activities and entities are associated with each other in two different ways: activities are consumers of entities and activities are producers of entities. For the purpose of provenance, we define the following notions of generation and usage. </p>
+
+<p>
+<div class="glossary-ref" ref="glossary-generation">
+</div>
+</p>
+
+<p>
+<div class="glossary-ref" ref="glossary-usage">
+</div>
+</p>
+
+
+
+<p><div class="anexample" id="generation-example">
+Examples of generation are the completed creation of a file by a
+program, the completed creation of a linked data set, and the completed
+publication of a new version of a document.
+</div>
+</p>
+
+<p>
+<div class="anexample" id="usage-example">
+Usage examples include a procedure beginning to consume an argument, a service starting to read a value on a port, a program beginning to read a configuration
+file, or the point at which an ingredient, such as eggs, is being added in a baking activity. Usage may entirely consume an entity (e.g. eggs are no longer available after being added to
+the mix); alternatively, a same entity may be used multiple times, possibly by different activities (e.g. a file on a file system can be read indefinitely).
+</div></p>
+
+
+<p>Activities are consumers of entities and producers of entities. In some case, the consumption of an entity influences the creation of another in some way. This notion is captured by derivations, defined as follows.</p>
+
+<p>
+<span class="glossary-ref" ref="glossary-derivation">
+</p>
+
+
+<div class="anexample" id="derivation-example">
+<p>Examples of derivation include the transformation of a relational table into a
+linked data set, the transformation of a canvas into a painting, the transportation of a work of art from London to New York, and a physical transformation such as the melting of ice into water.</p>
+</div>
+
+</section>
+
+ <section id="section-types-entities-agents">
+<h2>Types of Entities and Agents</h2>
+
+<p>There are some useful types of entities and agents that are commonly encountered in applications making data and documents available on the Web; we introduce them in this section. </p>
+
+<p>
+<span class="glossary-ref" ref="glossary-plan">
+</span>
+PROV-DM is not
+prescriptive about the nature of plans, their representation, the
+actions or steps they consist of, or their intended goals. Since plans may evolve over time,
+it may become necessary to track their provenance, so plans themselves are
+entities.</p>
+
+<div class="anexample" id="plan-example">
+<p>
+A plan can be a blog post tutorial for how to set up a web server, a list of instructions for a micro-processor execution, a cook's written recipe for a chocolate cake, or a workflow for a scientific experiment.
+</p>
+</div>
+
+<p>
+<span class="glossary-ref" ref="glossary-collection"></span> This concept allows for the provenance of the collection, but also of its constituents to be expressed. Such a notion of collection corresponds to a wide variety of concrete data structures, such as a <em>maps</em>, <em>dictionaries</em> or <em>associative arrays</em>.</p>
+
+<div class="anexample" id="collection-example">
+<p>
+An example of collection is an archive of documents. Each document has its own provenance, but the archive itself also has some provenance: who maintained it, which documents it contained at which point in time, how it was assembled, etc.
+</div>
+
+
+<!-- alternative names: provenance record, bundle -->
+<p>An <dfn title="concept-accountEntity">AccountEntity</dfn> is an entity that contains a bundle of provenance assertions. </p>
+
+<div class="anexample" id="account-example">
+<p>
+Having found a resource, a user may want to retrieve its
+provenance. For users to decide whether they can place their trust in
+that resource, they may want to analyze its provenance, but also determine
+who the provenance is attributed to, and when it was
+generated. Hence, from the PROV-DM data model, the provenance is
+regarded as an entity, an AccountEntity, for which provenance can be
+sought.
+</p>
+</div>
+
+
+<p>Three types of agents are recognized by PROV-DM because they are commonly encountered in applications making data and documents available on the Web: persons, software agents, and organizations.</p>
+
+<div class="anexample" id="software-agents-example">
+<p> Even software agents can be assigned some responsibility for the effects they have in the world, so for example if one is using a Text Editor and one's laptop crashes, then one would say
+that the Text Editor was responsible for crashing the laptop. If one invokes a service to buy a book, that service can be considered responsible for drawing funds from one's bank to make
+the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well). </p>
+</div>
+<p>So when
+someone models software as an agent for an activity in the PROV-DM model, they mean the agent has some responsibility for that activity.</p>
+</section>
+
+ <section id="section-responsibility">
+<h2>Activity Association and Responsibility Chain</h2>
+
+
+
+
+
+<p>It is important to reflect that there is a degree in the
+responsibility of agents, and that is a major reason for
+distinguishing among all the agents that have some association with an
+activity and determine which ones are really the originators of the
+entity. For example, a programmer and a researcher could both be
+associated with running a workflow, but it may not matter which
+programmer clicked the button to start the workflow while it would
+matter a lot which researcher told the programmer to do so. So there
+is some notion of responsibility that needs to be captured. </p>
+
+<!-- <div class="note"> to be revisited for WD5. Paolo's proposed text: "Agents are defined in sec. 2.1 as having some kind of responsibility for activities. However, one may want to be more specific regarding the degrees of an agent's responsibility. For example, ..."</div>
+-->
+
+
+<p>Provenance reflects activities that have occurred. In some
+cases, those activities reflect the execution of a plan that was
+designed in advance to guide the execution. PROV-DM allows attaching
+a plan to an activity, which represents what was intended to
+happen. 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="note">Proposal: remove the above para as it repeats from 2.3. Proposed text: "the <em>activity association</em> relation provides a way to indicate that an agent is responsible for an activity, possibly with an associated plan."[PM]</div> -->
+
+
+<p>
+<span class="glossary-ref" ref="glossary-activityAssociation"></span>
+</p>
+
+<div class="anexample" id="association-example">
+<p>Examples of association between an activity and agent are:
+<ul>
+<li>creation of a web page under the guidance of a designer;</li>
+<li>various forms of participation in a panel discussion, including audience member, panelist, or panel chair;</li>
+<li>a public event, sponsored by a company, and hosted by a museum;</li>
+<li>an XSLT transform initiated by a user;</li>
+</ul>
+</div>
+
+<p>
+<span class="glossary-ref" ref="glossary-responsibilityChain">
+</span> The nature of this relation is intended to be broad, including delegation or a contractual relation. </p>
+
+<!--<div class="note">Propose to rephrase as follows: <br/>
+A relation between two agents, denoted <dfn title="concept-responsibilityChain">actedOnBehalfOf</dfn> indicates that
+ that a "subordinate" agent acted on behalf of a "responsible" agent, in the context of an activity. The nature of this relation is intended to be broad, including delegation or a contractual relation.
+ When this relation is used transitively, i.e., one agent acts on behalf of another, who also acts on behalf of another, etc., these relations form a <dfn title="concept-responsibilityChain">responsibility chain</dfn>.
+</div>-->
+
+
+
+
+
+<div class="anexample" id="responsibilityChain-example">
+<p>A student publishing a web page describing an academic
+department could result in both the student and the department being
+agents associated with the activity, and it may not matter which
+student published a web page but it matters a lot that the department
+told the student to put up the web page.
+</p>
+</div>
+</section>
+
+
+ <section id="section-UML">
+<h2>Overview Diagram</h2>
+
+<p> The following diagram summarizes the elements and relations just described</p>
+
+<div class="note">
+ TODO: short text required to explain the overview diagram
+</div>
+
+
+<div style="text-align: center; ">
+ <figure>
+
+ <img src="OverviewDiagram.svg" alt="PROV-DM overview" style="max-width: 70%; " />
+
+<figcaption>PROV-DM overview</figcaption>
+ </figure>
+</div>
+
+
+</section>
+</section>
+<!-- </section> -->
+
+<section id="prov-dm-example">
+<h2>Example</h2>
+
+
+<p>In this example, we consider the second version of the PROV-DM document
+<a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">http://www.w3.org/TR/2011/WD-prov-dm-20111215</a>. Its provenance can be expressed from several perspectives, which we present. In the first one, provenance is concerned with the W3C process, whereas in the second one, it takes the authors' viewpoint. </p>
+
+
+<section id="section-example-a">
+<h3>The Process View</h3>
+
+
+
+
+<p>
+
+In this section, we show the kind of provenance record that the <a href="http://www.w3.org/Consortium">WWW Consortium</a> could keep for auditors to check that due processes are followed. All entities involved in this example are Web resources, with well defined URIs (some of which locating archived email messages, available to W3C Members).</p>
+
+<ul>
+<li> Two versions of the technical report are involved: <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> (second working draft) and <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> (first working draft);</li>
+<li> Both <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> and <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> were published by the WWW Consortium agent (<span class="name"><a href="http://www.w3.org/Consortium">w3:Consortium</a></span>); </li>
+<li> The publication activity for <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> is <span class="name">ex:pub2</span>;</li>
+<li> The publication activity for <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> is <span class="name">ex:pub1</span>;
+</li>
+
+<li> The report <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> is derived from <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span>;</li>
+
+<li> The publication activity <span class="name">ex:pub1</span> used a <a href="http://www.w3.org/2005/08/01-transitions.html#pubreq">publication request</a> (<span class="name"><a href="https://lists.w3.org/Archives/Member/w3c-archive/2011Oct/0141">ar2:0141</a></span>) and a <a href="http://www.w3.org/2005/08/01-transitions.html#transreq">transition request</a> (<span class="name"><a href="https://lists.w3.org/Archives/Member/chairs/2011OctDec/0004">ar1:0004</a></span>);</li>
+<li> The publication activity <span class="name">ex:pub1</span> used a <a href="http://www.w3.org/2005/08/01-transitions.html#pubreq">publication request</a> (<span class="name"><a href="https://lists.w3.org/Archives/Member/w3c-archive/2011Dec/0111">ar3:0111</a></span>);</li>
+<li> Technical reports were published according to the process rules (<span class="name"><a href="http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance">pr:rec-advance</a></span>), a plan in PROV-DM terminology.</li>
+</ul>
+
+<p>
+We now paraphrase some PROV-DM assertions, and illustrate them with the PROV-ASN notation, a notation for PROV-DM aimed at human consumption. Full details of the provenance record can be found <a href="examples/w3c-publication1.prov-asn">here</a>.
+
+<ul>
+<li>There is a technical report, a working draft on the recommendation track (<a href="http://www.w3.org/2005/10/Process-20051014/tr.html#RecsWD">pr:RecsWD</a>), which is regarded as an entity so that we can describe its provenance. Similar descriptions exist for all entities.
+<pre>
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+</pre>
+</li>
+<li>There is a publication activity.
+<pre>
+activity(ex:pub2,,,[prov:type="publish"])
+</pre>
+</li>
+
+<li>The technical report was generated by the publication activity: this is a <a title="concept-Generation">Generation</a>.
+<pre>
+wasGeneratedBy(tr:WD-prov-dm-20111215, ex:pub2)
+</pre>
+</li>
+
+
+<li>The second draft of the technical report was derived from the first draft of the technical report: this is a <a title="concept-Derivation">Derivation</a>.
+<pre>
+wasDerivedFrom(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018)
+</pre>
+</li>
+
+<li>The activity required a publication request: this is a <a title="concept-Usage">Usage</a>.
+<pre>
+used(ex:pub2,ar3:0111)
+</pre>
+</li>
+
+<li>The activity was associated with the Consortium agent, and proceeded according to its publication policy: this is an <a title="concept-activityAssociation">Activity Association</a>.
+<pre>
+wasAssociatedWith(ex:pub2, w3:Consortium @ pr:rec-advance)
+</pre>
+</li>
+</ul>
+
+<p>
+Provenance descriptions can be <em>illustrated</em> graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of
+provenance statements. Therefore, it should not be seen as an alternate notation for expressing provenance.</p>
+
+<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and octagonal shapes, respectively. Usage,
+Generation, Derivation, and Activity Association are represented as directed edges.</p>
+
+<p>Entities are laid out according to the ordering of their generation event. We endeavor to show time progressing from top to bottom. This means that edges for Usage, Generation and
+Derivation typically point upwards.</p>
+
+
+
+
+
+
+<div style="text-align: center;">
+ <figure>
+ <img src="examples/w3c-publication1.png" alt="Provenance of a Tech Report" style="max-width: 70%; "/>
+<figcaption>Provenance of a Tech Report</figcaption>
+ </figure>
+</div>
+
+<div class='note'>
+Illustration to be hand crafted instead of being generated automatically. It's important to adopt a common style for all illustrations across all PROV documents.
+</div>
+
+
+<p> This simple example has shown a variety of PROV-DM constructs, such as Entity, Agent, Activity, Usage, Generation, Derivation, and ActivityAssociation. In this example, it happens that all entities were already Web resources, with readily available URIs, which we used. We note that some of the resources are public, whereas others have restricted access: provenance statements only make use of their identifiers. If identifiers do not pre-exist, e.g. for activities, then they can be minted, for instance <span class="name">ex:pub2</span>, occurring in the namespace identified by prefix <span class="name">ex</span>. We note that the URI scheme developed by W3C is particularly suited for expressing provenance of these reports, since each URI denotes a specific version of a report. It then becomes very easy to relate the various versions, with PROV-DM constructs. </p>
+
+
+</section>
+<section id="section-example-b">
+<h3>The Authors View</h3>
+
+<p>In this section, we consider another perspective on technical report
+<a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">http://www.w3.org/TR/2011/WD-prov-dm-20111215</a>. Here, provenance is concerned with the document editing activity, as perceived by authors. This kind of information could be used by authors in their CV or in a narrative about this document. </p>
+
+<ul>
+<li> The same technical report is involved: <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>;</li>
+<li> An editing activity for <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> is <span class="name">ex:edit1</span>;</li>
+<li> The report <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> is generated by activity <span class="name">ex:edit1</span>;</li>
+<li> Several persons are associated with activity <span class="name">ex:edit1</span>, some in an editorial role, some in a contributor's role.</li>
+</ul>
+
+<p>Again, we paraphrase some PROV-DM assertions, and illustrate them with the PROV-ASN notation.
+Full details of the provenance record can be found <a href="examples/w3c-publication3.prov-asn">here</a>.</p>
+
+<ul>
+<li>There is a technical report, which from the author's perspective is a document in its second version.
+<pre>
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
+</pre>
+<p>While this description is about the same report <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, its details differ from the author's perspective: it is a document and it has a version number. </p></li>
+
+<li>There is an editing activity.
+<pre>
+activity(ex:edit1,,,[prov:type="edit"])
+</pre>
+</li>
+
+<li>The technical report was generated by the editing activity: this is a <a title="concept-generation">Generation</a>.
+<pre>
+wasGeneratedBy(tr:WD-prov-dm-20111215, ex:edit1)
+</pre>
+</li>
+
+
+<li>There are some agents.
+<pre>
+agent(ex:Paolo, [ prov:type="Human" ])
+agent(ex:Simon, [ prov:type="Human" ])
+</pre>
+</li>
+
+<li>Agents were assigned various responsibilities in the editing activity: contributor and editor.
+<pre>
+wasAssociatedWith(ex:edit1, ex:Paolo, [prov:role="editor"])
+wasAssociatedWith(ex:edit1, ex:Simon, [prov:role="contributor"])
+</pre>
+</li>
+</ul>
+
+
+
+<div style="text-align: center;">
+ <figure>
+ <img src="http://www.w3.org/2011/prov/wiki/images/c/cd/W3c-publication3.png" alt="Provenance of a Tech Report (b)" style="max-width: 98%; "/>
+<figcaption id="prov-tech-report">Provenance of a Tech Report (b)</figcaption>
+ </figure>
+</div>
+</section>
+
+<section id="section-example-c">
+<h3>Attribution of Provenance</h3>
+
+<p>The two previous sections provide two different perspectives on the provenance of a technical report. By design, the PROV approach allows for the provenance of a subject to be provided by multiple sources. For users to decide whether they can place their trust in the technical report, they may want to analyze its provenance, but also determine
+who the provenance is attributed to, and when it was
+generated, etc. In other words, we need to be able to express the provenance of provenance.</p>
+
+<p>No new mechanism is required to support this requirement. PROV-DM makes the assumption that provenance statements have been bundled up, and named, by some mechanism outside the scope of PROV-DM. For instance, in this case, provenance statements were put in a file and exposed on the Web, respectively at <a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/examples/w3c-publication1.prov-asn">ex:prov1</a> and <a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/examples/w3c-publication3.prov-asn">ex:prov3</a>. To express their respective provenance, these resources must be seen as entities, and all the constructs of PROV-DM are now available to characterize their provenance. In the example below, <span class="name">ex:prov1</span> is attributed to the agent <span class="name">w3:Consortium</span>, whereas <span class="name">ex:prov3</span> to <span class="name">ex:Simon</span>.
+
+<pre>
+entity(ex:prov1, [prov:type="prov:AccountEntity" %% xsd:QName ])
+wasAttributedTo(ex1:prov1,w3:Consortium)
+
+entity(ex:prov3, [prov:type="prov:AccountEntity" %% xsd:QName ])
+wasAttributedTo(ex1:prov3,ex:Simon)
+</pre>
+
+
+
+</section>
+
+</section>
+
+<section id="data-model-concepts">
+
+<h2>PROV-DM Core</h2>
+
+<p>In this section, we revisit each concept introduction in <a href='#conceptualization'>Section 2</a>, and provide its detailed definition in the PROV data model, in terms of its various constituents. </p>
+
+<p>In PROV-DM, we distinguish elements from relations, which are respectively discussed in
+<a href='#term-element'>Section 4.1</a> and <a href='#term-relation'>Section 4.2</a>.</p>
+
+<section id="term-element">
+<h3>Element</h3>
+
+
+ <section id="term-Entty">
+
+<h4>Entity</h4>
+
+
+<div class="glossary-ref" ref="glossary-entity" withspan='true'></div>
+
+
+<p><div class="attributes" id="attributes-entity">An entity<span class="withAsn">, written <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN, </span> contains:</p>
+<ul>
+<li><em>id</em>: an identifier identifying an entity; </li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs representing this entity's situation in the world.</li>
+</ul></div>
+
+<div class="anexample">
+<p>
+The following expression</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
+</pre>
+states the existence of an entity, denoted by identifier <span class="name">tr:WD-prov-dm-20111215</span>, with type <span class="name">document</span> and version number <span class="name">2</span>. The attributes <span class="name">ex:version</span> is application specific, whereas the attribute <span
+class="name">type</span> is reserved in the PROV-DM namespace.
+<!--The following expression</p>
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
+entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
+</pre>
+states the existence of an entity, denoted by identifier <span class="name">e0</span>, with type <span class="name">File</span> and path <span class="name">/shared/crime.txt</span> in the
+file system, and creator alice. The attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span
+class="name">type</span> is reserved in the PROV-DM namespace.-->
+</div>
+
+<p>Further considerations:</p>
+<ul>
+<li>The sets of Activities and Entities are disjoint, as explained below.</li>
+</ul>
+
+
+<div class='issue'>The characterization interval of an entity is currently implicit. Making it explicit would allow us to define wasComplementOf more precisely.
+Beginning and end of characterization interval could be expressed by attributes (similarly to activities).
+How do we define the end of an entity? This is <a href="http://www.w3.org/2011/prov/track/issues/204">ISSUE-204</a>.
+</div>
+
+
+ <div class="issue">
+There is still some confusion about what the identifiers really denote. For instance, are they entity identifiers or entity record identifiers. This is <a
+href="http://www.w3.org/2011/prov/track/issues/183">ISSUE-183</a>.
+An example and questions appear in <a href="http://www.w3.org/2011/prov/track/issues/215">ISSUE-215</a>. A related issued is also raised in <a
+href="http://www.w3.org/2011/prov/track/issues/145">ISSUE-145</a>.
+</div>
+
+
+ </section>
+
+ <section id="term-Activity">
+
+<h3>Activity</h3>
+
+<div class="glossary-ref" ref="glossary-activity" withspan='true'></div>
+
+<p><div class="attributes" id="attributes-activity"> An activity<span class="withAsn">, written <span class="name">activity(id, st, et, [ attr1=val1, ...])</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an identifier identifying an activity;</li>
+<li><em>startTime</em>: an OPTIONAL time for the start of the activity;</li>
+<li><em>endTime</em>: an OPTIONAL time for the end of the activity;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs for this activity.</li>
+</ul></div>
+
+<div class="anexample">
+<p>
+The following expression</p>
+<pre class="codeexample">
+activity(a1,2011-11-16T16:05:00,2011-11-16T16:06:00,
+ [ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
+</pre>
+<p>states the existence of an activity with identifier <span class="name">a1</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span
+class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span>. The attribute <span class="name">host</span> is application specific (declared in some namespace with prefix <span class="name">ex</span>). The attribute <span
+class="name">type</span> is a reserved attribute of PROV-DM, allowing for sub-typing to be expressed.</p>
+</div>
+
+
+
+<p>Further considerations:</p>
+<ul>
+<li>An activity is not an entity.
+Indeed, an entity exists in full at
+any point in its lifetime, persists during this
+interval, and preserves the characteristics that makes it
+identifiable. In contrast, an activity is something that happens,
+unfolds or develops through time, but is typically not identifiable by
+the characteristics it exhibits at any point during its duration.
+This distinction is similar to the distinction between
+'continuant' and 'occurrent' in logic [[Logic]].</li>
+</ul>
+
+
+</section>
+
+<section id="term-Agent">
+<h3>Agent</h3>
+
+<div class="glossary-ref" ref="glossary-agent" withspan='true'></div>
+
+
+<p><div class="attributes" id="attributes-agent">An agent<span class="withAsn">, noted <span class="name">agent(id, [ attr1=val1, ...])</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an identifier identifying an agent;</li>
+<li><em>attributes</em>: a set of attribute-value pairs representing this agent's situation in the world.
+</li>
+</ul></div>
+
+
+<p>
+From an interoperability perspective, it is useful to define some basic categories of agents since
+it will improve the use of provenance by applications.
+There should be very few of these basic categories to keep the model simple and accessible.
+There are three types of agents in the model since they are common across most anticipated domains of use:
+<ul>
+<li><span class="name">Human</span>: agents of type Human are people. (This type is equivalent to a "foaf:person" [[FOAF]])</li>
+<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc. (This type is equivalent to a "foaf:organization"
+[[FOAF]])</li>
+<li><span class="name">ComputingSystem</span>: a computing system agent is a piece of software and/or hardware. </li>
+</ul>
+<p>These types are mutually exclusive, though they do not cover all kinds of agent. </p>
+
+
+
+<div class="anexample">
+<p>The following expression is about an agent identified by <span class="name">e1</span>, which is a person, named Alice, with employee number 1234.</p>
+<pre class="codeexample">
+agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Human" %% xsd:QName])
+</pre>
+<p>It is optional to specify the type of an agent. When present, it is expressed using the <span class="name">prov:type</span> attribute.</p>
+</div>
+
+<div class='issue'> Shouldn't we allow for entities (not agent) to be associated with an activity? Should we drop the inference association-agent? <a
+href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
+
+</section>
+
+ <section id="term-note">
+
+<h4>Note</h4>
+
+<p>As provenance descriptions are exchanged between systems, it may be useful to add extra-information to what they are describing. For instance, a "trust service" may add value-judgements about the
+trustworthiness of some of the entities or agents involved. Likewise, an interactive visualization component may want to enrich a set of provenance descriptions with information helping reproduce their
+visual representation. To help with interoperability, PROV-DM introduces a simple annotation mechanism allowing anything that is identifiable to be associated with notes.</p>
+
+<p>A <dfn title="dfn-note">note</dfn><span class="withAsn">, noted <span class="name">note(id, [ attr1=val1, ...])</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an identifier identifying the note;</li>
+<li><em>attributes</em>: a set of attribute-value pairs, whose meaning is application specific.</li>
+</ul>
+
+
+
+
+<p>A separate PROV-DM relation is used to associate a note with something that is identifiable (see <a href="#term-annotation">Section on annotation</a>). A given note may be associated with
+multiple identifiable things.
+</p>
+
+
+<div class="anexample">
+<p>
+The following note consists of a set of application-specific attribute-value pairs, intended
+to help the rendering of what it is associated with, by
+specifying its color and its position on the screen.</p>
+<pre class="codeexample">
+note(ex2:n1,[ex2:color="blue", ex2:screenX=20, ex2:screenY=30])
+hasAnnotation(tr:WD-prov-dm-20111215,ex2:n1)
+</pre>
+<p>The note is associated with the entity <span class="name">tr:WD-prov-dm-20111215</span> previously introduced (<a title="annotation">hasAnnotation</a> is
+discussed in Section <a href="#term-annotation">Annotation</a>). The note's identifier and attributes are declares in a separate namespace denoted by prefix <span class="name">ex2</span>.
+</p>
+
+<p>Alternatively, a reputation service may enrich a provenance record with notes providing reputation ratings about agents. In the following fragment, both agents <span class="name">ex:Simon</span> and <span class="name">ex:Paolo</span> are rated "excellent".</p>
+<pre class="codeexample">
+note(ex3:n2,[ex3:reputation="excellent"])
+hasAnnotation(ex:Simon,ex3:n2)
+hasAnnotation(ex:Paolo,ex3:n2)
+</pre>
+<p>The note's identifier and attributes are declares in a separate namespace denoted by prefix <span class="name">ex3</span>.</p>
+
+</div>
+
+
+ </section>
+
+</section>
+
+
+<section id="term-relation">
+<h3>Relation</h3>
+
+<p>
+This section describes all the PROV-DM relations between the elements introduced in <a href="#term-element">Section Element</a>. While these relations are not
+binary, they all involve two primary elements. They can be summarized as follows. </p>
+
+
+<div style="text-align: center;">
+<table border="1" style="margin-left: auto; margin-right: auto;">
+<caption>PROV-DM Core Relation Summary</caption>
+<tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Note</td></tr>
+<tr><td>Entity</td><td><a title="derivations">wasDerivedFrom</a><br><a title="dfn-alternate">alternateOf</a><br><a title="dfn-specialization">specializationOf</a></td><td><a
+title="dfn-Generation">wasGeneratedBy</a></td><td>—</td><td><a title="dfn-annotation">hasAnnotation</a></td></tr>
+<tr><td>Activity</td><td><a title="usage">used</a></td><td>—</td><td><a title="start record">wasStartedBy</a><br><a title="end record">wasEndedBy</a><br><a title="dfn-activity-association">wasAssociatedWith</a></td><td><a title="dfn-annotation">hasAnnotation</a></td></tr>
+<tr><td>Agent</td><td>—</td><td>—</td><td><a title="dfn-responsibility-chain">actedOnBehalfOf</a></td><td><a title="dfn-annotation">hasAnnotation</a></td></tr>
+<tr><td>Note</td><td>—</td><td>—</td><td>—</td><td><a title="dfn-annotation">hasAnnotation</a></td></tr>
+</table>
+</div>
+
+
+
+<section id="activity-entity-relation">
+<h3>Activity-Entity Relation</h3>
+
+<section id="term-Generation">
+<h4>Generation</h4>
+
+<div class="glossary-ref" ref="glossary-generation" withspan='true'></div>
+
+<p>
+<div class="attributes" id="attributes-generation"><dfn title="dfn-Generation">Generation</dfn><span class="withAsn">, written <span class="name">wasGeneratedBy(id,e,a,t,attrs)</span> in PROV-ASN,</span> has the following components:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying a generation;</li>
+<li><em>entity</em>: an identifier identifying a created entity; </li>
+<li><em>activity</em>: an OPTIONAL identifier identifying the activity that creates the entity;</li>
+
+<li><em>time</em>: an OPTIONAL "generation time", the time at which the entity was completely created;</li>
+
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs that describes the modalities of generation of this entity by this activity.</li>
+</ul></div>
+<p>While each of the components <em>activity</em>, <em>time</em>, and <em>attributes</em> is OPTIONAL, at least one of them MUST be present.</p>
+
+
+
+
+
+<div class='anexample'>
+<p>
+The following expressions</p>
+<pre class="codeexample">
+ wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1", ex:order=1])
+ wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p1", ex:order=2])
+</pre>
+<p>state the existence of two generations (with respective times <span class="name">2001-10-26T21:32:52</span> and <span
+class="name">2001-10-26T10:00:00</span>), at which new entities, identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an
+activity, identified by <span class="name">a1</span>.
+The first one is available as the first value on port p1, whereas the other is the second value on port p1. The semantics of <span class="name">port</span> and <span
+class="name">order</span> are application specific.
+</p>
+</div>
+
+
+<div class='anexample'>
+<p>
+In some cases, we may want to record the time at which an entity was generated without having to specify the activity that generated it. To support this requirement, the activity component in generation is optional. Hence, the following expression indicates the time at which an entity is generated, without naming the activity that did it.</p>
+<pre class="codeexample">
+ wasGeneratedBy(e,,2001-10-26T21:32:52)
+</pre>
+</div>
+
+
+</section>
+
+
+<section id="term-Usage">
+<h3>Usage</h3>
+
+<div class="glossary-ref" ref="glossary-usage" withspan='true'></div>
+
+
+<p><div class="attributes" id="attributes-usage"><dfn title="dfn-Usage">Usage</dfn><span class="withAsn">, written <span class="name">used(id,a,e,t,attrs)</span> in PROV-ASN,</span> has the following constituents:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying a usage;</li>
+<li><em>activity</em>: an identifier for the consuming activity;</li>
+<li><em>entity</em>: an identifier for the consumed entity;</li>
+<li><em>time</em>: an OPTIONAL "usage time", the time at which the entity started to be used;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs that describe the modalities of usage of this entity by this activity.</li>
+</ul></div>
+
+<p>
+A reference to a given entity MAY appear in multiple usages that share
+ a given activity identifier.
+</p>
+
+
+<div class='anexample'>
+<p>The following usages</p>
+<pre class="codeexample">
+ used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"])
+ used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])
+</pre>
+<p>state that the activity identified by <span class="name">a1</span> consumed two entities identified by <span
+class="name">e1</span> and <span class="name">e2</span>, at times <span class="name">2011-11-16T16:00:00</span> and <span class="name">2011-11-16T16:00:01</span>, respectively; the first
+one was found as the value of parameter <span class="name">p1</span>, whereas the second was found as value of parameter <span class="name">p2</span>. The semantics of <span
+class="name">parameter</span> is application specific.</p>
+</div>
+
+
+
+<div class='note'>
+
+
+
+<p>
+A usage record's id is OPTIONAL. It MUST be present when annotating usage records (see Section <a href="#term-annotation">Annotation Record</a>) or when defining precise-1 derivations (see
+<a href="#Derivation-Relation">Derivation</a>).</p>
+</div>
+
+
+
+
+</section>
+</section>
+
+
+
+
+
+<section id="activity-agent-relation">
+<h3>Activity-Agent Relation</h3>
+
+<section id="term-ActivityAssociation">
+<h4>Activity Association</h4>
+
+<div class="glossary-ref" ref="glossary-activityAssociation" withspan='true'></div>
+
+<p>As far as responsibility is concerned, PROV-DM offers two kinds of constructs. The first, introduced in this section, is a relation between an agent, a plan, and an activity; the second, introduced in <a
+href="#term-responsibility">Section Responsibility</a>, is a relation between agents expressing that an agent was acting on behalf of another, in the context of an activity. </p>
+
+
+<p><div class="attributes" id="attributes-activity-association">An <dfn title="dfn-activity-association">activity association</dfn><span class="withAsn">, written <span class="name">wasAssociatedWith(id,a,ag,pl,attrs)</span> in PROV-ASN,</span> has the following
+constituents:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier for the association between an activity and an agent;</li>
+<li><em>activity</em>: an identifier for the activity;</li>
+<li><em>agent</em>: an identifier for the agent associated with the activity;</li>
+<li><em>plan</em>: an OPTIONAL identifier for the plan adopted by the agent in the context of this activity;
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs that describe the modalities of association of this activity with this agent.</li>
+</ul></div>
+
+<div class="anexample">
+In the following example, a designer and an operator agents are associated with an activity. The designer's goals are achieved by a workflow <span class="name">ex:wf</span>.
+<pre class="codeexample">
+activity(ex:a,[prov:type="workflow execution"])
+agent(ex:ag1,[prov:type="operator"])
+agent(ex:ag2,[prov:type="designer"])
+wasAssociatedWith(ex:a,ex:ag1,[prov:role="loggedInUser", ex:how="webapp"])
+wasAssociatedWith(ex:a,ex:ag2,ex:wf,[prov:role="designer", ex:context="project1"])
+entity(ex:wf,[prov:type="prov:Plan"%% xsd:QName, ex:label="Workflow 1",
+ ex:url="http://example.org/workflow1.bpel" %% xsd:anyURI])
+</pre>
+Since the workflow <span class="name">ex:wf</span> is itself an entity, its provenance can also be expressed in PROV-DM: it can be generated by some activity and derived from other entities,
+for instance.
+</div>
+
+<div class='issue'> The activity association record does not allow for a plan to be asserted without an agent.
+This seems over-restrictive. Discussed in the context of <a href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
+
+
+<div class='issue'> Agents should not be inferred. WasAssociatedWith should also work with entities.
+This is <a href="http://www.w3.org/2011/prov/track/issues/206">ISSUE-206</a>.</div>
+
+
+</section>
+
+<section id="term-Start-End">
+<h4>Activity Start and Activity End</h4>
+
+<p> A <dfn title="dfn-Start">activity start</dfn> is a representation of an agent starting an activity.
+ An <dfn title="dfn-End">activity end</dfn> is a representation of an agent ending an activity. Both relations are specialized forms of <span class="name">wasAssociatedWith</span>. They contain
+attributes describing the modalities of acting/ending activities.</p>
+
+
+
+<p>An activity start<span class="withAsn">, written <span class="name">wasStartedBy(id,a,ag,attrs)</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying the activity start;</li>
+<li><em>activity</em>: an identifier identifying the started activity;
+<li><em>agent</em>: an identifier for the agent starting the activity;
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs describing modalities according to which the agent started the activity.
+</ul>
+
+<p>An activity end<span class="withAsn">, written <span class="name">wasEndedBy(id,a,ag,attrs)</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying the activity end;</li>
+<li><em>activity</em>: an identifier identifying the ended activity;
+<li><em>agent</em>: an identifier for the agent ending the activity;
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs describing modalities according to which the agent ended the activity.
+</ul>
+
+
+<div class="anexample">
+<p>
+In the following example,</p>
+<pre class="codeexample">
+wasStartedBy(a,ag,[ex:mode="manual"])
+wasEndedby(a,ag,[ex:mode="manual"])
+</pre>
+<p>there is an activity denoted by <span class="name">a</span>
+that was started and ended by an agent denoted by <span class="name">ag</span>, in "manual" mode, an application specific characterization of these relations.
+</p>
+</div>
+
+<div class='issue'>
+Should we define start/end records as representation of activity start/end events.
+Should time be associated with these events rather than with activities. This will be similar to what
+we do for entities. This is issue <a href="http://www.w3.org/2011/prov/track/issues/207">ISSUE-207</a>.</div>
+
+
+</section>
+
+
+
+
+</section>
+
+<section id="entity-entity-agent-agent-relation">
+<h4>Entity-Entity or Agent-Agent Relation</h4>
+
+<section id="term-responsibility">
+
+<h4>Responsibility Chain</h4>
+
+<div class="glossary-ref" ref="glossary-responsibilityChain" withspan='true'></div>
+
+<p>PROV-DM offers a mild version of responsibility
+in the form of a relation to represent when an agent acted on another
+agent's behalf. So in the example of someone running a mail program,
+the program is an agent of that activity and the person is also an
+agent of the activity, but we would also add that the mail software
+agent is running on the person's behalf. In the other example, the
+student acted on behalf of his supervisor, who acted on behalf of the
+department chair, who acts on behalf of the university, and all those
+agents are responsible in some way for the activity to take place but
+we do not say explicitly who bears responsibility and to what
+degree. </p>
+
+<p>We could also say that an agent can act on behalf of several other
+agents (a group of agents). This would also make possible to
+indirectly reflect chains of responsibility. This also indirectly
+reflects control without requiring that control is explicitly
+indicated. In some contexts there will be a need to represent
+responsibility explicitly, for example to indicate legal
+responsibility, and that could be added as an extension to this core
+model. Similarly with control, since in particular contexts there
+might be a need to define specific aspects of control that various
+agents exert over a given activity.</p>
+
+<p><div class="attributes" id="attributes-responsibility-chain">A <dfn title="dfn-responsibility-chain">responsibility chain</dfn><span class="withAsn">, written <span class="name">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-ASN,</span> has the following constituents:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying the responsibility chain;</li>
+<li><em>subordinate</em>: an identifier for the agent associated with an activity, acting on behalf of the responsible
+agent;</li>
+<li><em>responsible</em>: an identifier for the agent, on behalf of which the subordinate agent acted;</li>
+<li><em>activity</em>: an OPTIONAL identifier of an activity for which the responsibility chain holds;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs that describe the modalities of this relation.</li>
+</ul></div>
+
+
+<div class="anexample">
+In the following example, a programmer, a researcher and a funder agents are described. The programmer and researcher are associated with a workflow activity. The programmer acts on behalf
+of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher. The terms
+'delegation' and 'contact' used in this example are domain specific.
+<pre class="codeexample">
+activity(a,[prov:type="workflow"])
+agent(ag1,[prov:type="programmer"])
+agent(ag2,[prov:type="researcher"])
+agent(ag3,[prov:type="funder"])
+wasAssociatedWith(a,ag1,[prov:role="loggedInUser"])
+wasAssociatedWith(a,ag2)
+actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])
+actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
+</pre>
+</div>
+
+
+</section>
+
+<section id="Derivation-Relation">
+<h4>Derivation</h4>
+
+<div class="glossary-ref" ref="glossary-derivation" withspan='true'></div>
+
+
+<div class='note'>
+This text was not edited much. It keeps on referring to asserter/assertion. Before editing this section, we would like to have <a href="http://www.w3.org/2011/prov/track/issues/249">ISSUE-249</a> resolved.
+</div>
+
+
+<p>According to <a href="#conceptualization">Section Conceptualization</a>, for an entity to be transformed from, created from, or affected by another in some way, there must be some
+underpinning activities performing the necessary actions resulting in such a derivation.
+However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may
+not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or
+less precise derivations to be asserted. Hence, PROV-DM uses the terms <em>precise</em> and <em>imprecise</em> to characterize the different kinds of derivations. We note
+that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation assertion, that may be imprecise. </p>
+
+<p>The lack of precision may come from two sources:</p>
+<ul>
+<li> the number of activities that underpin a derivation is not asserted or known, or</li>
+<li> any of the other details that are involved in the derivation is not asserted or known; these include activity identities, generation and usage, and their attributes.</li>
+</ul>
+
+
+
+
+<p>Hence, we can consider two axis. An activity number axis that has values <em>single</em>, <em>multiple</em>, and <em>unknown</em>, respectively representing the case where one activity
+is known to have occurred, more than one activities are known to have occurred, or an unknown number of activities have occurred. Likewise, we can consider another axis to cover other
+details (identities, generation, usage, and attributes), with values <em>asserted</em> and <em>not asserted</em>. We can then form a matrix of possible derivations. Out of the six
+possibilities,
+PROV-DM offers three forms of derivations to cater for five of them, while the remaining one is not meaningful. The following table summarizes names for the three kinds of
+derivation, which we then explain.</p>
+
+<div style="text-align: center;">
+<table border="1" style="margin-left: auto; margin-right: auto;">
+<caption>PROV-DM Derivation Type Summary</caption>
+<tr><td colspan=2 rowspan=2></td><td colspan=2><em>other details</em> axis</td></tr>
+<tr><td>asserted</td><td>not asserted</td></tr>
+<tr><td rowspan=3><em>activity number</em><br>axis</td><td>single</td><td><a>precise-1 derivation</a></td><td><a>imprecise-1 derivation</a></td></tr>
+<tr><td>multiple</td><td><a>imprecise-n derivation</a></td><td rowspan=2><a>imprecise-n derivation</a></td></tr>
+<tr><td>unknown</td><td>—</td></tr>
+</table>
+</div>
+
+<ul>
+<li> The asserter asserts that derivation is due to exactly one activity, and all the details are asserted. We call this a precise-1 derivation.</li>
+<li> The asserter asserts that derivation is due to exactly one activity, but other details, whether known or unknown, are not asserted. We call this an imprecise-1 derivation.</li>
+<li> The following cases are captured by an imprecise-n derivation.
+<ul>
+<li> The asserter knows that multiple activities are involved or ignores the number of activities involved in the derivation, and other details are not asserted. </li>
+<li> The asserter knows that multiple activities are involved in the derivation, and all their details are asserted. In this case, these activities are connected by means of generated and
+used intermediary entities. Despite all activities and details being known, there is no guarantee that any of these activities plays an active role in the derivation; hence, this case is
+also regarded as imprecise. Instead, precise derivations need to be expressed between these intermediary entities. </li>
+</ul>
+</ul>
+
+<p> We note that the last theoretical cases cannot occur, since
+ asserting the details of an unknown number of activities is a contradiction.
+</p>
+
+<p>In order to represent the number of activities in a derivation, we introduce a PROV-DM attribute <span class="name">steps</span>, which can take two possible values: <span
+class="name">single</span> and <span class="name">any</span>.
+When <span class="name">prov:steps="single"</span>, derivation is due to one activity; when <span class="name">prov:steps="any"</span>, the number of activities is multiple or not known.</p>
+
+
+<p>The three kinds of <dfn id="dfn-derivation">derivations</dfn> are successively introduced. Making use of the attribute <span class="name">steps</span>, we can distinguish the various derivation types.</p>
+
+<p><div class="attributes" id="attributes-derivation">A <dfn>precise-1 derivation</dfn><span class="withAsn">, written <span class="name">wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying the derivation;</li>
+<li><em>generatedEntity</em>: the identifier of the generation entity;</li>
+<li><em>usedEntity</em>: the identifier of the used entity;</li>
+<li><em>activity</em>: the identifier of the activity using and generating the above entities;</li>
+<li><em>generation</em>: the identifier the generation for the generated entity and activity;</li>
+<li><em>usage</em>: the identifier of the usage for the used entity and activity;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs that describe the modalities of this derivation, optionally including the attribute-value
+pair <span class="name">prov:steps="single"</span>.</li>
+</ul>
+</div>
+<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in a precise-1 derivation since it already refers to the one and only one activity underpinning the
+derivation.</p>
+
+
+<p>An <dfn>imprecise-1 derivation</dfn><span class="withAsn">, written <span class="name">wasDerivedFrom(id, e2,e1, t, attrs)</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying the derivation;</li>
+<li><em>generatedEntity</em>: the identifier of the generated entity;</li>
+<li><em>usedEntity</em>: the identifier of the used entity;</li>
+<li><em>time</em>: an OPTIONAL "generation time", the time at which the entity was created;</li>
+<li><em>attributes</em>: a set of attribute-value pairs that describe the modalities of this derivation; it MUST include the attribute-value pair <span class="name">prov:steps="single"</span>.</li>
+</ul>
+<p>An imprecise-1 derivation MUST include the attribute <span class="name">prov:steps</span>, since it is the only means to distinguish this derivation from an imprecise-n derivation.</p>
+
+
+<p>An <dfn>imprecise-n derivation</dfn><span class="withAsn">, written <span class="name">wasDerivedFrom(id, e2, e1, t, attrs)</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying the derivation;</li>
+<li><em>generatedEntity</em>: the identifier of the generated entity;</li>
+<li><em>usedEntity</em>: the identifier of the used entity;</li>
+<li><em>time</em>: an OPTIONAL "generation time", the time at which the entity was created;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs that describe the modalities of this derivation; it optionally includes the attribute-value pair <span class="name">prov:steps="any"</span>.</li>
+</ul>
+<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in an imprecise-n derivation. It defaults to <span class="name">prov:steps="any"</span>.</p>
+
+
+<p>None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property
+holds.</p>
+
+
+<div class="anexample">
+<p>The following descriptions state the existence of derivations.</p>
+<pre class="codeexample">
+wasDerivedFrom(e5,e3,a4,g2,u2)
+wasDerivedFrom(e5,e3,a4,g2,u2,[prov:steps="single"])
+
+wasDerivedFrom(e3,e2,[prov:steps="single"])
+
+wasDerivedFrom(e2,e1,[])
+wasDerivedFrom(e2,e1,[prov:steps="any"])
+
+wasDerivedFrom(e2,e1,2012-01-18T16:00:00, [prov:steps="any"])
+</pre>
+<p>
+The first two are precise-1 derivations expressing that the activity identified by <span class="name">a4</span>, by
+using the entity denoted by <span class="name">e3</span> according to usage <span class="name">u2</span>
+ derived the
+entity denoted by <span class="name">e5</span> and generated it according to generation
+ <span class="name">g2</span>. </p>
+
+<p>
+The third line describes an imprecise-1 derivation, which is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity and associated attributes implicit. The fourth and fifth lines are about imprecise-n derivations between <span class="name">e2</span> and <span class="name">e1</span>, but no information is provided as to the number and identity of activities underpinning the derivation. The sixth derivation extends the fifth with the derivation time of <span class="name">e2</span>.
+</p>
+</div>
+
+
+
+<div class='issue'>Several points were raised about the attribute steps.
+Its name, its default value <a href="http://www.w3.org/2011/prov/track/issues/180">ISSUE-180</a>.
+ <a href="http://www.w3.org/2011/prov/track/issues/179">ISSUE-179</a>.</div>
+
+<div class='issue'> Emphasize the notion of 'affected by' <a href="http://www.w3.org/2011/prov/track/issues/133">ISSUE-133</a>.</div>
+
+
+<div class='issue'> Is imprecise-1 derivation necessary? Can we just use precise-1 and imprecise-n? <a href="http://www.w3.org/2011/prov/track/issues/249">ISSUE-249</a>.</div>
+
+
+</section>
+
+
+<section id="term-alternate-specialization">
+
+<h4>Alternate and Specialization</h4>
+
+<p>The purpose of this section is to introduce relations between two entities that refer to the same thing in the world.
+Consider for example three entities:
+</p>
+<ul>
+ <li><span class="name">e1</span> denoting "Bob, the holder of Facebook account ABC",
+
+ <li><span class="name">e2</span> denoting "Bob, the holder of Twitter account XYZ",
+
+ <li><span class="name">e3</span> denoting "Bob, the person".
+</ul>
+
+<p>These entities refer to the same real person Bob, either in different contexts, or at different levels of abstraction. Specifically:
+
+
+<ol>
+ <li>e1 and e2 refer to Bob in two contexts (as Facebook and Twitter users, respectively)
+ <li> both of e1 and e2 are more detailed than e3.
+</ol>
+
+
+
+<p>The following two relations are introduced for expressing alternative or specialized entities. </p>
+
+
+
+
+<p>An <dfn title="dfn-Alternate">alternate relation</dfn><span class="withAsn">, written <span class="name">alternateOf(id, alt1, alt2, attrs)</span> in PROV-ASN,</span> addresses case (1). It has the following constituents:</p>
+
+<ul>
+<li><em>id</em>: an OPTIONAL identifier for the association between the two alternates;</li>
+<li><em>firstAlternate</em>: an identifier of the first of the two entities;</li>
+<li><em>secondAlternate</em>: an identifier of the second of the two entities;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe this relation.</li>
+</ul>
+
+<div class="anexample" id="anexample-alternate">
+<p>The following expressions describe two persons, respectively holder of a Facebook account and a Twitter account, and their relation as alternate. </p>
+<pre class="codeexample">
+entity(facebook:ABC, [ prov:type="person with Facebook account " ])
+entity(twitter:XYZ, [ prov:type="person with Twitter account" ])
+alternateOf(facebook:ABC, twitter:XYZ)
+</pre>
+</div>
+
+
+
+<p>A <dfn title="dfn-Specialization">specialization relation</dfn><span class="withAsn">, written <span class="name">specializationOf(id, sub, super, attrs)</span> in PROV-ASN,</span> addresses case (2). It has the following constituents:</p>
+
+<ul>
+<li><em>id</em>: an OPTIONAL identifier for the association between the two entities;</li>
+<li><em>specializedEntity</em>: an identifier of the specialized entity;</li>
+<li><em>generalEntity</em>: an identifier of the entity that is being specialized;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe this relation.</li>
+</ul>
+
+<div class="anexample" id="anexample-specialization">
+<p>The following expressions describe two persons, the second of which is holder of a Twitter account. The second entity is a specialization of the first. </p>
+<pre class="codeexample">
+entity(ex:Bob, [ prov:type="person", ex:name="Bob" ])
+entity(twitter:XYZ, [ prov:type="person with Twitter account" ])
+specializationOf(twitter:XYZ, ex:Bob)
+</pre>
+</div>
+
+<!--
+<p>To promote take up of these relations, it is not specified whether they are transitive or symmetric. We anticipate that applications will specialize these relations according to their needs. </p>
+-->
+
+<div class='issue'>A discussion on alternative definition of these relations has not yet reached a satisfactory conclusion. This is <a
+href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a>. Also <a href="http://www.w3.org/2011/prov/track/issues/96">ISSUE-96</a>.</div>
+
+
+</section>
+</section>
+
+
+
+<section id="term-annotation">
+<h4>Annotation</h4>
+
+
+<p>
+<div class="glossary" id="glossary-annotation">
+An <dfn title="concept-annotation">annotation</dfn> is a link between something that is identifiable and a note referred to by its identifier.</div>Multiple notes can
+be associated with a given identified object; symmetrically, multiple objects can be associated with a given note. Since notes have identifiers, they can also be
+annotated. The annotation mechanism (with note and annotation) forms a key aspect of the extensibility mechanism of PROV-DM (see <a
+href="#extensibility-section">extensibility section</a>).</p>
+
+<p>An <dfn title="dfn-annotation">annotation relation</dfn><span class="withAsn">, written <span class="name">hasAnnotation(id,r,n,attrs)</span> in PROV-ASN,</span> has the following constituents:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier for this relation;</li>
+<li><em>something</em>: the identifier of something being annotated;</li>
+<li><em>note</em>: an identifier of a note;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe this annotation.</li>
+</ul>
+
+<div class="anexample">
+<p>
+The following expressions</p>
+<pre class="codexample">
+entity(e1,[prov:type="document"])
+entity(e2,[prov:type="document"])
+activity(a,t1,t2)
+used(u1,a,e1,[ex:file="stdin"])
+wasGeneratedBy(e2, a, [ex:file="stdout"])
+
+note(n1,[ex:icon="doc.png"])
+hasAnnotation(e1,n1)
+hasAnnotation(e2,n1)
+
+note(n2,[ex:style="dotted"])
+hasAnnotation(u1,n2)
+</pre>
+<p>describe two documents (attribute-value pair: <span class="name">prov:type="document"</span>) identified by <span class="name">e1</span> and <span
+class="name">e2</span>, and their annotation with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. The example also
+includes an activity, its usage of the first entity, and its generation of the second entity. The <a title="dfn-usage">usage</a> is annotated with a style (an application specific way
+of rendering this edge graphically). To be able to express this annotation, the usage was provided with an identifier <span class="name">u1</span>, which was then referred to in <span
+class="name">hasAnnotation(u1,n2)</span>.
+</p>
+</div>
+
+
+</section>
+</section>
+
+
+
+<section id="second-class-elements">
+<h3>Further Elements of PROV-DM</h3>
+
+This section introduces further elements of PROV-DM.
+
+<section id="term-NamespaceDeclaration">
+<h3>Namespace Declaration</h3>
+
+<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [[!IRI]]. In PROV-DM, attributes, identifiers, and literals with <a title="qualified name">qualified names</a> as data type can be placed in a namespace using the mechanisms described in this specification. </p>
+
+
+<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this
+declaration refers to this namespace.
+A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every un-prefixed qualified name in the scope of this default namespace declaration
+refers to this namespace.</p>
+
+<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
+
+</section>
+
+<section id="term-identifier">
+<h4>Identifier</h4>
+
+<p>
+An <dfn id="dfn-identifier">identifier</dfn> is a <a>qualified
+ name</a>.
+</p>
+
+<p>
+A <dfn id="dfn-qualifiedName">qualified name</dfn> is a name subject to <a>namespace</a> interpretation. It consists of a <a>namespace</a>, denoted by an optional prefix, and a local name.</p>
+
+
+<p>PROV-DM stipulates that a qualified name can be mapped into an IRI
+ by concatenating the IRI associated with the prefix and the local part.</p>
+
+<p>A qualified name's prefix is OPTIONAL. If a prefix occurs in a
+ qualified name, it refers to a <a>namespace</a> declared in a namespace declaration. In the absence of prefix, the qualified name
+ refers to the <a title="default namespace declaration">default namespace</a>.</p>
+
+</section>
+
+<section id="term-attribute">
+<h4>Attribute</h4>
+
+<p>An <dfn title="dfn-attribute">attribute</dfn> is a <a>qualified name</a>.
+
+
+<p>The PROV data model introduces a pre-defined set of attributes in the <a href="#prov-dm-namespace">PROV-DM namespace</a>, which we define below.
+The interpretation of any attribute declared in another namespace is out of scope.</p>
+
+<section id="term-attribute-role">
+<h4>prov:role</h4>
+
+<p>The attribute <dfn title="dfn-role"><span class="name">prov:role</span></dfn> denotes the function of an entity with respect to an activity, in the context of a usage, generation,
+activity association, activity start, and activity end. The attribute <span class="name">prov:role</span> is allowed to occur multiple times in a list of attribute-value pairs. The value associated with a <span
+class="name">prov:role</span> attribute MUST be a PROV-DM <a title="literal">Literal</a>.</p>
+
+<div class="anexample">
+<p>The following activity start describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
+<pre class="codeexample">
+ wasStartedBy(a,ag, [prov:role="program-operator"])
+</pre>
+</div>
+</section>
+
+<section id="term-attribute-type">
+<h4>prov:type</h4>
+
+<p>The attribute <dfn title="dfn-type"><span class="name">prov:type</span></dfn> provides further typing information for an element or relation. PROV-DM liberally
+defines a type as a category of things having common characteristics. PROV-DM is agnostic about the representation of types, and only states that
+the value associated with a <span class="name">prov:type</span> attribute MUST be a PROV-DM Literal. The attribute <span class="name">prov:type</span>
+is allowed to occur multiple times.</p>
+
+<div class="anexample">
+<p>The following describes an agent of type software agent.</p>
+<pre class="codeexample">
+ agent(ag, [prov:type="prov:ComputingSystem" %% xsd:QName])
+</pre>
+</div>
+</section>
+
+<section id="term-attribute-steps">
+<h4>prov:steps</h4>
+
+<p> The attribute <dfn title="dfn-steps"><span class="name">prov:steps</span></dfn> defines the level of precision associated with a derivation. The value associated with a <span
+class="name">prov:steps</span> attribute MUST be <span class="name">"single"</span> or <span class="name">"any"</span>. The attribute <span class="name">prov:steps</span> occurs at most
+once in a derivation. A derivation without attribute <span class="name">prov:steps</span> is considered to be equivalent to the same derivation extended with an extra attribute
+<span class="name">prov:steps</span> and associated value <span class="name">"any"</span>. </p>
+
+<div class="anexample">
+<p>The following expression declares an imprecise-1 derivation, which is known to involve one activity, though its identity, usage details of <span class="name">ex:e1</span>, and generation
+details of <span class="name">ex:e2</span> are not explicit.</p>
+<pre class="codeexample">
+ wasDerivedFrom(ex:e2, ex:e1, [prov:steps="single"])
+</pre>
+</div>
+</section>
+
+<section id="term-attribute-label">
+<h4>prov:label</h4>
+
+<p> The attribute <dfn title="dfn-label"><span class="name">prov:label</span></dfn> provides a human-readable representation of a PROV-DM element or relation. The value associated with the attribute <span class="name">prov:label</span> MUST be a string.</p>
+
+<div class='issue'>
+ This is <a href="http://www.w3.org/2011/prov/track/issues/219">ISSUE-219</a>. </div>
+</section>
+
+
+
+<section id="term-attribute-location">
+<h4>prov:location</h4>
+
+<p><dfn title="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate,
+address, landmark, row, column, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations, by means of attributes. </p>
+
+
+<p>
+The attribute <dfn title="dfn-location"><span class="name">prov:location</span></dfn> is an OPTIONAL attribute of entity and activity. The value associated with the attribute <span class="name">prov:location</span> MUST be a PROV-DM Literal, expected to denote a location.
+</p>
+
+<div class="anexample">
+<p>The following expression describes entity Mona Lisa, a painting, with a location attribute. </p>
+<pre class="codeexample">
+ entity(ex:MonaLisa, [prov:location="Le Louvres, Paris", prov:type="StillImage"])
+</pre>
+</div>
+</section>
+
+
+
+
+</section>
+
+
+</section>
+
+
+
+
+<section id="term-literal">
+<h4>Literal</h4>
+
+<div class='note'>
+Usually, in programming languages, Literal are a notation for values. So, Literals should probably be moved to the serialization. Here, instead, we should define the types of values. Thoughts?
+</div>
+
+<p>
+A PROV-DM Literal represents a data value such as a particular string
+or number. A PROV-DM Literal represents a value whose interpretation is outside the scope of PROV-DM.
+</p>
+
+
+<div class="anexample">
+<p>
+The following examples respectively are the string "abc", the string "abc", the integer number 1, and the IRI "http://example.org/foo".
+<pre class="codeexample">
+ "abc"
+ 1
+ "http://example.org/foo" %% xsd:anyURI
+</pre>
+<p>The following example shows a literal of type <span class="name">xsd:QName</span> (see
+<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#QName">QName</a> [[!XMLSCHEMA-2]]).
+The prefix <span class="name">ex</span> MUST be bound to a <a>namespace</a> declared in a <a>namespace declaration</a>.</p>
+<pre class="codeexample">
+ "ex:value" %% xsd:QName
+</pre>
+</div>
+
+
+
+</section>
+
+
+
+
+<section id="term-Time">
+<h4>Time</h4>
+
+<div class='note'>
+It's a legacy of the charter that time is a top level section. Time is a specific kind of value, and should be folded into the "value" section.
+</div>
+
+
+<p><dfn title="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [[!XMLSCHEMA-2]].</p>
+
+
+
+<p>Time is OPTIONAL in usage, generation, and activity</p>
+
+
+
+
+
+</section>
+
+</section>
+
+</section>
+
+
+<section id="common-relations">
+<h2>PROV-DM Common Relations</h2>
+
+<p>The following figure summarizes the additional relations described in this section.
+</p>
+
+<div style="text-align: center;">
+<figure>
+<img src="commonRelations.svg" alt="common relations"/>
+<figcaption>PROV-DM Common Relations</figcaption>
+</figure>
+</div>
+
+
+
+
+
+<section id="term-Revision">
+<h3>Revision</h3>
+
+<p> A <dfn title="dfn-Revision">revision</dfn> is the result of revising an entity into a revised version.
+ Deciding whether something is made available as a revision of something else usually involves an agent who takes responsibility for approving that the former is a due variant of the latter.
+ The agent who is responsible for the revision may optionally be specified.
+ Revision is a particular case of <a href="#Derivation-Relation">derivation</a> of an entity into its revised version.</p>
+
+<p> A revision relation<span class="withAsn">, written <span class="name">wasRevisionOf(id,e2,e1,ag,attrs)</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier for the relation;</li>
+<li><em>newer</em>: the identifier of the revised entity;
+<li><em>older</em>: the identifier of the older entity;
+<li><em>responsibility</em>: an OPTIONAL identifier for the agent who approved the newer entity as a variant of the older;
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe the properties of this relation.</li>
+</ul>
+
+
+
+<div class="anexample">
+<p>
+Revisiting the example of <a href="#section-example-a">Section 3.1</a>,
+we can now state that the report
+ <span class="name">tr:WD-prov-dm-20111215</span> is a revision of
+ the report <span class="name">tr:WD-prov-dm-20111018</span>, approved by
+agent <span class="name">w3:Consortium</span>.
+<pre class="codeexample">
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+entity(tr:WD-prov-dm-20111018, [ prov:type="pr:RecsWD" %% xsd:QName ])
+wasRevisionOf(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, w3:Consortium)
+</pre>
+</div>
+
+
+
+</section> <!-- end revision -->
+
+
+<section id="term-attribution">
+<h3>Attribution</h3>
+
+<p><dfn id="dfn-attribution">Attribution</dfn> is the ascribing of an entity to an agent. More precisely, when an entity <span class="name">e</span> is attributed to agent <span class="name">ag</span>, entity <span class="name">e</span> was generated by some activity <span class="name">a</span>, which in turn was associated to agent <span class="name">ag</span>. Thus, this relation is useful when the activity is not known, or irrelevant.
+
+<p> An attribution relation<span class="withAsn">, written <span class="name"> wasAttributedTo(id,e,ag,attr)</span> in PROV-ASN,</span> contains the following elements:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier for the relation;</li>
+<li><em>entity</em>: an entity identifier;</li>
+<li><em>agent</em>: the identifier of the agent whom the entity is ascribed to;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+</ul>
+
+<div class="anexample">
+<p>
+Revisiting the example of <a href="#section-example-b">Section 3.2</a>,
+we can ascribe <span class="name">tr:WD-prov-dm-20111215</span> to some agents without having to make an activity explicit.
+<pre class="codeexample">
+agent(ex:Paolo, [ prov:type="Human" ])
+agent(ex:Simon, [ prov:type="Human" ])
+entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
+wasAttributedTo(tr:WD-prov-dm-20111215, ex:Paolo, [prov:role="editor"])
+wasAttributedTo(tr:WD-prov-dm-20111215, ex:Simon, [prov:role="contributor"])
+</pre>
+</div>
+
+</section> <!-- end attribution -->
+
+<section id="term-OrderingOfActivities">
+<h3>Activity Ordering</h3>
+
+
+<p>The following relations express dependencies amongst activities.</p>
+
+<ul>
+ <li> An <dfn title="InformationFlowOrdering">information flow ordering relation</dfn> states that activity <span class="name">a2</span> is dependent on another <span class="name">a1</span>, by way of some entity <span class="name">e</span> that is generated by <span class="name">a1</span> and used by <span class="name">a2</span>.
+ <li>A <dfn title="ControlOrdering">control ordering relation</dfn> states that activity <span class="name">a2</span> was initiated by another activity <span class="name">a1</span>.
+</ul>
+
+<p>
+An information flow ordering relation<span class="withAsn">, written as
+<span class="name">wasInformedBy(id,a2,a1,attrs)</span> in PROV-ASN,</span> contains:
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying the relation;</li>
+<li><em>informed</em>: the identifier of the informed activity;
+<li><em>informant</em>: the identifier of the informant activity;
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe properties of the relation.</li>
+</ul>
+<p> Relation <span class="name">wasInformedBy</span> is not transitive.</p>
+
+
+<div class="anexample">
+<p>
+Consider two long running services, which we represent by activities <span class="name">s1</span> and <span class="name">s2</span>.
+<pre class="codeexample">
+activity(s1,,,[prov:type="service"])
+activity(s2,,,[prov:type="service"])
+wasInformedBy(s2,s1)
+</pre>
+The last line indicates that some entity was generated by <span class="name">s1</span> and used by <span class="name">s2</span>.
+</div>
+
+
+<p>
+A control ordering relation<span class="withAsn">, written as
+<span class="name">wasStartedBy(id, a2, a1, attrs)</span> in PROV-ASN,</span> contains: </p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier of the relation;</li>
+<li><em>started</em>: the identifier of the started activity;
+<li><em>starter</em>: the identifier of the activity that started the other;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+</ul>
+
+
+
+
+<div class="anexample">
+<p>
+Suppose activities <span class="name">a1</span> and <span class="name">a2</span> are computer processes that are executed on different hosts, and that <span class="name">a1</span> started <span class="name">a2</span>. This can be expressed as in the following fragment:</p>
+<pre class="codeexample">
+activity(a1,t1,t2,[ex:host="server1.example.org",prov:type="workflow"])
+activity(a2,t3,t4,[ex:host="server2.example.org",prov:type="subworkflow"])
+wasStartedBy(a2,a1)
+</pre>
+</div>
+
+</section>
+
+<section id="term-traceability">
+<h3>Traceability</h3>
+
+<p> A <dfn title="dfn-Traceability">traceability relation</dfn> between two entities <span class="name">e2</span> and <span class="name">e1</span> is a generic dependency of <span class="name">e2</span>
+on <span class="name">e1</span> that indicates either that <span class="name">e1</span> was necessary for <span class="name">e2</span> to be created, or that <span class="name">e1</span> bears
+some responsibility for <span class="name">e2</span>'s existence.
+
+
+<p> A traceability relation<span class="withAsn">, written <span class="name">tracedTo(id,e2,e1,attrs)</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying the relation;</li>
+<li><em>entity</em>: an identifier identifying an entity;
+<li><em>ancestor</em>: an identifier identifying an ancestor entity that the former depends on;
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe properties of the relation.</li>
+</ul>
+<p>We note that the ancestor is allowed to be an agent since agents are entities. </p>
+
+<div class="anexample">
+<p>We refer to the example of <a href="#section-example-a">Section 3.1</a>, and specifically to <a href="#prov-tech-report">Figure prov-tech-report</a>. We can see that there is a path from
+<span class="name">tr:WD-prov-dm-20111215</span> to
+<span class="name">w3:Consortium</span> or to
+<span class="name">pr:rec-advance</span>. This is expressed as follows.
+<pre class="codeexample">
+ tracedTo(tr:WD-prov-dm-20111215,w3:Consortium)
+ tracedTo(tr:WD-prov-dm-20111215,pr:rec-advance)
+</pre>
+</div>
+
+
+<p>Further considerations:</p>
+<ul>
+ <li>Traceability is more general than <a href="#Derivation-Relation">Derivation</a>.
+</ul>
+
+
+<div class='note'>
+ I propose to delete the following, given that this document does not mention inferences. [LM]
+<p>Further considerations:</p>
+<ul>
+ <li>Traceability is more general than <a href="#Derivation-Relation">Derivation</a>. This means that an assertion of the form: <span class="name">tracedTo(...,e2,e1,...)</span> can be inferred from an assertion of the form:
+ <span class="name">wasDerivedFrom(e2,e1,..)</span>. The precise inference rules are specified in [REF].
+ <li>Traceability is related to responsibility by way of inference rules that involve <a href="#term-responsibility">responsibility chain</a> and <a href="#term-Generation">generation</a> relations.
+ These rules are specified in [REF]
+</ul>
+</div>
+
+<div class="note">looking at the definition, there is something wrong. It's not true that e2 was neceaary for e1 (in the transitive case) and
+that e1 bears responsibility. [LM]</div>
+</section>
+
+
+
+<section id="term-quotation">
+<h3>Quotation</h3>
+
+<div class="note">I find that quotation is really a misnomer. This expands into derivation with attribution, in what sense is the derived entity a "quote" of the original? . The agent that is quoted is particularly obscure. It does not seem to be involved in the quoting at all. Why isn't quoting an activity with the quoting agent associated with it? [PM]</div>
+
+<p> A <dfn>quotation</dfn>
+ is the repeat of an entity (such as text or image) by
+someone other that its original author. Quotation
+ is a particular case of <a href="#Derivation-Relation">derivation</a> in which entity <span class="name">e2</span> is derived from entity <span class="name">e1</span> by copying, or "quoting", parts of it.</p>
+
+<p> A quotation relation<span class="withAsn">, written <span class="name"> wasQuotedFrom(id,e2,e1,ag2,ag1,attrs)</span> in PROV-ASN,</span> contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier for the relation;</li>
+<li><em>quote</em>: an identifier of the entity that represents the quote (the partial copy);
+<li><em>quoted</em>: an identifier of the original entity being quoted;
+<li><em>quoterAgent</em>: an OPTIONAL identifier of the agent who is doing the quoting;
+<li><em>quotedAgent</em>: an OPTIONAL identifier of the agent who attributed to the original entity;
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+
+</ul>
+
+</section> <!-- end quotation -->
+
+
+<section id="term-summary">
+<h3>Summary</h3>
+
+<div class="note">Omitted as this is likely to be removed [PM]</div>
+
+<div class='issue'>Drop this relation <a href="http://www.w3.org/2011/prov/track/issues/220">ISSUE-220</a>.</div>
+
+
+</section> <!-- end summary -->
+
+
+<section id="term-orignal-source">
+<h3>Original Source</h3>
+
+<div class="note"> I find this relation confusing. Please add an example. I wouldn't really know when to use this. [PM]</div>
+
+<p> An <dfn>original source relation</dfn> is a particular case of <a href="#Derivation-Relation">derivation</a> that states that an entity <span class="name">e2</span> (derived) was originally part of some other entity <span class="name">e1</span> (the original source).</p>
+
+<p> An original source relation<span class="withAsn">, written <span class="name"> hadOriginalSource(id,e2,e1,attrs)</span>,</span> contains:</p>
+<ul>
+<li><em>id</em>: an OPTIONAL identifier identifying the relation;</li>
+<li><em>derived</em>: an identifier for the derived entity; </li>
+<li><em>source</em>: an identifier for the original source entity;</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
+</ul>
+
+</section> <!-- end original source -->
+
+
+
+<section id="term-Collection">
+<h3>Collections</h3>
+
+<p><strong>Collection relations</strong> address the need to describe the evolution of entities that have a collection structure, that is, which may contain other entities. Specifically, this section exploits the built-in type for entities, called <a title="concept-collection">collection</a>, and two relations to describe the effect of adding elements to, and removing elements from, a collection entity.
+The intent of these relations and entity types is to capture the <em>history of changes that occurred to a collection</em>. </p>
+
+<p>A collection is an entity that has a logical internal structure consisting of key-value pairs, often referred to as a map.
+More precisely, the following entity types are introduced:
+
+<ul>
+ <li> <span class="name">Collection</span> denotes an entity of type collection, i.e. an entity that can participate in insertion and removal relations;
+
+ <li><span class="name">EmptyCollection</span> denotes an empty collection.
+</ul>
+
+The following relations relate a collection <span class="name">c1</span> with a collection <span class="name">c2</span> obtained after adding or removing a new pair to (resp. from) <span class="name">c1</span>:
+
+<ul>
+ <li>Insertion relation <span class="name">CollectionAfterInsertion(c2, c1, k, v)</span> states that <span class="name">c2</span> is the state of the collection
+following the insertion of pair <span class="name">(k,v)</span> into collection <span class="name">c1</span>;</li>
+
+<li> Removal relation <span class="name">CollectionAfterRemoval(c2,c1, k)</span> states that <span class="name">c2</span> is the state of the collection following the removal of the pair corresponding to key <span class="name">k</span> from <span class="name">c1</span>.</li>
+
+</ul>
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="EmptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+ entity(c1, [prov:type="Collection"])
+ entity(c2, [prov:type="Collection"])
+
+ CollectionAfterInsertion(c1, c, "k1", v1) // c1 = { ("k1",v1) }
+ CollectionAfterInsertion(c2, c1, "k2", v2) // c2 = { ("k1",v1), ("k2", v2) }
+ CollectionAfterRemoval(c3, c2, k1) // c3 = { ("k2",v2) }
+</pre>
+</div>
+
+
+<p> A relation CollectionAfterInsertion<span class="withAsn">, written <span class="name"> CollectionAfterInsertion(collAfter, collBefore, key, value)</span>,</span> contains:</p>
+<ul>
+<li><em>after</em>: an identifier for the collection <em>after</em> insertion; </li>
+<li><em>before</em>: an identifier for the collection <em>before</em> insertion;</li>
+<li><em>key</em>: the key that has been inserted</li>
+<li><em>value</em>: an identifier for the value that has been inserted with the key.</li>
+</ul>
+
+<p> A relation CollectionAfterDeletion, written <span class="name"> CollectionAfterDeletion(collAfter, collBefore, key)</span>, contains:</p>
+<ul>
+<li><em>after</em>: an identifier for the collection <em>after</em> the deletion; </li>
+<li><em>before</em>: an identifier for the collection <em>before</em> the deletion;</li>
+<li><em>key</em>: the key corresponding to the (key, value) pair that has been deleted from the collection.</li>
+</ul>
+
+<div class='note'>
+I propose to call them afterInsertion instead of CollectionAfterInsertion (likewise, for deletion).
+What about attributes and optional Id?
+</div>
+
+
+<p>Further considerations:</p>
+
+<ul>
+ <li>The <strong>map</strong> collection type provides a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more (the specification of such specialized structures in terms of key-value pairs is out of the scope of this document).</li>
+
+<li>Keys are literals, and values are entities. This allows expressing nested collections, that is, collections whose values include entities of type collection.</li>
+
+<li>Insertion and removal relations are a particular case of <a href="#Derivation-Relation">derivation</a>.</li>
+
+ <li>This representation of a collection's evolution makes no assumption regarding the underlying data structure used to store and manage collections. In particular, no assumptions are needed regarding the mutability of a data structure that is subject to updates. In fact, the state of a collection (i.e., the set of key-value pairs it contains) at a given point in a sequence of operations is never stated explicitly. Rather, it can be obtained by querying the chain of derivations involving insertions and removals. Entity type <span class="name">emptyCollection</span> can be used in this context as it marks the start of a sequence of collection operations.</li>
+
+
+<!--
+ <li> One can have multiple assertions regarding the state of a collection following a <em>set</em> of insertions, for example:<br/>
+<span class="name">CollectionAfterInsertion(c2,c1, k1, v1)</span><br/>
+<span class="name">CollectionAfterInsertion(c2,c1, k2, v2)</span><br/>
+ <span class="name">...</span><br/>
+This is interpreted as <em>" <span class="name">c2</span> is the state that results from inserting <span class="name">(k1, v1)</span>, <span class="name">(k2, v2)</span> etc. into <span class="name">c1</span>"</em></li></p>
+
+<li> It is possible to have multiple derivations from a single root collection, possibly by different asserters, as shown in the following example.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="EmptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+ entity(v3)
+ entity(c1, [prov:type="Collection"])
+ entity(c2, [prov:type="Collection"])
+ entity(c3, [prov:type="Collection"])
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 = { (k1,v1) }
+ CollectionAfterInsertion(c2, c, k2, v2) // c2 = { (k2 v2) }
+ CollectionAfterInsertion(c3, c1, k3,v3) // c3 = { (k1,v1), (k3,v3) }
+</pre>
+</div>
+
+<div class='note'>Asserter not defined</div>
+</li></p>
+
+
+<li>Given the pair of assertions:
+
+<span class="name">CollectionAfterInsertion(c, c1, k1, v1)</span><br/>
+<span class="name">CollectionAfterInsertion(c, c2, k2, v2)</span><br/>
+
+it follows that <span class="name">c1==c2, k1==k2, v1==v2</span>, because one cannot have two different derivations for the same final collection state.</li></p>
+
+
+<li>Given the following set of insertions:<br/>
+
+<span class="name">CollectionAfterInsertion(c1, c, k, v1)</span><br/>
+<span class="name">CollectionAfterInsertion(c1, c, k, v2)</span><br/>
+
+it follows that <span class="name">v1==v2</span>.</li></p>
+
+
+<li> The state of a collection is only known to the extent that a chain of derivations starting from an empty collection can be found. Since a set of assertions regarding a collection's evolution may be incomplete, so is the reconstructed state obtained by querying those assertions. In general, all assertions reflect the asserter's partial knowledge of a sequence of data transformation events. In the particular case of collection evolution, in which the asserter <em>knows</em> that some of the state changes may have been missed, then the more generic <a href="#Derivation-Relation">derivation</a> relation should be used to signal that some updates may have occurred, which cannot be precisely asserted as insertions or removals. The following two examples illustrate this.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="collection"]) // e is a collection, possibly not empty
+ entity(v1)
+ entity(v2, [prov:type="collection"]) // v2 is a collection
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 <em>includes</em> { (k1,v1) } but may contain additional unknown pairs
+ CollectionAfterInsertion(c2, c1, k2, v2) // c2 includes { (k1,v1), (k2 v2) } where v2 is a collection with unknown state
+</pre>
+</div>
+ In the example, the state of <span class="name">c2</span> is only partially known because the collection is constructed from partially known other collections.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="emptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 = { (k1,v1) }
+ wasDerivedFrom(c2, c1) // the asserted knows that c2 is somehow derived from c1, but cannot assert the precise sequence of updates
+ CollectionAfterInsertion(c3, c2, k2, v2)
+</pre>
+</div>
+Here <span class="name">c3</span> includes <span class="name">{ (k2 v2) }</span> but the earlier "gap" leaves uncertainty regarding <span class="name">(k1,v1)</span> (it may have been removed) or any other pair that may have been added as part of the derivation activities.</li></p>
+-->
+</ul>
+<div class='note'>Deleted further items. Some of them are constraints which belong to part 2.</div>
+
+
+</section> <!-- end collections-->
+
+
+</section>
+
+<!-- end sec. 5 -->
+
+ <section id="extensibility-section">
+<h2>PROV-DM Extensibility Points</h2>
+
+
+<p>The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
+
+<ul>
+<li> Attributes occur in all elements and relations of the data model. Applications are free to introduce
+application-specific attributes, according to their perspective on the world. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace
+declared in a namespace declaration.
+
+<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes catering for extensibility: <span class="name">type</span>, <span
+class="name">location</span>.</li>
+
+
+<li> Sets of Attribute-value pairs offer a mechanism to
+describe modalities of use, generation, activity association, and responsibility chain.
+Such attributes are also qualified by namespaces.
+
+<p>To this end, the <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
+
+
+<li>Notes allow arbitrary metadata to be associated with anything identifiable in PROV-DM. Notes consist of name-value pairs. Like attributes, names are qualified by a
+namespace.</li>
+
+
+<li>Namespaces allow attributes and names to be qualified. </li>
+
+<li>Sub-typing of elements and relations is allowed by means of the reserved attribute <span class="name">type</span>.</li>
+
+<li>Domain specific values can be expressed by means of typed literals. </li>
+</ul>
+
+<p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged. To ensure interoperability, specializations of
+the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in the PROV-DM documents (part 1 to 3). </p>
+
+
+
+ </section>
+
+
+
+<section id="FurtherConsiderations">
+<h4>Data Model Constraints</h4>
+
+
+<ul>
+
+<li>This specification defines PROV-DM, a data model that allows
+descriptions of the people, institutions, entities, and activities,
+involved in producing, influencing, or delivering a piece of data or a
+thing to be expressed. However, with this data model, it is also possible to compose
+descriptions that would not make sense: for instance, one could
+express that an entity was used before it was generated, or that the
+activity that generated an entity began its existence after the entity
+generation. A set of consistency constraints have been defined for PROV-DM and
+can be found in a companion specification [[PROV-DM-CONSTRAINTS]].
+They can be used by asserters as a guideline for composing provenance descriptions that are consistent, and
+by implementers of reasoning engines. </li>
+
+
+
+<li>
+<p> The example of <a href="#prov-dm-example">section 3</a> contains identifiers such as <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, which denotes a specific version of a technical report. On the other hand, a URI such as <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a> points to the latest version of a document. One needs to ensure that provenance descriptions for the latter document remain valid as denoted resources change. </p>
+
+<p>To this end, PROV-DM allows asserters to describe "<em>partial states</em>" of entities by means of attributes and associated values. Some further constraints apply to the use of these attributes, since the values associated with them are expected to remain unchanged for some period of time. The constraints associated to attributes are also specified in the companion specification [[PROV-DM-CONSTRAINTS]].</p>
+
+
+</li>
+
+
+<li>The existence of some mechanism(s) by which a set of provenance descriptions can be bundled up and named is assumed. No such mechanism is considered as mature for standardization, and therefore such mechanisms remain outside the scope of PROV-DM. Various ways of achieving this functionality exist, for instance, by:
+<ul>
+<li> bundling up a set of descriptions in a file and exposing it as a Web resource;</li>
+<li> relying on specific serializations to name bundles of descriptions;</li>
+<li> using the idea of a service that is capable of associating provenance descriptions to whom they are attributed to.</li>
+</ul>
+<p>Even though a mechanism for blundling up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named bundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-accountEntity">AccountEntity</a> so that its provenance can be expressed. The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as constraint that <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
+</li>
+
+
+</ul>
+
+
+</section>
+
+<div id="glossary_div" class="remove">
+<!-- glossary loaded from glossary.js will be hooked up here,
+ class remove, will remove this element from the final output.
+-->
+</div>
+
+ </body>
+</html>