Re: concerning lite, fast, large versions of OWL

At 8:12 PM -0400 10/17/2002, Jim Hendler wrote:
>Enrico - all those arguments address why it would not be so bad to 
>include classes as instances in OWL Lite, but I'm not sure they 
>address the specific need to include these things in Lite.  That is, 
>it would be perfectly fine for a tool developer to say "I include 
>all of OWL Lite and also classes as instances"  or such.  This is 
>not meant to be a refutation, I mean it as a real question - why do 
>you feel we need these metaclasses in the simplest subset of our 
>language rather than in the langauge as a whole?
>  -JH


You are absolutely right.  My point is that the arguments put forward 
so far for NOT having classes as instances in OWL Lite are not 
convincing (or at least they do not convince me, they clearly 
convince other people!).  If we talk about arguments for having 
classes as instances in OWL Lite, the main reasons would be that it 
is something you need very often in applications and it is already 
provided by RDF.  By having it in OWL-Lite  I will be able to import 
any RDF model (e.g., in the AKT project we have one which contains 
hundreds of thousands of triples) in a straightforward way without 
worrying about semantic incompatibilites.

So, basically I would like to hear whether people think this is 
useful enough to have it in OWL-Lite or not.  If  people think we 
don't need it, then we should not have it.


>At 1:00 AM +0100 10/18/02, Enrico Motta wrote:
>>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.
>>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.
>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 Friday, 18 October 2002 14:53:41 UTC