RE: acknowledging PROV responses from Freimuth, Robert, Ph.D. on 2012-10-24 (public-prov-comments@w3.org from October 2012)

From: Freimuth, Robert, Ph.D. <Freimuth.Robert@mayo.edu>
Date: Wed, 24 Oct 2012 23:39:25 +0000
To: Paul Groth <p.t.groth@vu.nl>
CC: "public-prov-comments@w3.org" <public-prov-comments@w3.org>
Message-ID: <76A706C559A90249BA321EE35470B857023001@MSGPEXCEI12A.mfad.mfroot.org>
Dear Paul,

Thanks to you and the working group for considering my comments.  My replies are below.  I will review and respond to the last 3 in the list later tonight or tomorrow.

Thanks,
Bob


  *   1.1.1 ISSUE-532 (Role)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-532_.28Role.29> - prov:type seems to satisfy the requirement
  *
  *   1.1.2 ISSUE-525 (Specialization/Alternate)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-525_.28Specialization.2FAlternate.29>
  *   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.
  *
  *   1.1.3 ISSUE-507 (Inverse Relations)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-507_.28Inverse_Relations.29> - I know there has been considerable discussion regarding the normative/informative sections of the documents.  This should address the original comment.
  *
  *   1.1.4 ISSUE-504 (collection/bundle)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-504_.28collection.2Fbundle.29>
  *   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.
  *
  *   1.1.5 ISSUE-503 (adopt plan)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-503_.28adopt_plan.29>
  *   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.



  *   1.1.8 ISSUE-500 (activity hierarchy)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-500_.28activity_hierarchy.29>
  *   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.



  *   1.1.9 ISSUE-505 (prov-n notation)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-505_.28prov-n_notation.29>
  *   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).
  *
  *   1.1.10 ISSUE-508 (Table 5)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-508_.28Table_5.29> - Thanks for clarifying the text.  Issue-533 will address the remainder of the comment.
  *
  *   1.1.11 ISSUE-531 (Multiple location)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-531_.28Multiple_location.29> - Addressed - no further comment
  *
  *   1.1.12 ISSUE-528 (MentionOf)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-528_.28MentionOf.29> - 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.
  *
  *   1.1.13 ISSUE-517 (Revision/Quotation)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-517_.28Revision.2FQuotation.29>
  *   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.
  *
  *   1.1.14 ISSUE-501 (DrivingACarToBoston)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-501_.28DrivingACarToBoston.29> - no further comment
  *
  *   1.1.15 ISSUE-516 (DerivationAsBundle)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-516_.28DerivationAsBundle.29>
  *   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).
  *
  *   1.1.16 ISSUE-514 (Starter/EnderActivity)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-514_.28Starter.2FEnderActivity.29>
  *   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.
  *
  *   1.1.17 ISSUE-513 (StartSubActivity)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-513_.28StartSubActivity.29>
  *   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.
  *
  *   1.1.18 ISSUE-511 (UsageSubActivity)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-511_.28UsageSubActivity.29>
  *   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.
  *
  *   1.1.19 ISSUE-510 (GenerationSubActivity)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-510_.28GenerationSubActivity.29>
  *   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.
  *
  *   1.1.20 ISSUE-512 (FinePayingExample)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-512_.28FinePayingExample.29> - I think this is more clear.  No further comment.
  *
  *   1.1.21 ISSUE-497 (Figure 1)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-497_.28Figure_1.29> - No further comment
  *
  *   1.1.22 ISSUE-515 (Invalidation)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-515_.28Invalidation.29>
  *   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.
  *
  *   1.1.23 ISSUE-530 (attributes)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-530_.28attributes.29>
  *   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.
  *
  *   1.1.24 ISSUE-520 (Person/Organization/SoftwareAgent)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-520_.28Person.2FOrganization.2FSoftwareAgent.29>
  *   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.
  *
  *   1.1.25 ISSUE-522 (Activity Delegation)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-522_.28Activity_Delegation.29>
  *   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.
  *



________________________________
From: pgroth@gmail.com [mailto:pgroth@gmail.com] On Behalf Of Paul Groth
Sent: Wednesday, October 17, 2012 1:41 PM
To: Freimuth, Robert, Ph.D.
Cc: public-prov-comments@w3.org
Subject: acknowledging PROV responses

Dear Bob,

As you have seen we've been slowly working through your issues. A key thing for the working group going forward is to record your acknowledgement of the resolution, whether it satisfies your concern or not and if not why.

Because you had quite a number of issues, I think it's best to list them out. You'll find the list below and is taken from the page: http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments

Each issue is linked back to the response. Maybe the best way is for issues that you are happy with the resolution to just list them out and state that you are fine with how they are dealt with. We can then maybe get your other responses to the other issues.

Thanks again for your detailed feedback on PROV. It's helping us make a better specification.

regards
Paul


Issues

  *   1.1.1 ISSUE-532 (Role)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-532_.28Role.29>
  *   1.1.2 ISSUE-525 (Specialization/Alternate)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-525_.28Specialization.2FAlternate.29>
  *   1.1.3 ISSUE-507 (Inverse Relations)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-507_.28Inverse_Relations.29>
  *   1.1.4 ISSUE-504 (collection/bundle)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-504_.28collection.2Fbundle.29>
  *   1.1.5 ISSUE-503 (adopt plan)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-503_.28adopt_plan.29>
  *   1.1.8 ISSUE-500 (activity hierarchy)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-500_.28activity_hierarchy.29>
  *   1.1.9 ISSUE-505 (prov-n notation)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-505_.28prov-n_notation.29>
  *   1.1.10 ISSUE-508 (Table 5)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-508_.28Table_5.29>
  *   1.1.11 ISSUE-531 (Multiple location)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-531_.28Multiple_location.29>
  *   1.1.12 ISSUE-528 (MentionOf)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-528_.28MentionOf.29>
  *   1.1.13 ISSUE-517 (Revision/Quotation)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-517_.28Revision.2FQuotation.29>
  *   1.1.14 ISSUE-501 (DrivingACarToBoston)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-501_.28DrivingACarToBoston.29>
  *   1.1.15 ISSUE-516 (DerivationAsBundle)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-516_.28DerivationAsBundle.29>
  *   1.1.16 ISSUE-514 (Starter/EnderActivity)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-514_.28Starter.2FEnderActivity.29>
  *   1.1.17 ISSUE-513 (StartSubActivity)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-513_.28StartSubActivity.29>
  *   1.1.18 ISSUE-511 (UsageSubActivity)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-511_.28UsageSubActivity.29>
  *   1.1.19 ISSUE-510 (GenerationSubActivity)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-510_.28GenerationSubActivity.29>
  *   1.1.20 ISSUE-512 (FinePayingExample)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-512_.28FinePayingExample.29>
  *   1.1.21 ISSUE-497 (Figure 1)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-497_.28Figure_1.29>
  *   1.1.22 ISSUE-515 (Invalidation)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-515_.28Invalidation.29>
  *   1.1.23 ISSUE-530 (attributes)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-530_.28attributes.29>
  *   1.1.24 ISSUE-520 (Person/Organization/SoftwareAgent)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-520_.28Person.2FOrganization.2FSoftwareAgent.29>
  *   1.1.25 ISSUE-522 (Activity Delegation)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-522_.28Activity_Delegation.29>
  *   1.1.26 ISSUE-509 (AttributesInUML)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-509_.28AttributesInUML.29>
  *   1.1.27 ISSUE-526 (Alternate)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-526_.28Alternate.29>
  *   1.1.28 ISSUE-502 (Derivation)<http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-502_.28Derivation.29>


--
--
Dr. Paul Groth (p.t.groth@vu.nl<mailto:p.t.groth@vu.nl>)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Knowledge Representation & Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam
Received on Wednesday, 24 October 2012 23:39:53 UTC