--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-274-gk.txt Mon Mar 12 12:06:12 2012 +0000
@@ -0,0 +1,247 @@
+ > Summary: I think the content is generally a big improvement, but there
+ > are some possible further removals, and I think there remain a number
+ > of document quality issues to be addressed before getting to last
+ > call. Hopefully, these can be considered in DM5
+ >
+ > When the content stabilizes, I may offer some alternate drafting
+ > suggestions, but I think it's in too much flux right now for that to
+ > be worthwhile.
+ >
+ > ...
+ >
+ > Re: http://dvcs.w3.org/hg/prov/raw-file/f52c0bb53dd4/model/prov-dm.html
+ > (Retrieved 2012-30-08)
+ >
+ > I'd wish to see all references to "things in the world" expunged: it's
+ > an ugly expression that begs more questions than it answers, and IMO
+ > runs the risk of confusing readers.
+ >
+ > Section 1 intro: rewording in 1st 3 paras.
+ >
+ > Suggest that the provenance notation be a part 1 appendix, not a
+ > separate part/document. Drop references to ASN - it's *not* an
+ > *abstract* syntax notion; indeed, I think that very expression is an
+ > oxymoron.
+ >
+ > Part 2 is *not* an upgrade path. Please don't say this. (It's a
+ > refinement of use that allows provenance information from different
+ > sources to be combined in meaningful ways.)
+ >
+ > More text refinement in section 1.
+ >
+ >
+ > Section 2.1
+ >
+ > Saying "Activity is anything ..." is confusing. It suggests a
+ > continuant rather than an occurrent.
+ >
+ > Sub-editing would improve this.
+ >
+ >
+ > Section 2.2
+ >
+ > I think it would be clearer if generation and usage were introduced as
+ > events associated with activities. (Discussion of them being
+ > instantaneous can come in Part 2)
+ >
+ > Introducing generation as "completed production" reads really
+ > strangely to me, and sounds as if it could be a produced artifact. I
+ > think a form like "completion of production" is clearer. Similarly
+ > for usage, something like "starting to consume".
+ >
+ > Sub-editing would improve this.
+ >
+ >
+ > Section 2.3:
+ >
+ > "AccountEntity" - why not just "Account". Also, I understood this was
+ > to *be* a bundle, not a container for a bundle.
+ >
+ > The example given has no clear relationship to the description. I
+ > understood the key use-case here was to express provenance of
+ > procenance, and that is why we have accounts. I think that should be
+ > stated clearly; e.g.
+ >
+ > "An account is a bundle of provenance statements treated as an entity
+ > which may itself have some associated provenance."
+ >
+ >
+ > Agents. I think the notion of responsibility here is so loose as to
+ > be of no practical value. When we say a text editor is "responsible
+ > for" crashing a computer, that's a kind of anthropomorphism, not a
+ > literal claim of responsibility. What we really mean is that the text
+ > editor caused the crash. The notion of responsibility is generally
+ > associated with duty, authority and/or accountability
+ > (cf. http://oxforddictionaries.com/definition/responsibility?view=uk).
+ > This is why persons and organizations are distinct from software
+ > agents. I suggest that the text here should "stick to the knitting":
+ > just state that these are commonly encountered kinds of agent, and
+ > leave it at that.
+ >
+ >
+ > Section 2.4
+ >
+ > This continues the muddle about "responsibility", until the definition
+ > of agent responsibility realtion which seems about right to me (note
+ > the phrase "accountable for" here).
+ >
+ > The use of responsibility in the description of association seems
+ > completely wrong to me.
+ >
+ > The discussion of activity association is surreal. A plan is defined
+ > previously as an "Entity", but association relates an *agent* to an
+ > activity.
+ >
+ > I think this section needs re-drafting.
+ >
+ >
+ > Section 2.5
+ >
+ > I think the intent and content of the diagram is generally good, but
+ > that its visual presentation could usefully be improved. I think it
+ > should appear as part of the introduction to section 2, not at the
+ > end.
+ >
+ >
+ > Generally in section 2, I think the examples are mostly well-chosen,
+ > but their presentation breaks up the flow of the overview; I woukd
+ > prefer that the examples were more succinct, maybe fewer, and
+ > introduced inline in the descriptive overview text. Ideally the whole
+ > overview would fit on just one or two pages (i.e. about half its
+ > current length on a printed page). The key purpose here, IMO, is to
+ > give a quick overview of how the various concepts are used together.
+ >
+ >
+ > Section 3:
+ >
+ > I don't find this example at all helpful. It requires too much effort
+ > to understand, and I find the process view vs author view is
+ > confusing. What is this section actually trying to tell the reader?
+ > I can't tell.
+ >
+ > I think a comprehensive example like this would be better sited as an
+ > appendix, rather than an interruption to the main flow of the
+ > document.
+ >
+ >
+ > Section 4.1:
+ >
+ > I find the sub-heading "Element" is confusing/unhelpful.
+ >
+ >
+ > Section 4.1.1 - verbatim repetition of text defining "Entity" already
+ > present in section - this is unhelpful.
+ >
+ > The description of the provenance notation expressions should use the
+ > same terms as are used in the template presented; i.e.. *not* "[
+ > attr=val1, ... ]" and "attributes".
+ >
+ > Don't need to say anything about disjointness of entities and
+ > activities in Part 1.
+ >
+ >
+ > Secftion 4.1.2
+ >
+ > Similar comments to section 4.1.1
+ >
+ > (But I think the simple statement "An activity is not an entity ..."
+ > is good.)
+ >
+ >
+ > Section 4.1.3
+ >
+ > Similar comments to section 4.1.1
+ >
+ > Don't need to say why sub-categories of agent are introduced.
+ >
+ > I would probably avoid making the mutual exclusivity claim (legally,
+ > it may be or become a debatable point).
+ >
+ >
+ > Section 4.1.4
+ >
+ > I don't see that notes are an essential part of the provenance
+ > structure. I'd prefer to drop them, as I don't see them adding any
+ > expressive capability.
+ >
+ >
+ > Section 4.2
+ >
+ > The table of different relation domain and range combinations is fair
+ > enough, but I'm not convinced the additional level of document
+ > structure reflecting this is useful.
+ >
+ > Ideally, I think the relations would all appear at the same document
+ > level as the concepts, so they have a similar "visual signature" when
+ > scanning the document.
+ >
+ > Most or all subsections have repetition of text from section 2 similar
+ > to that noted for section 4.1.1
+ >
+ > Also, most sections seem to suffer from a similar mismatch between the
+ > provenance notation template given and the accompanying description of
+ > the constituent elements.
+ >
+ > I think generation and usage should be described as events (not
+ > necxessarily to introduce a formal notion of events, just make it
+ > clear that they are events corresponding to some change in the
+ > relationship between an entity and an activity)
+ >
+ >
+ > Section 4.2.2.1
+ >
+ > "Responsibility" again.
+ >
+ > There are two things going on here that I feel are very muddled:
+ >
+ > (a) this rather odd notion of responsibility, and
+ >
+ > (b) associating a plan with an activity.
+ >
+ > At the very least, I think these aspects should be separated, not just
+ > lumped into an single overloaded element.
+ >
+ > I'm not sure why some expression components are explicit and possibly
+ > optional parameters, while athewrs are attributes. What's the
+ > intended difference here?
+ >
+ >
+ > Section 4.2.3.1
+ >
+ > Responsibility again. In this case, I think there may be some
+ > justification for talking about responsibility, but earlier treatment
+ > of this idea makes it hard for me to know what is really being
+ > expressed. I think it is the notion that some actions of one agent
+ > are authorized or controlled by another agent in the context of a
+ > given activity, hence any accountability for the outcome may propagate
+ > back to the controlling or authorizing agent. But that's not entirely
+ > clear to me from the text.
+ >
+ > Also, I can't tell if the structures here would accommodate different
+ > agents having different responsibilities. E.g. a manager authorizes
+ > an engineer to purchase a component, but is then instructed by the
+ > engineer in its deployment/installation... when the component fails
+ > to achieve some required outcome, who is accountable? The manager for
+ > not authorizing enough funds, or the engineer for not properly
+ > explaining how to use the component?
+ >
+ >
+ > Section 4.2.3.2
+ >
+ > Skipped - I understand this is due to be replaced. (Despite my
+ > reservations expressed elsewhere, the replacement looks like a
+ > significant improvement.)
+ >
+ >
+ > Section 4.2.3.3
+ >
+ > Do we still need Alternate and Specialization in the provenance
+ > notation?
+ >
+ > ...
+ >
+ > I'm running out of time, so I'll stop here.
+ >
+ >
+ >
+ >
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-274-sam.txt Mon Mar 12 12:06:12 2012 +0000
@@ -0,0 +1,259 @@
+ > Hello Luc,
+ >
+ >
+ >
+ > I send my review for PROV-DM again, because I am not sure you received
+ > it. Two weeks ago, I posted this to the prov mailing list, but with a
+ > different email address than the one I am listed on at W3C, because of
+ > a mail server crash. Because of this, it took some days before it was
+ > distributed to the PROV list. This is, I think, the reason my review
+ > wasn`t good received.
+ >
+ >
+ >
+ > In mean time, the mail server is up again and if you want I can send
+ > it again to the prov mailing list, this time using the right email
+ > address.
+ >
+ >
+ >
+ > Best,
+ >
+ >
+ >
+ > Sam
+ >
+ >
+ >
+ > --
+ > Sam Coppens
+ >
+ > Ghent University - IBBT
+ > Faculty of Engineering
+ > Department of Electronics and Information Systems
+ > Multimedia Lab
+ >
+ > Gaston Crommenlaan 8 bus 201
+ > B-9050 Ledeberg-Ghent
+ > Belgium
+ >
+ > t: +32 9 33 14959
+ > f: +32 9 33 14896
+ > t secr: +32 9 33 14911
+ > e: sam.coppens@ugent.be or samcoppens@hotmail.com
+ >
+ >
+ > URL: http://multimedialab.elis.ugent.be
+ >
+ >
+ >
+ > From: Sam Coppens UGent [mailto:sam.coppens@ugent.be]
+ > Sent: Thursday, March 01, 2012 10:38 AM
+ > To: 'public-prov-wg@w3.org'
+ > Subject: Review of Provenance DM documents
+ >
+ >
+ >
+ > Hello,
+ >
+ >
+ >
+ > Here is my review of the PROV-DM documents.
+ >
+ >
+ >
+ > Best,
+ >
+ >
+ >
+ > Sam
+ >
+ >
+ >
+ >
+ >
+ > In general:
+ >
+ > The overall structure of the document is very clear and things are now
+ > nicely separated (data model, its constraints and its expression in
+ > PROV-ASN). This allows to find faster the information needed.
+ >
+ > All three documents are well written and understandable. In general, I
+ > would say it is a very good improvement over the previous version
+ > where everything was in 1 document. I would recommend this version to
+ > become the editor`s draft.
+ >
+ >
+ >
+ > PROV-DM part 1:
+ >
+ >
+ >
+ > General Remarks:
+ >
+ >
+ >
+ > In Section 1 , the paragraph right in front of section 1.1 talks about
+ > an `upgrade path` to enrich simple provenance with extra
+ > descriptions. The notion of an `upgrade path` must be clarified,
+ > because it is nowhere used in the remainder of the document, neither
+ > in PROV-DM part 2. It is confusing at the moment.
+ >
+ >
+ >
+ > Section 2, Subsection2.3: AccountEntity very shortly explained
+ > here. The notion of account is better specified in PROV-DM part
+ > 2. From the provided definition here it is not clear that the
+ > provenance of the same entity can be expressed as different
+ > accounts. The definition of AccountEntity also includes ` resource`,
+ > which is quite confusing, because it is not part of the provenance
+ > terminilogy. Maybe replace it by `Entity`.
+ >
+ >
+ >
+ >
+ >
+ >
+ >
+ > Section 4, Subsection 4.1.4: `A separate PROV-DM relation is used to
+ > associate a note with something that is identifiable (see Section on
+ > annotation). A given note may be associated with multiple identifiable
+ > things.` `Things` is confusing here. It is maybe better to say entity
+ > and/or activity. `Thing` brings in some semantics.
+ >
+ >
+ >
+ > Section 5, Subsection 5.7: The added value of `Original Source` over
+ > `Traceability` is not clear. It should be better explained why we need
+ > this relation. IMO, it could be expressed as a traceability relation
+ > or a specialization of the traceability relation.
+ >
+ >
+ >
+ > Spelling Corrections:
+ >
+ >
+ >
+ > Section 2, Subsection 2.1: Activity definition: two phrases after each
+ > other are the same: `An activity is anything that can operate on
+ > entities. In particular, activities may produce, consume, or transform
+ > an entity. Activities that operate on digital entities may for example
+ > move, copy, or duplicate them. Activities that operate on digital
+ > entities may for example move, copy, or duplicate them.`
+ >
+ >
+ >
+ > Section 2, Subsection 2.2: Usage definition: Usage is the beginning on
+ > an entity being consumed by an activity. Before usage, the activity
+ > had not begun to consume or use to this entity (and could not have
+ > been affected by the entity).
+ >
+ >
+ >
+ > Section 4, Subsection 4.1.4: example: `The note is associated with the
+ > entity tr:WD-prov-dm-20111215 previously introduced (hasAnnotation is
+ > discussed in Section Annotation). The note's identifier and attributes
+ > are declares declared in a separate namespace denoted by prefix ex2.`
+ >
+ >
+ >
+ >
+ >
+ > PROV-DM part 2:
+ >
+ >
+ >
+ > General Remarks:
+ >
+ >
+ >
+ > Section 1 & Section 2: These two sections are further refinements of
+ > the already explained data model. IMO, these sections could be
+ > included in PROV-DM part 1. The event based perspective on provenance
+ > is part of the core prov-dm model. Then PROV-DM part 2 focusses on the
+ > additional constraints.
+ >
+ >
+ >
+ > Section 2, Subsection 2.2: The example of different perspectives on a
+ > resource with a URL is essential in making accounts of provenance
+ > clear. What still needs some attention in the document is the relation
+ > entity – entity record and how they are identified and which of these
+ > two identifiers are referred to when pointing to an entity. An example
+ > would make it clear. (maybe PROV-DM part 1 is a better place to
+ > explain this)
+ >
+ >
+ >
+ > Spelling Corrections:
+ >
+ >
+ >
+ > Section 4, Intro: In this section, we revisit elements and relations
+ > of PROV-DM, and examine and examine the constraints associated with
+ > their definitions.
+ >
+ >
+ >
+ > Section 4, Subsection 4.2.1: This entity become becomes available for
+ > usage after this instantaneous event.
+ >
+ >
+ >
+ > Section 4, Subsection 4.2.6: precise-1 derivation is richer than an
+ > imprecise-1 derivation, itself, being more informative that an
+ > imprecise-n derivation. Hence, the following implications hold.
+ >
+ >
+ >
+ > Section 6, Intro: We anticipate that verification algorithms could be
+ > developedm, though this verification is outside the scope of this
+ > specification.
+ >
+ >
+ >
+ >
+ >
+ > PROV-DM part 3:
+ >
+ >
+ >
+ > General Remarks:
+ >
+ >
+ >
+ > No Remarks.
+ >
+ >
+ >
+ > Spelling Corrections:
+ >
+ >
+ >
+ > Section 3, Subsection 3.2.7: `A specialization relation`s text matches
+ > the specializationExpression production.`
+ >
+ >
+ >
+ > --
+ > Sam Coppens
+ >
+ > Ghent University - IBBT
+ > Faculty of Engineering
+ > Department of Electronics and Information Systems
+ > Multimedia Lab
+ >
+ > Gaston Crommenlaan 8 bus 201
+ > B-9050 Ledeberg-Ghent
+ > Belgium
+ >
+ > t: +32 9 33 14959
+ > f: +32 9 33 14896
+ > t secr: +32 9 33 14911
+ > e: sam.coppens@ugent.be or samcoppens@hotmail.com
+ >
+ >
+ > URL: http://multimedialab.elis.ugent.be
+ >
+ >
+ >