W3C home > Mailing lists > Public > www-webont-wg@w3.org > December 2002

Re: Issue: Add hasValue to OWL Lite

From: Jim Hendler <hendler@cs.umd.edu>
Date: Wed, 11 Dec 2002 09:11:49 -0500
Message-Id: <p05111705ba1cf4332abf@[]>
To: Frank van Harmelen <Frank.van.Harmelen@cs.vu.nl>, www-webont-wg@w3.org

At 11:08 PM +0100 12/10/02, Frank van Harmelen wrote:
>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.  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).  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 

  Perhaps more importantly, we've had several requests for hasvalue 
being included in Lite in our comments list- 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.


>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>

[1] http://www.mindswap.org/2002/parka
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)
Received on Wednesday, 11 December 2002 09:11:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:49 UTC