further responses and closed issues in prov-dm

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.


     1.1.2 ISSUE-525 (Specialization/Alternate)

     I think my comment was misunderstood.  Fig 8 in
     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

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.
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.
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: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)

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

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 
    o PROV constraints defines the semantics of optional arguments, and
      specifically, in Table 3, explains that activity in delegation is
    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
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

Sentence was added to the text explaining the notion of derivation:

Acknowledgment  expected.


All issues below are now closed.


     1.1.1 ISSUE-532 (Role) - prov:type seems to satisfy the requirement


     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


     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.


     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).


     1.1.10 ISSUE-508 (Table 5) - Thanks for clarifying the text.
     Issue-533 will address the remainder of the comment.


     1.1.11 ISSUE-531 (Multiple location) - Addressed - no further comment


     1.1.14 ISSUE-501 (DrivingACarToBoston) - no further comment

     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


     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


     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.


     1.1.20 ISSUE-512 (FinePayingExample) - I think this is more clear.
     No further comment.


     1.1.21 ISSUE-497 (Figure 1) - No further comment


     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.


       1.1.26 ISSUE-509 (AttributesInUML) - no further comment


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 Friday, 26 October 2012 12:54:15 UTC