--- a/model/comments/issue-331-curt.txt Thu Apr 12 12:19:12 2012 +0100
+++ b/model/comments/issue-331-curt.txt Thu Apr 12 14:48:38 2012 +0100
@@ -6,7 +6,7 @@
> optional arguments where the argument mapping is unambiguous,
> particularly at the beginning or end of the argument list.
-TODO. Need to check. and explain the convention.
+TODO. Need to check and better explain the convention.
>
>
@@ -26,11 +26,15 @@
> or should we be using them the same way in the various examples?
>
-I thought I had fixed them all. Obviously not. TODO.
+All of them are now:
-It would be nice to have a notation in ASN for qualified names, e.g:
+ > [prov:type="prov:Collection" %% xsd:QName]
-[prov:type = <prov:Collection>]
+
+It would be nice to have a notation in prov-n for qualified names, e.g:
+[prov:type = 'prov:Collection']
+
+This will be considered for the next iteration.
>
@@ -48,6 +52,7 @@
>
I think it's important to say people and not agent.
+For us, agent is just something that bears some form of responsibility ...
>
> "actities"
@@ -71,7 +76,8 @@
>
>
-ok
+ok, updated as follows:
+"Second, a separate document describes a provenance notation for expressing instances of provenance for human consumption; this notation is used in examples in this document."
> Status of This Document
> -----------------------
@@ -117,6 +123,9 @@
> ...separating the data model from its contraints and the notation
> used to illustrate it.
>
+
+Yes, done.
+
>
> The PROV-DM release is synchronized with the release of the PROV-O,
> PROV-PRIMER, PROV-N, PROV-DM-CONSTRAINTS documents.
@@ -124,12 +133,14 @@
> add "and" between last two
>
>
+
> We are now making clear what the entry path to the PROV family of
> specifications is.
>
> We are now clarifying the entry path to the PROV family of
> specifications.
>
+yes, much simpler.
>
> 1. Introduction
> ---------------
@@ -137,12 +148,16 @@
> ...with extra-descriptions that help...
>
> extraneous -?
+
+Done
>
>
> ...introduction to the PROV data model by overviewing a set of concepts...
>
> ...introduction to the PROV data model with an overview of concepts...
>
+
+was updated.
>
> 2.1 Entity and Activity
> -----------------------
@@ -159,6 +174,9 @@
>
> some cases
>
+
+yes, done
+
>
> 2.3 Agents and Other Types of Entities
> --------------------------------------
@@ -170,6 +188,11 @@
> Should those three be bolded here? Maybe not since we aren't
> really defining them and they are just special defined types?
>
+
+Was dropped from section 2.
+
+TODO: add these definitions, in bold, in section 4.
+
>
> ...member of the collections.
>
@@ -181,6 +204,9 @@
>
> This concept allows for the provenance of the collection itself to
> be expressed in addition to that of the constituents.
+
+Yes, done
+
>
>
> Such a notion of collection corresponds to a wide variety of concrete
@@ -192,12 +218,18 @@
> Perhaps just "Such a notion of collection corresponds to concrete
> data structures such as a maps, dictionaries, or associative arrays."?
>
+
+TODO.
>
> 2.5 Simplified Overview Diagram
> -------------------------------
>
> I would add a sentence somewhere in here about Agent being an Entity.
>
+
+We are moving away from this.
+We are now removing the subtype between agent and an entity in the diagram.
+
> Maybe here:
>
> ...how they relate to each other. At this stage...
@@ -207,12 +239,17 @@
> this stage...
>
>
+No change, given previous comment.
+
+
> 2.6 PROV-N: The Provenance Notation
> -----------------------------------
>
> PROV-N is a notation that is designed to write instances...
>
> PROV-N is a notation for writing instances...
+
+
>
>
> ...a series of arguments in bracket.
@@ -221,10 +258,15 @@
>
> (actually, I usually call them parentheses, but either is fine.)
>
+
+Yes
>
> The bulleted list here has inconsistent spacing between bulleted
> items.
>
+
+fixed.
+
>
> ...which always occur in first position...
>
@@ -243,6 +285,8 @@
> optional set of attribute-value pairs in the last position,
> delimited by square brackets.
>
+
+All done.
>
> 3.1 The Process View
> --------------------
@@ -260,6 +304,8 @@
>
> ...illustrate them with the PROV-N notation.
>
+
+Ditto
>
> 4. PROV-DM Types and Relations
>
@@ -275,6 +321,9 @@
>
> referring to the same thing.
>
+
+All done.
+
>
> 4.1 Component 1: Entities and Activities
> ----------------------------------------
@@ -292,6 +341,8 @@
>
> (If you reword this figure description, make the other figure
> descriptions match, if not, don't
+
+OK
>
>
> Associations are not just binary; indeed, Usage, Generation, Start,
@@ -300,7 +351,10 @@
>
> Associations are not just binary; indeed, Usage, Generation, Start,
> End also include time attributes.
- >
+
+OK
+
+>
>
> 4.1.3 Generation
> ----------------
@@ -336,6 +390,8 @@
> UML association classes are used...
>
>
+
+Yes.
> 4.3.1 Derivation
> ----------------
>
@@ -348,10 +404,13 @@
> facilitate provenance-based reproducibility.
>
>
+Yes
> ...it was passed as, if the activity...
>
> replace , with 'or'
>
+
+No change here.
>
> 4.5 Component 5: Collections
> ----------------------------
@@ -362,8 +421,12 @@
> Many applications also need to express the provenance of the
> collection itself...
>
+yes
+
>
> 4.7.4.4 prov:type
> -----------------
>
> include Collection and EmptyCollection here?
+Yes indeed.
+
--- a/model/prov-dm.html Thu Apr 12 12:19:12 2012 +0100
+++ b/model/prov-dm.html Thu Apr 12 14:48:38 2012 +0100
@@ -209,7 +209,7 @@
producing a piece of data or thing.
PROV-DM is structured in six components, dealing with:
(1) entities and activities, and the time at which they were created, used, or ended;
-(2) agents bearing responsibility for entities that were generated and actities that happened;
+(2) agents bearing responsibility for entities that were generated and activities that happened;
(3) derivations of entities from entities;
(4) properties to link entities that refer to a same thing;
(5) collections forming a logical structure for its members;
@@ -223,18 +223,17 @@
<p>Two further documents complete the specification of PROV-DM.
First, a companion document specifies the set of constraints that
-provenance descriptions should follow; these provide
-an interpretation for provenance descriptions. Second, to
-be able to provide examples of provenance, a notation is used for
-expressing instances of PROV-DM for human consumption; the syntactic
-details of this notation are also kept in a separate document. </p>
+provenance descriptions should follow. Second,
+a separate document describes a provenance notation for expressing
+instances of provenance for human consumption; this notation is used in examples in
+this document. </p>
</section>
<section id="sotd">
<h4>PROV Family of Specifications</h4>
This document is part of the PROV family of specifications, a set of specifications defining various aspects that are necessary to achieve the vision of inter-operable
-interchange of provenance information in heterogeneous environments such as the Web. The specifications are as follows.
+interchange of provenance information in heterogeneous environments such as the Web. The specifications are:
<ul>
<li> PROV-DM, the PROV data model for provenance (this document);</li>
<li> PROV-DM-CONSTRAINTS, a set of constraints applying to the PROV data model;</li>
@@ -247,7 +246,7 @@
</ul>
<h4>How to read the PROV Family of Specifications</h4>
<ul>
-<li>The primer is the entry point to PROV offering a pedagogical presentation of the provenance model.</li>
+<li>The primer is the entry point to PROV offering an introduction to the provenance model.</li>
<li>The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL-RL ontology. For further details, PROV-DM and PROV-DM-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. PROV-SEM provides a mathematical semantics.</li>
<li>The XML community should focus on PROV-XML defining an XML schema for PROV-DM. Further details can also be found in PROV-DM, PROV-DM-CONSTRAINTS, and PROV-SEM.</li>
<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
@@ -257,7 +256,7 @@
<h4>Fourth Public Working Draft</h4>
-<p>This is the fourth public release of the PROV-DM document. Following feedback, the Working Group has decided to reorganize this document substantially, separating the data model, from its contraints, and the notation used to illustrate it. The PROV-DM release is synchronized with the release of the PROV-O, PROV-PRIMER, PROV-N, PROV-DM-CONSTRAINTS documents. We are now making clear what the entry path to the PROV family of specifications is.</p>
+<p>This is the fourth public release of the PROV-DM document. Following feedback, the Working Group has decided to reorganize this document substantially, separating the data model from its contraints and the notation used to illustrate it. The PROV-DM release is synchronized with the release of the PROV-O, PROV-PRIMER, PROV-N, and PROV-DM-CONSTRAINTS documents. We are now clarifying the entry path to the PROV family of specifications.</p>
</section>
@@ -326,7 +325,7 @@
The PROV data model is structured according to six components covering various aspects of provenance:</p>
<ul>
<li> component 1: entities and activities, and the time at which they were created, used, or ended;
-<li> component 2: agents bearing responsibility for entities that were generated and actities that happened;
+<li> component 2: agents bearing responsibility for entities that were generated and activities that happened;
<li> component 3: derivations between entities;
<li> component 4: properties to link entities that refer to a same thing;
<li> component 5: collections of entities, whose provenance can itself be tracked;
@@ -339,7 +338,7 @@
With these, it becomes possible to write useful provenance descriptions, and publish or embed them along side the data they relate to. </p>
<p>However, if something about which provenance is expressed is subject to change, then it is challenging to express its provenance precisely (e.g. the data from which a daily weather report is derived changes from day to day).
- To address this challenge, a <em>refinement</em> is proposed to enrich simple provenance, with extra-descriptions that help qualify the specific subject of provenance and provenance itself, with attributes and temporal information, intended to satisfy a comprehensive set of constraints. These aspects are covered in the companion specification [[PROV-DM-CONSTRAINTS]].
+ To address this challenge, a <em>refinement</em> is proposed to enrich simple provenance, with extra descriptions that help qualify the specific subject of provenance and provenance itself, with attributes and temporal information, intended to satisfy a comprehensive set of constraints. These aspects are covered in the companion specification [[PROV-DM-CONSTRAINTS]].
</p>
@@ -432,7 +431,7 @@
<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, 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>
+<p>An activity may be the publishing of a document on the Web, sending a twitter message, extracting metadata embedded in a file, driving a car from Boston to Cambridge, assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a SPARQL query over a triple store, or editing a file.</p>
</div>
</section>
@@ -470,7 +469,7 @@
</div>
-<p>Activities are utilize entities and are producers of entities. In some case, utilizing an entity influences the creation of another in some way. This notion is captured by derivations, defined as follows.</p>
+<p>Activities are utilize entities and are producers of entities. In some cases, utilizing an entity influences the creation of another in some way. This notion is captured by derivations, defined as follows.</p>
<p>
<span class="glossary-ref" data-ref="glossary-derivation" data-withspan="true"></span>
@@ -487,11 +486,12 @@
<section id="section-agents-attribution-association-responsibility">
<h2>Agents, Attribution, Association, and Responsibility</h2>
-<p>The motivation for introducing agents in the model is to denote the agent's responsibility for activities that happened and entities that were generated. </p>
+<p>The motivation for introducing agents in the model is to express the agent's responsibility for activities that happened and entities that were generated. </p>
<p>
<span class="glossary-ref" data-ref="glossary-agent" data-withspan="true">
-</span>
+</span> An agent MAY be a particular type of entity. This means that the model can be
+ used to express provenance of the agents themselves.
</p>
@@ -500,8 +500,7 @@
the activities. Concepts such as triggers are themselves defined in relations between entities and activities. So the notion of having some degree of responsibility is really what makes an agent.</p>
-<p>An agent may be a particular type of entity. This means that the model can be
- used to express provenance of the agents themselves. </p>
+
<div class="anexample" id="agent-example">
<p>
@@ -607,7 +606,7 @@
<p>There are two further types of entities, collections and accounts, which are now introduced. </p>
<p>
-<span class="glossary-ref" data-ref="glossary-collection" data-withspan="true"></span> This concept allows for the provenance of the collection, 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>
+<span class="glossary-ref" data-ref="glossary-collection" data-withspan="true"></span> This concept allows for the provenance of the collection itself to be expressed in addition to that of the members. 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>
@@ -691,21 +690,21 @@
</p>
<p>However, it is important to provide instances of provenance for human consumption, as in this document or elsewhere.
-To this end, PROV-N is a notation that is designed to write instances of the PROV-DM data model in a compact textual form, without the syntactic baggage and constraints coming with a markup language such as XML or a description framework such as RDF. We outline here some of its key design principles. For full details, the reader is referred to the companion specification [[PROV-N]].</p>
+To this end, PROV-N is a notation for writing instances of the PROV-DM data model in a compact textual form, without the syntactic baggage and constraints coming with a markup language such as XML or a description framework such as RDF. We outline here some of its key design principles. For full details, the reader is referred to the companion specification [[PROV-N]].</p>
<ul>
<li>PROV-N expressions adopt a <em>functional notation</em> consisting
-of a name and a series of arguments in bracket.</li>
+of a name and a series of arguments in parentheses.</li>
<li>The interpretation of PROV-N arguments is defined according to their <em>position</em> in the list of arguments. This convention allows for a compact notation. </li>
-<li><p>
-PROV-N <em>optional arguments</em> need not be specified. For cases where it is desirable to indicate which arguments have not been specified, PROV-N uses the <em>syntactic marker</em> <span class="name">-</span> for unspecified arguments.</p>
+<li>
+PROV-N <em>optional arguments</em> need not be specified. For cases where it is desirable to indicate which arguments have not been specified, PROV-N uses the <em>syntactic marker</em> <span class="name">-</span> for unspecified arguments.
</li>
-<li><p>Most expressions
-have an identifier which always occur in <em>first position</em>,
-and an optional set of attribute-value pairs, which occur in <em>last position</em>, and delimited by square brackets. </p>
+<li>Most expressions
+have an identifier in the <em>first position</em>,
+and an optional set of attribute-value pairs in the <em>last position</em>, delimited by square brackets.
</li>
</ul>
@@ -760,7 +759,7 @@
<p>
-Concretely, in this section, we describe the kind of provenance record that the <a href="http://www.w3.org/Consortium">WWW Consortium</a> could keep for auditors to check that due processes are followed. All entities involved in this example are Web resources, with well defined URIs (some of which locating archived email messages, available to W3C Members).</p>
+Concretely, in this section, we describe the kind of provenance record that the <a href="http://www.w3.org/Consortium">WWW Consortium</a> could keep for auditors to check that due processes are followed. All entities involved in this example are Web resources, with well defined URIs (some of which refer 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>
@@ -777,7 +776,7 @@
</ul>
<p>
-We now paraphrase some PROV-DM descriptions, and illustrate them with the PROV-N notation, a notation for PROV-DM aimed at human consumption. We then follow them with a graphical illustration. Full details of the provenance record can be found <a href="examples/w3c-publication1.pn">here</a>.
+We now paraphrase some PROV-DM descriptions, and illustrate them with the PROV-N notation. We then follow them with a graphical illustration. Full details of the provenance record can be found <a href="examples/w3c-publication1.pn">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.
@@ -952,8 +951,8 @@
<ul>
<li><b>Component 1: entities and activities.</b> The first component consists of entities, activities, and all concepts linking them, such as generation, usage, start, end. The first component is the only one comprising time-related concepts. </li>
<li><b>Component 2: agents and responsibility.</b> The second component consists of agents and concepts ascribing responsibility to agents.</li>
-<li><b>Component 3: derivations.</b> The third component is formed with derivations and its derivation subtypes.</li>
-<li><b>Component 4: alternate.</b> The fourth component consists of relations linking entities somehow referring to a same thing. </li>
+<li><b>Component 3: derivations.</b> The third component is formed with derivations and derivation subtypes.</li>
+<li><b>Component 4: alternate.</b> The fourth component consists of relations linking entities somehow referring to the same thing. </li>
<li><b>Component 5: collections.</b> The fifth component is comprised of collections and operations related to collections. </li>
<li><b>Component 6: annotations.</b> The sixth component is concerned with annotations to PROV-DM concepts.</li>
</ul>
@@ -1035,7 +1034,7 @@
<section id="component1">
<h3>Component 1: Entities and Activities</h3>
-<p>The first component of PROV-DM is concerned with <a title="entity">entities</a> and <a title="activity">activities</a>, and their inter-relations: <a>Usage</a>, <a>Generation</a>, <a>Start</a>, <a>End</a>, <a>Communication</a>, and <a>Start by Activity</a>. Figure <a href="#figure-component1">figure-component1</a> overviews the first component, with two "UML classes" and binary associations between them. Associations are not just binary; indeed, <a>Usage</a>, <a>Generation</a>, <a>Start</a>, <a>End</a> are remarkable because they have <em>time</em> attributes, which are placeholders for time information related to provenance.
+<p>The first component of PROV-DM is concerned with <a title="entity">entities</a> and <a title="activity">activities</a>, and their interrelations: <a>Usage</a>, <a>Generation</a>, <a>Start</a>, <a>End</a>, <a>Communication</a>, and <a>Start by Activity</a>. Figure <a href="#figure-component1">figure-component1</a> uses UML to depict the first component, with two classes and binary associations between them. Associations are not just binary; indeed, <a>Usage</a>, <a>Generation</a>, <a>Start</a>, <a>End</a> also include <em>time</em> attributes.
</p>
<div style="text-align: center;">
@@ -1372,7 +1371,7 @@
<p>The second component of PROV-DM is concerned with <a title="agent">agents</a> and the notions of
<a>Attribution</a>, <a>Association</a>, <a>Responsibility</a>, relating agents to entities, activities, and agents, respectively.
-Figure <a href="#figure-component2">figure-component2</a> depicts the second component, with four "UML classes" (Entity, Activity, Agent, and Plan) and associations between them. So-called "UML association classes" are used to express n-ary relations.
+Figure <a href="#figure-component2">figure-component2</a> depicts the second component with four classes (Entity, Activity, Agent, and Plan) and associations between them. UML association classes are used to express n-ary relations.
</p>
@@ -1566,7 +1565,7 @@
<p>The third component of PROV-DM is concerned with <a title="derivation">derivations</a> between <a title="entity">entities</a>, and subtypes of derivations <a>Revision</a>, <a>Quotation</a>, <a>Original Source</a>, and <a>Traceability</a>.
-Figure <a href="#figure-component3">figure-component3</a> overviews the third component, with three "UML classes" (Entity, Activity, and Agent) and associations between them. So-called "UML association classes" are used to express n-ary relations.
+Figure <a href="#figure-component3">figure-component3</a> depicts the third component with three classes (Entity, Activity, and Agent) and associations between them. UML association classes express n-ary relations.
</p>
@@ -1591,7 +1590,7 @@
<p>According to <a href="#starting-points">Section Starting Points</a>, for an entity to be transformed from, created from, or resulting from an update to another, there must be some
underpinning activities performing the necessary actions resulting in such a derivation.
-A derivation can be described at various levels of precision. In its simplest form, derivation relates two entities. Optionally, attributes can be added to describe modalities of derivation. If the derivation is the result of a single known activity, then this activity can also be optionally expressed. And to provide a completely accurate description of the derivation, the generation and usage of the generated and used entities, respectively, can be provided. The reason for optional information such as activity, generation, and usage to be linked to derivations is to aid analysis of provenance and to facilitate provenance-based reproducibility. </p>
+A derivation can be described at various levels of precision. In its simplest form, derivation relates two entities. Optionally, attributes can be added to describe modalities of derivation. If the derivation is the result of a single known activity, then this activity can also be optionally expressed. And to provide a completely accurate description of the derivation, the generation and usage of the generated and used entities, respectively, can be provided. Optional information such as activity, generation, and usage can be linked to derivations to aid analysis of provenance and to facilitate provenance-based reproducibility. </p>
<p><div class="attributes" id="attributes-derivation">A <dfn title="wasDerivedFrom">derivation</dfn><span class="withPn">, written <span class="pnExpression" id="pn-wasDerivedFrom">wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)</span> in PROV-N,</span> has:
@@ -1800,8 +1799,8 @@
<p>The fourth component of PROV-DM is concerned with
relations <a>specialization</a> and <a>alternate</a> between entities.
-Figure <a href="#figure-component4">figure-component4</a> overviews
-the component, which consists of a single "UML Class" and two associations.
+Figure <a href="#figure-component4">figure-component4</a> depicts
+the fourth component with a single class and two associations.
</p>
@@ -1922,10 +1921,10 @@
<h3>Component 5: Collections</h3>
<p>The fifth component of PROV-DM is concerned with the notion of collections.
-A collection is an entity that has some members. The members are themselves entities, and therefore their provenance can be expressed. In many applications, it is also of interest to be able to express the provenance of the collection itself: e.g. who maintains the collection, which members it contains as it evolves, and how it was assembled. The purpose of Component 5 is to define the types and relations that are useful to express the provenance of collections. </p>
-
-<p>Figure <a href="#figure-component5">figure-component5</a> overviews
-the component, which consists of two "UML Class" and three associations.
+A collection is an entity that has some members. The members are themselves entities, and therefore their provenance can be expressed. Many applications need to be able to express the provenance of the collection itself: e.g. who maintains the collection, which members it contains as it evolves, and how it was assembled. The purpose of Component 5 is to define the types and relations that are useful to express the provenance of collections. </p>
+
+<p>Figure <a href="#figure-component5">figure-component5</a> depicts
+the fifth component with two classes and three associations.
</p>
@@ -1971,8 +1970,8 @@
<div class="anexample">
<pre class="codeexample">
-entity(c0, [prov:type="EmptyCollection" %% xsd:QName]) // c0 is an empty collection
-entity(c1, [prov:type="Collection" %% xsd:QName]) // c1 is a collection, with unknown content
+entity(c0, [prov:type="prov:EmptyCollection" %% xsd:QName]) // c0 is an empty collection
+entity(c1, [prov:type="prov:Collection" %% xsd:QName]) // c1 is a collection, with unknown content
</pre>
</div>
@@ -2014,12 +2013,12 @@
<div class="anexample">
<pre class="codeexample">
-entity(c0, [prov:type="EmptyCollection" %% xsd:QName]) // c0 is an empty collection
+entity(c0, [prov:type="prov:EmptyCollection" %% xsd:QName]) // c0 is an empty collection
entity(e1)
entity(e2)
entity(e3)
-entity(c1, [prov:type="Collection" %% xsd:QName])
-entity(c2, [prov:type="Collection" %% xsd:QName])
+entity(c1, [prov:type="prov:Collection" %% xsd:QName])
+entity(c2, [prov:type="prov:Collection" %% xsd:QName])
derivedByInsertionFrom(c1, c0, {("k1", e1), ("k2", e2)})
derivedByInsertionFrom(c2, c1, {("k3", e3)})
@@ -2036,12 +2035,12 @@
<div class="anexample">
<pre class="codeexample">
-entity(c0, [prov:type="EmptyCollection" %% xsd:QName]) // c0 is an empty collection
+entity(c0, [prov:type="prov:EmptyCollection" %% xsd:QName]) // c0 is an empty collection
entity(e1)
entity(e2)
entity(e3)
-entity(c1, [prov:type="Collection" %% xsd:QName])
-entity(c2, [prov:type="Collection" %% xsd:QName])
+entity(c1, [prov:type="prov:Collection" %% xsd:QName])
+entity(c2, [prov:type="prov:Collection" %% xsd:QName])
derivedByInsertionFrom(c1, c0, {("k1", e1), ("k2", e2)})
derivedByInsertionFrom(c2, c1, {("k1", e3)})
@@ -2082,12 +2081,12 @@
<div class="anexample">
<pre class="codeexample">
-entity(c0, [prov:type="EmptyCollection"]) // c0 is an empty collection
+entity(c0, [prov:type="prov:EmptyCollection"]) // c0 is an empty collection
entity(e1)
entity(e2)
entity(e3)
-entity(c1, [prov:type="Collection"])
-entity(c2, [prov:type="Collection"])
+entity(c1, [prov:type="prov:Collection"])
+entity(c2, [prov:type="prov:Collection"])
derivedByInsertionFrom(c1, c0, {("k1", e1), ("k2",e2)})
derivedByInsertionFrom(c2, c1, {("k3", e3)})
@@ -2424,6 +2423,8 @@
<li>prov:SoftwareAgent</li>
<li>prov:Organization</li>
<li>prov:Person</li>
+<li>prov:Collection</li>
+<li>prov:EmptyCollection</li>
</ul>
</section>