Re: Issue: Add hasValue to OWL Lite

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
>

Received on Thursday, 12 December 2002 10:49:38 UTC