Luc,
I'm responding privately (cc'ed to www-archive), as I said I'd stay out of the
WG discussion having made a public objection. I wanted you to be aware that I
don't feel this response addresses my concerns. If you choose to do so, you may
introduce this message into WG discusions, but I feel that has to be your
decision, not mine. (You should be able to find the www-archive link somewhere
in http://lists.w3.org/Archives/Public/www-archive/2012Nov/ if you wish to refer
to this message.)
The substance of my specific objection is that in its present form, the Mention
construct is inadequately described, and appears to serve no useful purpose that
is not already possible, and if left to stand may be used in ways not explicitly
sanctioned that may be non-interoperable. Your response here does not affect my
view on this.
References:
* http://lists.w3.org/Archives/Public/public-prov-comments/2012Aug/0001.html
(my original objection)
* (others at the end of this message)
Responding to specific points in your proposed response:
On 05/11/2012 07:42, Luc Moreau wrote:
Dear all, kind reminder.
Thanks
Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
On 1 Nov 2012, at 16:33, "Luc Moreau"
<[email protected]<mailto:[email protected]>> wrote:
Dear all,
At
http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#PROV-DM_.28Under_Review.29
you will find proposed answers to the ISSUE-475. It is copied below for your
convenience.
It will become the group response unless we hear objections by Tuesday November
6th, noon GMT.
Best regards,
Luc
ISSUE-475 (Mention)
* Original email:
http://lists.w3.org/Archives/Public/public-prov-comments/2012Aug/0001.html
* Tracker: http://www.w3.org/2011/prov/track/issues/475
* Group Response:
* The reviewer suggests that the work to describe contextualized
provenance should be deferred so that it can be aligned with ongoing W3C work
on RDF datasets and their semantics. Since ISSUE-475 was submitted, the RDF
working group has decided that it will not provide a formal semantics for RDF
Datasets. This RDF resolution ensures that any semantics for bundle and/or
mention is guaranteed not to be in conflict with the RDF semantics.
If the RDF group can't provide a semantic framework for RDF dataset constructs,
I don't think the PROV group is qualified to do so. mentionOf can only be
expressed in RDF by making reference to RDF dataset or similar constructs.
In the absence of RDF-imposed semantic constraints, we may be free to introduce
our own contextual semantics for RDF datasets, but at the risk of creating
inconsistencies with semantics defined by other groups who are similarly free.
Further, the decision of the RDF group to not define any semantic framework at
this time does not prevent a future RDF working group from so doing.
(BTW, I'm considering objecting to this lack of provision of a semantic
framework for RDF datasets by the RDF group.)
* As PROV-Constraints section 6.2 clearly indicates, PROV-bundles
validity is determined by examining bundles in isolation of each other. Our
response to issue-482 also indicates that PROV itself does not set any
constraints on how a given ID is being used across multiple bundles. Given
this, mentionOf is a general relation which allows an entity to be linked to
another entity described in another bundle.
In which case, unless it is semantically vacuous, this mentionOf construct
violates this principle of independent validity, since it makes cross-bundle
references. Any non-trivial semantic constraints on mentionOf will impose
cross-bundle constraints on bundle validity.
* The reviewer suggests that
mentionOf(infra, supra, b)
could simply be expressed as
specializationOf(infra, supra)
entity(infra, [mentionedIn=b])
*
* This design was considered and rejected by the Working Group:
* By design, relations between PROV objects are expressed by PROV
relations (usage, generation, etc, mention), and are not expressed as PROV
attributes. The suggested additional attribute mentionedIn would relate the
entity infra with bundle b, and would go against this prov-dm design.
This design was offered as an example, not a proposal, so I don't think the
group's rejection of that specific design invalidates my point that the function
of "mentionOf" can be covered by existing features of the model. (I would argue
that, even if the group have not adopted this design, it remains a legal
construct within PROV-DM modulo choosing a name for "mentionedIn" that is not in
the prov: namespace.)
* The interpretation of the attribute-value pair mentionedIn=b is
somewhat difficult, because infra is not itself described in bundle b: supra is
the entity described in bundle b. So, syntactically, mentionedIn=b may look
like an attribute-value pair, but in reality, it can only be understood in the
presence of specializationOf(infra, supra). Hence, the reason for introducing
the ternary relation mentionOf.
Then I misunderstood or misread the specification. I should have suggested:
entity(supra, [mentionedIn=b])
With that change the rest of my comment stands.
My comment about redundancy would similarly apply if there were a binary
mentionedIn relation, but that would require a different new construct in
PROV-DM, which might appear thus:
specializationOf(infra, supra)
mentionedIn(supra, b)
If this form of mentioned had been specified, I would not be objecting.
* The Working Group left it unspecified which new attributes could be
inferred for infra, and in general what constraints apply to mentionOf. The
reviewer is critical of this decision, arguing that nothing new can be inferred
from mentionOf, and therefore mentionOf can be replaced by specializationOf.
'Under-specification' is a feature of PROV: what can be inferred from relations
such as usage, derivation, alternate? The group recently acknowledged this for
alternateOf and added a clarifiying note in the text. This observation is
applicable to further PROV concepts, such as Quotation, PrimarySource,
SoftwareAgent, etc. which do not allow us to infer more than their parent
concept would (Derivation, Agent). We are in a same situation with mentionOf.
Further inferences are left to be specified by applications.
I think the definition of "mentionOf" is the worst kind of underspecification,
not really comparable with the others you mention (except maybe "alternateOf").
A significant new structure is introduced into the model with no indication of
its semantics? This is almost guaranteed to lead to interoperability failure.
As I've argued elsewhere, I actually think too many constructs have been
introduced into PROV, but I think that for they most part they are mostly
harmless, creating "noise" but not likely to lead to fundamental
interoperability problems.
It would be better in my view to leave implementers to implement their own new
constructs, with semantics as needed by their applications. Later, when we see
what is actually needed, it may be appropriate to select one or some and bless
them with standard status and semantics.
* The reviewer's suggestion to address the use of Example 45 is to copy part of
the referred bundle. By copying statements from the original context to the new context,
we have lost the original context in which they occur (... their provenance!), and we
have no way of expressing that wasAssociatedWith(ex:a1, ...) in the new context is a
"kind of specialization" of wasAssociatedWith(ex:a1,...) in the original
context, ... which is why mentionOf was introduced in the first place.
It was my understanding, and I think it's what the specification says, that a
bundle is simple a collection of provenance statements, *not* a context.
"A bundle ◊ is a named set of provenance descriptions, and is itself an entity,
so allowing provenance of provenance to be expressed."
In particular: the provenance of a bundle *has no effect on* the semantics of
the content of the bundle. Thus, COPYING a provenance statement from one bundle
to another has no effect on the claim it makes. (The provenance of a bundle
within which it appears may affect one's decision to trust that statement, but
that's a different issue that lies beyond the scope of PROV as defined.)
* The reviewer also comments on the lack of information about 'Fixed
aspects'. We refer to our response to ISSUE-462, and recent associated changes
to the document.
I don't believe this adds any useful information with respect to my present
objection. Indeed, this aligns with the interpretation I *assumed* when framing
my objection.
* The Working Group identified 'mention' as a feature at risk, because
it was seeking experience from implementers. The Working Group will keep this
feature marked at risk as it enters the CR phase, and will reassess its
suitability based on implementers feedback.
My position as a member of the working group was, and is, that this is a feature
that needs to be more widely *reviewed* - maybe that didn't find itself into the
wording of the "at risk" notation.
I note the wording used is:
[[
This feature is "at risk" and may be removed from this specification based on
feedback. Please send feedback to [email protected].
The "Mention" construct might be removed from PROV if implementation experience
reveals problems with supporting this construct.
]]
-- http://www.w3.org/TR/2012/WD-prov-dm-20120724/#term-mention
Since the second statement does not exclude the first (which says nothing about
*implementation*), I disagree with your narrower interpretation of "at risk".
#g
--
* References:
* RDF resolution:
http://www.w3.org/2011/rdf-wg/meeting/2012-10-03#resolution_1
* Email discussion on mention:
http://lists.w3.org/Archives/Public/public-prov-wg/2012Jun/0400.html
* alternateOf:
http://dvcs.w3.org/hg/prov/diff/60b6ee097555/model/prov-dm.html#l1.8
* Response to ISSUE-482:
http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-482_.28Bundles_and_IDs.29
* Prov constraints section 6.2:
http://www.w3.org/TR/prov-constraints/#bundle-constraints
* Response to ISSUE-462:
http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-462_.28Definition_of_Entity.29
* Changes to the document:
* Original author's acknowledgement:
[edit<http://www.w3.org/2011/prov/wiki/index.php?title=ResponsesToPublicComments&action=edit§ion=46>]
--
Professor Luc Moreau
Electronics and Computer Science tel: +44 23 8059 4487
University of Southampton fax: +44 23 8059 2865
Southampton SO17 1BJ email:
[email protected]<mailto:[email protected]>
United Kingdom http://www.ecs.soton.ac.uk/~lavm
