Re: further responses and closed issues in prov-dm

Dear all,

The following issues have now been closed, following Bob's feedback.

ISSUE-492
ISSUE-504
ISSUE-506
ISSUE-517
ISSUE-528
ISSUE-530

Regards,
Luc

On 10/26/2012 01:53 PM, Luc Moreau wrote:
> Hi Paul, all,
>
> Below, find:
> 1. The proposed changes to responses and/or document that
>     I have implemented following Bob's response.
>
>     For each issue, I then indicate if further acknowledgement
>     is expected from Bob, or if I propose to close the issue.
>
> 2. The list of issues that are now closed.
>
> We have processed the group responses up to ISSUE-520 (as they
> appear in the Wiki). The remaining responses still need to be formally 
> sent
> back to the reviewers.
>
> Cheers,
> Luc
>
>
>
>
>     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.
> Acknowledgement expected.
>
>     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.
>
> Acknowledgement expected.
>
>     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.
>
> I added the following to our response.
>
> In the follow-on message, the reviewer discusses the traffic light 
> example. As the light changes from red to green, the green traffic 
> light is invalidated and the red traffic light is generated. Both are 
> specializations of the traffic-light, which continues its existence 
> across this change state, since color is not one of its attributes.
> entity(ex:traffic-light)
> entity(ex:green-traffic-light, [ex:color="green"])
> entity(ex:red-traffic-light, [ex:color="red"])
> specializationOf(ex:green-traffic-light, ex:traffic-light)
> specializationOf(ex:red-traffic-light, ex:traffic-light)
> wasGeneratedBy(ex:red-traffic-light,-,2011-11-16T16:00:00)
> wasInvalidatedBy(ex:green-traffic-light,-,2011-11-16T16:00:00)
>
> I proposed to close this issue.
>
>     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."
>
> Change made
> http://dvcs.w3.org/hg/prov/diff/60b6ee097555/model/prov-dm.html
> Acknowledgment  expected.
>
>
>       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.
>
> Sentence was added to the text explaining the notion of derivation:
>  http://dvcs.w3.org/hg/prov/diff/780b82818bcf/model/prov-dm.html
>
> Acknowledgment  expected.
>
>
> ----------------------------------------------------------------------
>
> 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
>
>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Thursday, 1 November 2012 08:21:34 UTC