Re: Consistency, decidability, etc (was Re: SEM: 5.1 literal/data values was RE: ADMIN: Minutes of telecon 11th July 2002)

On July 18, Jim Hendler writes:
> <Chair neutrality off>
> Ian -
>   I must finally confess that I've reached the point where I'm finding 
> your own stances inconsistent and I'm simply unable to guess where 
> the motivation is.
> When you talk about OWL-Lite you continually say that people will 
> define the subsets they need for what they want to do, but when you 
> talk about full OWL you keep saying we cannot have any language 
> features that break consistent reasoners and the like.

My stance all along is that we should design OWL so that it has
certain desirable computational properties, in particular that it is
POSSIBLE to implement sound and complete (and terminating)
reasoners. If we don't care about the computational properties of the
language, then it is hard to see why we are bothering to restrict
ourselves to such a relatively clumsy and inexpressive language - why
not go straight to full FOL (I can hear Pat saying "amen to that"), or
something even more expressive?

Of course some applications may only use a subset of OWL, and they may
have access to more efficient reasoners for that subset. Fine.

>   These seem inconsistent to me.  Why can't you live with your 
> FACT-based, consistent reasoner only working on a proper subset of 
> whatever we publish -- and let us have other features for what we 
> need or want.  Why is it right for me to have to say "My RIC tool 
> supports the following OWL features:" but you insist that your 
> reasoners have to be able to support every feature or the language is 
> somehow broken.
>   I could live very happily with a solution that says "My Fact tool 
> supports the following features: " and then defines a subset on which 
> you could be consistent and decidable and efficient.  I could then 
> decide for my application if I want to be in your representational

This is disingenuous. The argument is not w.r.t. "my reasoners". The
argument is w.r.t. ANY reasoner. I have simply tried to point out when
proposed additions/changes to the language would take us outside the
space where (to the best of my knowledge) ANYONE knows how to design a
sound and complete reasoner, and I have argued against such
additions/changes on the above stated grounds.

>   So frankly I could see you be a strong advocate for a carefully 
> designed named subset for the sake of interoperability, or defending 
> certain language features because they are useful in your FACT-based 
> work, but I cannot understand why you insist on trying to disallow 
> anything in the full language that you cannot handle.

To reiterate, I haven't defended or opposed features based on their
being "useful in my FACT-based work", or on the basis of whether or
not I can "handle" them, and I don't appreciate your representing my
efforts to provide the WG with factual information about the
computational consequences of various design choices in this light. I
will continue to argue against our designing a language whose
computational properties would make it difficult or impossible for
ANYONE to build a fully conformant implementation. I believe this to be
entirely consistent and easy to understand.

>   I think we would have much more success in reaching consensus if 
> people would worry more abotu making sure what they need is included, 
> and a little less about keeping out things that other people want.

Personally, I very much appreciate it when members of the working
group contribute factual information about the language design based
on their own areas of expertise. I believe we would have much more
success in reaching consensus if our deliberations were based on more
of this kind of information.


>    -Jim H,
> <chair neutrality on>
> -- 
> Professor James Hendler
> Director, Semantic Web and Agent Technologies	  301-405-2696
> Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
> Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)

Received on Friday, 19 July 2002 11:54:57 UTC