--- a/model/comments/issue-331-Khalid.txt Wed Apr 11 09:43:03 2012 +0100
+++ b/model/comments/issue-331-Khalid.txt Wed Apr 11 09:59:41 2012 +0100
@@ -1,35 +1,126 @@
-
--------------
-- In the beginning of the working draft "How to read the PROV Family", it is said that "Developers seeking to retrieve or publish provenance should focus *on* PROv-AQ". Given the discussion that we had few weeks ago on using a SPARQL end point to query provenance that is encoded using provo. I would add PROVO as well to that sentence.
-
-- Fourth public working draft -> Fifth working draft
-
-- 1.1 Structure of the document. "... which are allows users" -> "which allow users"
-
-- 2.2 Generation, Usage, Derivation
-In the definition of Usage it is said that "Before usage, the activity had not begun to consume or use this entity and could not have been affected by the entity". I note that this sentence assumes that an entity can be used only once by an activity. In practice, the same activity can use the same entity, for example with different roles.
-
-- The usage example states situations in which the usage implies that the activity consumes the entity, and others in which the entity remains intact. Will is be useful to distinguich these two kinds of usage explicitly, by specializing the usage relation? In particular, I note that the notion of consumption entails interesting properties such as the invalidation of an entity and the fact that an entity can be consumed by at most one activity.
-
-- 3.1 Illustration of PROV-DM by an example.
-I find this section hard to read, and this is not the first time I read it. I think its readability can be improved if the following comments are considered. - In the text, the first and second working draft are referred using identifiers that are not intuitive, tr:WD-prov-dm-201.... I am not suggesting not to use them, but to specify whether they represent the first or the second working draft, whenever they are used in the text. - The figure given at the end of Sectio 3.1 can be more helpful in guiding the reader if it placed earlier in that section. - Talkiing about the figure the fact there are two arrows that link an arrow to a class, I understand their meaning, by I am not sure the reader will. - Section 3.2 giving information about the provenance form the author point of view seems to be simpler, and I think it would be better to start by the provenance from the author point of view before presenting the provenance from the process point of view.
+ >
+ > - In the beginning of the working draft "How to read the PROV Family",
+ > it is said that "Developers seeking to retrieve or publish
+ > provenance should focus *on* PROv-AQ". Given the discussion that we
+ > had few weeks ago on using a SPARQL end point to query provenance
+ > that is encoded using provo. I would add PROVO as well to that
+ > sentence.
-- 4: PROV-DM Types and Relations
-I am not sure the notion of component helps in the readability of the document. Refering to component1, component 2, etc. in the text is not helpful. I guess the only justification of using the term component is Figure PROV-DM component, which shows dependencies between those component. That said, I don't think that figure is helpful. It simply used to specify that one concept or a relation in a component depends on one concept or relation in another component. I note also that the term component is used in the text to refers to the definition elements in PROV-N. I would therefore suggest not ti use the notion of component, and rather use directly heading such as "Entity, Activity and their Relations", "Agent and their Responsibility", etc.
-
-- One of the consequence of trying to structure the model into component, is the fact that the reader will have to read the details of communication and start by activity, before reaching the definition of agent, responsibility and derivation, which are far more important for the ordinary reader. That said, I think the starting point which are in the beginning of the document already introduced the main concepts and relations.
-
-- 4.1.8 Start by Activity
-In the example given it is not explained why a2 was started by a1. There is an assumption that the reader will understand that a sub-workflow will be started by the parent workflow. I think this should explicitly stated.
+OK
+ >
+ > - Fourth public working draft -> Fifth working draft
+ >
-- 4.4.1 Specialization
-In the first paragraph: "common entity" -> "common thing"
+it's still the fourth *public* WD.
--4.5 Component 5: Collections
-I think that there is a need for defining collection here.
-Although it is stated that a collection is an entity. I feel there is a need for specifying what the members of a collection are as part of the collection specification, even when the specification of those members is optional.
-The membership relation fulfills the above requirements only partly, it is meant to specify a subset of the members that belong to a collection, not necessarily all of them.
-Therefore, I would suggest using a dedicated chracterizing attribute "members" for entities that happen to be collections.
-For example, we can define a collection c1 as
-entity (c1, [prov:type="Collection", prov:members = {<k1,v1>,...,<kn,vn>}]
+ > - 1.1 Structure of the document. "... which are allows users" -> "which allow users"
+
+yes.
+
+ >
+ > - 2.2 Generation, Usage, Derivation In the definition of Usage it is
+ > said that "Before usage, the activity had not begun to consume or use
+ > this entity and could not have been affected by the entity". I note
+ > that this sentence assumes that an entity can be used only once by an
+ > activity. In practice, the same activity can use the same entity, for
+ > example with different roles.
+
+Is this implied by consumption? Then, yes, it was not the intent.
+Utilise? instead.
+
+ >
+ > - The usage example states situations in which the usage implies that
+ > the activity consumes the entity, and others in which the entity
+ > remains intact. Will is be useful to distinguich these two kinds of
+ > usage explicitly, by specializing the usage relation? In particular,
+ > I note that the notion of consumption entails interesting properties
+ > such as the invalidation of an entity and the fact that an entity
+ > can be consumed by at most one activity.
+
+This is ISSUE=23:
+http://www.w3.org/2011/prov/track/issues/23
+
+
+ >
+ > - 3.1 Illustration of PROV-DM by an example. I find this section hard
+ > to read, and this is not the first time I read it. I think its
+ > readability can be improved if the following comments are
+ > considered. - In the text, the first and second working draft are
+ > referred using identifiers that are not intuitive,
+ > tr:WD-prov-dm-201.... I am not suggesting not to use them, but to
+ > specify whether they represent the first or the second working draft,
+ > whenever they are used in the text. - The figure given at the end of
+ > Sectio 3.1 can be more helpful in guiding the reader if it placed
+ > earlier in that section. - Talkiing about the figure the fact there
+ > are two arrows that link an arrow to a class, I understand their
+ > meaning, by I am not sure the reader will. - Section 3.2 giving
+
+I don't understand what is being referred to.
+
+ > information about the provenance form the author point of view seems
+ > to be simpler, and I think it would be better to start by the
+ > provenance from the author point of view before presenting the
+ > provenance from the process point of view.
+ >
+
+We could start with the author view.
+
+
+ > - 4: PROV-DM Types and Relations I am not sure the notion of component
+ > helps in the readability of the document. Refering to component1,
+ > component 2, etc. in the text is not helpful. I guess the only
+ > justification of using the term component is Figure PROV-DM component,
+ > which shows dependencies between those component. That said, I don't
+ > think that figure is helpful. It simply used to specify that one
+ > concept or a relation in a component depends on one concept or
+ > relation in another component. I note also that the term component is
+ > used in the text to refers to the definition elements in PROV-N. I
+
+I don't think so, we use the term constituent.
+
+ > would therefore suggest not ti use the notion of component, and rather
+ > use directly heading such as "Entity, Activity and their Relations",
+ > "Agent and their Responsibility", etc.
+
+It's useful to have groupings of concepts, to give some structure to the dm.
+The term component is reasonable for this.
+
+ >
+ > - One of the consequence of trying to structure the model into
+ > component, is the fact that the reader will have to read the details
+ > of communication and start by activity, before reaching the
+ > definition of agent, responsibility and derivation, which are far
+ > more important for the ordinary reader. That said, I think the
+ > starting point which are in the beginning of the document already
+ > introduced the main concepts and relations.
+
+'far more important' is a very relative concepts. Some may not want
+to express derivation, some may not want to express responsibility.
+
+Having thought about it a lot, it is not clear what other logical
+order to follow.
+
+
+ >
+ > - 4.1.8 Start by Activity In the example given it is not explained why
+ > a2 was started by a1. There is an assumption that the reader will
+ > understand that a sub-workflow will be started by the parent
+ > workflow. I think this should explicitly stated.
+ >
+ > - 4.4.1 Specialization In the first paragraph: "common entity" ->
+ > "common thing"
+ >
+ > -4.5 Component 5: Collections I think that there is a need for
+ > defining collection here. Although it is stated that a collection is
+ > an entity. I feel there is a need for specifying what the members of a
+ > collection are as part of the collection specification, even when the
+ > specification of those members is optional. The membership relation
+ > fulfills the above requirements only partly, it is meant to specify a
+ > subset of the members that belong to a collection, not necessarily all
+ > of them. Therefore, I would suggest using a dedicated chracterizing
+ > attribute "members" for entities that happen to be collections.
+ >
+ > For example, we can define a collection c1 as
+ > entity (c1, [prov:type="Collection", prov:members = {<k1,v1>,...,<kn,vn>}]
+ >