- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Fri, 26 Oct 2012 13:53:46 +0100
- To: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
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 Friday, 26 October 2012 12:54:15 UTC