From: AAAI Technical Report WS-96-05. Compilation copyright © 1996, AAAI (www.aaai.org). All rights reserved. Object-Oriented ProgrammingSupport for CLASSIC Ralf M~iller University of Hamburg,Computer Science Department Vogt-KOlln-Str.30, D-22527Hamburg, Germany moeller@in formatik,uni-hamburg, de Abstract:The main thesis of this paperis that in order to tional programmingpoint of view it is irrelevant useDescription Logics in practical applications, a seamless whether a result of a function call is defined by integration with object-oriented systemdevelopment meth- merely looking up a set of instances in a relation odologiesmust be realized. It presents an object-oriented table or by actually computinginstances with com- programminglayer for CLASSIC. plex algorithms and auxiliary data structures. Sec- 1. Introduction ond, using genetic accesser functions for retrieving the objects that are directly set into relation to a spe- Althoughthe logical semantics of Description Logics cific individual allows a lot of error checkingcode to (DL)modeling constructs is a big plus, to ensure deci- be automatically generated. A unified interface for dability of the subsumptionproblem, the expressive- accessing the services that an object provides hides ness of the logical language must be limited. The manyrepresentation details whichare irrelevant from consequenceis that in a real application without toy a moreabstract perspective. problems, currently not all aspects can be formally modeled with DL constructs. This means that pro- For example,in a graphical user interface, the draw- grammingis still necessary. As a DL we use the ing function for an object might depend on the CLASSICsystem [9]. Reducing CLASSICto practice object’s concepts. User interface programmingis one [1] means that the DL can be integrated into the of the best examplesfor the application of object-ori- whole system development approach which, at the ented programmingtechniques. For rapid user inter- current state of the art, uses object-oriented modeling. face development however, an existing UIMSmust In this paper, the CLOSOOP perspective will be used be reused. UIMSsprovide powerful programming [10]. Thepaper presents an object-oriented programming abstractions which are modeledwith the object-ori- layer for CLASSIC.It assumes basic knowledgeabout ented representation techniques (e.g. for CLOSthe CLOS1 [3]. UIMSCLIM might be used [7]). There is no way to rebuild these software libraries with CLASSICor The integration of CLASSICand CLOSrequires that any other DLin a reasonable time. So what can be genetic functions and methods can be written for done? Copying information associated with a DL CLASSICindividuals. The procedural parts of an object into a CLOSobject which is used for UI part application should be able to use CLASSICindividu- of an application is inadequate as well. Unfortu- als just like CLOSinstances. The "services" of an nately, managing multiple "copies" of the same object are accessed only by the use of generic func- object is a direct contradiction to the principles of tions. This meansthat the relational part of CLASSIC object-otiented programming.Thus, for rapid appli- should be hidden behind a functional layer because, cation development, object-oriented programming from a software engineering point of view, dealing techniques must be made available to CLASSICindi- with individuals and relations earl be quite cumber- viduals. The next chapter discusses an approach that somefor at least two reasons: First of all, froma func- demonstrates how this can be achieved with an extension to CLASSICthat uses CLOS-like genetic 1. Thispaper is a shortenedand rewritten version of a paperpre- functions to access information about an individual. sentedat OOPSLA’96[5]. Theextensions for the CLASSICsys- It will be shownthat the implementation of CLAS- tempresented in this paperare availablefrom the author[6]. SIC methoddispatch can be surprisingly simple. - 170- 2. Integrating OOP and DL ated. If they do not already exist, corresponding generic2 functions are automatically generated. Generic functions for Description Logics have also been developed in the LoomSystem [2]. Methoddis- The first role option :single-value-p specifies patch for individuals is provided by specific genetic whether a single value or a set of values should be functions which dispatch on ABoxobjects but not on returned by the role reader function. The other option CLOSobjects. Loomalso supports CLOSclasses for :error-if-null is used to insert code for error the implementation of ABoxindividuals but only a checking to avoid an empty set to be returned. The limited sort of reasoning is implemented on these following example illustrates the use of define- instances (no dynamic reclassification by forward accessor. For concept and role declarations the inferences). KRSSsyntax is used [8]. (define-primitive-conceptship classic-thing) Theapproach presented in this paper clearly separates (define-primitive-rolehas-position-x nil) CLASSICand CLOSbut provides a unified way to (define-primitive-rolehas-position-y nil) access the services of both systems. (define-accessorsship (has-position-xposition-x : single-value-pt 2.1. Accessors: A Functional Interface to a :error-if-nullt) Knowledge Base (has-position-yposition-y CLASSICitself provides a relational interface for : single-value-pt :error-if-nullt) retrieving and adding role fillers. Givenan individual and a role, the set of fillers can be retrieved: (cl- As in CLOS,for accessing information of an object, fillers<ind> <role>). In manycases only one define-accessors defines methods for generic filler is returned. However,the result will alwaysbe a functions. Additional methods might be written by set (actually a list) and the function first must the programmer(e.g. around methods or after and applied to get the list element itself. To hide the before methods). CLASSICindividuals require repeating access to the first element, an additional another dispatch mechanismwhich is realized by extended generic functions. function will have to be written. Furthermore,in some circumstances,it will be considered as an error if the 2.2. Generic Functions and Methods filler is not known. Unfortunately, additional code mustbe written to checkthis. If nil (the emptyset) The extended generic functions presented in this returned, an error is likely to occur in subsequent paper can dispatch on CLASSICconcepts or CLOS function calls whenan individual is expected. Again, classes or both. The form define-generic- func- code must be written to avoid this. Instead of writing tion is used to define a generic function with dis- this code manually, a more general mechanismis patching extended to CLASSICindividuals. advantageous. The way to access individuals should The argument list of define-generic-function be declaratively defined using generic functions and indicates which arguments expect CLASSICdispatch corresponding low-level code for methods should be and which arguments use standard CLOSdispatch. automatically generated. The declaration form (define-generic-function<function-name> define- acces sors has been introduced to specify (<dispatched-argument-description>... the access to individuals in that way. [ <other-argument>... ] ) [ <option>...] ) (define-accessors<concept-name> (<role-name><accessor- name> A description for a dispatching argumentis a list con- [ :single-value-p<boolean> ] sisting of an argumentname and a dispatch indicator [ :error-lf-null<boolean> ] ) ...) For each role description mentionedafter the concept 2. The explicit declaration of a generic aeeessor function is nee- name, a reader method and a serf writer method for essary, for instance, whena special methodcombination that dif- the generic function <accessor-name> is gener- fers from the standard methodcombination is to be used [10]. - 171- (either :clos or :classic). Just as defgeneric function can be defined as follows (comparethis to from CLOS,define-generic-function alSO sup- initialize- instance from CLOS). ports ordinary argumentswithout specializer (called (define-methodinitialize-individual :after other-arguments). The optionsfor define- ((ind <concept-name>)&rest initargs) generic-function are the same as for defge- ., ,) neric.Note that method combinations are also sup- Initialization arguments can also be given to cre- ported. ate-individual.The list of "initargs" is a sequenceof rolenames and corresponding setsof ini- Methodscan be definedwith the form define- tialfillers) method. (define-method<function-name> [ <qualifier> 2.4. Computation of the Concept Precedence ( <dispatched-argument>... [ <other-argument>... ] ) List ¯ 0 0 ) The TBoxdefines a partial order relation between The syntax of a dispatched argument in a method concepts (subsumption relation). In order to define parameter list is identical to the syntax of arguments howmethod dispatch is handled, the multiple inherit- for defmethod of CLOS. The <qualifier> indi- ance lattice must be serialized by a concept prece- cates the kind of methodcombination. In addition to dence list which represents a total order between names for CLOSclasses, CLASSICconcept names concepts. A concept precedence list is used for the can be used as specializers. same purposes as a CLOSclass precedence list, it The following declarations continue the example defines howan effective methodfor a specific func- from above. tion call is computed(see the detailed introduction in (define-generic-functionpos ( (ship :classic) [3]). A valid