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

Re: concerning lite, fast, large versions of OWL

From: Enrico Motta <e.motta@open.ac.uk>
Date: Fri, 18 Oct 2002 01:00:15 +0100
Message-Id: <p05100300b9d4f0bec0b4@[212.126.155.4]>
To: Frank van Harmelen <Frank.van.Harmelen@cs.vu.nl>, Christopher Welty <welty@us.ibm.com>, www-webont-wg@w3.org

Frank,

It is an incredibly rare event for me to say that I do not  agree 
with something you say, but I guess this is one of those rarities!

You say that classes as instances should not be in OWL-lite basically 
because of three reasons:
1) they break the beautiful inclusion hierarchy (OWL Light < 
OWL/FOL-style < OWL/RDF-style)
2) they make reasoning more complicated
3) they make tool implementation more complicated.

I am not convinced by either of these three arguments

1) If we add RDF to the picture, what we get is 2 distinct 
hierarchies in your scenario

RDF <  OWL/RDF-style
OWL Light < OWL/FOL-style <  OWL/RDF-style

This is not brilliant either, given that OWL is supposed to be based 
on RDF.  If we make OWL-light RDF-compliant, then we get the 
following picture

RDF <  OWL Light <  OWL/RDF-style
OWL/FOL-style <  OWL/RDF-style

This isn't great either, but it is no worse than the alternative.  It 
basically shows an inclusion hierarchy baed on top of RDF, with an 
alternative, FAST-OWL, for those applications/scenarios/groups who 
need both powerful and complete reasoners and do not care about the 
(very) basic metalevel support provided by RDF.

2) I am not sure why reasoning should be more complicated. It may be 
undecidable, but this is different from being complicated, in the 
sense of ease of implementation of reasoners, rather than formal 
complexity. Do you really think FAST-OWL is going to be that easy to 
implement? Both FAST-OWL and LARGE-OWL have very powerful constructs 
and inevitably they will BOTH be tricky to implement correctly. But I 
don't really understand why having metaclasses should seriously make 
implementing OWL-lite more difficult.

3) In our group we have have been implementing KB tools for almost 20 
years and I really can't see why having classes as metaclasses makes 
tool implementation more difficult.  Instance links from a class to a 
metaclass do not affect the display or the browsing of subclassOf 
hierarchies. And in any case such problem is a lot simpler than 
supporting browsing and visualization of ontology entities in a 
language that allows DL-style flexibility in the association between 
properties and classes.

My view is that the need to link classes to their metaclasses is so 
ubiquitous in knowledge representation that it will be a problem to 
leave it out of OWL-lite.  I guess this is why the RDF folks added it 
to something as 'bare' as RDF.  Indeed, the wine ontology subgroup in 
Bristol spent quite a bit of time trying to come up with examples 
where such need (of representing metaclasses) would not arise, given 
that we did not know whether OWL would support classes as 
metaclasses.  It is a truly ubiquitous problem, which is often solved 
by modelling classes as instances, thus making it difficult to teach 
students how to build proper ontologies and limiting 
interoperability. For instance, it is very difficult to talk both 
about individual grapes and about types of grapes that are excellent 
for wine, without the ability to treat classes as individuals. In 
Bristol we solved it simply by ignoring instances of class GRAPE and 
talking only about GRAPE-TYPE, but this was simply a way to avoid the 
problem, rather than solving it.

Enrico

PS Btw, at the cost of sounding real pedantic I should also object to 
the implied statement that having classes as instances means that we 
will go beyond OWL/FOL-style.  Maybe it is only a matter of labels, 
but, as  Pat Hayes has stated many times in this list, treating 
classes as instances is not really a problem for FOL treatments. I 
stopped being a formal logician back in 1986, but I do remember that 
even back then this was not a problem for 1st order logic.
Received on Thursday, 17 October 2002 20:00:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:53 GMT