--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-409-daniel.txt Tue Jun 19 13:17:52 2012 -0700
@@ -0,0 +1,183 @@
+Hi Luc, all.
+I have gone through the latest draft. I think you and Paolo have done a very good job. You will find my feedback below,
+although I just realize that some of my points overlap with the ones posted by Khalid.
+Best,
+Daniel.
+
+Document reviewed: http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120614/prov-dm.html
+
+Questions for the reviewers:
+
+ 1. Can the document be released as a WD? Yes, but take into account the comments about contextualization (I think it is not necessary)
+ 2. Can the document be released as a last call WD? Same response as the previous one.
+ 3. Renaming wasRevisionOf to wasRevisedFrom? +0. Both terms are ok.
+ 4. Primitive datatypes. Do we have to list them all? I think that for prov types makes sense, but table 8 is unnecessary.
+
+Detailed feedback:
+
+Abstract:
+ Provenance is information about entities, activities, and people, involved in producing a piece of data or thing.
+I think that:
+ Provenance is information about entities, activities and people involved in producing a piece of data or thing
+is easier to read.
+
+STATUS:
+PROV-O is not an OWL-RL profile completely. The prov-o team decided to relax a bit the constraints in order to be able to be closer to prov dm.
+
+2. PROV Overview:
+"A provenance description is an instance of a core and extended provenance structure described below. "
+ I don't understand very well this sentence. Provenance description is referred to a lot of times along the document, but the only definition I found was this sentence. Please clarify.
+2.1 Prov Core structures
+Typo: the title of figure 1 is not placed under the figure.
+
+"In the Core of PROV, all relations are binary".
+So we have 2 different relationships for qualifications? are used (a1, e1) and used(a1, e1, [ prov:role="inpu1" ]) different?
+This is what it looks when you read this line, and in DM both usages are the same relation. Thus I suggest to remove the binary vs n-ary distinction.
+
+2.1.1
+"In PROV, things we want to describe the provenance of are called entities and have some fixed aspect."
+I would change sentence to "In PROV, things we want to describe the provenance of are called entities.", since you are not saying what a "some fixed aspect" is.
+
+In usage definition, the activity could not have been affected by the enitity. I remember discussing in PROV-O scenarios where an activity uses the same entity twice with different roles to produce different results. According to this definition, that scenario would not be possible. Therefore I suggest to remove the "affected" part of the definition. This also applies for section 5.1.4.
+
+(After example 3)
+"This is answered by considering that a single artifact may correspond to several entities;"
+We have not talked about artifact until now. I suggest to change "artifact" with "thing", which has been already used befor in the examples.
+We find the artifact reference again at the end of the paragraph : "This breadth of provenance allows descriptions of interactions between physical and digital artifacts"
+
+2.2.2
+Example 13 is not an example, it is just an explanation of the definition. I suggest to rephrase it as an example (one could be having many provenance descriptions about a resource, and a client that wants to see who did them in order to filter them by creator or date of creation)
+
+Section 3
+"PROV-N optional arguments need not be specified:"
+->
+typo: PROV-N optional arguments need not TO be specified:
+
+4.1
+Caption of figure 2 is out of place. Also happens in figure 3 (section 4.2).
+
+5
+Table 5. I think there is a typo with Revision, Quotation and Primary Source. They do not appear as relationships.
+
+Figure 5: the title is not centered under the figure.
+
+5.2 (Derivations).
+The third component of PROV-DM is concerned with: derivations of entities from others, ...
+I suggest to change slightly the sentence:
+The third component of PROV-DM is concerned with: derivations of entities from other entities, ...
+
+Caption of Figure 6 is not under the figure.
+Caption of Figure 7 is not under the figure.
+
+Typo in Example 34: instead of using prov:role, the example uses prov:type
+
+Figure 8: the caption is not under the figure.
+
+Figure 9: the caption is not under the figure.
+
+5.5.3: Contextualization
+I'm not entirely convinced with this section. It reminds me a lot to what the accounts were trying to do, and we decided to leave accounts
+out of the DM because they making the model complex.
+
+Example 45, could be modeled without contextualization by just pinning the rating to the activity and the agent. The rating tool could
+just say: ex:Bob ex:hadGoodPerformanceIn ex:a1.
+
+In example 46, I don't see why do I have to create a different entity for asserting the triples about the rendering. I would just reuse
+the entity I had in the first bundle. Since the triples are asserted in different bundles, I can allways filter the statements about
+an entity depending on the bundle it belongs to. I thought that the bundles were there for doing that too.
+
+From a usability point of view, contextualization makes it difficult to retrieve provenance information about an entity, IMO.
+
+However I haven't been participating actively on the discussions about this in the mailing list, so I don't disagree on having it.
+I just think that it overcomplicates the model, and I don't think I'll use it.
+
+Figure 10: the caption is not under the figure.
+
+Example 54: in the example, it should be Le louvre instead of Le Louvres, right?
+
+Note after Example 57: No, I don't think prov:encoding is necessary. That is domain specific.
+
+I don't think table 8 is necessary. It would be enough to say that the prov:values are compatible with the xsd stanndard.
+
+2012/6/17 Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>
+
+ Hi,
+
+ I read the new draft of the prov-dm. You will find my comments below.
+ Regarding the question of the editors about conceptualization. I am no opposed to its presence in the DM, but its definition should be simplified substantially (see the comments below).
+
+ Regards, khalid
+
+ -----------
+ - In the beginning of the document (PROC Family Specification), it is stated that "PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF". I am not sure that PROVO is entirely 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.
+
+ - 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.
+
+ - In the introduction, in the list that describes the components, there is a mismatch between this list and the components in the table of contents: according to the list in the introduction, 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.
+
+ - Section 2 is supposed to be an overview, but it is quite long.
+
+ - Section 2 makes the difference between binary and expanded relations. I am not sure this makes sense in the context of the DM. It was introduced in PROV-O, because the language we are using is not expressive enough for specifying n-ary relations in a natural way. This is not the case for PROV-DM, PROV-N allow expressing such relations without a problem. Also, reading the section on Expanded 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.
+
+ - In Section 2, when explaining "Usage", it is said that "Usage is the beginning of utilizing an entity by an activity. Before usage, the activity had not begun to utilize this entity and could not have 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).
+
+ - 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 journey is a possible interpretation, and I don't think it is the 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.
+
+ - In Section 2.1.3, first paragraph: "more trustworthy that that from a lobby organization" -> "more trustworthy than that from a lobby organization"
+
+ - 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.
+
+ - 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.
+
+ - The column "Core Structures", in Table 3, is confusing. components 1, 2 and 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!
+
+ - In the definition of communication, Section 5.1.5, it is stated that "Communication is the exchange of an unspecified entity". Why do we require that the entity should be unspecified. Aren't we restricting who may want to specify the entity (or entities) exchanged between 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".
+
+ - I notice that Invalidation (Section 5.1.8), is not present in Figure 5.
+
+ - In section 5.2 (Component 2: Derivations), the first sentence in this section says "The third component".
+
+ - I find the definition of "Primary Source", hard to follow. Can we simplify it?
+
+ - In the definition of delegation, the activity is an optional argument. What is the semantics of delegation when the activity is not specified. I suspect that it means that the activity for which 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.
+
+ - 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".
+
+ - 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"?
+
+ - 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 domain-specific manner". This is not reflected in the definition of bundle, which form my understanding, aggregate a number of provenance descriptions that happen (by accident) to be in a bundle, e.g., a file. The notion of context and domain dependency introduced in contextualization seems to assume that a bundle contains provenance description within the bundle are domain dependent and that they have been specified within a given context. The notion of context is also loose, and cam mean different things to different people.
+
+ Now, looking at example 45, it may be that what the first paragraphs in Section 5.5.3 are misleading, and that the purpose is to have something simple. If the objective is basically to specify that a given entity e1 is a specialization of another entity e2 and to be able to locate the bundle in which e2 is described, then we should just do that. In other words, we should use "specializationOf", and add a construct that specify the bundle in which a given entity is described, e.g., isDescribedIn(e2,bundle2)?
+
+ Therefore, to answer the question that the editor asked regarding contextualization, I do not oppose its presence in the DM, but I think it definition should be simplified substantially to reflect the way it will be used in practice. I would also urge the editors to avoid using the term contextualization as it is vague.
+
+ - 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 not the main one. Collection is a general contruct, and we should allow people to contruct collections that contains duplicate entities with different or same identifiers.
+
+
+ On 14 June 2012 12:07, Provenance Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
+
+ PROV-ISSUE-409 (prov-dm-review-LC): feedback on PROV-DM document (for last call release) [prov-dm]
+
+ http://www.w3.org/2011/prov/track/issues/409
+
+ Raised by: Luc Moreau
+ On product: prov-dm
+
+
+ This is the issue to collect feedback on the prov-dm document.
+
+ Document to review is available from:
+
+ http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120614/prov-dm.html
+
+ Question for reviewers: http://www.w3.org/2011/prov/wiki/Meetings:Telecon2012.06.14
+
+ Cheers,
+ Luc
+
+
+
+
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-409-khalid.txt Tue Jun 19 13:17:52 2012 -0700
@@ -0,0 +1,179 @@
+Hi,
+
+I read the new draft of the prov-dm. You will find my comments below.
+Regarding the question of the editors about conceptualization. I am no opposed to its presence in the DM, but its definition should be simplified substantially (see the comments below).
+
+Regards, khalid
+
+-----------
+- In the beginning of the document (PROC Family Specification), it is stated that "PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF". I am not sure that PROVO is entirely 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.
+
+- 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.
+
+- In the introduction, in the list that describes the components, there is a mismatch between this list and the components in the table of contents: according to the list in the introduction, 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.
+
+- Section 2 is supposed to be an overview, but it is quite long.
+
+- Section 2 makes the difference between binary and expanded relations. I am not sure this makes sense in the context of the DM. It was introduced in PROV-O, because the language we are using is not expressive enough for specifying n-ary relations in a natural way. This is not the case for PROV-DM, PROV-N allow expressing such relations without a problem. Also, reading the section on Expanded 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.
+
+- In Section 2, when explaining "Usage", it is said that "Usage is the beginning of utilizing an entity by an activity. Before usage, the activity had not begun to utilize this entity and could not have 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).
+
+- 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 journey is a possible interpretation, and I don't think it is the 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.
+
+- In Section 2.1.3, first paragraph: "more trustworthy that that from a lobby organization" -> "more trustworthy than that from a lobby organization"
+
+- 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.
+
+- 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.
+
+- The column "Core Structures", in Table 3, is confusing. components 1, 2 and 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!
+
+- In the definition of communication, Section 5.1.5, it is stated that "Communication is the exchange of an unspecified entity". Why do we require that the entity should be unspecified. Aren't we restricting who may want to specify the entity (or entities) exchanged between 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".
+
+- I notice that Invalidation (Section 5.1.8), is not present in Figure 5.
+
+- In section 5.2 (Component 2: Derivations), the first sentence in this section says "The third component".
+
+- I find the definition of "Primary Source", hard to follow. Can we simplify it?
+
+- In the definition of delegation, the activity is an optional argument. What is the semantics of delegation when the activity is not specified. I suspect that it means that the activity for which 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.
+
+- 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".
+
+- 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"?
+
+- 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 domain-specific manner". This is not reflected in the definition of bundle, which form my understanding, aggregate a number of provenance descriptions that happen (by accident) to be in a bundle, e.g., a file. The notion of context and domain dependency introduced in contextualization seems to assume that a bundle contains provenance description within the bundle are domain dependent and that they have been specified within a given context. The notion of context is also loose, and cam mean different things to different people.
+
+Now, looking at example 45, it may be that what the first paragraphs in Section 5.5.3 are misleading, and that the purpose is to have something simple. If the objective is basically to specify that a given entity e1 is a specialization of another entity e2 and to be able to locate the bundle in which e2 is described, then we should just do that. In other words, we should use "specializationOf", and add a construct that specify the bundle in which a given entity is described, e.g., isDescribedIn(e2,bundle2)?
+
+Therefore, to answer the question that the editor asked regarding contextualization, I do not oppose its presence in the DM, but I think it definition should be simplified substantially to reflect the way it will be used in practice. I would also urge the editors to avoid using the term contextualization as it is vague.
+
+- 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 not the main one. Collection is a general contruct, and we should allow people to contruct collections that contains duplicate entities with different or same identifiers.
+
+
+On 14 June 2012 12:07, Provenance Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
+
+ PROV-ISSUE-409 (prov-dm-review-LC): feedback on PROV-DM document (for last call release) [prov-dm]
+
+ http://www.w3.org/2011/prov/track/issues/409
+
+ Raised by: Luc Moreau
+ On product: prov-dm
+
+
+ This is the issue to collect feedback on the prov-dm document.
+
+ Document to review is available from:
+
+ http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120614/prov-dm.html
+
+ Question for reviewers: http://www.w3.org/2011/prov/wiki/Meetings:Telecon2012.06.14
+
+ Cheers,
+ Luc
+
+
+
+
+----------------------------------------------------------------------
+
+
+
+Hi,
+
+I realized that I didn't answer all the questions that were asked by the editors in my review. You will find them below.
+
+Thanks, khalid
+
+ 1. Can the document be released as a WD? Yes, provided that contextualization definition is amended in the light of the comments below.
+ 2. Can the document be released as a last call WD? Yes
+ 3. Renaming wasRevisionOf to wasRevisedFrom? It is fine with me either ways
+ 4. Primitive datatypes. Do we have to list them all? I think it would be good, but I wouldn't say they are mandatory.
+
+
+ 2012/6/17 Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>
+
+ Hi,
+
+ I read the new draft of the prov-dm. You will find my comments below.
+ Regarding the question of the editors about conceptualization. I am no opposed to its presence in the DM, but its definition should be simplified substantially (see the comments below).
+
+ Regards, khalid
+
+ -----------
+ - In the beginning of the document (PROC Family Specification), it is stated that "PROV-O, the PROV ontology, an OWL-RL ontology allowing the mapping of PROV to RDF". I am not sure that PROVO is entirely 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.
+
+ - 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.
+
+ - In the introduction, in the list that describes the components, there is a mismatch between this list and the components in the table of contents: according to the list in the introduction, 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.
+
+ - Section 2 is supposed to be an overview, but it is quite long.
+
+ - Section 2 makes the difference between binary and expanded relations. I am not sure this makes sense in the context of the DM. It was introduced in PROV-O, because the language we are using is not expressive enough for specifying n-ary relations in a natural way. This is not the case for PROV-DM, PROV-N allow expressing such relations without a problem. Also, reading the section on Expanded 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.
+
+ - In Section 2, when explaining "Usage", it is said that "Usage is the beginning of utilizing an entity by an activity. Before usage, the activity had not begun to utilize this entity and could not have 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).
+
+ - 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 journey is a possible interpretation, and I don't think it is the 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.
+
+ - In Section 2.1.3, first paragraph: "more trustworthy that that from a lobby organization" -> "more trustworthy than that from a lobby organization"
+
+ - 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.
+
+ - 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.
+
+ - The column "Core Structures", in Table 3, is confusing. components 1, 2 and 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!
+
+ - In the definition of communication, Section 5.1.5, it is stated that "Communication is the exchange of an unspecified entity". Why do we require that the entity should be unspecified. Aren't we restricting who may want to specify the entity (or entities) exchanged between 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".
+
+ - I notice that Invalidation (Section 5.1.8), is not present in Figure 5.
+
+ - In section 5.2 (Component 2: Derivations), the first sentence in this section says "The third component".
+
+ - I find the definition of "Primary Source", hard to follow. Can we simplify it?
+
+ - In the definition of delegation, the activity is an optional argument. What is the semantics of delegation when the activity is not specified. I suspect that it means that the activity for which 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.
+
+ - 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".
+
+ - 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"?
+
+ - 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 domain-specific manner". This is not reflected in the definition of bundle, which form my understanding, aggregate a number of provenance descriptions that happen (by accident) to be in a bundle, e.g., a file. The notion of context and domain dependency introduced in contextualization seems to assume that a bundle contains provenance description within the bundle are domain dependent and that they have been specified within a given context. The notion of context is also loose, and cam mean different things to different people.
+
+ Now, looking at example 45, it may be that what the first paragraphs in Section 5.5.3 are misleading, and that the purpose is to have something simple. If the objective is basically to specify that a given entity e1 is a specialization of another entity e2 and to be able to locate the bundle in which e2 is described, then we should just do that. In other words, we should use "specializationOf", and add a construct that specify the bundle in which a given entity is described, e.g., isDescribedIn(e2,bundle2)?
+
+ Therefore, to answer the question that the editor asked regarding contextualization, I do not oppose its presence in the DM, but I think it definition should be simplified substantially to reflect the way it will be used in practice. I would also urge the editors to avoid using the term contextualization as it is vague.
+
+ - 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 not the main one. Collection is a general contruct, and we should allow people to contruct collections that contains duplicate entities with different or same identifiers.
+
+
+ On 14 June 2012 12:07, Provenance Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
+
+ PROV-ISSUE-409 (prov-dm-review-LC): feedback on PROV-DM document (for last call release) [prov-dm]
+
+ http://www.w3.org/2011/prov/track/issues/409
+
+ Raised by: Luc Moreau
+ On product: prov-dm
+
+
+ This is the issue to collect feedback on the prov-dm document.
+
+ Document to review is available from:
+
+ http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120614/prov-dm.html
+
+ Question for reviewers: http://www.w3.org/2011/prov/wiki/Meetings:Telecon2012.06.14
+
+ Cheers,
+ Luc
+
+
+
+
+
+
+