Re: Issue: Add hasValue to OWL Lite

Ian -The  IJCAI paper about SHOQ(D) which might somehow connote what 
you are asserting, but I am afraid I don't see the connection.  The 
argument you make in
[1]  is the argument that the worst case computational complexity of 
reasoning goes up from absurd (EXPtime) to ridiculous (NEXPtime) with 
the addition of oneOf (or hasValue).  However, exptime already means 
you are limitied to relatively small domains or to incompleteness, 
and thus I don't find Nexptime compellingly bad.

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.

At 10:41 PM +0000 12/11/02, Ian Horrocks wrote:
>On December 11, Jim Hendler writes:
>>  At 11:08 PM +0100 12/10/02, Frank van Harmelen wrote:
>>  >Deb,
>>  >
>>  >Thanks for your summary of the discussion and lay-out of the options:
>>  >
>>  >Deborah McGuinness wrote:
>>  >
>>  >>
>>  >>I see the following options emerging from the discussion 
>>surrounding adding
>>  >>hasValue to OWL Lite.
>>  >>This attempts to choose highlights from the email discussion with the
>>  >>subject OWL Lite semantics as well.
>>  >>
>>  >>1 - do not add any notion of hasValue to OWL Lite.
>>  >>[...]
>>  >>2 - add hasValue to OWL Lite with the semantics as specified in OWL DL.
>>  >>[...]
>>  >>3 - add hasValue to OWL Lite with a restricted semantics.  A restricted
>>  >>semantics was proposed by Jeremy.
>>  >
>>  >I also largely follow your trade-off of the options:
>>  >
>>  >3 is not feasible at this time (on top of which I support earlier
>>  >discussion this week which makes it clear that it's not even an
>>  >attractive option)
>>  I agree 3 is not feasible at this time (although I'm not sure I agree
>>  with the parenthetical given Pat's responses to Ian)
>>  >
>>  >2 makes OWL Light so close to OWL DL that OWL Light would loose its
>>  >right to exist (remember that also Jeremy's proposal was aimed
>>  >making OWL Light lighter, while this option would make it
>>  >significantly heavier)
>>  <chair hat off!>
>>  I disagree with the above.  So far all I have seen is a bald
>>  assertion by Ian that hasvalue is hard to implement.
>I object most strenuously to being accused of having said something so
>patently stupid as "hasvalue is hard to implement". What I said was
>that *adding hasValue to OWL Lite* would make the *resulting logic* much
>harder to implement.
>>   As I've made
>>  clear often in the WG, I don't care much about computational
>>  complexity - because at web scales the issue is a red herring in my
>>  opinion (nor do I see any proof that LITE is in a lower complexity
>>  class without hasvalue).
>But you mention below having seen pointers to the literature that
>demonstrates just this. I can also refer you back to the thread
>beginning with [1] for one of the many occasions when we have covered
>this before! It contains a pointer into the literature and a more
>intuitive explanation that I gave in response to requests from the
>>   Implementationally, every major KR system I
>>  know of has a hasvalue in some form, all my tools do, and I don't see
>>  it as particularly hard to implement.  In fact, in several of our
>>  databased-implementations (cf. Parka [1]) it is absolutely trivial to
>>  implement.
>All this critically depends on our definition of "implement".
>>    Perhaps more importantly, we've had several requests for hasvalue
>>  being included in Lite in our comments list
>Then *tell them to use OWL DL*. As I have already pointed out, adding
>hasValue to OWL Lite makes it more or less identical to OWL DL; and if
>it is really so easy to implement, then it wont be a problem, will it.
>- including from Protege,
>>  one of the most used systems of any of those we are considering in
>>  our implementation report (Protege has close to 5000 registered
>>  users, and an active users mailing list with nearly 1000 members)!
>>  If we decide not to include hasvalue in Lite and if we go to LC and
>>  get this same comment, we will have to have a better answer than "Ian
>>  asserted it was hard to implement" - and we will have to have that
>>  answer formally recorded and documented per W3C process on addressing
>>  Last Call comments.  We don't lightly ignore input on our WDs and I
>>  sure don't see anything yet on our mailing list that a disgruntled
>>  commenter couldn't appeal.
>>  Sorry Ian, but all I've seen from you is pointers to work about
>>  computational complexity -- and I just don't see that as a compelling
>>  reason not to include an easy to implement, important feature that
>>  our users are requesting.
>>    -JH
>>  >
>>  >This leaves option 1 to me. Apparently, this is just the way the world is:
>>  >those people who will want to use has-value will end up using OWL-DL
>>  >(nothing wrong with that).
>>  >Wanting OWL Lite to be *light* and at the same time include all the
>>  >most-frequently-used primitives is simply not going to work (and why
>>  >should it).
>>  I still don't see any argument that convinces me that hasvalue is any
>>  worse than anything else in the language with respect to *light*ness,
>>  and it is alot easier to implement in my systems than several things
>>  already in Lite (for example the cardinality constraints).
>>  <chair hat back on>
>>    -JH
>>  [1]
>>  --
>>  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)

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 Wednesday, 11 December 2002 20:51:42 UTC