--- a/model/comments/issue-409-khalid.txt Wed Jun 27 11:24:23 2012 +0100
+++ b/model/comments/issue-409-khalid.txt Wed Jun 27 11:29:26 2012 +0100
@@ -37,11 +37,17 @@
> OWL-RL compliant. We have been using in PROVO the term OWL-RL++,
> because there are minor violation of OWL-RL in few places in the
> ontology.
+
+OK, OWL-RL -> OWL2
+
>
> - In the Table of Content, the titles of Section 4.1 and Section 4.2
> may need to be detailed a bit more. As they are, they are not
> informative at the level of the table of content, when the reader is
> browsing.
+
+I have added "Example: " to section titles 4.1 -- 4.3
+
>
> - In the introduction, in the list that describes the components,
> there is a mismatch between this list and the components in the
@@ -49,8 +55,14 @@
> component 2 is about agents and component 3 is about derivations,
> whereas according to the table of contents, component 2 is about
> derivations and component 3 is about agents.
+
+Thanks, updated.
+
>
> - Section 2 is supposed to be an overview, but it is quite long.
+
+Examples can be hidden. It's then 2.5pages.
+
>
> - Section 2 makes the difference between binary and expanded
> relations. I am not sure this makes sense in the context of the
@@ -61,6 +73,10 @@
> relations from the point of view of a reader who is not part of the
> working group, it seems that this is a source of confusion, and I
> don't see a real benefit from its presence in the DM.
+
+Yes, it's a group decision to present "PROV core" as consisting of binary
+relations.
+
>
> - In Section 2, when explaining "Usage", it is said that "Usage is the
> beginning of utilizing an entity by an activity. Before usage, the
@@ -68,6 +84,10 @@
> been afected by the entity.". this statement does not hold when an
> entity is used multiple times by the same activity (e.g., to feed
> different parameters).
+
+You're right. But, it's all with respect to *the* usage we refer to.
+I don't know how to address it.
+
>
> - The discussion that follows Example 3, and explains that actually a
> car is used and that another car is generated at the end of the
@@ -75,26 +95,54 @@
> more natural interpretation. A simpler interpretation that the
> reader may grasp quickly, is that the driving activity used a car,
> that's it. Not every activity needs to generate an entity.
+
+Agreed that not every activity needs to generate an entity.
+
+However, Example 2 mentions driving a car from Boston to
+Cambridge. Hence, the explanation following example 3.
+
>
> - In Section 2.1.3, first paragraph: "more trustworthy that that from
> a lobby organization" -> "more trustworthy than that from a lobby
> organization"
+
+Done
+
>
> - In Section 2.1.3, in the statement about Delegation, it may be worth
> specifying what is the scope of delegation, is the delegation valid
> for a given activity or all activities carried out by the agent.
+
+The definition says " .. to carry out a specific activity ... ".
+Do we need to say more?
+
>
> - In example 13, "[...] but also determine who its provenance is
> attributed to [...]". This sentence implies that an agent is always
> a human. "who" can be replaced by "the agent" to avoid confusion.
+
+OK done
+
>
> - The column "Core Structures", in Table 3, is confusing. components
> 1, 2 and 3 do not contain only core concepts.
+
+The text says: "All components specify extended structures, whereas only the first three define core structures."
+
+I think it's clear that C1-3 do not contain only core concepts.
+
>
> - In the UML diagram in Figure 5, as well as in other UML diagrams,
> "attributes" is defined as a filed for Entity, Activity and
> others. Looking just as the UML diagram, the reader may think that
> there is a filed called attributes!
+
+
+It's how it's defined:
+
+attributes: an optional set of attribute-value pairs ((attr1, val1), ...) representing additional information about this ...
+
+
>
> - In the definition of communication, Section 5.1.5, it is stated that
> "Communication is the exchange of an unspecified entity". Why do we
@@ -103,12 +151,30 @@
> two activities to be specified. I would suggest to rephrase that
> sentence in the following lines "Communication is the exchange of an
> entity that may be unspecified".
+
+
+If the entity is specified, then we don't need Communication.
+We would just write:
+wasGeneratedBy(e,a1)
+used(a2,e)
+
+
>
> - I notice that Invalidation (Section 5.1.8), is not present in Figure 5.
+
+It is: WasInvalidatedBy is between WasGeneratedBy and wasInformedBy
+
>
> - In section 5.2 (Component 2: Derivations), the first sentence in this section says "The third component".
+
+Fixed
+
>
> - I find the definition of "Primary Source", hard to follow. Can we simplify it?
+
+At the F2F3, we agreed on definition, and I have added a linke to
+wikipedia's page on primary source.
+
>
> - In the definition of delegation, the activity is an optional
> argument. What is the semantics of delegation when the activity is
@@ -116,16 +182,30 @@
> the delegation holds is unknown. However, the reader may think that
> the delegation hold for all the activities that are carried out by
> the agent in question.
+
+That's the kind of details we have agreed to put in the constraints document.
+
+It's not an universal quantifier but an existential quantifier on
+ a specific activity (as per definition).
+
>
> - The first paragraph, 3rd sentence, in Section 5.4, "It comprises a
> Bundle class and a subclass of Entity"-> "It specifies that Bundle
> is a sub-class of Entity".
+
+Yes, there was a typo. Fixed.
+
>
> - The first sentence in Example 40 states that "A provenance
> aggregator could merge two bundles". the verb merge has a strong
> semantics that does not applies in this case. I think we could
> simply say "could union"?
>
+
+Which semantics do you refer to? This is just an example.
+
+
+
> - Section 5.5.3 on contextualization is difficult to follow. The third
> paragraph in this section states that "A bundle's description
> provide a context in which to interpret an entity in a
@@ -154,6 +234,10 @@
> will be used in practice. I would also urge the editors to avoid using
> the term contextualization as it is vague.
>
+
+Please look at how contextualization was folded into specialization.
+
+
> - In section 5.6.1, it is stated that collection is a multiset because
> it may not be possible to verify that two distinct entity
> identifiers do not denote the same entity. This is one reason, but
@@ -161,6 +245,10 @@
> allow people to contruct collections that contains duplicate
> entities with different or same identifiers.
>
+
+I removed this paragraph, because I don't think the DM should specify
+whether it's a set or a multi-set.
+
>
> On 14 June 2012 12:07, Provenance Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
>
--- a/model/prov-dm.html Wed Jun 27 11:24:23 2012 +0100
+++ b/model/prov-dm.html Wed Jun 27 11:29:26 2012 +0100
@@ -442,7 +442,7 @@
<li> PROV-DM, the PROV data model for provenance (this document);</li>
<li> PROV-CONSTRAINTS, a set of constraints applying to the PROV data model;</li>
<li> PROV-N, a notation for provenance aimed at human consumption;</li>
-<li> PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF;</li>
+<li> PROV-O, the PROV ontology, an OWL2 ontology allowing the mapping of PROV to RDF;</li>
<li> PROV-AQ, the mechanisms for accessing and querying provenance; </li>
<li> PROV-PRIMER, a primer for the PROV data model;</li>
<li> PROV-SEM, a formal semantics for the PROV data model;</li>
@@ -866,7 +866,7 @@
for deciding whether something is reliable and/or trustworthy is
knowing who or what <em>was reponsible</em> for its production. Data published by
a respected independent organization may be considered more
- trustworthy that that from a lobby organization; a claim by a
+ trustworthy than that from a lobby organization; a claim by a
well-known scientist with an established track record may be more
believed than a claim by a new student; a calculation performed by an
established software library may be more reliable than by a one-off
@@ -1073,7 +1073,7 @@
<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
+the agent 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 Bundle), by which provenance of provenance can then be
@@ -1197,7 +1197,7 @@
<section id="section-example-one">
-<h3>The Authors View</h3>
+<h3>Example: The Authors View</h3>
<p style="font-style:italic; " ><b>Description:</b> A document
@@ -1274,7 +1274,7 @@
</section>
<section id="section-example-two">
-<h3>The Process View</h3>
+<h3>Example: The Process View</h3>
<p style="font-style:italic; " ><b>Description:</b> The World Wide Web
@@ -1368,7 +1368,7 @@
<section id="section-example-c">
-<h3>Attribution of Provenance</h3>
+<h3>Example: Attribution of Provenance</h3>
<p>The two previous sections offer two different perspectives on the provenance of a document. PROV allows for multiple sources to provide the provenance of a subject. For users to decide whether they can place their trust in the document, they may want to analyze its provenance, but also determine who the provenance is attributed to, and when it was
generated, etc. In other words, we need to be able to express the provenance of provenance.</p>
@@ -1517,7 +1517,8 @@
<tr><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td></tr>
-<tr class="component6-color"><td class="provType"><a>Collection</a></td><td><a title="collection">... prov:type='prov:Collection' ...</a></td><td rowspan="7"><a href="#component6">Component 6: Collections</a></td></tr>
+<tr class="component6-color"><td class="provType"><a>Collection</a></td><td><a title="collection">... prov:type='prov:Collection' ...</a></td><td rowspan="3"><a href="#component6">Component 6: Collections</a></td></tr>
+<tr class="component6-color"><td class="provType"><a title="empty collection">EmptyCollection</a></td><td><a title="empty collection">... prov:type='prov:EmptyCollection' ...</a></td></tr>
<tr class="component6-color"><td><a>Collection Membership</a></td><td><a title="memberOf">memberOf(id; c, {e_1, ..., e_n}, cplt, attrs)</a></td></tr>
</table>
</div>
@@ -1973,13 +1974,13 @@
-<p>The third component of PROV-DM is concerned with: <a title="derivation">derivations</a> of <a title="entity">entities</a> from others; derivation subtypes <a>Revision</a>, <a>Quotation</a>, and <a>Primary Source</a>; derivation-related <a>Influence</a>.
+<p>The second component of PROV-DM is concerned with: <a title="derivation">derivations</a> of <a title="entity">entities</a> from others; derivation subtypes <a>Revision</a>, <a>Quotation</a>, and <a>Primary Source</a>; derivation-related <a>Influence</a>.
<a href="#figure-component2">Figure 6</a> depicts the third component
with PROV core structures in the yellow area, including two classes
(<a>Entity</a>, <a>Activity</a>) and binary association
(<a>Derivation</a>). PROV extended structures are found outside this
area. UML association classes express expanded n-ary relations.
-The subclasses are marked by the UML stereotype "prov:type" to indicate that that the corresponding types are valid values for the attribute <a href="#term-attribute-type">prov:type</a>.
+The subclasses are marked by the UML stereotype "prov:type" to indicate that the corresponding types are valid values for the attribute <a href="#term-attribute-type">prov:type</a>.
</p>
@@ -2154,11 +2155,13 @@
<span class="glossary-ref" data-ref="glossary-primary-source"></span>
</p>
-<p>Because of the directness of primary sources, they "speak for
-themselves" in ways that cannot be captured through the filter of
-secondary sources. As such, it is important for secondary sources to
-reference those primary sources from which they were derived, so that
-their reliability can be investigated.</p>
+<p>Because of the directness
+of <a href="http://en.wikipedia.org/wiki/Primary_source">primary
+sources</a>, they "speak for themselves" in ways that cannot be
+captured through the filter of secondary sources. As such, it is
+important for secondary sources to reference those primary sources
+from which they were derived, so that their reliability can be
+investigated.</p>
<p>A <dfn>primary source</dfn> relation is a particular case of <a>derivation</a> of
@@ -2467,7 +2470,7 @@
<p>The fourth component of PROV-DM is concerned with bundles, a mechanism to support provenance of provenance.
-<a href="#figure-component4">Figure 8</a> depicts a UML class diagram for the fourth component. It comprises a <a>Bundle</a> class and a subclass of <a>Entity</a>.
+<a href="#figure-component4">Figure 8</a> depicts a UML class diagram for the fourth component. It comprises a <a>Bundle</a> class defined as a subclass of <a>Entity</a>.
</p>
<div style="text-align: center;">
@@ -3057,10 +3060,10 @@
<h3>Component 6: Collections</h3>
<p>The sixth 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. Some applications need to be able to express the provenance of the collection itself: e.g. who maintains the collection (attribution), which members it contains as it evolves, and how it was assembled. The purpose of Component 6 is to define the types and relations that are useful to express the provenance of collections. In PROV, the concept of Collection is implemented by means of dictionaries, which we introduce in this section. </p>
+A collection is an entity that has some members. The members are themselves entities, and therefore their provenance can be expressed. Some applications need to be able to express the provenance of the collection itself: e.g. who maintains the collection (attribution), which members it contains as it evolves, and how it was assembled. The purpose of Component 6 is to define the types and relations that are useful to express the provenance of collections. </p>
<p><a href="#figure-component6">Figure 10</a> depicts
-the sixth component with a new classe (Collection) and one association (memberOf).
+the sixth component with two new classes (Collection, Empty Collection) and one association (MemberOf).
</p>
@@ -3073,17 +3076,11 @@
</div>
-<p>The intent of these relations and types is to express the <em>history of changes that occurred to a collection</em>.
-Changes to collections are about the insertion of entities into, and the removal of entities from the collection.
-Indirectly, such history provides a way to reconstruct the contents of the collection.</p>
-
<section id="term-collection">
<h3>Collection</h3>
<span class="glossary-ref" data-ref="glossary-collection"></span>
-<p>A collection is a multiset of entities (it is a multiset, rather than a set, because it may not be possible to verify that two distinct entity identitifiers do not denote, in fact, the same entity).</p>
-
<span class="glossary-ref" data-ref="glossary-empty-collection"></span>
Binary file model/uml/component6.png has changed