Re: Proposed response to Martin Merry, HP

On Fri, 2003-05-09 at 17:56, Jim Hendler wrote:
> The following is my proposed response to the message from Martin 
> Merry, which is found at:
> http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0046.html
> 
> 
> Thanks for your comment.  We believe it raises two important 
> questions, one is whether the design of OWL DL as is would require a 
> long CR period, the other is whether dropping #hasValue and #oneOf 
> should be done by the WG.  Let me answer these in reverse order.
> 
> 1 - a Long CR:
>   From a Process point of view (and ignoring your technical point for 
> a moment, I promise to return to it), I would point out that there is 
> no requirement that all features of a recommendation must be handled 
> by all implementations.

You switched from "we believe it raises" to "I would point out";
are you writing for the WG or for yourself? please be consistent.

Note that the comments on schedule aren't technical issues
at all.

I'd suggest just

  Thanks for your advice on the schedule; we'll consider
  it along with many other factors as we decide when
  to ask The Director to advance the specification.

No need to ask if he's satisfied with that part of
the response; his comment wasn't about the text
of the spec. It's advice to a decision we haven't
even made yet.

I don't like the hiding behind process ala "there's
no requirement that all features are implemented
by all implementations." That's pretty much the
definition of interoperability, and that is our
goal, while we don't guarantee 100% to meet it.


>   The process document states that the 
> requirement to move from CR to PR is:
> 
> each feature of the technical report has been implemented. 
> Preferably, the Working Group should be able to demonstrate two 
> interoperable implementations of each feature.
> 
> For every part of the OWL DL specification we currently have multiple 
> implementations that can implement it, and in fact for every subset 
> of the language features that doesn't contain BOTH "inverseOF" and 
> "OneOf" we have multiple working and interoperable implementations 
> either complete at this time, or coming soon.
>   So from a process point of view, we believe the current OWL DL 
> implementation meets the requirements for advancement.
> 
> 2 - Your second issue is a more important one, you suggest that for 
> the current OWL DL, which includes  OneOf there is a lack of 
> practical implementation experience -- this is not quite correct.  We 
> have numerous implementations that support oneOf quite well.

This claim should be backed up by citations of at least
three such implementations.

Or better yet, just please don't make up ad-hoc answers like this.

Cite from the specs and/or the decision record.

If you can't find an answer there, then this is a new issue
and the WG should consider it.

Ian suggests we "point to the extensive discussion we had regarding the
features to be in/out of OWL DL and Lite". I'm having trouble
finding relevant decisions. There aren't any issues
whose names make their relevance to this comment obvious to me.

>   What is 
> correct is that for the whole of OWL DL, which includes BOTH 
> owl:inverseOf and owl:oneOf there is a problem -- if both are used 
> together, in the same ontology, there is a possibility that the 
> solution to some queries will take a very long time (that is, that 
> there is no effective algorithm).  This is true -- although the 
> language containing both of those features is decidable (it is, and 
> it's not just Ian's assertion, the proofs are quite well known and 
> studied), the algorithmic complexity is potentially quite high. 
> However, there are other solutions than removing owl:oneOf, for 
> example removing owl:inverseOf would work as well.
>   In fact, the problem is that there are two useful features in OWL DL 
> (inverse properties and designators such as oneOf and hasValue) that 
> are widely used in practice.  The WG believes that removing either 
> one of these would cause there to be many valuable use cases that 
> could not be represented in OWL DL.  However, there is no problem 
> with documents that use either Inverses XOR designators, it is only 
> when both are used together that the problem occurs.  A "common 
> sense" analogy is found in medicine where there are many drugs that 
> are each beneficial, but when used together they can cause bad side 
> effects -- inverse and oneOf are analogous to two such drugs.
> 
> In your comment you write:
> 
> 
> We find that the draft documents make it clear that OWL Full systems will
> not have full reasoning support and that therefore users will not be too
> surprised when there is a resulting migration cost from one OWL Full 
> system to another.
> 
> so we believe that if the documents made clearer that using BOTH 
> oneOf and inverseOf (and their various forms) could lead to an 
> unexpected rise in complexity, we would set the expectation 
> correctly. In that way the current OWL DL subset would be easier to 
> understand, and the design rationale behind it better understood.
> 
> Thus, given these two below, we propose that the WebOntology working 
> group will make the issue above clearer and will write text to appear 
> in the Reference, S&AS and Test documents that explain the above. 
> However we would also propose not to remove these very useful 
> features from OWL DL or to have a long CR period mandated by this 
> specific issue.
> 
> If this outline of a solution is acceptable to you, we will produce 
> proposed text properly setting the expectations with respect to 
> inverse and oneof, and request your approval before closing this 
> comment.

Let's please not ask the commentor to buy a pig-in-a-poke.
If we're going to change our docs in response to the comment,
let's craft the words and *then* ask if they're acceptable.

> 
> We look forward to your response
>    Jim Hendler
>    WebOnt Co-Chair, on behalf of the Working Group
> 
> 
> 
> 
> 
> 
> 
> At 15:18 +0100 5/9/03, Merry, Martin wrote:
> We wish to comment on the usefulness of OWL DL as a sensible subset of OWL
> Full.
> 
> We're concerned that OWL users should have their expectations met when they
> use OWL compliant systems.
> 
> We find that the draft documents make it clear that OWL Full systems will
> not have full reasoning support and that therefore users will not be too
> surprised when there is a resulting migration cost from one OWL Full system
> to another.
> 
> We are concerned, however, that OWL DL is presented as a sensible stopping
> point before OWL Full, where there are greater guarantees.
> 
> The theoretical results for the decidability of OWL DL are interesting but
> not particularly helpful. OWL Lite is justified by practical results in DL
> systems (primarily from Ian Horrocks). There is no such practical experience
> for the OWL DL subset.  We would like to see such practical experience
> before OWL exits candidate recommendation.
> 
> In particular, we would like to see adequate practical implementation
> experience of the OWL DL constructs owl:oneOf and owl:hasValue.  We believe
> that this should include the goal that OWL DL reasoners can make a
> reasonable attempt at classic NP complete problems (such as the 3-SAT
> problem and the subgraph isomorphism problem) which can be straightforwardly
> encoded within OWL DL.  For example, any such problem that can be solved in
> seconds by a specialised reasoner should be soluble by a general OWL DL
> reasoner in minutes rather than years.
> 
> An alternative, would be to redefine OWL DL downwards, excluding owl:oneOf
> and owl:hasValue, which would then be subject to the health warnings of OWL
> Full - i.e. use of these constructs means that your ontology is likely to be
> outside the limits of practical reasoning. Such a redefinition of OWL DL,
> could sensibly accompany a redefinition of OWL Lite to exclude complete
> class definitions.
> 
> 
> Martin Merry
> HP Semantic Web Programme Manager
> 
> 
> 
> Martin Merry
> HP Semantic Web Programme Manager
> 
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Tuesday, 13 May 2003 10:22:00 UTC