--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/lc-ack-robert.txt Fri Oct 26 12:20:02 2012 +0100
@@ -0,0 +1,263 @@
+ 1.1.2 ISSUE-525 (Specialization/Alternate)
+
+ I think my comment was misunderstood. Fig 8 in
+ http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html
+ shows the entity-entity relationship as the more general
+ "wasInfluencedBy" relationship, which is defined within that
+ figure to have an ID and attributes (gray box). This is also
+ stated in section 5.3.5. Section 5.5 defines SpecializationOf,
+ AlternateOf, and MentionOf, all of which are entity-entity
+ relationships. Therefore, it seems that specialization is a type
+ of influence and should therefore contain the ID/attributes
+ pattern. If this is not the case, the text may require
+ clarification.
+
+New change implemented.
+Further ack to obtain.
+
+ 1.1.4 ISSUE-504 (collection/bundle)
+
+ In my opinion, a prov description is as much a "thing in the
+ world" as an activity, attribution, or association (all of which
+ can have an ID). Applications that merge, aggregate, and/or infer
+ provenance will need to track the provenance of individual
+ statements; doing so will require an ID for each statement. It
+ should be noted that if descriptions cannot be given IDs directly,
+ they can (individually) be wrapped in a bundle but this is a
+ highly inefficient workaround.
+
+Suggested change implemented.
+Further response added.
+Given that this point has been debated at length (there is no support
+to introduce identifiers for individual prov statements), I propose
+to close this issue.
+
+ 1.1.5 ISSUE-503 (adopt plan)
+
+ The use case in question is simply indicating that a given plan
+ was adopted by a given entity (without necessarily specifying an
+ associated activity). It is not an influence, so wasDerivedFrom
+ and wasAttributedTo do not address the issue. The proposed OWL
+ solution (inverse hadPlan) is technology-specific and isn't quite
+ sufficient, as it requires an activity. I think I'm looking for
+ something similar to wasAssociatedWith, which allows one to
+ associate an activity (required) with an agent and/or plan
+ (optional). In this case, I want to link a plan (required) to an
+ agent (required) with an optional activity.
+
+Suggested change implemented.
+Further response added.
+
+ 1.1.15 ISSUE-516 (DerivationAsBundle) Section 5.2.1 states, "there
+ must be some underpinning activities performing the necessary
+ actions resulting in such a derivation". Note both "activities"
+ and "actions" are plural. The statement wasDerivedFrom, however,
+ allows only a single activity to be specified. Is derivation
+ intended to support multiple activities (as per the text), and if
+ so, are multiple statements necessary (one for each activity)?
+ The question about derivation as a bundle was based on the
+ impression that multiple activities might be part of "a
+ derivation" (as per the text).
+
+Clarification about activity/activities implemented.
+http://dvcs.w3.org/hg/prov/rev/65532a436d0c
+Acknowledgement expected.
+
+ 1.1.16 ISSUE-514 (Starter/EnderActivity) The new table helps. I
+ might suggest defining the significance of the terms in
+ parentheses within the table. Also, the agent column probably
+ could be deleted.
+
+Added cross-linking to attribute definitions.
+http://dvcs.w3.org/hg/prov/rev/a995233c4419
+Acknowledgement expected.
+
+ 1.1.12 ISSUE-528 (MentionOf) - I don't feel strongly about this.
+ The comment was in response to an editorial notation in the DM
+ inquiring whether this relation was necessary.
+
+I propose to close. Debate continues for issue-475.
+
+ 1.1.13 ISSUE-517 (Revision/Quotation) I agree that "The
+ definitions of Revision and Quotation are reasonably intuitive."
+ However, the line between the two is fuzzy and it should be
+ acknowledged that those creating provenance statements may face an
+ arbitrary choice between the two.
+
+I extended the response with "We acknowledge the reviewer's follow-on comment. Ultimately, the Working Group provides a vocabulary, and users of that Vocabulary will have to make judgement as to which constructs they have to use. This issue is not specific to revision and quotation. (e.g. What is entity? what is activity? Is this specialization or alternate? etc)"
+I propose to close.
+
+ 1.1.22 ISSUE-515 (Invalidation) Re: temporarily unavailable
+ entities. Thanks for the example. This may address the question.
+ Re: invalidation due to state change. The response by the working
+ group makes sense ("As a minimum, an entity must have a fixed
+ identity during its lifetime." and "some aspects, represented as
+ attributes, that do not change over that lifespan"). That
+ question was motivated by the traffic light example in the DM: "An
+ entity's lifetime can end for different reasons: ... an entity
+ attribute is changing: e.g. the traffic light changed from green
+ to red", then further down in the text "the traffic light became
+ red and therefore is regarded as a different entity to the green
+ light". In that example, the identity of the traffic light did
+ not change, and some attributes of the light remain constant;
+ therefore, it is difficult for me to understand why the state
+ change would invalidate the entity. This example seems to
+ contradict the working group's response to the question.
+
+TODO
+
+ 1.1.23 ISSUE-530 (attributes) I understand the group's difficulty
+ in reaching consensus on this issue. Since it is possible to
+ support these attributes via the optional user-defined attributes,
+ leaving them out of the spec will not prevent their use.
+ Variability in implementation is likely, however, so it might be
+ worthwhile to centralize these within an extension once
+ implementations have a chance to experiment with the spec.
+
+Added a comment:
+ In response to the follow-on message, the Working Group, as it wraps up its activities, will consider follow-on activities, and mechanisms for community to share information. The Semantic Web wiki is a starting point.
+
+I propose to close this issue.
+ 1.1.25 ISSUE-522 (Activity Delegation) There were two parts to my
+ comment. First, agents can be either entities or activities.
+ Does delegation apply to only those agents that are entities, or
+ can activity-agents also delegate? Second, the definition of
+ delegation includes only the delegate and responsible agents;
+ activity is optional. Therefore, it is possible to state that one
+ agent is the delegate of another, irrespective of any activity.
+ This delegation likely is not indefinite, however, and is bounded
+ by some context (e.g., time, role within an organization, etc).
+ It should be possible to describe the bounds of the delegation.
+ This might be done using user-defined attributes, but
+ interoperability would suffer without some guidance within the
+ spec.
+
+Added comment to address this point.
+
+ - It is true that, in a delegation, activity is optional. The reviewer suggests "Therefore, it is possible to state that one agent is the delegate of another, irrespective of any activity. This delegation likely is not indefinite, however, and is bounded by some context (e.g., time, role within an organization, etc). It should be possible to describe the bounds of the delegation.". But it is not the intended semantics:
+ o PROV constraints defines the semantics of optional arguments, and
+ specifically, in Table 3, explains that activity in delegation is
+ expandable.
+ o It means that an absent activity can be replaced by an
+ existential variable. Hence, actedOnBehalfOf(ag2,ag1) really means
+ that agent ag2 acted on behalf of agent ag1 in the context of some
+ unspecified activity. Some activity, not all activity.
+ o This (unspecified) activity defines the bounds of the
+ delegation. If these bounds need to be made explicit, than an
+ activity also needs to be made explicit.
+
+Acknowledgment expected
+
+ 1.1.27 ISSUE-526 (Alternate) The text in the working group's
+ response to this comment (see below) is helpful. It might be
+ beneficial to add this to the DM document.
+
+ "Note that alternateOf is a necessarily very general
+ relationship that, in reasoning, only tells you that the two
+ alternate entities fix different aspects of some common thing
+ (possibly evolving over time), and so there is some relevant
+ connection between the provenance of the alternates. In a
+ specific application context, alternateOf, or a subtype of it,
+ could allow you to infer more."
+
+TODO
+
+ 1.1.28 ISSUE-502 (Derivation) In my opinion, the initial
+ emphasis on transformation may muddle the definition. The
+ working group's response contained a helpful phrase ("The focus
+ of derivation is on connecting a generated entity to a used
+ entity.") that would add clarity to the definition of
+ derivation.
+
+TODO
+
+
+----------------------------------------------------------------------
+
+All issues below are now closed.
+
+----------------------------------------------------------------------
+
+
+ 1.1.1 ISSUE-532 (Role) - prov:type seems to satisfy the requirement
+
+Closed
+
+
+ 1.1.3 ISSUE-507 (Inverse Relations) - I know there has been
+ considerable discussion regarding the normative/informative
+ sections of the documents. This should address the original
+ comment.
+
+Closed
+
+
+ 1.1.8 ISSUE-500 (activity hierarchy)
+
+ I believe hierarchies of activities will be important when
+ maintaining provenance. I understand the working group is not
+ going to support this use case. I will consider extending the
+ prov spec to support activity hierarchies.
+
+Closed
+
+ 1.1.9 ISSUE-505 (prov-n notation) I believe I reviewed a version
+ of the DM that did not consistently apply the semi-colon
+ convention. The core of the comment, however, duplicates
+ issue-533 (still pending).
+
+Closed
+
+ 1.1.10 ISSUE-508 (Table 5) - Thanks for clarifying the text.
+ Issue-533 will address the remainder of the comment.
+
+Closed
+
+ 1.1.11 ISSUE-531 (Multiple location) - Addressed - no further comment
+
+Closed
+
+ 1.1.14 ISSUE-501 (DrivingACarToBoston) - no further comment
+
+Closed
+ 1.1.17 ISSUE-513 (StartSubActivity) As for Issue-500, I believe it
+ will be important to support these features. As they are not part
+ of the core spec, it may be possible to support them through an
+ extension.
+
+Closed
+
+ 1.1.18 ISSUE-511 (UsageSubActivity) As for Issue-500, I believe it
+ will be important to support these features. As they are not part
+ of the core spec, it may be possible to support them through an
+ extension.
+
+Closed
+
+ 1.1.19 ISSUE-510 (GenerationSubActivity) As for Issue-500, I
+ believe it will be important to support these features. As they
+ are not part of the core spec, it may be possible to support them
+ through an extension.
+
+Closed
+
+ 1.1.20 ISSUE-512 (FinePayingExample) - I think this is more clear.
+ No further comment.
+
+Closed
+
+ 1.1.21 ISSUE-497 (Figure 1) - No further comment
+
+Closed
+
+
+ 1.1.24 ISSUE-520 (Person/Organization/SoftwareAgent)
+ Thank you for the detailed response - it helped clarify for me the intended distinction between entity and agent. I tend to think about these concepts in a different way.
+
+
+Closed.
+
+ 1.1.26 ISSUE-509 (AttributesInUML) - no further comment
+
+Closed
+