--- a/model/comments/issue-331-Tim.txt Thu Apr 12 22:42:11 2012 +0100
+++ b/model/comments/issue-331-Tim.txt Fri Apr 13 14:19:05 2012 +0100
@@ -140,6 +140,9 @@
> "When examining PROV-DM in details, some relations, while involving two primary elements, are shown to be nary."
> * Is it "in detail"?
> * suggest to add link to where these "detail" and "nary" are discussed later in the document.
+
+Updated text. Added reference to section 4.
+
>
> 10)
> It seems asymmetric that "wasInformedBy" is not part of the diagram
@@ -151,6 +154,13 @@
> complete.") Communication occurs throughout the publication example,
> so it could be added.
>
+
+We made a selection of constructs to appear in section 2 (and used in 3).
+We only represent those here.
+
+Adding more concepts to section 2 would make it even longer. We have
+some comments that it may be too long already.
+
>
> 11)
> The final paragraph in section 2.5 tries to tie things together, but it does not do so clearly.
@@ -167,33 +177,57 @@
>
> * for the intended purpose, "Section starting-points" is _this_ section (and not some other that needs to be hunted down).
+Yes done.
+
> * "example discussed in the next section" provides a relative reference that could be more informative. Perhaps "following section" can help.
> * "They will then be explained" -> "The starting points will be explained"
> * Not having numbers on the sections makes it difficult to infer the organization.
> * The point about the third column in the table means nothing to me. Why do I care? Is this useful in PROV-N land? It's not mentioned explicitly until the following sentence (which is where it is re-introduced unnecessarily).
- >
+
+
+Whole paragraph rewritten as follows:
+
+Figure 1 is not intended to be complete: it only illustrates types and relations introduced in this section (Section 2), exploited in the example discussed in Section 3, and explained in detail in Section 4. Names of relations depicted in Figure 1 are listed in the third column of Table 2. These names are part of a textual notation to write instances of the PROV-DM data model, which we introduce in the next section.
+
+
+
+
>
> 12)
> Expressions are not identified, but the following could be interpreted as such:
> "Most expressions have an identifier which always occur in first position"
> * suggest to rephrase so that the expression mentions (not has) an identifier.
>
+
+No action here.
+Paolo?
+
>
> 13)
> Not sure semicolon is appropriate here:
> "; we then provide attribution"
>
>
+Updated sentence:
+
+"Its provenance can be expressed from several perspectives: first, provenance is concerned with the W3C process; second, it takes the authors' viewpoint. Then, attribution of these two provenance descriptions is provided."
+
> 14)
> "must also preceded by" missing a "be"?
>
+
+yes
> 15)
> Odd phrasing: "(some of which locating archived email messages"
- >
+ >
+fixed
+
> 16)
> suggest removing "agent" from "were published by the WWW Consortium agent"
> -- it sounds like some software did it.
>
+
+Done
>
> 17)
> Collective confusion in example
@@ -208,14 +242,25 @@
> * 404: "Full details of the provenance record can be found here" ->
> http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120402/examples/w3c-publication3.pn
>
+404 was unfortunate.
+
+I Asked Tim on how to deal with this, given that URIs already exist out there!
+
> 18)
> This phrase seems to have the opposite affect of its intent:
> "its details differ from the author's perspective"
> * Perhaps "its details differ according to the asserting author"
+
+Rewrote as:
+From the author's perspective, the description states: it is a document and it has a version number.
+
>
> 19)
> Perhaps switch the two accounts in the example section. The second one is much smaller (and actually happens first).
> This could help readability.
+
+Yes, this was suggested by Khalid.
+TODO
>
> 20)
> Before section 4, the distinction between concepts and types/relations was made (to the extend of showing their mapping).
@@ -223,24 +268,43 @@
> * suggest to replace "concepts" with types and relations.
> * suggest to be precise about the relation between "concepts" and "types and relations" and to use then consistently.
>
+
+Yes, more care needs to be taken. So:
+
+"Provenance concepts, expressed as PROV-DM types and relations, are structured according to ... "
+
>
> 21)
> Beginning of section 4:
> "operations related to collections."
> * suggest to rephrase this with examples like in component 1; mentioning insertion and removal.
>
+
+Updated.
+
>
> 22)
> http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120402/prov-dm.html#prov-dm-concepts-and-relations
> * suggest adding a textual indicator for the component (to readability, and to avoid potential accessibility issues for visually impaired).
+
+I am not sure how or what, suggestion?
+
> * Also, the color code does not exist on the same page (one must scroll up to see it).
+
+I don't understand.
+
>
> 23)
> Second column for Collection seems odd in
> http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120402/prov-dm.html#prov-dm-concepts-and-relations
+
+UPdate.
+
>
> 24)
> "The attributes ex:version is" -> "The attribute ex:version is"
+
+Done
>
>
> 25)
@@ -257,6 +321,10 @@
> wasGeneratedBy(-,e2,a1, 2001-10-26T10:00:00, [ex:port="p2"])
>
> Is there an exception to the "- rule"?
+
+Nullet 4 in section 2.6
+Prov-N optional arguments need not be specified. For cases where it is desirable to indicate which arguments have not been specified, PROV-N uses the syntactic marker - for unspecified arguments.
+
>
>
> 26)
@@ -268,6 +336,8 @@
> * perhaps "Any usage or generation by an activity must follow the activity's start"
>
> * similar comment for definition of End
+
+Done.
>
>
> 27)
@@ -276,10 +346,18 @@
>
> "if the activity happens to consume the message content" could safely be removed for clarity. (the "regarded as an input" covers it more clearly)
+
+updated:
+"Furthermore, if the message is also an input to the activity, this can be described as follows:"
+
+
>
> 28)
>
> Should "wasAttributedTo(ex:foot_race,ex:DarthVader)" be "wasAttributedTo(ex:bang,ex:DarthVader)" ?
+
+Yes, that will teach to copy examples from untrusted sources ;-)
+
>
>
> 29)
@@ -289,6 +367,9 @@
> It seems odd that services are considered activities. Should they not be agents that perform more granular activities?
>
+
+
+
> * perhaps this example could be replaced to avoid yet another computer
> example: the "fine paying; check writing; mailing" activity was
> informed by the "traffic stop" activity. The implicit entity is a
@@ -296,6 +377,8 @@
> mailing address.
+done.
+
>
> 30)
>
@@ -306,6 +389,9 @@
> https://www.w3.org/2011/prov/track/issues/340
>
>
+
+See my response there. It's not a communication.
+
>
> 31)
>
@@ -316,6 +402,11 @@
> legitimate UML that can be interpreted by anybody outside of DM? Why
> isn't wasAssociatedWith class relating to Activity and Agent (like an
> ERD would do)?
+
+Primary binary relation is between activity and agent, and explicitly represented.
+Plan is a further attribute of wasAssociatedWith.
+
+
>
>
>
@@ -325,6 +416,9 @@
>
> -> "are responsible in some way for the activity that took take place"
>
+
+yes
+
>
>
> 33)
@@ -337,6 +431,9 @@
>
> * suggest to rephrase to "responsibility link [between subordinate and responsible]"
>
+
+chain -> link
+
>
>
>
@@ -346,21 +443,31 @@
>
> -> "attribute-value pairs that describe the modalities of this responsibility link."
>
+
+Done
+
>
> 35)
>
> "and a funder agents" -> "and a funder agent"
+
+"The following fragment describes three agents: a programmer, a researcher, and a funder."
>
> "has an contractual agreement" -> "has a contractual agreement"
>
>
+
+Done
+
> 36)
>
> should responsibility example include:
>
> wasAssociatedWith(a,ag3) ?
>
- >
+
+I've added it. Maybe we should be able to infer this?
+ >
>
>
> 37)
@@ -370,6 +477,9 @@
> "and subtypes of derivations" -> "subtypes of derivations"
>
>
+
+"The third component of PROV-DM is concerned with derivations of entities from others, and derivation subtypes Revision, Quotation, Original Source, and Traceability. "
+
>
>
> 36)
@@ -380,6 +490,9 @@
>
> a convention known by anybody? It is very difficult to interpret.
>
+
+As above.
+
>
>
> 37) 4.3.1
@@ -387,6 +500,9 @@
> The "build up" discussed for adding details about derivation is very nice.
>
>
+
+... we're getting there, at last!
+
>
> 38)
>
@@ -399,6 +515,9 @@
>
> and the paragraph. Perhaps a simple diagram would help follow. (but then this would be inconsistent with other definitions…)
>
+
+TODO
+
>
>
>
@@ -411,11 +530,27 @@
>
> Revision should "just be", and if one wants to know who says "it just is", we should use accounts to answer.
>
+
+It's not who said it, it's who is responsible for it.
+
+"The agent who is responsible for the revision may optionally be specified."
+
+
+
>
> The same experience that we used to remove "agent asserting an account" from "account" should be reapplied to this parameter as well.
>
> https://www.w3.org/2011/prov/track/issues/341
>
+
+
+We may want to say that we want responsibility to stay out of the derivation component.
+This would be a good refactoring I believe: we would remove agents from quotation and revision.
+We would keep derivation/responsibility well distinct.
+
+But we shouldn't conflate responsibility and accounts.
+
+
>
>
>
@@ -423,6 +558,9 @@
>
> Glad to see the "all" in "A quotation is the repeat of (some or all of) an entity"
>
+
+Good suggestion from someone ;-)
+
>
>
>
@@ -443,6 +581,10 @@
> but this is not done for Revision.
>
> * recommend to add this kind of phrase to revision section.
+
+
+Revision is a particular case of derivation of an entity into its revised version.
+
>
>
>
@@ -455,6 +597,11 @@
>
> * suggest to rephrase to something like "Let us consider the concept described in the current section"
>
+
+You're right, it's better to have the concept original source as subject.
+
+
+
>
>
> 43)
@@ -464,6 +611,9 @@
> suggest to += "(to the knowledge of the authors)"
>
>
+
+Done
+
>
> 44)
>
@@ -472,6 +622,9 @@
> be "Derivation and _attribution_ are particular cases of traceability." ?
>
>
+
+yes
+
>
> 45)
>
@@ -479,6 +632,9 @@
> pr:rec-advance." -" w3:Consortium _and_ to pr:rec-advance."
>
>
+
+yes
+
>
> 46)
>
@@ -486,6 +642,9 @@
> one cannot expect them to coordinate and agree on the identifiers to use to denote that thing."
>
> * we are nose diving back to owl:sameAs with this ^^
+
+TODO. How to fix?
+
>
> * The example is reasonable (date-specific URI versus non)
>
@@ -502,6 +661,8 @@
> - it emphasizes too much on the "choose your own URI" wild west of
> the web.
>
+
+TODO: suggestions please.
>
>
> 48)
@@ -515,6 +676,8 @@
> constrained entity than the latter. The common thing do not need to be
> identified. "
>
+
+Currently in discussion.
>
>
> 49)
@@ -527,6 +690,9 @@
>
> Though, I may just be confused on this (qualified vs. unqualified). Perhaps disregard this comment.
>
+
+Currently no action.
+TODO: shall we rename?
>
>
>
@@ -535,6 +701,7 @@
> "and is a generic indexing mechanisms" -> "and is a generic indexing mechanism"
>
>
+done
>
>
> 51)
@@ -544,6 +711,9 @@
> -> "and more. The specification of such specialized structures in terms of key-value pairs is out of the scope of this document."
>
>
+
+OK
+
>
> 52)
>
@@ -554,12 +724,18 @@
> present in the collection, as illustrated by the following example. "
>
>
+
+--> Insertion provides an "update semantics" for the keys that are already present in a collection, since a new pair replaces an existing pair with the same key in the new collection. This is illustrated by the following example.
+
>
> 53)
> "This is reflected in the constraints listed in Part II." seems to warrant a link.
>
>
>
+
+added citation.
+
>
> 54)
> first example in annotations
@@ -572,6 +748,12 @@
>
> The namespace of the attributes should NOT be in the same namespace as the instance.
>
+
+I think it should. It's the rendering application that creates the note. Text changed as follows:
+
+
+The note is linked to the entity tr:WD-prov-dm-20111215, with relation hasAnnotation discussed in Section 4.6.2. The note's identifier and attributes are declared in the namespace denoted by prefix ex to illustrate that the rendering application may differ from the application involving entity tr:WD-prov-dm-20111215.
+
>
>
> 55)
@@ -579,6 +761,8 @@
>
> ex3:n2 should NOT be in same namespace as ex3:reputation
>
+
+I think it should. It's the reputation service that adds the note.
>
>
> 56)
@@ -597,8 +781,6 @@
It is unclear to me whether this is equivalent to a derivation of provenance.
-Account and notes are on the chair's chopping list.
-
>
>
@@ -609,6 +791,9 @@
>
> ^^ does this refer to attributes mentioned in this document?
>
+
+Yes.
+
>
>
>
@@ -620,6 +805,9 @@
> respect to an activity, in the context of a usage, generation,
> association, start, and end"
>
+
+???
+TODO. I don't understand: linking what to what?
>
>
>
@@ -628,12 +816,15 @@
> "The PROV-DM namespace declares a set of reserved attributes catering for extensibility: type, role, location."
>
>
+
>
>
> 60)
> Please explicitly cite the parts in:
> "must preserve the semantics specified in the PROV-DM documents (part 1 to 3)."
>
+
+updated and added citation.
>
>
>
@@ -650,6 +841,13 @@
> didn't change, one's interpretation of what was written changes.
>
>
+
+Text is rephrased as
+
+"one needs to ensure that provenance descriptions for the latter resource remain valid as the resource state changes."
+
+
+
>
> 62) typo: "mechanism for blundling up provenance"
>
@@ -660,6 +858,13 @@
> awkward wording: "as well as constraint that structurally well-formed descriptions are expected to satisfy."
>
>
+
+constraintS
+
+
+WAW! extensive review, thanks!
+
+
>
>
> On Mar 29, 2012, at 9:36 AM, Provenance Working Group Issue Tracker wrote:
--- a/model/prov-dm.html Thu Apr 12 22:42:11 2012 +0100
+++ b/model/prov-dm.html Fri Apr 13 14:19:05 2012 +0100
@@ -326,7 +326,7 @@
<ul>
<li> component 1: entities and activities, and the time at which they were created, used, or ended;
<li> component 2: agents bearing responsibility for entities that were generated and activities that happened;
-<li> component 3: derivations between entities;
+<li> component 3: derivations of entities from others;
<li> component 4: properties to link entities that refer to a same thing;
<li> component 5: collections of entities, whose provenance can itself be tracked;
<li> component 6: a simple annotation mechanism.
@@ -628,20 +628,20 @@
<section id="section-UML">
<h2>Simplified Overview Diagram</h2>
-<p>So far, we have introduced a series of concepts underpinning provenance. PROV-DM is a conceptual data model consisting of types and relations between these. Table <a href="#overview-types-and-relations">(Mapping of Provenance concepts to types and relations in PROV-DM)</a> shows how provenance concepts can be mapped to types and relations in PROV-DM: the first column lists concepts introduced in this section, the second column indicates whether a concept maps to a type or a relation, whereas the third column contains the corresponding name. We note that names of relations have a verbal form in the past tense to express what happened in the past, as opposed to what may or will happen.
+<p>So far, we have introduced a series of concepts underpinning provenance. PROV-DM is a conceptual data model consisting of types and relations between these. <a href="#overview-types-and-relations">Table 2</a> shows how provenance concepts can be mapped to types and relations in PROV-DM: the first column lists concepts introduced in this section, the second column indicates whether a concept maps to a type or a relation, whereas the third column contains the corresponding name. Names of relations have a verbal form in the past tense to express what happened in the past, as opposed to what may or will happen.
</p>
<div style="text-align: left;">
<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="overview-types-and-relations">Mapping of Provenance concepts to types and relations in PROV-DM</caption>
-<tr><td><a>Provenance Concepts</a></td><td></td><td>PROV-DM types or relations</td></tr>
+<caption id="overview-types-and-relations">Table 2: Mapping of Provenance concepts to types and relations</caption>
+<tr><td><a><b>Provenance Concepts</b></a></td><td><b>PROV-DM types or relations</b></td><td><b>Name</b></td></tr>
<tr>
-<td><a>Entity</a></td><td rowspan="3">Types in PROV-DM</td><td><a title="dfn-Entity">entity</a></td></tr>
+<td><a>Entity</a></td><td rowspan="3">PROV-DM Types</td><td><a title="dfn-Entity">entity</a></td></tr>
<tr><td><a>Activity</a></td><td><a title="dfn-Activity">activity</a></td></tr>
<tr><td><a>Agent</a></td><td><a title="dfn-agent">agent</a></td></tr>
<tr>
-<td><a>Generation</a></td><td rowspan="6">Relations in PROV-DM</td><td><a title="wasGeneratedBy">wasGeneratedBy</a></td></tr>
+<td><a>Generation</a></td><td rowspan="6">PROV-DM Relations</td><td><a title="wasGeneratedBy">wasGeneratedBy</a></td></tr>
<tr><td><a>Usage</a></td><td><a title="used">used</a></td></tr>
<tr><td><a>Attribution</a></td><td><a title="wasAttributedTo">wasAttributedTo</a></td></tr>
<tr><td><a>Association</a></td><td><a title="wasAssociatedWith">wasAssociatedWith</a></td></tr>
@@ -650,19 +650,20 @@
</table>
</div>
-<p>Figure <a href="#">overview-types-and-relations</a> illustrates the three types (entity, activity, and agent) and how they relate to each other. At this stage, all relations are shown to be binary. When examining PROV-DM in details,
-some relations, while involving two primary elements, are shown to be n-ary. </p>
+<p><a href="#prov-dm-overview">Figure 1</a> illustrates the three types (entity, activity, and agent) and how they relate to each other. At this stage, all relations are shown to be binary. Definitions of <a href="#data-model-components">Section 4</a> reveal that some relations, while involving two primary elements, are n-ary. </p>
<div style="text-align: center; ">
<figure style="max-width: 70%; " >
<img src="images/OverviewDiagram.png" alt="Simplified Overview of PROV-DM" style="max-width: 70%; " />
-<figcaption id="prov-dm-overview">Simplified Overview of PROV-DM</figcaption>
+<figcaption id="prov-dm-overview">Figure 1: Simplified Overview of PROV-DM</figcaption>
</figure>
</div>
-<p>Figure <a href="#">overview-types-and-relations</a> is not intended to be complete. It only illustrates types and relations from Section <a href="#starting-points">starting-points</a> and exploited in the example discussed in the next section. They will then be explained in detail in Section <a href="#data-model-components">data-model-components</a>.
-The third column of Table <a href="#overview-types-and-relations">(Mapping of Provenance concepts to types and relations in PROV-DM)</a> lists names that are part of a textual notation to write instances of the PROV-DM data model. This notation, referred to as the PROV-N notation, is outlined in the next section. </p>
+<p><a href="#prov-dm-overview">Figure 1</a> is not intended to be complete: it only illustrates types and relations introduced in this section (<a href="#starting-points">Section 2</a>), exploited in the example discussed in <a href="#prov-dm-example">Section 3</a>, and explained in detail in <a href="#data-model-components">Section 4</a>.
+Names of relations depicted in <a href="#prov-dm-overview">Figure 1</a>
+are listed in
+the third column of <a href="#overview-types-and-relations">Table 2</a>. These names are part of a textual notation to write instances of the PROV-DM data model, which we introduce in the next section. </p>
<!--
<div class="note">
@@ -683,7 +684,7 @@
<ul>
<li>PROV-N expressions adopt a <em>functional notation</em> consisting
-of a name and a series of arguments in parentheses.</li>
+of a name and a list of arguments in parentheses.</li>
<li>The interpretation of PROV-N arguments is defined according to their <em>position</em> in the list of arguments. This convention allows for a compact notation. </li>
@@ -729,7 +730,7 @@
<p>The World Wide Web Consortium publishes many technical reports. In this example, we consider a technical report, and describe its provenance.
Specifically, we consider the second version of the PROV-DM document
-<a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">http://www.w3.org/TR/2011/WD-prov-dm-20111215</a>. Its provenance can be expressed from several perspectives, which we present. In the first one, provenance is concerned with the W3C process, whereas in the second one, it takes the authors' viewpoint; we then provide attribution to these two provenance descriptions.</p>
+<a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">http://www.w3.org/TR/2011/WD-prov-dm-20111215</a>. Its provenance can be expressed from several perspectives: first, provenance is concerned with the W3C process; second, it takes the authors' viewpoint. Then, attribution of these two provenance descriptions is provided.</p>
<section id="section-example-a">
@@ -741,7 +742,7 @@
policy. Working drafts are published regularly to reflect the work
accomplished by working groups. Every publication of a working draft
must be preceded by a "publication request" to the Webmaster. The
-very first version of a technical report must also preceded by a
+very first version of a technical report must also be preceded by a
"transition request" to be approved by the W3C director. All working
drafts are made available at a unique URI. In this scenario, we consider two successive versions of a given report, the policy according to which they were published, and the associated requests.
</p>
@@ -752,7 +753,7 @@
<ul>
<li> Two versions of the technical report are involved: <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> (second working draft) and <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> (first working draft);</li>
-<li> Both <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> and <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> were published by the WWW Consortium agent (<span class="name"><a href="http://www.w3.org/Consortium">w3:Consortium</a></span>); </li>
+<li> Both <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> and <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> were published by the WWW Consortium (<span class="name"><a href="http://www.w3.org/Consortium">w3:Consortium</a></span>); </li>
<li> The publication activity for <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span> is <span class="name">ex:act2</span>;</li>
<li> The publication activity for <span class="name"><span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018">tr:WD-prov-dm-20111018</a></span></span> is <span class="name">ex:act1</span>;
</li>
@@ -823,7 +824,7 @@
<div style="text-align: center;">
<figure>
<img src="images/w3-publication1.png" alt="Provenance of a Tech Report" style="max-width: 90%; "/>
-<figcaption>Provenance of a Tech Report</figcaption>
+<figcaption>Figure 2: Provenance of a Tech Report</figcaption>
</figure>
</div>
@@ -864,7 +865,7 @@
<pre>
entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
</pre>
-<p>While this description is about the same report <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, its details differ from the author's perspective: it is a document and it has a version number. </p></li>
+<p>This description is about the same report <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>. From the author's perspective, the description states: it is a document and it has a version number. </p></li>
<li>There is an editing activity.
<pre>
@@ -888,8 +889,8 @@
<li>Agents were assigned various responsibilities in the editing activity: contributor and editor.
<pre>
-wasAssociatedWith(ex:edit1, ex:Paolo, -, [prov:role="editor"])
-wasAssociatedWith(ex:edit1, ex:Simon, -, [prov:role="contributor"])
+wasAssociatedWith(ex:edit1, ex:Paolo, -, [ prov:role="editor" ])
+wasAssociatedWith(ex:edit1, ex:Simon, -, [ prov:role="contributor" ])
</pre>
</li>
</ul>
@@ -899,7 +900,7 @@
<div style="text-align: center; ">
<figure>
<img src="images/w3-publication3.png" alt="Provenance of a Tech Report (b)" style="max-width: 98%; "/>
-<figcaption id="prov-tech-report">Provenance of a Tech Report (b)</figcaption>
+<figcaption id="prov-tech-report">Figure 3: Provenance of a Tech Report (b)</figcaption>
</figure>
</div>
@@ -933,16 +934,16 @@
<h2>PROV-DM Types and Relations</h2>
-<p>PROV-DM concepts are structured according to six components that are introduced in this section.
-Components and their dependencies are illustrated in Figure <a href="#prov-dm-components">prov-dm-components</a>. A component that relies on concepts defined in another also sits above it in this figure.
+<p>Provenance concepts, expressed as PROV-DM types and relations, are structured according to six components that are introduced in this section.
+Components and their dependencies are illustrated in <a href="#prov-dm-components">Figure 4</a>. A component that relies on concepts defined in another also sits above it in this figure.
PROV-DM consists of the following components.</p>
<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 1: entities and activities.</b> The first component consists of entities, activities, and concepts linking them, such as generation, usage, start, end. The first component is the only one comprising time-related concepts. </li>
<li><b>Component 2: agents and responsibility.</b> The second component consists of agents and concepts ascribing responsibility to agents.</li>
<li><b>Component 3: derivations.</b> The third component is formed with derivations and derivation subtypes.</li>
<li><b>Component 4: alternate.</b> The fourth component consists of relations linking entities 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 5: collections.</b> The fifth component is about collections and concepts capturing their transformation, such as insertion and removal. </li>
<li><b>Component 6: annotations.</b> The sixth component is concerned with annotations to PROV-DM concepts.</li>
</ul>
@@ -958,18 +959,18 @@
<area title="derivations" href="#component3" coords="80,0,210,70" alt="derivations" shape="rect"/>
<area title="agents/responsibility" href="#component2" coords="0,0,70,220" alt="agents/responsibility" shape="rect"/>
</map>
-<figcaption id="prov-dm-components">PROV-DM Components</figcaption>
+<figcaption id="prov-dm-components">Figure 4: PROV-DM Components</figcaption>
</figure>
</div>
<p>
-While not all PROV-DM relations are binary, they all involve two primary elements. Hence, Table <a href="#relations-at-a-glance">relations-at-a-glance</a> indexes all relations according to their two primary elements. The table adopts the same color scheme as Figure <a href="#prov-dm-components">prov-dm-components</a>, allowing components to be readily identified.
+While not all PROV-DM relations are binary, they all involve two primary elements. Hence, <a href="#relations-at-a-glance">Table 3</a> indexes all relations according to their two primary elements. The table adopts the same color scheme as <a href="#prov-dm-components">Figure 4</a>, allowing components to be readily identified.
Note that for simplicity, this table does not include collection-oriented relations.
</p>
<div style="text-align: center;">
<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="relations-at-a-glance">PROV-DM Relations At a Glance</caption>
+<caption id="relations-at-a-glance">Table 3: PROV-DM Relations At a Glance</caption>
<tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Note</td></tr>
<tr><td>Entity</td><td><div class="component3-color"><a>wasDerivedFrom</a><br><a>wasRevisionOf</a><br><a>wasQuotedFrom</a><br><a>hadOriginalSource</a></div><div class="component4-color"><a>alternateOf</a><br><a>specializationOf</a></div></td><td class="component1-color"><a
title="wasGeneratedBy">wasGeneratedBy</a></td><td class="component2-color"><a>wasAttributedTo</a></td><td class="component6-color"><a>hasAnnotation</a></td></tr>
@@ -979,12 +980,12 @@
</table>
</div>
-<p>Table <a href="#prov-dm-concepts-and-relations">prov-dm-concepts-and-relations</a> is a complete index of all the types and relations of PROV-DM, color-coded according to the component they belong to. In the first column, concept names link to their informal definition, whereas, in the second column, representations link to the information used to represent the concept.</p>
+<p><a href="#prov-dm-types-and-relations">Table 4</a> is a complete index of all the types and relations of PROV-DM, color-coded according to the component they belong to. In the first column, concept names link to their informal definition, whereas, in the second column, representations link to the information used to represent the concept.</p>
<div style="text-align: left;">
<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption id="prov-dm-concepts-and-relations">PROV-DM Types and Relations</caption>
+<caption id="prov-dm-types-and-relations">Table 4: PROV-DM Types and Relations</caption>
<tr><td><a><b>Type or Relation Name</b></a></td><td><b>Representation in the PROV-N notation</b></td></tr>
<tr class="component1-color"><td><a>Entity</a></td><td><a title="dfn-Entity">entity(id, [ attr1=val1, ...])</a></td></tr>
<tr class="component1-color"><td><a>Activity</a></td><td><a title="dfn-Activity">activity(id, st, et, [ attr1=val1, ...])</a></td></tr>
@@ -1029,7 +1030,7 @@
<div style="text-align: center;">
<figure>
<img src="images/Entities-Activities.png" alt="entities and activities"/>
-<figcaption id="figure-component1">Entities and Activities Component Overview</figcaption>
+<figcaption id="figure-component1">Figure 5: Entities and Activities Component Overview</figcaption>
</figure>
</div>
@@ -1057,7 +1058,7 @@
<pre class="codeexample">
entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
</pre>
-states the existence of an entity, denoted by identifier <span class="name">tr:WD-prov-dm-20111215</span>, with type <span class="name">document</span> and version number <span class="name">2</span>. The attributes <span class="name">ex:version</span> is application specific, whereas the attribute <span
+states the existence of an entity, denoted by identifier <span class="name">tr:WD-prov-dm-20111215</span>, with type <span class="name">document</span> and version number <span class="name">2</span>. The attribute <span class="name">ex:version</span> is application specific, whereas the attribute <span
class="name">type</span> is reserved in the PROV-DM namespace.
<!--The following expression</p>
<pre class="codeexample">
@@ -1231,7 +1232,7 @@
activity(a1,[prov:type="Discuss"])
wasStartedBy(a1,e1,2011-11-16T16:05:00)
</pre>
-Furthermore, if the activity happens to consume the message content, then the message would also be regarded as an input to the activity, which we describe as follows:
+Furthermore, if the message is also an input to the activity, this can be described as follows:
<pre class="codeexample">
used(a1,e1,-)
</pre>
@@ -1245,8 +1246,8 @@
activity(ex:foot_race)
wasStartedBy(ex:foot_race,ex:bang,2012-03-09T08:05:08-05:00)
entity(ex:bang)
-agent(ex:DarthVader)
-wasAttributedTo(ex:foot_race,ex:DarthVader)
+agent(ex:Bob)
+wasAttributedTo(ex:bang,ex:Bob)
</pre>
</div>
@@ -1309,13 +1310,13 @@
<div class="anexample">
<p>
-Consider two long running services, which we represent by activities <span class="name">s1</span> and <span class="name">s2</span>.
+Consider two activities <span class="name">a1</span> and <span class="name">a2</span>, the former performed by a government agency, and the latter by a driver caught speeding.
<pre class="codeexample">
-activity(s1, [prov:type="service"])
-activity(s2, [prov:type="service"])
-wasInformedBy(s2,s1)
+activity(a1, [prov:type="traffic regulations enforcing"])
+activity(a2, [prov:type="fine paying; check writing; mailing"])
+wasInformedBy(a2,a1)
</pre>
-The last line indicates that some entity was generated by <span class="name">s1</span> and used by <span class="name">s2</span>.
+The last line indicates that some implicit entity was generated by <span class="name">a1</span> and used by <span class="name">a2</span>; this entity may be a traffic ticket that had a notice of fine, amount, and payment mailing details.
</div>
</section>
@@ -1367,7 +1368,7 @@
<div style="text-align: center;">
<figure>
<img src="images/Agents-Responsibility.png" alt="agents and responsibilities"/>
-<figcaption id="figure-component2">Agents and Responsibilities Component Overview</figcaption>
+<figcaption id="figure-component2">Figure 6: Agents and Responsibilities Component Overview</figcaption>
</figure>
</div>
@@ -1498,28 +1499,28 @@
agents of the activity; furthermore, the mail software
agent is running on the person's behalf. In another example, the
student acted on behalf of his supervisor, who acted on behalf of the
-department chair, who acts on behalf of the university; all those
-agents are responsible in some way for the activity to take place but
+department chair, who acted on behalf of the university; all those
+agents are responsible in some way for the activity that took place but
we do not say explicitly who bears responsibility and to what
degree. </p>
<p>
<div class="attributes" id="attributes-responsibility">
-A <dfn title="actedOnBehalfOf">responsibility</dfn> relation<span class="withPn">, written <span class="pnExpression">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-N,</span> has:
+A <dfn title="actedOnBehalfOf">responsibility</dfn> link<span class="withPn">, written <span class="pnExpression">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-N,</span> has:
<ul>
-<li><span class='attribute' id="responsibility.id">id</span>: an OPTIONAL identifier for the responsibility chain;</li>
+<li><span class='attribute' id="responsibility.id">id</span>: an OPTIONAL identifier for the responsibility link between subordinate and responsible;</li>
<li><span class='attribute' id="responsibility.subordinate">subordinate</span>: an identifier (<span class="name">ag2</span>) for the agent associated with an activity, acting on behalf of the responsible
agent;</li>
<li><span class='attribute' id="responsibility.responsible">responsible</span>: an identifier (<span class="name">ag1</span>) for the agent, on behalf of which the subordinate agent acted;</li>
-<li><span class='attribute' id="responsibility.activity">activity</span>: an OPTIONAL identifier (<span class="name">a</span>) of an activity for which the responsibility chain holds;</li>
-<li><span class='attribute' id="responsibility.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this responsibility relation.</li>
+<li><span class='attribute' id="responsibility.activity">activity</span>: an OPTIONAL identifier (<span class="name">a</span>) of an activity for which the responsibility link holds;</li>
+<li><span class='attribute' id="responsibility.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this responsibility link.</li>
</ul></div>
<div class="anexample">
-<p>In the following example, a programmer, a researcher and a funder agents are described. The programmer and researcher are associated with a workflow activity. The programmer acts on behalf
-of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher. The terms
+<p>The following fragment describes three agents: a programmer, a researcher, and a funder. The programmer and researcher are associated with a workflow activity. The programmer acts on behalf
+of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has a contractual agreement with the researcher. The terms
'delegation' and 'contact' used in this example are domain specific.</p>
<pre class="codeexample">
activity(a,[prov:type="workflow"])
@@ -1528,6 +1529,7 @@
agent(ag3,[prov:type="funder"])
wasAssociatedWith(a,ag1,[prov:role="loggedInUser"])
wasAssociatedWith(a,ag2)
+wasAssociatedWith(a,ag3)
actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])
actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
</pre>
@@ -1553,7 +1555,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>.
+<p>The third component of PROV-DM is concerned with <a title="derivation">derivations</a> of <a title="entity">entities</a> from others, and derivation subtypes <a>Revision</a>, <a>Quotation</a>, <a>Original Source</a>, and <a>Traceability</a>.
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>
@@ -1561,7 +1563,7 @@
<div style="text-align: center;">
<figure>
<img src="images/Derivation.png" alt="derivation"/>
-<figcaption id="figure-component3">Derivation Component Overview</figcaption>
+<figcaption id="figure-component3">Figure 7: Derivation Component Overview</figcaption>
</figure>
</div>
@@ -1577,7 +1579,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
+<p>According to <a href="#starting-points">Section 2</a>, for an entity to be transformed from, created from, or resulting from an update to another, there must be some
underpinning activities performing the necessary actions resulting in such a derivation.
A derivation can be described at various levels of precision. In its simplest form, derivation relates two entities. Optionally, attributes can be added to 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>
@@ -1726,12 +1728,12 @@
<div class="anexample">
<p>
-Let us consider the current section <a href="#term-original-source"><span class="name">dm:term-original-source</span></a>, and
-the Google page <a href="http://googlenewsblog.blogspot.com/2010/11/credit-where-credit-is-due.html"><span class="name">go:credit-where-credit-is-due.html</span></a>, where the notion was originally described.
+Let us consider the concept introduced in the current section, identified as <a href="#concept-original-source"><span class="name">dm:concept-original-source</span></a>, and
+the Google page <a href="http://googlenewsblog.blogspot.com/2010/11/credit-where-credit-is-due.html"><span class="name">go:credit-where-credit-is-due.html</span></a>, where the notion original-source was originally described (to the knowledge of the authors).
<pre class="codeexample">
-entity(dm:term-original-source)
+entity(dm:concept-original-source)
entity(go:credit-where-credit-is-due.html)
-hadOriginalSource(dm:term-original-source,go:credit-where-credit-is-due.html)
+hadOriginalSource(dm:concept-original-source,go:credit-where-credit-is-due.html)
</pre>
</div>
@@ -1751,7 +1753,7 @@
some responsibility for <span class="name">e2</span>'s existence.
-<p><dfn title="tracedTo">Traceability</dfn><span class="withPn">, written <span class="pnExpression">tracedTo(id,e2,e1,attrs)</span> in PROV-N,</span> has:</p>
+<p>A <dfn title="tracedTo">Traceability</dfn> relation <span class="withPn">, written <span class="pnExpression">tracedTo(id,e2,e1,attrs)</span> in PROV-N,</span> has:</p>
<ul>
<li><span class='attribute' id="traceability.id">id</span>: an OPTIONAL identifier identifying the relation;</li>
<li><span class='attribute' id="traceability.entity">entity</span>: an identifier (<span class="name">e2</span>) for an entity;
@@ -1761,13 +1763,13 @@
<p>We note that the ancestor is allowed to be an agent since agents are entities. </p>
<p>
-<a>Derivation</a> and <a>association</a> are particular cases of traceability.
+<a>Derivation</a> and <a>attribution</a> are particular cases of traceability.
</p>
<div class="anexample">
-<p>We refer to the example of <a href="#section-example-a">Section 3.1</a>, and specifically to <a href="#prov-tech-report">Figure prov-tech-report</a>. We can see that there is a path from
+<p>We refer to the example of <a href="#section-example-a">Section 3.1</a>, and specifically to <a href="#prov-tech-report">Figure 3</a>. We can see that there is a path from
<span class="name">tr:WD-prov-dm-20111215</span> to
-<span class="name">w3:Consortium</span> or to
+<span class="name">w3:Consortium</span> and to
<span class="name">pr:rec-advance</span>. This is expressed as follows.
<pre class="codeexample">
tracedTo(tr:WD-prov-dm-20111215,w3:Consortium)
@@ -1796,7 +1798,7 @@
<div style="text-align: center;">
<figure>
<img src="images/Alternates.png" alt="alternates"/>
-<figcaption id="figure-component4">Alternates Component Overview</figcaption>
+<figcaption id="figure-component4">Figure 8: Alternates Component Overview</figcaption>
</figure>
</div>
@@ -1920,7 +1922,7 @@
<div style="text-align: center;">
<figure>
<img src="images/Collections.png" alt="collections"/>
-<figcaption id="figure-component5">Collections Component Overview</figcaption>
+<figcaption id="figure-component5">Figure 9: Collections Component Overview</figcaption>
</figure>
</div>
@@ -1935,7 +1937,7 @@
<span class="glossary-ref" data-ref="glossary-collection"></span>
-<p>Conceptually, a collection has a logical structure consisting of key-entity pairs. This structure is often referred to as a <em>map</em>, and is a generic indexing mechanisms that can abstract commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more (the specification of such specialized structures in terms of key-value pairs is out of the scope of this document).</p>
+<p>Conceptually, a collection has a logical structure consisting of key-entity pairs. This structure is often referred to as a <em>map</em>, and is a generic indexing mechanism that can abstract commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more. The specification of such specialized structures in terms of key-value pairs is out of the scope of this document.</p>
<p>A given collection forms a given structure for its members. A different structure (obtained either by insertion or removal of members) constitutes a different collection. Hence,
for the purpose of provenance, a collection entity is viewed as a snapshot of a structure. Insertion and removal operations result in new snapshots, each snapshot forming an identifiable collection entity.</p>
@@ -1979,7 +1981,7 @@
<p><div class="attributes" id="attributes-derivedByInsertionFrom">
-<p>A <dfn title="derivedByInsertionFrom">Derivation-by-Insertion</dfn> relation<span class="withPn">, written <span class="pnExpression">derivedByInsertionFrom(id, c2, c1, {(key_1, e_1), ..., (key_n, e_n)}, attrs)</span>,</span> has:</p>
+<p>An <dfn title="derivedByInsertionFrom">Insertion</dfn> relation<span class="withPn">, written <span class="pnExpression">derivedByInsertionFrom(id, c2, c1, {(key_1, e_1), ..., (key_n, e_n)}, attrs)</span>,</span> has:</p>
<ul>
<li><span class='attribute' id="derivedByInsertionFrom.id">id</span>: an OPTIONAL identifier identifying the relation;</li>
<li><span class='attribute' id="derivedByInsertionFrom.after">after</span>: an identifier (<span class="name">c2</span>) for the collection <em>after</em> insertion; </li>
@@ -1992,7 +1994,7 @@
</div>
<p>
-A Derivation-by-Insertion relation <span class="name">derivedByInsertionFrom(id, c2, c1, {(key_1, e_1), ..., (key_n, e_n)})</span> states that <span class="name">c2</span> is the state of the collection
+An Insertion relation <span class="name">derivedByInsertionFrom(id, c2, c1, {(key_1, e_1), ..., (key_n, e_n)})</span> states that <span class="name">c2</span> is the state of the collection
following the insertion of pairs <span class="name">(key_1, e_1)</span>, ..., <span class="name">(key_n, e_n)</span> into collection <span class="name">c1</span>.</p>
@@ -2020,7 +2022,8 @@
</ul>
</div>
-<p>Insertion provides an "update semantics" for the keys that are already present in the collection, as illustrated by the following example. </p>
+<p>Insertion provides an "update semantics" for the keys that are already present in a collection,
+since a new pair replaces an existing pair with the same key in the new collection. This is illustrated by the following example.</p>
<div class="anexample">
<pre class="codeexample">
@@ -2056,7 +2059,7 @@
<p>
<div class="attributes" id="attributes-derivedByRemovalFrom">
-<p> A <dfn title="derivedByRemovalFrom">Derivation-by-Removal</dfn> relation, written <span class="pnExpression">derivedByRemovalFrom(id, c2, c1, {key_1, ... key_n}, attrs)</span>, has:</p>
+<p> A <dfn title="derivedByRemovalFrom">Removal</dfn> relation, written <span class="pnExpression">derivedByRemovalFrom(id, c2, c1, {key_1, ... key_n}, attrs)</span>, has:</p>
<ul>
<li><span class='attribute' id="derivedByRemovalFrom.id">id</span>: an OPTIONAL identifier identifying the relation;</li>
<li><span class='attribute' id="derivedByRemovalFrom.after">after</span>: an identifier (<span class="name">c2</span>) for the collection <em>after</em> the deletion; </li>
@@ -2066,7 +2069,7 @@
</ul>
</div>
-<p>Derivation-by-Removal relation <span class="name">derivedByRemovalFrom(id, c2,c1, {key_1, ..., key_n})</span> states that <span class="name">c2</span> is the state of the collection following the removal of the set of pairs corresponding to keys <span class="name">key_1...key_n</span> from <span class="name">c1</span>.
+<p>A Removal relation <span class="name">derivedByRemovalFrom(id, c2,c1, {key_1, ..., key_n})</span> states that <span class="name">c2</span> is the state of the collection following the removal of the set of pairs corresponding to keys <span class="name">key_1...key_n</span> from <span class="name">c1</span>.
<div class="anexample">
<pre class="codeexample">
@@ -2163,7 +2166,7 @@
<li>The state of a collection (i.e., the set of key-entity pairs it contains) at a given point in a sequence of operations is never stated explicitly. Rather, it can be obtained by querying the chain of derivations involving insertions and removals. Entity type <span class="name">emptyCollection</span> can be used in this context as it marks the start of a sequence of collection operations.</li>
-<li>The representation of a collection through these relations makes no assumption regarding the underlying data structure used to store and manage collections. In particular, no assumptions are needed regarding the mutability of a data structure that is subject to updates. Entities, however, are immutable and this applies to those entities that represent collections. This is reflected in the constraints listed in Part II. </li>
+<li>The representation of a collection through these relations makes no assumption regarding the underlying data structure used to store and manage collections. In particular, no assumptions are needed regarding the mutability of a data structure that is subject to updates. Entities, however, are immutable and this applies to those entities that represent collections. This is reflected in the constraints listed in [[PROV-DM-CONSTRAINTS]]. </li>
</ul>
@@ -2207,21 +2210,22 @@
to help the rendering of what it is associated with, by
specifying its color and its position on the screen.</p>
<pre class="codeexample">
-note(ex2:n1,[ex2:color="blue", ex2:screenX=20, ex2:screenY=30])
-hasAnnotation(tr:WD-prov-dm-20111215,ex2:n1)
+note(ex:n1,[ex:color="blue", ex:screenX=20, ex:screenY=30])
+hasAnnotation(tr:WD-prov-dm-20111215,ex:n1)
</pre>
-<p>The note is associated with the entity <span class="name">tr:WD-prov-dm-20111215</span>.
-Relation <a title="annotation">hasAnnotation</a> is
-discussed in the <a href="#term-annotation">next section</a>. The note's identifier and attributes are declared in a separate namespace denoted by prefix <span class="name">ex2</span>.
+<p>The note is linked to the entity <span class="name">tr:WD-prov-dm-20111215</span>, with
+relation <a title="annotation">hasAnnotation</a>
+discussed in <a href="#term-annotation">Section 4.6.2</a>.
+The note's identifier and attributes are declared in the namespace denoted by prefix <span class="name">ex</span> to illustrate that the rendering application may differ from the application involving entity <span class="name">tr:WD-prov-dm-20111215</span>.
</p>
</div>
<div class="anexample" id="anexample-note2">
-<p>Alternatively, a reputation service may enrich a provenance record with notes providing reputation ratings about agents. In the following fragment, both agents <span class="name">ex:Simon</span> and <span class="name">ex:Paolo</span> are rated "excellent".</p>
+<p>Alternatively, a reputation service may enrich a provenance record with notes providing reputation ratings about agents. In the following fragment, both agents <span class="name">ex2:Simon</span> and <span class="name">ex2:Paolo</span> are rated "excellent".</p>
<pre class="codeexample">
note(ex3:n2,[ex3:reputation="excellent"])
-hasAnnotation(ex:Simon,ex3:n2)
-hasAnnotation(ex:Paolo,ex3:n2)
+hasAnnotation(ex2:Simon,ex3:n2)
+hasAnnotation(ex2:Paolo,ex3:n2)
</pre>
<p>The note's identifier and attributes are declared in a separate namespace denoted by prefix <span class="name">ex3</span>.</p>
@@ -2383,9 +2387,9 @@
class="name">prov:role</span> attribute MUST be a PROV-DM <a title="value">Value</a>.</p>
<div class="anexample">
-<p>The following activity start describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
+<p>The following activity is associated with an agent acting as the operator. </p>
<pre class="codeexample">
- wasStartedBy(a,ag, [prov:role="program-operator"])
+ wasAssociatedWith(a, ag, [prov:role="operator"])
</pre>
</div>
</section>
@@ -2445,7 +2449,7 @@
<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption>PROV-DM Data Types</caption>
+<caption>Table 5: PROV-DM Data Types</caption>
<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#decimal">xsd:decimal</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#double">xsd:double</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#dateTime">xsd:dateTime</a></td> </tr>
<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#integer">xsd:integer</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#float">xsd:float</a></td> </tr>
<tr><td><a href="http://www.w3.org/TR/xmlschema-2/#nonNegativeInteger">xsd:nonNegativeInteger</a></td> <td><a href="http://www.w3.org/TR/xmlschema-2/#string">xsd:string</a></td> <td><a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-XMLLiteral">rdf:XMLLiteral</a></td> </tr>
@@ -2511,32 +2515,53 @@
<h2>PROV-DM Extensibility Points</h2>
-<p>The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
+<p>The PROV data model provides extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
<ul>
-<li> Attributes occur in all elements and relations of the data model. Applications are free to introduce
-application-specific attributes, according to their perspective on the world. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace
+<li> Attribute-value lists occur in all types and relations of the data model. Applications designers are free to introduce further application-specific attributes. Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace
declared in a namespace declaration.
-<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes catering for extensibility: <span class="name">type</span>, <span class="name">role</span>, <span
-class="name">location</span>.</li>
-
-
-
+<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes catering for extensibility: <a href="#term-attribute-type"><span class="name">prov:type</span></a>, <a href="#term-attribute-role"><span class="name">prov:role</span></a>, <a href="#term-attribute-location"><span
+class="name">prov:location</span></a>.</li>
+
+<li>Sub-types and sub-relations can be expressed by means of the reserved attribute
+<a href="#term-attribute-type"><span class="name">prov:type</span></a>.
+
+<div class="anexample" id="anexample-sub-relation">
+<p>
+In the following example, <span class="name">e2</span> is a translation of <span class="name">e1</span>,
+expressed as a sub-type of derivation.
+<pre class="codeexample">
+ wasDerivedFrom(e2,e1, [prov:type="ex:Translation" %% xsd:QName])
+</pre>
+</div>
+
+<div class="anexample" id="anexample-sub-type">
+<p>
+In the following example, <span class="name">e</span> is described as a Car, a type of entity.
+<pre class="codeexample">
+ entity(e, [prov:type="ex:Car" %% xsd:QName])
+</pre>
+</div>
+
+
+
+
+</li>
+
+
+
+
+
+<li>New namespaces and associated prefixes can be declared, allowing attributes and names to be qualified. </li>
<li>Notes allow arbitrary metadata to be associated with anything identifiable in PROV-DM. Notes consist of attribute-value pairs. Attributes are qualified by a
namespace.</li>
-
-<li>Namespaces allow attributes and names to be qualified. </li>
-
-<li>Sub-typing of elements and relations is allowed by means of the reserved attribute <span class="name">type</span>.</li>
-
-<li>Domain specific values can be expressed by means of typed literals. </li>
</ul>
<p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged. To ensure interoperability, specializations of
-the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in the PROV-DM documents (part 1 to 3). </p>
+the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in this document and in [[PROV-DM-CONSTRAINTS]]. </p>
@@ -2557,15 +2582,15 @@
descriptions that would not make sense: for instance, one could
express that an entity was used before it was generated, or that the
activity that generated an entity began its existence after the entity
-generation. A set of consistency constraints have been defined for PROV-DM and
+generation. A set of constraints have been defined for PROV-DM and
can be found in a companion specification [[PROV-DM-CONSTRAINTS]].
-They can be used by asserters as a guideline for composing provenance descriptions that are consistent, and
-by implementers of reasoning engines. </li>
+They SHOULD be used by developers to compose provenance descriptions that are valid, and
+by implementers of reasoning engines aiming to check whether provenance descriptions have problems. </li>
<li>
-<p> The example of <a href="#prov-dm-example">section 3</a> contains identifiers such as <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, which denotes a specific version of a technical report. On the other hand, a URI such as <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a> points to the latest version of a document. One needs to ensure that provenance descriptions for the latter document remain valid as denoted resources change. </p>
+<p> The example of <a href="#prov-dm-example">section 3</a> contains identifiers such as <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, which denotes a specific version of a technical report. On the other hand, a URI such as <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a> denotes the latest version of a document. One needs to ensure that provenance descriptions for the latter resource remain valid as the resource state changes. </p>
<p>To this end, PROV-DM allows asserters to describe "<em>partial states</em>" of entities by means of attributes and associated values. Some further constraints apply to the use of these attributes, since the values associated with them are expected to remain unchanged for some period of time. The constraints associated to attributes allow provenance descriptions to be refined, they can also be found in the companion specification [[PROV-DM-CONSTRAINTS]].</p>
@@ -2579,7 +2604,7 @@
<li> relying on specific serializations to name bundles of descriptions;</li>
<li> using the idea of a service that is capable of associating provenance descriptions to whom they are attributed to.</li>
</ul>
-<p>Even though a mechanism for bundling up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named bundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-account">Account</a> so that its provenance can be expressed. The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as constraint that <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
+<p>Even though a mechanism for bundling up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named bundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-account">Account</a> so that its provenance can be expressed. The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as the constraints that <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
</li>