--- a/model/comments/issue-331-Jun.txt Thu Apr 12 10:21:52 2012 +0100
+++ b/model/comments/issue-331-Jun.txt Thu Apr 12 11:56:23 2012 +0100
@@ -40,7 +40,7 @@
> of -> on
>
-ok
+Done
>
>
@@ -54,6 +54,9 @@
>
> -> there are *further* covered in ...?
>
+
+NO ACTION
+
>
>
>
@@ -73,7 +76,7 @@
> producers.
>
-??
+This text was updated following Khalid comments, and problem solved.
>
>
>
@@ -82,6 +85,9 @@
>
> 1. There exist no prescriptive requirement -> There exist no
> prescriptive requirement*s*
+
+NO ACTION
+
>
> 2. In section 2.3, maybe the sub-types of Agents could also be given in
> bold, italic font when they were introduced at the first time, like what
@@ -89,7 +95,10 @@
>
>
-OK, need to write up definitions in glossary.
+TODO: add glossary definitions (for section 4).
+
+Removed the three types of agents from section 2.3.
+
>
>
@@ -112,6 +121,7 @@
> rest of the document.
>
+TODO
Delegation?
>
@@ -141,6 +151,7 @@
>
It's true that tense is not consistently used.
+TODO: when reorganizing example, adjust tense.
>
>
@@ -152,7 +163,7 @@
>
>
-I feel I meant 'of'
+I feel we mean 'of'
>
>
@@ -164,7 +175,7 @@
>
>
-This is prov-o question.
+This is a prov-o question.
>
>
@@ -175,7 +186,7 @@
>
>
-To update with phrasing suggested by GK.
+Done. Removed all of these, and adopted GK suggested phrasing.
>
>
@@ -190,11 +201,16 @@
> information with the collection. I think this time information is quite
> indirectly available rather than directly supported by the collection
> component.
+
>
>
We need to remove this reference to time.
+---> "which members it contains as it evolves"
+
+
+
>
>
> 4.5.4 Membership
@@ -207,7 +223,10 @@
> thorough check.
>
-effect first, cause second. That's the order that is followed.
+Effect first, cause second.
+That's the order that is followed consistently in the document.
+
+TODO: should we consider renaming?
>
@@ -219,9 +238,9 @@
> description, then it might be expressed using a different font rather
> then typeset?
-yes, to be updated, (I did it for some i part 2). Need to introduce bullet points.
-Need to be consistent.
+contains -> "has the following pairs has members".
+Also fixed the font issue.
>
>
@@ -237,6 +256,8 @@
Good point. Don't know how to address it. We can also drop this paragraph
from the main DM and leave this to part 2. It would consistent with the rest.
+TODO
+
>
>
>
@@ -248,6 +269,8 @@
> components sections. Is this on purpose?
I don't understand. Can you clarify?
+TODO
+
>
>
>
@@ -258,7 +281,13 @@
>
>
-TODO
+I added definition for note:
+
+A note is an identified set of application-specific attribute-value pairs.
+
+The attribute prov:label provides a human-readable representation of a PROV-DM element or relation. The value associated with the attribute prov:label must be a string.
+
+Isn't the difference clear?
>
> 6. Towards a Refinement of the PROV Data Model
@@ -277,5 +306,5 @@
>
> "blundling up" -> bundling up?
>
-OK
+Done
>
--- a/model/prov-dm.html Thu Apr 12 10:21:52 2012 +0100
+++ b/model/prov-dm.html Thu Apr 12 11:56:23 2012 +0100
@@ -250,7 +250,7 @@
<li>The primer is the entry point to PROV offering a pedagogical presentation of 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 of PROV-AQ.</li>
+<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
<li>Readers seeking to implement other PROV serializations
should focus on PROV-DM and PROV-DM-CONSTRAINTS. PROV-O, PROV-N, PROV-XML offer examples of mapping to RDF, text, and XML, respectively.</li>
</ul>
@@ -440,8 +440,8 @@
<section id="section-generation-usage-derivation">
<h2>Generation, Usage, Derivation</h2>
-<p>Activities and entities are associated with each other in two different ways: activities are consumers of entities and activities are producers of entities. The act of producing or consuming an entity may have a duration.
- The term 'generation' refers to the completion of the the act of producing; likewise, the term 'usage' refers to the beginning of the act of consuming entities. Thus, we define the following notions of generation and usage. </p>
+<p>Activities and entities are associated with each other in two different ways: activities utilize entities and activities produce entities. The act of utilizing or producing an entity may have a duration.
+ The term 'generation' refers to the completion of the the act of producing; likewise, the term 'usage' refers to the beginning of the act of utilizing entities. Thus, we define the following notions of generation and usage. </p>
<p>
<div class="glossary-ref" data-ref="glossary-generation" data-withspan="true">
@@ -470,7 +470,7 @@
</div>
-<p>Activities are consumers of entities and producers of entities. In some case, the consumption of an entity influences the creation of another in some way. This notion is captured by derivations, defined as follows.</p>
+<p>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>
<span class="glossary-ref" data-ref="glossary-derivation" data-withspan="true"></span>
@@ -484,10 +484,10 @@
</section>
-<section id="section-types-entities-agents">
-<h2>Agents and Other Types of Entities</h2>
-
-<p>The motivation for introducing agents in the model is to denote the agent's responsibility for activities. </p>
+<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>
<span class="glossary-ref" data-ref="glossary-agent" data-withspan="true">
@@ -500,18 +500,18 @@
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 is a particular type of Entity. This means that the model can be
+<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>
-Software for checking the use of grammar in a document may be defined as an agent of a document preparation activity, and at the same time one can describe its provenance, including for instance the vendor and the version history.</p>
+Software for checking the use of grammar in a document may be defined as an agent of a document preparation activity, and at the same time one can describe its provenance, including for instance the vendor and the version history. A Web site and service selling books on the Web and the company hosting
+them are also agents.
+</p>
</div>
-
-
-<p>There are some useful types of entities and agents that are commonly encountered in applications making data and documents available on the Web; we introduce them in the rest of this section. </p>
+<p>Agents may adopt sets of actions or steps to achieve their goals. This is captured by the notion of plan. </p>
<p>
<span class="glossary-ref" data-ref="glossary-plan" data-withspan="true">
@@ -532,44 +532,8 @@
-<p>Three types of agents are recognized because they are commonly encountered in applications making data and documents available on the Web: persons, software agents, and organizations.</p>
-
-<div class="anexample" id="types-of-agents-example">
-<p> A Web site and service selling books on the Web and the company hosting
-them are software agents and organizations, respectively.</p>
-</div>
-
-<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>
-
-<div class="anexample" id="collection-example">
-<p>
-An example of collection is an archive of documents. Each document has its own provenance, but the archive itself also has some provenance: who maintained it, which documents it contained at which point in time, how it was assembled, etc.
-</div>
-
-
-<!-- alternative names: provenance record, bundle -->
-<p>
-<span class="glossary-ref" data-ref="glossary-account" data-withspan="true">
-</span>Making an account an entity allows for provenance of provenance to be expressed.
-
-<div class="anexample" id="account-example">
-<p>
-For users to decide whether they can place their trust in
-a resource, they may want to analyze the resource's provenance, but also determine
-who its provenance is attributed to, and when it was
-generated. In other words, users need to be able to determine the provenance of provenance.
-Hence, provenance is also
-regarded as an entity (of type Account), by which provenance of provenance can then be
-expressed.
-</p>
-</div>
-
-</section>
-
-
-<section id="section-attribution-association-responsibility">
-<h2>Attribution, Association, and Responsibility</h2>
+
+
<p>Agents can be related to entities, activities, and other agents.</p>
@@ -637,7 +601,38 @@
</div>
</section>
-
+<section id="section-types-entities-agents">
+<h2>Further Entities: Collections and Accounts</h2>
+
+<p>There are two further types of entities, collections and accounts, which are now introduced. </p>
+
+<p>
+<span class="glossary-ref" data-ref="glossary-collection" data-withspan="true"></span> This concept allows for the provenance of the collection, but also of its constituents to be expressed. Such a notion of collection corresponds to a wide variety of concrete data structures, such as a <em>maps</em>, <em>dictionaries</em>, or <em>associative arrays</em>.</p>
+
+<div class="anexample" id="collection-example">
+<p>
+An example of collection is an archive of documents. Each document has its own provenance, but the archive itself also has some provenance: who maintained it, which documents it contained at which point in time, how it was assembled, etc.
+</div>
+
+
+<!-- alternative names: provenance record, bundle -->
+<p>
+<span class="glossary-ref" data-ref="glossary-account" data-withspan="true">
+</span>Making an account an entity allows for provenance of provenance to be expressed.
+
+<div class="anexample" id="account-example">
+<p>
+For users to decide whether they can place their trust in
+a resource, they may want to analyze the resource's provenance, but also determine
+who its provenance is attributed to, and when it was
+generated. In other words, users need to be able to determine the provenance of provenance.
+Hence, provenance is also
+regarded as an entity (of type Account), by which provenance of provenance can then be
+expressed.
+</p>
+</div>
+
+</section>
@@ -1926,7 +1921,7 @@
<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 member it contains at which point in time, 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>
+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.
@@ -2029,11 +2024,11 @@
derivedByInsertionFrom(c2, c1, {("k3", e3)})
</pre>
From this set of descriptions, we conclude:
-<pre class="codeexample">
- c0 = { }
- c1 = { ("k1", e1), ("k2", e2) }
- c2 = { ("k1", e1), ("k2", e2), ("k3", e3) }
- </pre>
+<ul>
+<li> <span class="name">c0</span> is the set <span class="name">{ }</span>
+<li> <span class="name">c1</span> is the set <span class="name">{ ("k1", e1), ("k2", e2) }</span>
+<li> <span class="name">c2</span> is the set <span class="name">{ ("k1", e1), ("k2", e2), ("k3", e3) }</span>
+</ul>
</div>
<p>Insertion provides an "update semantics" for the keys that are already present in the collection, as illustrated by the following example. </p>
@@ -2052,11 +2047,11 @@
</pre>
This is a case of <em>update</em> of <span class="name">e1</span> to <span class="name">e3</span> for the same key, <span class="name">"k1"</span>. <br/>
From this set of descriptions, we conclude:
- <pre class="codeexample">
- c0 = { }
- c1 = { ("k1", e1), ("k2", e2) }
- c2 = { ("k1", e3), ("k2", e2) }
- </pre>
+<ul>
+<li> <span class="name">c0</span> is the set <span class="name">{ }</span>
+<li> <span class="name">c1</span> is the set <span class="name">{ ("k1", e1), ("k2", e2) }</span>
+<li> <span class="name">c2</span> is the set <span class="name">{ ("k1", e3), ("k2", e2) }</span>
+</ul>
</div>
</section> <!-- insertion -->
@@ -2098,12 +2093,12 @@
derivedByRemovalFrom(c3, c2, {"k1", "k3"})
</pre>
From this set of descriptions, we conclude:
- <pre class="codeexample">
- c0 = { }
- c1 = { ("k1", e1), ("k2", e2) }
- c2 = { ("k1", e1), ("k2", e2), ("k3", e3) }
- c3 = { ("k2", e2) }
- </pre>
+<ul>
+<li><span class="name">c0</span> is the set <span class="name">{ }</span>
+<li><span class="name">c1</span> is the set <span class="name">{ ("k1", e1), ("k2", e2) }</span>
+<li><span class="name">c2</span> is the set <span class="name">{ ("k1", e1), ("k2", e2), ("k3", e3) }</span>
+<li><span class="name">c3</span> is the set <span class="name">{ ("k2", e2) }</span>
+</ul>
</div>
@@ -2148,12 +2143,12 @@
derivedByInsertionFrom(c1, c, {("k3", e3)})
</pre>
- From this set of assertions, we conclude:
- <pre class="codeexample">
- c contains ("k1", e1), ("k2", e2)
- c1 contains ("k1", e1), ("k2", e2), ("k3", v3)
- </pre>
- Note that the state of <span class="name">c1</span> with these relations is only partially known, because the state of <span class="name">c</span> is unknown.
+From these descriptions, we conclude:
+<ul>
+<li> <span class="name">c</span> has the following pairs as members: <span class="name">("k1", e1), ("k2", e2)</span>
+<li> <span class="name">c1</span> has the following pairs as members: <span class="name">("k1", e1), ("k2", e2), ("k3", v3)</span>
+</ul>
+<p> Note that the state of <span class="name">c1</span> with these relations is only partially known, because the state of <span class="name">c</span> is unknown.</p>
</div>
<!-- To go to part 2
@@ -2593,7 +2588,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 blundling up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named bundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-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 constraint that <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
</li>