first draft for hadPlan
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Tue, 13 Dec 2011 10:43:07 +0000
changeset 1252 6424f1990610
parent 1251 0fc9b1b3d1d1 (current diff)
parent 1250 1c3ba3c8f89b (diff)
child 1254 4bc03973e793
child 1261 3846a5309428
first draft for hadPlan
--- a/primer/Primer.html	Tue Dec 13 10:42:45 2011 +0000
+++ b/primer/Primer.html	Tue Dec 13 10:43:07 2011 +0000
@@ -1,964 +1,1010 @@
-<!DOCTYPE html>
-<html><head> 
-  <title>Prov Model Primer</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 class="remove">
-   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-Primer",
- 
-    // if your specification has a subtitle that goes below the main
-    // formal title, define it here
-    subtitle   :  "Initial draft for internal discussion",
- 
-    // if you wish the publication date to be other than today, set this
-    // publishDate:  "2009-08-06",
- 
-    // 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:  "1977-03-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/primer/Primer.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: "Yolanda Gil", url: "http://www.isi.edu/~gil/",
-      company: "Information Sciences Institute, University of Southern California, US" },
-     { name: "Simon Miles", url: "http://www.inf.kcl.ac.uk/~simonm",
-      company: "King's College London, UK" },
-    ],
- 
-    // 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: "TBD"},
-    ],
-          
-    // name of the WG
-    wg:           "Provenance Working Group",
-          
-    // URI of the public WG page
-    wgURI:        "http://www.w3.org/2011/prov/wiki/Main_Page",
-          
-    // 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:  "",
-   };
-  </script>
- </head>
- <body>
-  <section id="abstract">
-   <p>This document aims to provide an intuitive guide to the PROV Data Model,
-    with worked examples.</p>
-
-   <p>
-    This is a document for internal discussion, which will ultimately
-    evolve in the first Public Working Draft of the Primer.</p>
-  </section> 
-
-  <section> 
-   <h2>Introduction</h2>
-   <p>
-    This primer document provides an accessible introduction to the PROV Data Model
-    (PROV-DM) standard for representing provenance on the Web, and its representation
-    in the PROV Ontology (PROV-O).  Provenance describes
-    the origins of things, so PROV-DM data consists of assertions about the past.
-   </p>
-
-   <p>
-    This primer document aims to ease the adoption of the standard by providing:
-   </p>
-   <ul>
-    <li>An intuitive explanation of how PROV-DM models provenance.</li>
-    <li>Worked examples that can be followed to produce your own PROV-DM data.</li>
-    <li>Answers to frequently asked questions regarding how the model should be applied.</li>
-   </ul>
-
-   <p>
-    The provenance of digital objects represents their origins.  The PROV-DM is a 
-    proposed standard to represent provenance records, which reflect the entities 
-    and activities involved in producing and delivering or otherwise influencing a 
-    given object.  By knowing the provenance of an object, we can make determinations 
-    about how to use it.  Provenance records can be used for many purposes, such as 
-    understanding how data was collected so it can be meaningfully used, determining 
-    ownership and rights over an object, making judgments about information to 
-    determine whether to trust it, verifying that the activity used to obtain a 
-    result complies with given requirements, and reproducing how something it was generated.
-   </p>
-
-   <p>
-    As a standard for provenance, PROV-DM accommodates all those different uses 
-    of provenance.  However, different people may have different perspectives on provenance, 
-    and as a result different types of information might be captured in a provenance record.  
-    One perspective might focus on <i>agent-centered provenance</i>, that is, what entities 
-    were involved in generating or manipulating the information in question.  For example, 
-    in the provenance of a picture in a news article we might capture the photographer who 
-    took it, the person that edited it, and the newspaper that published it. A second perspective 
-    might focus on <i>object-centered provenance</i>, by tracing the origins of portions of a 
-    document to other documents. An example is having a web page that was assembled from content
-    from a news article, quotes of interviews with experts, and a graph that plots data from a 
-    government agency.  A third perspective one might take is on <i>process-centered provenance</i>, 
-    capturing the actions and steps taken to generate the information in question.  For example, a 
-    graph may have been generated by invoking a service to retrieve data from a database, and then 
-    extracting certain statistics from the data using some statistics package.
-   </p>
-
-   <p>
-    Provenance records are metadata.  There are other kinds of metadata that is 
-    not provenance.  For example, the size of an image is a metadata property of 
-    that image but it is not provenance.
-   </p>
-
-   <p>
-    A comprehensive overview of requirements, use cases, prior research, and proposed 
-    vocabularies for provenance are available from the 
-    <a href="http://www.w3.org/2005/Incubator/prov/XGR-prov/">Final Report of the W3C Provenance Incubator Group</a>.  
-    The document contains three general scenarios 
-    that may help identify the provenance aspects of your planned applications and 
-    help plan the design of your provenance system.
-   </p>
-   <p>
-    For a detailed description of PROV-DM, please refer to the 
-    <a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html">PROV Data Model and Abstract Syntax Notation Document</a>.
-   </p>
-  </section>
-
-  <section>
-   <h2>Intuitive overview of PROV-DM</h2>
-
-   <p><i>This section provides an intuitive explanation of the concepts in PROV-DM. 
-     As with the rest of this document, it should be treated as a starting point for
-     understanding the model, and not normative in itself. The model specification
-     provides the precise definitions and constraints to be followed in using PROV-DM.</i></p>
-
-   <section>
-    <h3>Entities</h3>
-
-    <p>
-     In PROV-DM, the things that you may ask the provenance of are called <i>entities</i>.
-     An entity’s provenance may refer to many other entities.  For example, a document D is
-     an entity whose provenance refers to other entities such as a graph inserted into D,
-     the dataset that was used to create that graph, or the author of the document.
-    </p>
-    <p>
-     Entities are described and identified by their attributes, may be more
-     or less specific, and may be described from different perspectives.  For example,
-     document D, the second version of document D, and document D as stored on my file system,
-     are three distinct entities for which we may describe the provenance. They
-     may all be perspectives on the same thing in the world (document D may exist only
-     in its second version and on my file system), but are <i>characterized</i> in
-     different ways by being described using different <i>attributes</i> (version, location, and 
-     so on).
-    </p>
-    <p>
-      The characterization of an entity means that the provenance assertions
-      about the entity are only about the thing when it has those attributes.
-      For example, the second version of document D is characterized by being the
-      second version, and so assertions about who reviewed that entity apply only
-      to the document as it is in its second version. When the document becomes
-      the third version, a new entity exists (the third version of D) and the
-      provenance assertions about who reviewed the second version do not apply.
-    </p>
-   </section>
-
-   <section>
-    <h3>Activities</h3>
-
-    <p>
-     While entities are static aspects in the world (things), <i>activities</i> are
-     dynamic aspects (actions, processes, etc.)
-     An activity is something that has either occurred or is still 
-     taking place. Most importantly, activities are how entities come into 
-     existence, often making use of previously existing entities to achieve this. 
-     For example, if the second version of document D was generated 
-     by a translation from the first version of the document in another language,
-     then this translation is an activity.
-    </p>
-   </section>
-
-   <section>
-    <h3>Use and Generation</h3>
-
-    <p>
-     Every entity is created by an activity, which is called the <i>generation</i> of the entity.
-     For example, writing a document brings the document into existence, while
-     revising the document brings a new version into existence.
-     Activities also make <i>use</i> of entities. For example, revising a document
-     to fix spelling mistakes uses the original version of the document as well
-     as a list of corrections. In PROV-DM, assertions can be made to state that 
-     particular activities used or generated particular entities.
-    </p>
-   </section>
-
-   <section>
-    <h3>Agents</h3>
-
-    <p>
-     An agent is a type of entity that takes an active role in an activity such 
-     that it can be assigned some degree of responsibility for the activity taking 
-     place. An agent can be a person, a piece of software, or an inanimate object.
-     In PROV-DM, agents are a kind of entity, and it is therefore possible to 
-     associate provenance with agents.  Consider a graph displaying some statistics 
-     regarding crime rates over time in a linear regression.  To represent the 
-     provenance of a that graph, we could state that the person who created the 
-     graph was an agent involved in its creation, and that the software used to 
-     create the graph was also an agent involved in that activity.  We 
-     can also represent the provenance of that software and the agents involved in 
-     that, such as the vendor of that software.
-    </p>     
-   </section>
-
-   <!--section>
-    <h3>Accounts</h3>
-  
-    <p>An intuitive overview of how to think about accounts in PROV-DM.</p>
-   </section -->
-
-   <section>
-    <h3>Roles</h3>
-
-    <p>
-     A role is a description of the function or part an entity 
-     played in an activity.  In PROV-DM data, roles are qualifying, application-specific,
-     information about the relationship between an entity and an activity, whether
-     that is how an activity used an entity, generated an entity, or was controlled by an agent.
-     For example, an agent may play the role of "editor" in an activity that uses
-     one entity in the role of "document to be edited" and another in the role of "edits
-     to be made", to generate a further entity in the role of "edited document".
-    </p>
-    <!--p>Roles are intended as an extension point in the model; it is expected users will define and use custom role taxonomies.  Role interpretation is application specific.</p -->
-   </section>
-
-   <section>
-    <h3>Revisions</h3>
-
-    <p>
-     A single resource, such as a document, may go through multiple revisions 
-     (also called versions and other comparable terms) over time. Between revisions, 
-     several changes may have taken place to the resource, each possibly controlled 
-     by different agents. The result of each revision is, in PROV-DM terms, an entity, 
-     and PROV-DM allows one to relate those entities by making an assertion that 
-     one is a revision of another.
-    </p>
-   </section>
-
-   <section>
-    <h3>Complementarity</h3>
-    <p>
-     As described above, entities can be described from different perspectives,
-     by being characterized by different attributes. For example, "document D",
-     "the second version of document D" and "document D as stored on my filesystem"
-     are different entities
-     because they are characterized in different ways. However, for some period of time
-     they may all refer to the same thing in the world, e.g. for a while the copy of 
-     D on my filesystem <i>was</i> the second version.
-    </p>
-    <p>
-     In PROV-DM, we say there is <i>complementarity</i> between one entity and another
-     if, in some period of time, they have the same or compatible characterization.
-     So, both "the second version of document D" and "document D as stored on my filesystem"
-     are complements of "document D", because they are both characterized by being
-     document D, but with specific additional attributes.
-     If, at some point in time, a version of D stored on my filesystem is the second one, then
-     "document D as stored on my filesystem" and "the second version of document D" are
-     complements of each other.
-    </p>
-
-    <!-- p>
-     Several asserted entities could be characterizing the same thing, in
-     particular when entities are asserted by different <em>accounts</em> or over
-     different time periods. If two such entities have <em>overlapping
-      lifespans</em>, and the first entity have some <em>attributes</em> that
-     have not been asserted (and not necessarily always true) for the second entity,
-     then the first entity is said to be <em>complementing</em> the second
-     entity, that is the first entity helps form a more detailed
-     description of the second entity, at least for the duration of the
-     overlapping lifespan.  
-    </p> 
-    <p> 
-     In addition, if <code>:A prov:wasComplementOf :B</code>, then of all the
-     attributes of the entity <code>:A</code> which can be <em>mapped</em> to
-     <em>compatible</em> attributes of <code>:B</code> MUST be <em>matching</em>
-     for the continuous duration of the overlap of <code>:A</code> and
-     <code>:B</code>'s lifespans.
-     It is out of scope for PROV to specify or assert the nature of
-     the <em>compatibility mapping</em> and <em>matching</em>, the exact
-     interpretation of these is left to the asserter of
-     <code>wasComplementOf</code>
-    </p>
-    <p>
-     If <code>:B</code> also have some attributes which 
-     are not asserted (or not always true) about <code>:A</code>,
-     then this MAY be asserted using the 
-     inverse relation <code>:B prov:wasComplementOf :A</code>. If two entities
-     both complement each other in this manner, both MUST have some
-     attributes the other does not have, although those attributes MAY
-     not have been asserted in the provenance. Note that the
-     <em>lack</em> of such an inverse assertion does not neccessarily
-     mean that <code>:B</code> did not have any additional attributes
-     for <code>:A</code> in the timespan, only that this has not
-     been asserted.
-    </p>
-    <p>
-     In the simplest case, both entites are described using the same
-     attributes, in which case <em>matching</em> means the values SHOULD
-     literally be the same (matching by identity). On the other hand an
-     attribute like <code>ex1:speed_in_mph</code> can be <em>mapped</em> to
-     a compatible <code>ex2:speed_in_kmh</code> attribute. Not all
-     attributes might be mappable in both directions, for instance
-     <code>ex1:city</code> to <code>ex2:country</code>, but not vice
-     versa.
-    </p>
-    <p>
-     Note that it is out of scope for PROV to assert or explain any
-     mapping of compatible attributes. This is merely a conclusion 
-     that can be drawn from the assertion that the two entities both
-     described the same thing in the overlapping time spans.  Also note
-     that asserting a complementary relationship does not detail how the
-     two entity timespans overlap, this could be anything from
-     complete one-to-one match (where all attributes are always true for
-     both entities) to merely touching overlaps. 
-    </p -->
-   </section>
-
-   <section>
-    <h3>Derivation</h3>
-
-    <p>
-     When one entity's existence, content, characteristics and so on are
-     at least partly due to another entity, then we say that the former is
-     derived from the latter. For example, one document may contain
-     material copied from another, a child is derived from his/her
-     ancestors, and a page displayed in a browser is derived from the same
-     page on the web server from which it was downloaded, as well as from
-     the designer's original sketches of what the page would look like.
-    </p>
-    <p>
-     There are different kinds of derivation expressible in PROV-DM.
-     Consider the case of the page in the browser above. It is derived from
-     the designer's sketch in the strictest sense, i.e. if the sketch had
-     been different so would the page. On the other hand, there are
-     entities that are part of the page's history but which did not inform
-     the content of that page, i.e. the page would have been the same even
-     if the earlier entity changed. For example, on creating the original
-     draft of the page, the designer may have included a banner image
-     saying "DRAFT - FOR REVIEW ONLY". This banner was not part of the
-     sketch, nor part of the published page downloaded to the browser, but
-     was part of the page's history, and while not affecting the browsed
-     page's content may have been a factor in its existence. Finally, in
-     some cases, we may be able to say not only that one entity was derived
-     from another, but also how it was derived, i.e. by what activity.
-     For example, the page in the browser is derived from the
-     page on the web server because a download activity sent the bytes of
-     the latter across an HTTP connection to the browser client.
-    </p>
-    <p>
-     In PROV-DM terms, we say that the page in the browser <i>was eventually
-      derived from</i> the sketch, <i>depended on</i> the banner image, and <i>was derived
-      from</i> the page on the web server due to the download activity.
-    </p>
-   </section>
-  </section>
-
-  <section>
-   <h2>Worked Examples</h2>
-
-   <p>In the following sections, we show how PROV-DM can be used to model 
-    provenance in specific examples.</p>
-
-   <p>We include examples of how the formal ontology 
-    can be used to represent the PROV-DM assertions as RDF triples.
-    These are shown using the Turtle notation. In 
-    the latter depictions, the namespace prefix <b>prov</b> denotes 
-    terms from the Prov ontology, while <b>ex1</b>, <b>ex2</b>, etc. 
-    denote terms specific to the example.</p>
-
-   <p>We also provide a representation of the examples in the Abstract
-    Syntax Model used in the conceptual model document. The full ASM data is
-    included in the appendix.</p>
-
-   <section>
-    <h3>Entities</h3>
-
-    <p>
-     An online newspaper publishes an article making using of data (GovData) provided through a government portal, in England. 
-     The article includes a chart based on GovData, with data values aggregated by
-     regions of the country.
-    </p>
-    <p>
-     A blogger, Betty, looking at the chart, spots what she thinks to be an error.
-     Betty retrieves the provenance of the chart, to determine from where the facts presented derive.
-    </p>
-    <p>The Prov data includes the assertions:</p>
-    <pre class="turtle example">
-     ex1:dataSet1    a prov:Entity .
-     ex1:regionList1 a prov:Entity .
-     ex1:aggregate1  a prov:Entity .
-     ex1:chart1      a prov:Entity .
-    </pre>
-    <p>
-     These statements, in order, assert that the original data set is an entity (<code>ex1:dataSet1</code>),
-     the list of regions
-     (<code>ex1:regionList1</code>) is an entity, the data aggregated by region is an entity (<code>ex1:aggregate1</code>), 
-     and the chart (<code>ex1:chart1</code>) is an entity.
-    </p>
-
-   </section>
-
-   <section>
-    <h3>Activities</h3>
-
-    <p>
-     Further, the Prov data asserts that there was
-     an activity (<code>ex1:compiled</code>) denoting the compilation of the
-     chart from the data set.
-    </p>
-    <pre class="turtle example">
-     ex1:compiled a prov:Activity .
-    </pre>
-    <p>
-     The provenance also includes reference to the steps involved in compilation,
-     aggregating the data by region and generating the chart graphic.
-    </p>
-    <pre class="turtle example">
-     ex1:aggregated  a prov:Activity .
-     ex1:illustrated a prov:Activity .
-    </pre>
-   </section>
-
-   <section>
-    <h3>Use and Generation</h3>
-
-    <p>
-     Finally, the Prov data asserts the key events that connected the above
-     entities and activities, i.e. the use of an entity by an activity,
-     or the generation of an entity by an activity.
-    </p>
-    <p>
-     For example, the data below states that the aggregation activity
-     (<code>ex1:aggregated</code>) used the data set, that it used the list of
-     regions, and that the aggregated data was generated by this activity.
-    </p>
-    <pre class="turtle example">
-     ex1:aggregated prov:used           ex1:dataSet1 ;
-                    prov:used           ex1:regionList1 .
-     ex1:aggregate1 prov:wasGeneratedBy ex1:aggregated .
-    </pre>
-    <p>
-     Similarly, the chart graphic creation activity (<code>ex1:illustrated</code>)
-     used the aggregated data, and the chart was generated by this activity.
-    </p>
-    <pre class="turtle example">
-     ex1:illustrated prov:used           ex1:aggregate1 .
-     ex1:chart1      prov:wasGeneratedBy ex1:illustrated .
-    </pre>
-
-    <!-- p>
-     For example, the provenance declares the event (of type <code>prov:Usage</code>)
-     where the aggregation activity used the GovData data set, and the event
-     (of type <code>prov:Generation</code>) where the same activity generated
-     the data aggregated by region.
-    </p>
-    <pre class="turtle example">
-     ex1:dataSet1Usage        a prov:Usage .
-     ex1:aggregate1Generation a prov:Generation .
-    </pre>
-    <p>
-     To describe these events, the provenance says within which activity
-     they occur and what entity is used or generated.
-    </p>
-    <pre class="turtle example">
-     ex1:aggregated prov:qualifiedUsage      ex1:dataSet1Usage .
-     ex1:aggregated prov:qualifiedGeneration ex1:aggregate1Generation .
-     ex1:dataSet1Usage        prov:entity ex1:dataSet1 .
-     ex1:aggregate1Generation prov:entity ex1:aggregate1 .
-    </pre>
-    <p>
-     Comparable events are described for the activity of generating the chart image
-     from the aggregated data.
-    </p>
-    <pre class="turtle example">
-     ex1:aggregate1Usage  a prov:Usage .
-     ex1:chart1Generation a prov:Generation .
-     ex1:illustrated prov:qualifiedUsage      ex1:aggregate1Usage .
-     ex1:illustrated prov:qualifiedGeneration ex1:chart1Generation .
-     ex1:aggregate1Usage  prov:entity ex1:aggregate1 .
-     ex1:chart1Generation prov:entity ex1:chart1 .
-    </pre -->
-    <p>
-     From this information Betty can see that
-     the mistake could have been in the original data set or else was introduced
-     in the compilation activity, and sets out to discover which.
-    </p>
-
-   </section>
-
-   <section>
-    <h3>Agents</h3>
-
-    <p>
-     Digging deeper, Betty wants to know who compiled the chart.  Betty sees 
-     that both the aggregation and chart creation activities were controlled 
-     by the Derek.
-    </p>
-    <pre class="turtle example">
-     ex1:aggregated  prov:wasControlledBy ex1:derek .
-     ex1:illustrated prov:wasControlledBy ex1:derek .
-    </pre>
-    <p>
-     The record for Derek provides the
-     following information, of which the first line is a PROV-O statement that
-     Derek is a (PROV-DM) agent.
-    </p>
-    <pre class="turtle example">
-     ex1:derek a prov:Agent ;
-               a foaf:Person ;
-               foaf:givenName "Derek"^^xsd:string ;
-               foaf:mbox      &lt;mailto:dererk@example.org&gt; .
-    </pre>
-   </section>
-
-   <!-- section>
-    <h3>Accounts</h3>
-  
-    <p><i>Suggested example:</i> The analyst provides his own record of how he compiled GovData to create 
-     the chart, which provides more detail than in the newspaper's provenance data. 
-     Specifically, the analysts account separates compilation into two stages: aggregating 
-     data by region and then producing the graphic. Therefore, there are two separate 
-     accounts of the same events.</p>
-   </section -->
-
-   <section>
-    <h3>Roles</h3>
-
-    <p>
-     For Betty to understand where the error lies, she needs to have more detailed 
-     information on how entities have been used in, participated in, and generated 
-     by activities.  Betty has determined that <code>ex1:aggregated</code> used 
-     entities <code>ex1:regionList1</code> and <code>ex1:dataSet1</code>, but she does not 
-     know what function these entities played in the processing.  Betty 
-     also knows that <code>ex1:derek</code> controlled the activities, but she does 
-     not know if Derek was the analyst responsible for determining how the data 
-     should be aggregated.
-    </p>
-    <p>
-     The above information is described as roles in the provenance data. The aggregation
-     activity involved entities in four roles: the data to be aggregated (<code>ex1:dataToAggregate</code>),
-     the regions to aggregate by (<code>ex1:regionsToAggregateBy</code>), the
-     resulting aggregated data (<code>ex1:aggregatedData</code>), and the
-     analyst doing the aggregation (<code>ex1:analyst</code>).
-    </p>
-    <pre class="turtle example">
-     ex1:dataToAggregate      a prov:Role .
-     ex1:regionsToAggregateBy a prov:Role .
-     ex1:aggregatedData       a prov:Role .
-     ex1:analyst              a prov:Role .
-    </pre>
-    <p>
-     In addition to the simple facts that the aggregation activity used, generated or
-     was controlled by entities/agents as described in the sections above, the
-     provenance data contains more details of <i>how</i> these entities and agents
-     were involved, i.e. the roles they played. For example, the data below states
-     that the aggregation activity (<code>ex1:aggregated</code>) included the usage
-     of the GovData data set (<code>ex1:dataSet1</code>) in the role of the data
-     to be aggregated (<code>ex1:dataToAggregate</code>).
-    </p>
-    <pre class="turtle example">
-     ex1:aggregated prov:hadQualifiedUsage [ a prov:Usage ;
-            prov:hadQualifiedEntity ex1:dataSet1 ;
-            prov:hadRole            ex1:dataToAggregate ] .
-    </pre>
-    <p>
-     This can then be distinguished from the same activity's usage of the list of
-     regions because the roles played are different.
-    </p>
-    <pre class="turtle example">
-     ex1:aggregated prov:hadQualifiedUsage [ a prov:Usage ;
-            prov:hadQualifiedEntity ex1:regionList1 ;
-            prov:hadRole            ex1:regionsToAggregateBy ] .
-    </pre>
-    <p>
-     Similarly, the provenance includes assertions that the same activity was
-     controlled in a particular way (<code>ex1:analyst</code>) by Derek, and that
-     the entity <code>ex1:aggregate1</code> took the role of the aggregated
-     data in what the activity generated.
-    </p>
-    <pre class="turtle example">
-     ex1:aggregated
-        prov:hadQualifiedControl [ a prov:Control ;
-            prov:hadQualifiedEntity ex1:derek ;
-            prov:hadRole            ex1:analyst
-        ] ;
-        prov:hadQualifiedGeneration [ a prov:Generation ;
-            prov:hadQualifiedEntity ex1:aggregate1 ;
-            prov:hadRole            ex1:aggregatedData
-        ] .
-    </pre>
-   </section>
-
-   <section>
-    <h3>Revision</h3>
-
-    <p>
-     After looking at the detail of the compilation activity, there appears
-     to be nothing wrong, so Betty concludes the error is in GovData. She contacts
-     the government, and a new version of GovData is created, declared to be the
-     next revision of the data by Edith. The provenance data now includes a statement
-     that the new data set, <code>ex1:dataSet2</code> is a new revision of the
-     old data set, <code>ex1:dataSet1</code>.
-    </p>
-    <pre class="turtle example">
-     ex1:dataSet2 prov:wasRevisionOf ex1:dataSet1 .
-    </pre>
-   </section>
-
-   <section>
-    <h3>Complementarity</h3>
-
-    <p>Betty lets Derek know that a new revision of the data set exists,
-     and he looks at the provenance of the new data to understand what he needs to
-     re-analyze. </p>
-    <p>In addition to specifying that 
-     <code>ex1:dataSet2</code> is a new revision of
-     <code>ex1:dataSet1</code>, the provenance from DataGov also 
-     asserts that both of these entities were a <em>complement of</em>
-     another entity <code>ex1:dataSet</code>.
-    </p>
-    <pre class="turtle example">
-     ex1:dataSet1 prov:wasComplementOf ex1:dataSet .
-     ex1:dataSet2 prov:wasComplementOf ex1:dataSet .
-    </pre>
-    <!--
-    <pre class="asn example">
-    wasComplementOf(ex1:dataSet1, ex1:dataSet)
-    wasComplementOf(ex1:dataSet2, ex1:dataSet)
-    </pre>
-    -->
-    <p>
-     This assertion means that <code>ex1:dataSet1</code> at some point shared
-     its characterizing attributes with <code>ex1:dataSet</code>, and the same for
-     <code>ex2:dataSet2</code>. Thus the <em>entity</em>
-     <code>ex1:dataSet1</code> did at some point represent the same
-     thing as characterized by the entity <code>ex1:dataSet</code>. The same is
-     true for <code>ex1:dataSet2</code>, though not necessarily at the
-     same point in time. 
-    </p>
-    <!-- p>
-     The term <em>was complement of</em> here means that the
-     <code>ex1:dataSet1</code>
-     provide additional details that adds to the details of
-     <code>ex1:dataSet</code> (complementing it), and that both of these
-     entities represented the same thing.
-     Characterizing attributes of <code>ex1:dataSet</code> are from this
-     asserted to have been <em>compatible</em> with the properties of
-     <code>ex1:dataSet1</code> and <code>ex1:dataSet2</code>.
-     <em>Compatible</em> here means that some kind of mapping can be
-     established between the attributes, they don't neccessarily have to
-     match directly.
-    </p -->
-    <p>
-     Derek then looks at the characterization of the generalized data set
-     (<code>ex1:dataSet</code>) to find the attributes shared with the first 
-     and second versions of the data set. The assertions below give the generalized
-     data set's attributes: it is of type <code>ex1:DataSet</code>, it covers
-     three named regions, it was created by <code>ex1:DataGov</code>, and
-     has a given title.
-    </p>
-    <pre class="example turtle">
-     ex1:dataSet a ex1:DataSet ;
-           ex1:regions ( ex1:North, ex1:NorthWest, ex1:East ) ;
-           dc:creator  ex1:DataGov ;
-           dc:title    "Regional incidence dataset 2011" .
-    </pre>
-    <p>
-     As <code>ex1:dataSet1</code> and <code>ex1:dataSet2</code> complement
-     <code>ex1:dataSet</code>,
-     Derek can deduce from the above attributes that both the former had
-     these same attributes at some point, i.e.      
-     the creator <code>ex1:DataGov</code> and so on.  Derek compares the above
-     assertions to the
-     attributes of <code>ex1:dataSet1</code>.
-    </p>
-    <pre class="example turtle">
-     ex1:dataSet1 a ex1:DataSet ;
-           ex1:postCodes      ( "N1", "N2", "NW1", "E1", "E2" ) ;
-           ex1:totalIncidents 141 ;
-           dc:creator         ex1:DataGov ;
-           dc:title           "Regional incidence dataset 2011" .
-    </pre>
-    <p>
-     Shared characterizing attributes are not necessarily represented in
-     the serialized assertions of different entities. For example, the creator
-     and title are exactly the same for <code>ex1:dataSet</code> and <code>ex1:dataSet1</code>,
-     but the regions covered by the data set are described in a different way:
-     "regions" for <code>ex1:dataSet</code> and "postCodes" for <code>ex1:dataSet1</code>.
-     Whether these are equivalent is a domain-specific judgment.
-     We can also see that, while <code>ex1:dataSet1</code> complements <code>ex1:dataSet</code>,
-     the inverse is not true. <code>ex1:dataSet1</code> is more specific, because
-     it has a "totalIncidents" attribute specific to that version of the data set.
-    </p>
-    <!-- p>     
-     Derek sees that the creator and title are directly mappable and 
-     equal between these entities. He also knows (from his region
-     aggregation method) that the <code>ex1:postCodes</code> <code>N1</code> and
-     <code>N2</code> are in the
-     region <code>ex1:North</code>, and so on, and can confirm that although
-     this regional characterisation of the data is not expressed
-     using the same attributes in the two entities, they are <em>compatible</em>. 
-    </p>
-    <p>Derek notes that <code>ex1:totalIncidents</code> is not stated
-     for <code>ex1:dataSet</code>, and not mappable to any of the
-     other existing attributes. Thus this could be one of the
-     complementing attributes that makes <code>ex1:dataSet1</code>
-     more specific than <code>ex1:dataSet</code>.
-
-     Derek can from the assertion <code>ex1:dataSet1
-      prov:wasComplementOf ex1:dataSet</code>
-     see that <code>ex1:dataSet</code>
-     did have 141 incidents when its characterization interval
-     overlapped that of <code>ex1:dataSet1</code>, but not neccessarily
-     throughout its lifetime. Note that in this example the provenance
-     assertions are not providing any direct description of the
-     characterization interval of the entities.
-    </p>
-    <p> 
-     Due to the open world assumption (more
-     information might be added later) he can not conclude
-     from this alone that <code>ex1:dataSet</code> at any point did
-     <strong>not</strong> have 141 incidents. He therefore does not know
-     for sure that <code>ex1:totalIncidents</code> is a complementing
-     attribute which <code>ex1:dataSet</code> does not have in its
-     characterisation.
-    </p>
-    <p>
-     Derek finally compares the newer revision 
-     <code>ex1:dataSet2</code> with
-     <code>ex1:dataSet</code>:
-    </p>
-    <pre class="example turtle">
-     ex1:dataSet2 a ex1:DataSet ;
-         ex1:postCodes ( "N1", "N2", "NW1", "NW2", "E1", "E2" ) ;
-         ex1:totalIncidents 158 ;
-         dc:creator ex1:DataGov ;
-         dc:title "Regional incidence dataset 2011" .
-    </pre>
-    <p>
-     In this revision, the new postcode <kbd>NW2</kbd> appears, this is still
-     <em>compatible</em> with the region <code>ex1:NorthWest</code>
-     of <code>ex1:dataSet</code>
-     On the other hand, the attribute <code>prov:totalIncidents</code> have gone up to 158. 
-    </p>
-    <p>
-     From the <code>prov:wasComplementOf</code> assertion Derek knows that
-     <code>ex1:dataSet2</code> also provides additional attributes for
-     <code>ex1:dataSet</code>, but because the total incidents can't
-     both be 141 and 158, the attribute <code>ex1:totalIncidents</code>
-     is a complementing attribute, and changes over the
-     characterisation interval (lifespan) of <code>ex1:dataSet</code>,
-     and is thus not one of its characterising attributes.  He also now
-     knows that <code>ex1:dataSet</code> is a common characterisation
-     of the dataset that spans (parts of) both revisions. It has
-     however not been asserted explicitly that the
-     <code>ex1:dataSet</code> is a somewhat more general
-     characterisation, just that it allows mutability on the
-     <code>prov:totalIncidents</code> attribute and overlapped (parts
-     of) the timespans of the two revisions.
-    </p>
-    <p>
-     From this Derek concludes that he can still use the regions North,
-     North West and East in the diagram layout, but as the
-     <code>ex1:totalIncidents</code> differ, something in the
-     raw data has changed. He can't from this provenance assertion
-     alone tell if that is merely from the addition of the post code
-     NW2, or if data for the other post codes have changed as well.
-     Derek decides to redo the aggregation by region using
-     <code>ex1:dataSet2</code> and regenerate the
-     graphics using the same layout.
-    </p -->
-   </section>
-
-   <section>
-    <h3>Derivation</h3>
-
-    <p>
-     Derek creates a new chart based on the revised data, 
-     using the same compilation activity as before. Betty checks the article again at a
-     later point, and wants to know if it is based on the old or new GovData.
-     She sees three new assertions about derivation in the provenance data, plus
-     an assertion about how the new chart was generated.
-    </p>
-    <pre class="example turtle">
-     ex1:chart2 prov:dependedOn               ex1:dataSet2 .
-     ex1:chart2 prov:wasEventuallyDerivedFrom ex1:dataSet2 .
-     ex1:chart2 prov:wasDerivedFrom           ex1:dataSet2 .
-     ex1:chart2 prov:wasGeneratedBy           ex1:compiled2 .
-    </pre>
-    <p>
-     She interprets these assertions as follows. The first says that the new chart included,
-     somewhere in the history of its creation, the revised data set.
-     The second says further that the new chart is as it because of the revised
-     data set, i.e. there is an explicit influence of the data on the chart.
-     Finally, the third and fourth assertions together say further that it was
-     the activity <code>ex1:compiled2</code> that derived the new chart
-     from the revised data set.
-    </p>
-   </section>
-  </section>
-
-  <section>
-   <h2>Frequently asked questions</h2>
-  </section>
-
-  <section class="appendix">
-   <h2>Abstract Syntax Notation for Examples</h2>
-   <p>
-    Below we give translations of the working example snippets into the PROV-DM
-    abstract syntax notation (ASN).
-   </p>
-   <section>
-    <h3>Entities</h3>
-    <pre class="example asn">
-     entity(ex1:dataSet1).
-     entity(ex1:regionList1).
-     entity(ex1:aggregate1).
-     entity(ex1:chart1).
-    </pre>
-   </section>
-    
-   <section>
-    <h3>Activities</h3>
-    <pre class="example asn">
-     activity(ex1:compiled,compilation_step).
-     activity(ex1:aggregated).
-     activity(ex1:illustrated).
-    </pre>
-    <p>
-     In the first assertion above, 'compilation_step' is an optional reference to the 'recipe' that describes 
-     what the 'compiled' activity did. The interpretation of its name, 
-     'compilation_step', is left to applications (it is not further resolved within PROV-DM).
-    </p>
-    <p>
-     In the second assertion, optional 'recipe' has been omitted.
-    </p>
-    <!--PM comment: here readers will be confused by the processExecutiion / activity disconnect!
-                       also this does not show start/end times, optional attributes. At least one example would be useful-->
-   </section>
-
-   <section>
-    <h3>Use and Generation</h3>
-    <pre class="example asn">
-     used(ex1:aggregated, ex1:dataSet1).
-     used(ex1:aggregated, ex1:regionList1).
-     wasGeneratedBy(ex1:aggregate1, ex1:aggregated).
-
-     used(ex1:illustrated, ex1:aggregate1).
-     wasGeneratedBy(ex1:chart1, ex1:illustrated).
-    </pre>
-   </section>
-
-   <section>
-    <h3>Agents</h3>
-    <pre class="example asn">
-     entity(ex1:derek, [ type="foaf:Person", foaf:givenName = "Derek", 
-            foaf:mbox= "&lt;mailto:derek@example.org&gt;"]).
-     agent(ex1:derek).
-
-     wasControlledBy(ex1:aggregated, ex1:derek).
-     wasControlledBy(ex1:illustrated, ex1:derek).
-    </pre>
-   </section>
-
-   <section>
-    <h3>Roles</h3>
-    <p>
-     Roles are not declared directly in PROV-DM, rather they are attributes of 
-     relations. Thus, the entire Turtle example in sec. 3.5 is rendered as follows:
-    </p>
-    <pre class="example asn">
-     used(ex1:aggregated, ex1:dataSet1,    [ prov:role = "dataToAggregate"]).
-     used(ex1:aggregated, ex1:regionList1, [ prov:role = "regionsToAggregteBy"]).
-    </pre>
-    <p>
-     In the first assertion above, note that this adds a "role" attribute to the first 'used' assertion of Ex. 3.
-     Similarly in the second assertion, we have added a "role" attribute to the second  'used' assertion of Ex. 3.
-    </p>
-   </section>
-
-   <section>
-    <h3>Revision</h3>
-    <pre class="example asn">
-     wasRevisionOf(ex1:dataSet2, ex1:dataSet1).
-    </pre>
-   </section>
-
-   <section>
-    <h3>Complementarity</h3>
-    <pre class="example asn">
-     entity(ex1:dataSet, [ type="ex1:DataSet", ex1:regions ="(ex1:North, ex1:NorthWest, ex1:East)",
-            dc:creator="ex1:DataGov", dc:title="Regional incidence dataset 2011"  ]).
-
-     wasComplementOf(dataSet1, dataSet).
-     wasComplementOf(dataSet2, dataSet).
-
-     entity(ex1:dataSet1, [ type="ex1:DataSet", ex1:postCodes="( 'N1', 'N2', 'NW1', 'E1', 'E2' ) ", 
-            ex1:totalIncidents = "141",        dc:creator =  " ex1:DataGov", 
-            dc:title = "Regional incidence dataset 2011"  ]).
-    </pre>
-   </section>
-
-   <section>
-    <h3>Derivation</h3>
-    <pre class="example asn">
-     dependedOn(ex1:chart2, ex1:dataSet2).
-     wasEventuallyDerivedFrom(ex1:chart2, ex1:dataSet2).
-     wasDerivedFrom(ex1:chart2, ex1:dataSet2).
-     wasGeneratedBy(ex1:chart2, ex1:compiled2).
-    </pre>
-   </section>
-  </section>
-
-  <section class="appendix">
-   <h2>Acknowledgements</h2>
-   <p>
-    WG membership to be listed here.
-   </p>
-  </section>
-
- </body></html>
+<!DOCTYPE html>
+<html><head> 
+  <title>Prov Model Primer</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 class="remove">
+   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-Primer",
+ 
+    // if your specification has a subtitle that goes below the main
+    // formal title, define it here
+    subtitle   :  "Initial draft for internal discussion",
+ 
+    // if you wish the publication date to be other than today, set this
+    // publishDate:  "2009-08-06",
+ 
+    // 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:  "1977-03-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/primer/Primer.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: "Yolanda Gil", url: "http://www.isi.edu/~gil/",
+      company: "Information Sciences Institute, University of Southern California, US" },
+     { name: "Simon Miles", url: "http://www.inf.kcl.ac.uk/~simonm",
+      company: "King's College London, UK" },
+    ],
+ 
+    // 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: "TBD"},
+    ],
+          
+    // name of the WG
+    wg:           "Provenance Working Group",
+          
+    // URI of the public WG page
+    wgURI:        "http://www.w3.org/2011/prov/wiki/Main_Page",
+          
+    // 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:  "",
+   };
+  </script>
+ </head>
+ <body>
+  <section id="abstract">
+   <p>This document aims to provide an intuitive guide to the PROV Data Model,
+    with worked examples.</p>
+
+   <p>
+    This is a document for internal discussion, which will ultimately
+    evolve in the first Public Working Draft of the Primer.</p>
+  </section> 
+
+  <section> 
+   <h2>Introduction</h2>
+   <p>
+    This primer document provides an accessible introduction to the PROV Data Model
+    (PROV-DM) standard for representing provenance on the Web, and its representation
+    in the PROV Ontology (PROV-O).  Provenance describes
+    the origins of things, so PROV-DM data consists of assertions about the past.
+   </p>
+
+   <p>
+    This primer document aims to ease the adoption of the standard by providing:
+   </p>
+   <ul>
+    <li>An intuitive explanation of how PROV-DM models provenance.</li>
+    <li>Worked examples that can be followed to produce your own PROV-DM data.</li>
+    <li>Answers to frequently asked questions regarding how the model should be applied.</li>
+   </ul>
+
+   <p>
+    The <i>provenance</i> of digital objects represents their origins.  The PROV-DM is a 
+    proposed standard to represent provenance records, which contain <i>assertions</i> about the entities 
+    and activities involved in producing and delivering or otherwise influencing a 
+    given object.  By knowing the provenance of an object, we can make determinations 
+    about how to use it.  Provenance records can be used for many purposes, such as 
+    understanding how data was collected so it can be meaningfully used, determining 
+    ownership and rights over an object, making judgments about information to 
+    determine whether to trust it, verifying that the process and steps used to obtain a 
+    result complies with given requirements, and reproducing how something it was generated.
+   </p>
+
+   <p>
+    As a standard for provenance, PROV-DM accommodates all those different uses 
+    of provenance.  Different people may have different perspectives on provenance, 
+    and as a result different types of information might be captured in provenance records.  
+    One perspective might focus on <i>agent-centered provenance</i>, that is, what entities 
+    were involved in generating or manipulating the information in question.  For example, 
+    in the provenance of a picture in a news article we might capture the photographer who 
+    took it, the person that edited it, and the newspaper that published it. A second perspective 
+    might focus on <i>object-centered provenance</i>, by tracing the origins of portions of a 
+    document to other documents. An example is having a web page that was assembled from content
+    from a news article, quotes of interviews with experts, and a chart that plots data from a 
+    government agency.  A third perspective one might take is on <i>process-centered provenance</i>, 
+    capturing the actions and steps taken to generate the information in question.  For example, a 
+    chart may have been generated by invoking a service to retrieve data from a database, then 
+    extracting certain statistics from the data using some statistics package, and finally 
+    processing these results with a graphing tool.
+   </p>
+
+   <p>
+    Provenance records are metadata.  There are other kinds of metadata that is 
+    not provenance.  For example, the size of an image is a metadata property of 
+    that image but it is not provenance.
+   </p>
+
+   <p>
+    For general background on provenance, a 
+    comprehensive overview of requirements, use cases, prior research, and proposed 
+    vocabularies for provenance are available from the 
+    <a href="http://www.w3.org/2005/Incubator/prov/XGR-prov/">Final Report of the W3C Provenance Incubator Group</a>.  
+    That document contains three general scenarios 
+    that may help identify the provenance aspects of your planned applications and 
+    help plan the design of your provenance system.
+   </p>
+   <p>
+    The next section gives an introductory overview of PROV-DM using simple examples.
+    The following section shows how the formal ontology PROV-O can be used to represent the PROV-DM assertions
+    as RDF triples.  The document also contains frequently asked questions, and an appendix giving example 
+    snippets of the PROV-DM Abstract Syntax Notation (ASN).
+    For a detailed description of PROV-DM, please refer to the 
+    <a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html">PROV Data Model and Abstract Syntax Notation document</a>.
+    For a detailed description of PROV-O, refer to the 
+    <a href="http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html">PROV Ontology Model and Formal Semantics document</a>.
+   </p>
+  </section>
+
+  <section>
+   <h2>Intuitive overview of PROV-DM</h2>
+
+   <p><i>This section provides an intuitive explanation of the concepts in PROV-DM. 
+     As with the rest of this document, it should be treated as a starting point for
+     understanding the model, and not normative in itself. The PROV-DM model specification
+     provides precise definitions and constraints to be used.</i></p>
+
+<p>
+The following ER diagram provides a high level overview of the <strong>structure of PROV-DM records</strong>.
+The diagram is the same that appears in the 
+<a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html">PROV Data Model and Abstract Syntax Notation document</a>,
+but note that this primer document only describes some of the terms shown in the diagram.
+</p>
+
+<div style="text-align: center;">
+  <img src="overview.png" alt="PROV-DM overview"/>
+</div>
+
+   <section>
+    <h3>Entities</h3>
+
+    <p>
+     In PROV-DM, the things that one may ask the provenance of are called <i>entities</i>.
+     Examples of such entities are a web page, a chart, and a spellchecker.
+    </p>
+    <p>
+     An entity’s provenance may refer to many other entities.  For example, a document D is
+     an entity whose provenance refers to other entities such as a chart inserted into D,
+     the dataset that was used to create that chart, or the author of the document.
+    </p>
+    <p>
+     Entities may be described from different perspectives that may be more or less specific.  For example,
+     document D as stored in my file system, the second version of document D after someone edited it, 
+     and D as an evolving document,
+     are three distinct entities for which we may describe the provenance. They
+     may all be perspectives on the same thing in the world (document D may exist only
+     in its second version and on my file system), but are <i>characterized</i> in
+     different ways by being described using different <i>attributes</i> (version, location, and 
+     so on).
+    </p>
+    <p>
+      The characterization of an entity means that the provenance assertions
+      about the entity are only about the thing when it has those attributes.
+      For example, the second version of document D is characterized by being the
+      second version, and so assertions about who reviewed that entity apply only
+      to the document as it is in its second version. When the document becomes
+      the third version, a new entity exists (the third version of D) and the
+      provenance assertions about who reviewed the second version do not apply.
+    </p>
+   </section>
+
+   <section>
+    <h3>Activities</h3>
+
+    <p>
+     Activities are how entities come into 
+     existence and how their attributes change to become new entities, 
+     often making use of previously existing entities to achieve this. 
+     For example, if the second version of document D was generated 
+     by a translation from the first version of the document in another language,
+     then this translation is an activity.
+     An activity may have either already occurred or be still 
+     taking place when a new entity is generated. 
+     While entities are static aspects in the world (things), <i>activities</i> are
+     dynamic aspects (actions, processes, etc.)
+    </p>
+   </section>
+
+   <section>
+    <h3>Use and Generation</h3>
+
+    <p>
+     Activities <i>generate</i> new entities.
+     For example, writing a document brings the document into existence, while
+     revising the document brings a new version into existence.
+    </p>
+    <p>
+     Activities also make <i>use</i> of entities. For example, revising a document
+     to fix spelling mistakes uses the original version of the document as well
+     as a list of corrections. 
+    </p>
+    <p>
+     Assertions can be made in a provenance record to state that 
+     particular activities used or generated particular entities.
+    </p>
+   </section>
+
+   <section>
+    <h3>Agents</h3>
+
+    <p>
+     An agent is a type of entity that takes an active role in an activity such 
+     that it can be assigned some degree of responsibility for the activity taking 
+     place. An agent can be a person, a piece of software, or an inanimate object.
+     Several agents can be associated with an activity.
+     Consider a chart displaying some statistics 
+     regarding crime rates over time in a linear regression.  To represent the 
+     provenance of a that chart, we could state that the person who created the 
+     chart was an agent involved in its creation, and that the software used to 
+     create the chart was also an agent involved in that activity.  
+    </p>
+    <p>
+     Since agents are a kind of entity, it is therefore possible to 
+     associate provenance records with the agents themselves.  
+     In the running example, we 
+     can also represent the provenance of the software used to create the chart, and specify the agents involved in 
+     producing that software, such as the vendor.
+    </p>     
+   </section>
+
+   <!--section>
+    <h3>Accounts</h3>
+  
+    <p>An intuitive overview of how to think about accounts in PROV-DM.</p>
+   </section -->
+
+   <section>
+    <h3>Roles</h3>
+
+    <p>
+     A <i>role</i> is a description of the function or the part that an entity 
+     played in an activity.  Roles specify
+     the relationship between an entity and an activity, whether
+     how an activity used an entity or generated an entity.  Roles also specify how agents are
+     involved in an activity, qualifying their participation in the activity or
+     specifying what agents controlled it. 
+     For example, an agent may play the role of "editor" in an activity that uses
+     one entity in the role of "document to be edited" and another in the role of "document
+     editor", to generate a further entity in the role of "edited document".
+     Roles are application specific.
+    </p>
+    <!--p>Roles are intended as an extension point in the model; it is expected users will define and use custom role taxonomies.  Role interpretation is application specific.</p -->
+   </section>
+
+   <section>
+    <h3>Revisions and Derivation</h3>
+
+    <p>
+     A given entity, such as a document, may go through multiple <i>revisions</i> 
+     (also called versions and other comparable terms) over time. Between revisions,
+     one or more attributes of the entity may change. 
+     The result of each revision is a new entity, 
+     and PROV-DM allows one to relate those entities by making an assertion that 
+     one is a revision of another.
+    </p>
+    <p>
+     When one entity's existence, content, characteristics and so on are
+     at least partly due to another entity, then we say that the former is
+     <i>derived</i> from the latter. For example, one document may contain
+     material copied from another, 
+     and a chart is derived from the data that is used to create it.
+    </p>
+   <!-- p>
+    <p>
+     There are different kinds of derivation expressible in PROV-DM.
+     Consider the case of the page in the browser above. It is derived from
+     the designer's sketch in the strictest sense, i.e. if the sketch had
+     been different so would the page. On the other hand, there are
+     entities that are part of the page's history but which did not inform
+     the content of that page, i.e. the page would have been the same even
+     if the earlier entity changed. For example, on creating the original
+     draft of the page, the designer may have included a banner image
+     saying "DRAFT - FOR REVIEW ONLY". This banner was not part of the
+     sketch, nor part of the published page downloaded to the browser, but
+     was part of the page's history, and while not affecting the browsed
+     page's content may have been a factor in its existence. Finally, in
+     some cases, we may be able to say not only that one entity was derived
+     from another, but also how it was derived, i.e. by what activity.
+     For example, the page in the browser is derived from the
+     page on the web server because a download activity sent the bytes of
+     the latter across an HTTP connection to the browser client.
+    </p>
+   </p -->
+    <p>
+     There are different kinds of derivation expressible in PROV-DM.  For 
+     example, the data may be normalized before creating the chart.  
+     In PROV-DM terms, we say that the chart <i>was eventually
+      derived from</i> the original data, <i>depended on</i> the settings 
+      of the graphing software, and <i>was derived
+      from</i> the normalized data.
+    </p>
+   </section>
+
+    <!-- p>
+   <section>
+    <h3>Complementarity</h3>
+    <p>
+     As described above, entities can be described from different perspectives,
+     by being characterized by different attributes. For example, "document D",
+     "the second version of document D" and "document D as stored on my filesystem"
+     are different entities
+     because they are characterized in different ways. However, for some period of time
+     they may all refer to the same thing in the world, e.g. for a while the copy of 
+     D on my filesystem <i>was</i> the second version.
+    </p>
+    <p>
+     In PROV-DM, we say there is <i>complementarity</i> between one entity and another
+     if, in some period of time, they have the same or compatible characterization.
+     So, both "the second version of document D" and "document D as stored on my filesystem"
+     are complements of "document D", because they are both characterized by being
+     document D, but with specific additional attributes.
+     If, at some point in time, a version of D stored on my filesystem is the second one, then
+     "document D as stored on my filesystem" and "the second version of document D" are
+     complements of each other.
+    </p>
+     Several asserted entities could be characterizing the same thing, in
+     particular when entities are asserted by different <em>accounts</em> or over
+     different time periods. If two such entities have <em>overlapping
+      lifespans</em>, and the first entity have some <em>attributes</em> that
+     have not been asserted (and not necessarily always true) for the second entity,
+     then the first entity is said to be <em>complementing</em> the second
+     entity, that is the first entity helps form a more detailed
+     description of the second entity, at least for the duration of the
+     overlapping lifespan.  
+    </p> 
+    <p> 
+     In addition, if <code>:A prov:wasComplementOf :B</code>, then of all the
+     attributes of the entity <code>:A</code> which can be <em>mapped</em> to
+     <em>compatible</em> attributes of <code>:B</code> MUST be <em>matching</em>
+     for the continuous duration of the overlap of <code>:A</code> and
+     <code>:B</code>'s lifespans.
+     It is out of scope for PROV to specify or assert the nature of
+     the <em>compatibility mapping</em> and <em>matching</em>, the exact
+     interpretation of these is left to the asserter of
+     <code>wasComplementOf</code>
+    </p>
+    <p>
+     If <code>:B</code> also have some attributes which 
+     are not asserted (or not always true) about <code>:A</code>,
+     then this MAY be asserted using the 
+     inverse relation <code>:B prov:wasComplementOf :A</code>. If two entities
+     both complement each other in this manner, both MUST have some
+     attributes the other does not have, although those attributes MAY
+     not have been asserted in the provenance. Note that the
+     <em>lack</em> of such an inverse assertion does not neccessarily
+     mean that <code>:B</code> did not have any additional attributes
+     for <code>:A</code> in the timespan, only that this has not
+     been asserted.
+    </p>
+    <p>
+     In the simplest case, both entites are described using the same
+     attributes, in which case <em>matching</em> means the values SHOULD
+     literally be the same (matching by identity). On the other hand an
+     attribute like <code>ex1:speed_in_mph</code> can be <em>mapped</em> to
+     a compatible <code>ex2:speed_in_kmh</code> attribute. Not all
+     attributes might be mappable in both directions, for instance
+     <code>ex1:city</code> to <code>ex2:country</code>, but not vice
+     versa.
+    </p>
+    <p>
+     Note that it is out of scope for PROV to assert or explain any
+     mapping of compatible attributes. This is merely a conclusion 
+     that can be drawn from the assertion that the two entities both
+     described the same thing in the overlapping time spans.  Also note
+     that asserting a complementary relationship does not detail how the
+     two entity timespans overlap, this could be anything from
+     complete one-to-one match (where all attributes are always true for
+     both entities) to merely touching overlaps. 
+   </section>
+    </p -->
+
+
+  </section>
+
+  <section>
+   <h2>Examples of Use of the PROV-O Ontology</h2>
+
+   <p>In the following sections, we show how PROV-DM can be used to model 
+    provenance in specific examples.</p>
+
+   <p>We include examples of how the formal ontology PROV-O 
+    can be used to represent the PROV-DM assertions as RDF triples.
+    These are shown using the Turtle notation. In 
+    the latter depictions, the namespace prefix <b>prov</b> denotes 
+    terms from the Prov ontology, while <b>ex1</b>, <b>ex2</b>, etc. 
+    denote terms specific to the example.</p>
+
+   <p>We also provide a representation of the examples in the Abstract
+    Syntax Model ASM used in the conceptual model document. The full ASM data 
+    for the examples in this section is
+    included in the appendix.</p>
+
+   <section>
+    <h3>Entities</h3>
+
+    <p>
+     An online newspaper publishes an article with a chart about crime statistics making using of data (GovData) provided through a government portal. 
+     The article includes a chart based on the data, with data values aggregated by
+     geographical regions.
+    </p>
+    <p>
+     A blogger, Betty, looking at the article, spots what she thinks to be an error in the chart.
+     Betty retrieves the provenance record of the article, how it was created.
+    </p>
+    <p>Betty would find the following assertions about entities in the provenance record:</p>
+    <pre class="turtle example">
+     ex1:newspaper1    a prov:Entity .
+     ex1:article1    a prov:Entity .
+     ex1:regionList1 a prov:Entity .
+     ex1:aggregate1  a prov:Entity .
+     ex1:chart1      a prov:Entity .
+    </pre>
+    <p>
+     These statements, in order, assert that there is a newspaper (<code>ex1:newspaper1</code>) and an article (<code>ex1:article1</code>),
+     that the original data set is an entity (<code>ex1:dataSet1</code>),
+     there is a list of regions
+     (<code>ex1:regionList1</code>) that is an entity, that the data aggregated by region is an entity (<code>ex1:aggregate1</code>), 
+     and that the chart (<code>ex1:chart1</code>) is an entity.
+    </p>
+
+   </section>
+
+   <section>
+    <h3>Activities</h3>
+
+    <p>
+     Further, the provenance record asserts that there was
+     an activity (<code>ex1:compiled</code>) denoting the compilation of the
+     chart from the data set.
+    </p>
+    <pre class="turtle example">
+     ex1:compiled a prov:Activity .
+    </pre>
+    <p>
+     The provenance record also includes reference to the more specific steps involved in this compilation,
+     which are first aggregating the data by region and then generating the chart graphic.
+    </p>
+    <pre class="turtle example">
+     ex1:aggregated  a prov:Activity .
+     ex1:plotted a prov:Activity .
+    </pre>
+   </section>
+
+   <section>
+    <h3>Use and Generation</h3>
+
+    <p>
+     Finally, the provenance record asserts the key relations among the above
+     entities and activities, i.e. the use of an entity by an activity,
+     or the generation of an entity by an activity.
+    </p>
+    <p>
+     For example, the assertions below state that the aggregation activity
+     (<code>ex1:aggregated</code>) used the original data set, that it used the list of
+     regions, and that the aggregated data was generated by this activity.
+    </p>
+    <pre class="turtle example">
+     ex1:aggregated prov:used           ex1:dataSet1 ;
+                    prov:used           ex1:regionList1 .
+     ex1:aggregate1 prov:wasGeneratedBy ex1:aggregated .
+    </pre>
+    <p>
+     Similarly, the chart graphic creation activity (<code>ex1:illustrated</code>)
+     used the aggregated data, and the chart was generated by this activity.
+    </p>
+    <pre class="turtle example">
+     ex1:illustrated prov:used           ex1:aggregate1 .
+     ex1:chart1      prov:wasGeneratedBy ex1:illustrated .
+    </pre>
+
+    <!--p>
+     For example, the provenance declares the event (of type <code>prov:Usage</code>)
+     where the aggregation activity used the GovData data set, and the event
+     (of type <code>prov:Generation</code>) where the same activity generated
+     the data aggregated by region.
+    </p>
+    <pre class="turtle example">
+     ex1:dataSet1Usage        a prov:Usage .
+     ex1:aggregate1Generation a prov:Generation .
+    </pre>
+    <p>
+     To describe these events, the provenance says within which activity
+     they occur and what entity is used or generated.
+    </p>
+    <pre class="turtle example">
+     ex1:aggregated prov:qualifiedUsage      ex1:dataSet1Usage .
+     ex1:aggregated prov:qualifiedGeneration ex1:aggregate1Generation .
+     ex1:dataSet1Usage        prov:entity ex1:dataSet1 .
+     ex1:aggregate1Generation prov:entity ex1:aggregate1 .
+    </pre>
+    <p>
+     Comparable events are described for the activity of generating the chart image
+     from the aggregated data.
+    </p>
+    <pre class="turtle example">
+     ex1:aggregate1Usage  a prov:Usage .
+     ex1:chart1Generation a prov:Generation .
+     ex1:illustrated prov:qualifiedUsage      ex1:aggregate1Usage .
+     ex1:illustrated prov:qualifiedGeneration ex1:chart1Generation .
+     ex1:aggregate1Usage  prov:entity ex1:aggregate1 .
+     ex1:chart1Generation prov:entity ex1:chart1 .
+    </pre>
+    <p>
+     From this information Betty can see that
+     the mistake could have been in the original data set or else was introduced
+     in the compilation activity, and sets out to discover which.
+    </p>
+    </p -->
+
+   </section>
+
+   <section>
+    <h3>Agents</h3>
+
+    <p>
+     Digging deeper, Betty wants to know who compiled the chart.
+     Betty sees that Derek was involved in both the aggregation and
+     chart creation activities:
+    </p>
+    <pre class="turtle example">
+     ex1:aggregated  prov:wasAssociatedWith ex1:derek .
+     ex1:illustrated prov:wasAssociatedWith ex1:derek .
+    </pre>
+    <p>
+     The record for Derek provides the
+     following information, of which the first line is a PROV-O statement that
+     Derek is an agent, followed by statements about general properties of Derek.
+    </p>
+    <pre class="turtle example">
+     ex1:derek a prov:Agent ;
+               a foaf:Person ;
+               foaf:givenName "Derek"^^xsd:string ;
+               foaf:mbox      &lt;mailto:dererk@example.org&gt; .
+    </pre>
+   </section>
+
+   <!-- section>
+    <h3>Accounts</h3>
+  
+    <p><i>Suggested example:</i> The analyst provides his own record of how he compiled GovData to create 
+     the chart, which provides more detail than in the newspaper's provenance data. 
+     Specifically, the analysts account separates compilation into two stages: aggregating 
+     data by region and then producing the chart. Therefore, there are two separate 
+     accounts of the same events.</p>
+   </section -->
+
+   <section>
+    <h3>Roles</h3>
+
+    <p>
+     For Betty to understand where the error lies, she needs to have more detailed 
+     information on how entities have been used in, participated in, and generated 
+     by activities.  Betty has determined that <code>ex1:aggregated</code> used 
+     entities <code>ex1:regionList1</code> and <code>ex1:dataSet1</code>, but she does not 
+     know what function these entities played in the processing.  Betty 
+     also knows that <code>ex1:derek</code> controlled the activities, but she does 
+     not know if Derek was the analyst responsible for determining how the data 
+     should be aggregated.
+    </p>
+    <p>
+     The above information is described as roles in the provenance records. The aggregation
+     activity involved entities in four roles: the data to be aggregated (<code>ex1:dataToAggregate</code>),
+     the regions to aggregate by (<code>ex1:regionsToAggregateBy</code>), the
+     resulting aggregated data (<code>ex1:aggregatedData</code>), and the
+     analyst doing the aggregation (<code>ex1:analyst</code>).
+    </p>
+    <pre class="turtle example">
+     ex1:dataToAggregate      a prov:Role .
+     ex1:regionsToAggregateBy a prov:Role .
+     ex1:aggregatedData       a prov:Role .
+     ex1:analyst              a prov:Role .
+    </pre>
+    <p>
+     In addition to the simple facts that the aggregation activity used, generated or
+     was controlled by entities/agents as described in the sections above, the
+     provenance record contains more details of <i>how</i> these entities and agents
+     were involved, i.e. the roles they played. For example, the assertions below state
+     that the aggregation activity (<code>ex1:aggregated</code>) included the usage
+     of the government data set (<code>ex1:dataSet1</code>) in the role of the data
+     to be aggregated (<code>ex1:dataToAggregate</code>).
+    </p>
+    <pre class="turtle example">
+     ex1:aggregated prov:hadQualifiedUsage [ a prov:Usage ;
+            prov:hadQualifiedEntity ex1:dataSet1 ;
+            prov:hadRole            ex1:dataToAggregate ] .
+    </pre>
+    <p>
+     This can then be distinguished from the same activity's usage of the list of
+     regions because the roles played are different.
+    </p>
+    <pre class="turtle example">
+     ex1:aggregated prov:hadQualifiedUsage [ a prov:Usage ;
+            prov:hadQualifiedEntity ex1:regionList1 ;
+            prov:hadRole            ex1:regionsToAggregateBy ] .
+    </pre>
+    <p>
+     Similarly, the provenance includes assertions that the same activity was
+     controlled in a particular way (<code>ex1:analyst</code>) by Derek, and that
+     the entity <code>ex1:aggregate1</code> took the role of the aggregated
+     data in what the activity generated.
+    </p>
+    <pre class="turtle example">
+     ex1:aggregated
+        prov:hadQualifiedControl [ a prov:Control ;
+            prov:hadQualifiedEntity ex1:derek ;
+            prov:hadRole            ex1:analyst
+        ] ;
+        prov:hadQualifiedGeneration [ a prov:Generation ;
+            prov:hadQualifiedEntity ex1:aggregate1 ;
+            prov:hadRole            ex1:aggregatedData
+        ] .
+    </pre>
+   </section>
+
+   <section>
+    <h3>Revision</h3>
+
+    <p>
+     After looking at the detail of the compilation activity, there appears
+     to be nothing wrong, so Betty concludes the error is in the government dataset. 
+     She looks at the characterization of the dataset <code>ex1:dataSet1</code>, 
+     and sees that it is missing data from one of the zipcodes in the area.  She contacts
+     the government, and a new version of GovData is created, declared to be the
+     next revision of the data by Edith. The provenance record of this new dataset,
+     <code>ex1:dataSet2</code>, states that it is a revision of the
+     old data set, <code>ex1:dataSet1</code>.
+    </p>
+    <pre class="turtle example">
+     ex1:dataSet2 prov:wasRevisionOf ex1:dataSet1 .
+    </pre>
+   </section>
+
+   <!-- section>
+    <h3>Complementarity</h3>
+
+    <p>Betty lets Derek know that a new revision of the data set exists,
+     and he looks at the provenance of the new data to understand what he needs to
+     re-analyze. </p>
+    <p>In addition to specifying that 
+     <code>ex1:dataSet2</code> is a new revision of
+     <code>ex1:dataSet1</code>, the provenance from DataGov also 
+     asserts that both of these entities were a <em>complement of</em>
+     another entity <code>ex1:dataSet</code>.
+    </p>
+    <pre class="turtle example">
+     ex1:dataSet1 prov:wasComplementOf ex1:dataSet .
+     ex1:dataSet2 prov:wasComplementOf ex1:dataSet .
+    </pre>
+    <!--
+    <pre class="asn example">
+    wasComplementOf(ex1:dataSet1, ex1:dataSet)
+    wasComplementOf(ex1:dataSet2, ex1:dataSet)
+    </pre>
+    -->
+    <p>
+     This assertion means that <code>ex1:dataSet1</code> at some point shared
+     its characterizing attributes with <code>ex1:dataSet</code>, and the same for
+     <code>ex2:dataSet2</code>. Thus the <em>entity</em>
+     <code>ex1:dataSet1</code> did at some point represent the same
+     thing as characterized by the entity <code>ex1:dataSet</code>. The same is
+     true for <code>ex1:dataSet2</code>, though not necessarily at the
+     same point in time. 
+    </p>
+    <!-- p>
+     The term <em>was complement of</em> here means that the
+     <code>ex1:dataSet1</code>
+     provide additional details that adds to the details of
+     <code>ex1:dataSet</code> (complementing it), and that both of these
+     entities represented the same thing.
+     Characterizing attributes of <code>ex1:dataSet</code> are from this
+     asserted to have been <em>compatible</em> with the properties of
+     <code>ex1:dataSet1</code> and <code>ex1:dataSet2</code>.
+     <em>Compatible</em> here means that some kind of mapping can be
+     established between the attributes, they don't neccessarily have to
+     match directly.
+    </p -->
+    <p>
+     Derek then looks at the characterization of the generalized data set
+     (<code>ex1:dataSet</code>) to find the attributes shared with the first 
+     and second versions of the data set. The assertions below give the generalized
+     data set's attributes: it is of type <code>ex1:DataSet</code>, it covers
+     three named regions, it was created by <code>ex1:DataGov</code>, and
+     has a given title.
+    </p>
+    <pre class="example turtle">
+     ex1:dataSet a ex1:DataSet ;
+           ex1:regions ( ex1:North, ex1:NorthWest, ex1:East ) ;
+           dc:creator  ex1:DataGov ;
+           dc:title    "Regional incidence dataset 2011" .
+    </pre>
+    <p>
+     As <code>ex1:dataSet1</code> and <code>ex1:dataSet2</code> complement
+     <code>ex1:dataSet</code>,
+     Derek can deduce from the above attributes that both the former had
+     these same attributes at some point, i.e.      
+     the creator <code>ex1:DataGov</code> and so on.  Derek compares the above
+     assertions to the
+     attributes of <code>ex1:dataSet1</code>.
+    </p>
+    <pre class="example turtle">
+     ex1:dataSet1 a ex1:DataSet ;
+           ex1:postCodes      ( "N1", "N2", "NW1", "E1", "E2" ) ;
+           ex1:totalIncidents 141 ;
+           dc:creator         ex1:DataGov ;
+           dc:title           "Regional incidence dataset 2011" .
+    </pre>
+    <p>
+     Shared characterizing attributes are not necessarily represented in
+     the serialized assertions of different entities. For example, the creator
+     and title are exactly the same for <code>ex1:dataSet</code> and <code>ex1:dataSet1</code>,
+     but the regions covered by the data set are described in a different way:
+     "regions" for <code>ex1:dataSet</code> and "postCodes" for <code>ex1:dataSet1</code>.
+     Whether these are equivalent is a domain-specific judgment.
+     We can also see that, while <code>ex1:dataSet1</code> complements <code>ex1:dataSet</code>,
+     the inverse is not true. <code>ex1:dataSet1</code> is more specific, because
+     it has a "totalIncidents" attribute specific to that version of the data set.
+    </p>
+    <!-- p>     
+     Derek sees that the creator and title are directly mappable and 
+     equal between these entities. He also knows (from his region
+     aggregation method) that the <code>ex1:postCodes</code> <code>N1</code> and
+     <code>N2</code> are in the
+     region <code>ex1:North</code>, and so on, and can confirm that although
+     this regional characterisation of the data is not expressed
+     using the same attributes in the two entities, they are <em>compatible</em>. 
+    </p>
+    <p>Derek notes that <code>ex1:totalIncidents</code> is not stated
+     for <code>ex1:dataSet</code>, and not mappable to any of the
+     other existing attributes. Thus this could be one of the
+     complementing attributes that makes <code>ex1:dataSet1</code>
+     more specific than <code>ex1:dataSet</code>.
+
+     Derek can from the assertion <code>ex1:dataSet1
+      prov:wasComplementOf ex1:dataSet</code>
+     see that <code>ex1:dataSet</code>
+     did have 141 incidents when its characterization interval
+     overlapped that of <code>ex1:dataSet1</code>, but not neccessarily
+     throughout its lifetime. Note that in this example the provenance
+     assertions are not providing any direct description of the
+     characterization interval of the entities.
+    </p>
+    <p> 
+     Due to the open world assumption (more
+     information might be added later) he can not conclude
+     from this alone that <code>ex1:dataSet</code> at any point did
+     <strong>not</strong> have 141 incidents. He therefore does not know
+     for sure that <code>ex1:totalIncidents</code> is a complementing
+     attribute which <code>ex1:dataSet</code> does not have in its
+     characterisation.
+    </p>
+    <p>
+     Derek finally compares the newer revision 
+     <code>ex1:dataSet2</code> with
+     <code>ex1:dataSet</code>:
+    </p>
+    <pre class="example turtle">
+     ex1:dataSet2 a ex1:DataSet ;
+         ex1:postCodes ( "N1", "N2", "NW1", "NW2", "E1", "E2" ) ;
+         ex1:totalIncidents 158 ;
+         dc:creator ex1:DataGov ;
+         dc:title "Regional incidence dataset 2011" .
+    </pre>
+    <p>
+     In this revision, the new postcode <kbd>NW2</kbd> appears, this is still
+     <em>compatible</em> with the region <code>ex1:NorthWest</code>
+     of <code>ex1:dataSet</code>
+     On the other hand, the attribute <code>prov:totalIncidents</code> have gone up to 158. 
+    </p>
+    <p>
+     From the <code>prov:wasComplementOf</code> assertion Derek knows that
+     <code>ex1:dataSet2</code> also provides additional attributes for
+     <code>ex1:dataSet</code>, but because the total incidents can't
+     both be 141 and 158, the attribute <code>ex1:totalIncidents</code>
+     is a complementing attribute, and changes over the
+     characterisation interval (lifespan) of <code>ex1:dataSet</code>,
+     and is thus not one of its characterising attributes.  He also now
+     knows that <code>ex1:dataSet</code> is a common characterisation
+     of the dataset that spans (parts of) both revisions. It has
+     however not been asserted explicitly that the
+     <code>ex1:dataSet</code> is a somewhat more general
+     characterisation, just that it allows mutability on the
+     <code>prov:totalIncidents</code> attribute and overlapped (parts
+     of) the timespans of the two revisions.
+    </p>
+    <p>
+     From this Derek concludes that he can still use the regions North,
+     North West and East in the diagram layout, but as the
+     <code>ex1:totalIncidents</code> differ, something in the
+     raw data has changed. He can't from this provenance assertion
+     alone tell if that is merely from the addition of the post code
+     NW2, or if data for the other post codes have changed as well.
+     Derek decides to redo the aggregation by region using
+     <code>ex1:dataSet2</code> and regenerate the
+     chart using the same layout.
+    </p -->
+   </section -->
+
+   <section>
+    <h3>Derivation</h3>
+
+    <p>
+     Derek notices that there is a new dataset available and creates a new chart based on the revised data, 
+     using the same compilation activity as before. Betty checks the article again at a
+     later point, and wants to know if it is based on the old or new GovData.
+     She sees three new assertions about derivation in the provenance data, plus
+     an assertion about how the new chart was generated.
+    </p>
+    <pre class="example turtle">
+     ex1:chart2 prov:dependedOn               ex1:dataSet2 .
+     ex1:chart2 prov:wasEventuallyDerivedFrom ex1:dataSet2 .
+     ex1:chart2 prov:wasDerivedFrom           ex1:dataSet2 .
+     ex1:chart2 prov:wasGeneratedBy           ex1:compiled2 .
+    </pre>
+    <p>
+     She interprets these assertions as follows. The first says that the new chart included,
+     somewhere in the history of its creation, the revised data set.
+     The second says further that the new chart is as it because of the revised
+     data set, i.e. there is an explicit influence of the data on the chart.
+     Finally, the third and fourth assertions together say further that it was
+     the activity <code>ex1:compiled2</code> that derived the new chart
+     from the revised data set.
+    </p>
+   </section>
+  </section>
+
+  <section>
+   <h2>Frequently asked questions</h2>
+  </section>
+
+  <section class="appendix">
+   <h2>Abstract Syntax Notation for Examples</h2>
+   <p>
+    Below we give translations of the working example snippets into the PROV-DM
+    abstract syntax notation (ASN).
+   </p>
+   <section>
+    <h3>Entities</h3>
+    <pre class="example asn">
+     entity(ex1:dataSet1).
+     entity(ex1:regionList1).
+     entity(ex1:aggregate1).
+     entity(ex1:chart1).
+    </pre>
+   </section>
+    
+   <section>
+    <h3>Activities</h3>
+    <pre class="example asn">
+     activity(ex1:compiled).
+     activity(ex1:aggregated).
+     activity(ex1:illustrated).
+    </pre>
+    <!--
+    <p>
+     In the first assertion above, 'compilation_step' is an optional reference to the 'recipe' that describes 
+     what the 'compiled' activity did. The interpretation of its name, 
+     'compilation_step', is left to applications (it is not further resolved within PROV-DM).
+    </p>
+    <p>
+     In the second assertion, optional 'recipe' has been omitted.
+    </p>
+    -->
+    <!--PM comment: here readers will be confused by the processExecutiion / activity disconnect!
+                       also this does not show start/end times, optional attributes. At least one example would be useful-->
+   </section>
+
+   <section>
+    <h3>Use and Generation</h3>
+    <pre class="example asn">
+     used(ex1:aggregated, ex1:dataSet1).
+     used(ex1:aggregated, ex1:regionList1).
+     wasGeneratedBy(ex1:aggregate1, ex1:aggregated).
+
+     used(ex1:illustrated, ex1:aggregate1).
+     wasGeneratedBy(ex1:chart1, ex1:illustrated).
+    </pre>
+   </section>
+
+   <section>
+    <h3>Agents</h3>
+    <pre class="example asn">
+     entity(ex1:derek, [ type="foaf:Person", foaf:givenName = "Derek", 
+            foaf:mbox= "&lt;mailto:derek@example.org&gt;"]).
+     agent(ex1:derek).
+
+     wasControlledBy(ex1:aggregated, ex1:derek).
+     wasControlledBy(ex1:illustrated, ex1:derek).
+    </pre>
+   </section>
+
+   <section>
+    <h3>Roles</h3>
+    <p>
+     Roles are not declared directly in PROV-DM, rather they are attributes of 
+     relations. Thus, the entire Turtle example in sec. 3.5 is rendered as follows:
+    </p>
+    <pre class="example asn">
+     used(ex1:aggregated, ex1:dataSet1,    [ prov:role = "dataToAggregate"]).
+     used(ex1:aggregated, ex1:regionList1, [ prov:role = "regionsToAggregteBy"]).
+    </pre>
+    <p>
+     In the first assertion above, note that this adds a "role" attribute to the first 'used' assertion of Ex. 3.
+     Similarly in the second assertion, we have added a "role" attribute to the second  'used' assertion of Ex. 3.
+    </p>
+   </section>
+
+   <section>
+    <h3>Revision</h3>
+    <pre class="example asn">
+     wasRevisionOf(ex1:dataSet2, ex1:dataSet1).
+    </pre>
+   </section>
+
+    <!--
+   <section>
+    <h3>Complementarity</h3>
+    <pre class="example asn">
+     entity(ex1:dataSet, [ type="ex1:DataSet", ex1:regions ="(ex1:North, ex1:NorthWest, ex1:East)",
+            dc:creator="ex1:DataGov", dc:title="Regional incidence dataset 2011"  ]).
+
+     wasComplementOf(dataSet1, dataSet).
+     wasComplementOf(dataSet2, dataSet).
+
+     entity(ex1:dataSet1, [ type="ex1:DataSet", ex1:postCodes="( 'N1', 'N2', 'NW1', 'E1', 'E2' ) ", 
+            ex1:totalIncidents = "141",        dc:creator =  " ex1:DataGov", 
+            dc:title = "Regional incidence dataset 2011"  ]).
+    </pre>
+   </section>
+   -->
+
+   <section>
+    <h3>Derivation</h3>
+    <pre class="example asn">
+     dependedOn(ex1:chart2, ex1:dataSet2).
+     wasEventuallyDerivedFrom(ex1:chart2, ex1:dataSet2).
+     wasDerivedFrom(ex1:chart2, ex1:dataSet2).
+     wasGeneratedBy(ex1:chart2, ex1:compiled2).
+    </pre>
+   </section>
+  </section>
+
+  <section class="appendix">
+   <h2>Acknowledgements</h2>
+   <p>
+    WG membership to be listed here.
+   </p>
+  </section>
+
+ </body></html>