On December 12, Jim Hendler writes:
>
> A
> >
> >
> >3. For ExpTime logics, it is possible to devise relatively simple
> >algorithms that are goal directed and know when they are done. It has
> >also been demonstrated that these algorithms can be optimised so as to
> >give good performance in realistic applications.
> >
> >4. For NExpTime logics, no such algorithm is known. This is
> >illustrative of just how significant the jump from ExpTime to NExpTime
> >is from both a theoretical and a practical perspective.
>
> but OWL DL is in the NExpTime class - right? And there are
> implementations for that
WRONG. There are no sound and complete implementations for OWL DL. We
have been telling you this for a long time and we have written about
it in several papers, including the AAAI paper I referred to in an
earlier email.
> - so it's not like adding hasValue makes OWL
> Lite unimplementable.
WRONG AGAIN.
> My argument is simple - the hasValue is easily
> dealt with compared to some other features of OWL DL (particularly
> conjunctions and disjunctions of unnamed class constructs).
It is ludicrous to talk about the ease of implementability of a single
feature in isolation. As Peter (Crowther) pointed out in his email, it
*is* known how to implement hasValue without inverse, and inverse
without hasValue, but not both at the same time.
> I think
> OWL Lite is already harder than I would like it to be, but this
> feature is not worse than not having it to those of us who want to
> use this langauge subset (which, as I understand it, doesn't include
> you).
WRONG AGAIN. I already sent an email describing a couple of very
promising applications where I would like to use OWL Lite.
> More importantly, I know of no work around for not having hasValue.
> For some other things (classes as instances for example) there are
> well known ways to kludge it, so people oculd stay in LITE without
> using those features. For hasValue, we're talking basic definitional
> properties. The only workaround I know of is inverseFunctional on
> datatypes (I.e. one uses strings as keys), but that is much worse
> because that workaround takes us into FULL.
WRONG AGAIN. There is a very well known "work around", which is to
treat nominals as primitive classes. The Classic system had this trick
built into the implementation. This was described in a very well known
paper [1] which formalised the work around by giving an alternative
semantics somewhat in the style of Jeremy.
> >> In short, you are arguing that adding hasValue makes the worst case
> >> computational complexity of OWL Lite to be the same as that of OWL
> >> DL. OK, I'm willing to admit that. However, the working group never
> >> agreed that we were limiting Owl lite based on worst case complexity
> >> -- in fact, you yourself argued that the only argument in favor of
> >> Lite is ease of implementation -- okay, I throw that back to you --
> >> Jos and I have argued this is not hard to implement. In my case, it
> >> is naturally implemented by databases, which are often optimized for
> >> these sorts of tasks.
> >
> >As I mentioned in my earlier email, this depends on your definition of
> >"implement", and on just what it is you want to implement. To me, a
> >prerequisite for implementation is having an algorithm.
>
> right, and if there is no algorithm AT ALL then OWL DL wouldn't work.
> Since there are algorithms, we're back to what you argued for in the
> first place, implementational ease - but that is not equivalent to
> computational complexity, which seems to be our point of difference.
WRONG AGAIN - although admittedly this is the same error as above.
>
> Again, I think we have reached as far as we can in arguing, and it is
> time to vote.
Well, I think it was important to correct the numerous errors in this
email before doing that.
> >
> >Also, as far as OWL Lite -v- OWL DL is concerned, if what you are
> >saying about "implementation" is true, then OWL DL is equally easy to
> >implement and there is no requirement whatsoever for OWL Lite. If it
> >makes you feel better, you could "re-badge" OWL DL as OWL Lite.
>
> Ian, that's facile and you know it,
Not at all. Now that you are better informed I hope you can see that
this line of reasoning makes perfect sense.
> and as I said before, we're not
> willing to reopen that issue
If you really don't want to open *that* issue, then I would like to
raise a different issue. I suggest that we add oneOf *and* full number
restrictions to OWL Lite, and scrap OWL DL.
Regards, Ian
[1] A. Borgida and P. F. Patel-Schneider, A Semantics and Complete
Algorithm for Subsumption in the Classic Description Logic, JAIR, 1994.
http://www.cs.washington.edu/research/jair/home.html
> -JH
>
> --
> Professor James Hendler hendler@cs.umd.edu
> 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)
> http://www.cs.umd.edu/users/hendler
>