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,ComputerScience Department
Vogt-KOlln-Str.30, D-22527Hamburg,Germany
moeller@in formatik,uni-hamburg,
de
Abstract:Themainthesis of this paperis that in order to
useDescriptionLogicsinpractical applications,a seamless
integration with object-oriented systemdevelopment
methodologiesmustbe realized. It presents an object-oriented
programming
layer for CLASSIC.
1. Introduction
tional programmingpoint of view it is irrelevant
whether a result of a function call is defined by
merely looking up a set of instances in a relation
table or by actually computinginstances with complex algorithms and auxiliary data structures. Second, using genetic accesser functions for retrieving
the objects that are directly set into relation to a specific individual allows a lot of error checkingcodeto
be automatically generated. A unified interface for
accessing the services that an object provides hides
manyrepresentation details whichare irrelevant from
a moreabstract perspective.
Althoughthe logical semantics of Description Logics
(DL)modelingconstructs is a big plus, to ensure decidability of the subsumptionproblem, the expressiveness of the logical language must be limited. The
consequenceis that in a real application without toy
problems, currently not all aspects can be formally
For example,in a graphical user interface, the drawmodeled with DL constructs. This means that proing function for an object might depend on the
grammingis still necessary. As a DL we use the
object’s concepts. User interface programmingis one
CLASSIC
system [9]. Reducing CLASSICto practice
of the best examplesfor the application of object-ori[1] means that the DL can be integrated into the
ented programmingtechniques. For rapid user interwhole system development approach which, at the
current state of the art, uses object-oriented modeling. face development however, an existing UIMSmust
In this paper, the CLOSOOPperspective will be used be reused. UIMSsprovide powerful programming
[10]. Thepaper presents an object-oriented programming abstractions which are modeledwith the object-orilayer for CLASSIC.
It assumes basic knowledgeabout ented representation techniques (e.g. for CLOSthe
1CLOS[3].
UIMSCLIMmight be used [7]). There is no way to
rebuild these software libraries with CLASSIC
or
The integration of CLASSIC
and 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 CLASSIC
individuof an application is inadequate as well. Unfortuals just like CLOSinstances. The "services" of an
nately, managing multiple "copies" of the same
object are accessed only by the use of generic funcobject is a direct contradiction to the principles of
tions. This meansthat the relational part of CLASSIC
object-otiented programming.Thus, for rapid applishould be hidden behind a functional layer because,
cation development, object-oriented programming
from a software engineering point of view, dealing
techniques must be madeavailable to CLASSIC
indiwith individuals and relations earl be quite cumberviduals. The next chapter discusses an approach that
somefor at least two reasons: First of all, froma funcdemonstrates how this can be achieved with an
extension to CLASSICthat uses CLOS-like genetic
1. Thispaperis a shortened
andrewrittenversionof a paperpre- functions to access information about an individual.
sentedat OOPSLA’96
[5]. Theextensionsfor the CLASSIC
sysIt will be shownthat the implementation of CLAStempresented
in this paperare availablefromthe author[6].
SIC methoddispatch can be surprisingly simple.
- 170-
2. Integrating
ated. If they do not already exist, corresponding
2generic functions are automatically generated.
OOPand DL
Generic functions for Description Logics have also
been developed in the LoomSystem [2]. Methoddispatch for individuals is provided by specific genetic
functions which dispatch on ABoxobjects but not on
CLOSobjects. Loomalso supports CLOSclasses for
the implementation of ABoxindividuals but only a
limited sort of reasoning is implemented on these
instances (no dynamic reclassification by forward
inferences).
The first role option :single-value-p specifies
whether a single value or a set of values should be
returned by the role reader function. The other option
:error-if-null
is used to insert code for error
checking to avoid an empty set to be returned. The
following example illustrates the use of defineaccessor. For concept and role declarations the
KRSSsyntax is used [8].
Theapproachpresented in this paper clearly separates
CLASSICand CLOSbut provides a unified way to
access the services of both systems.
2.1. Accessors: A Functional Interface to a
Knowledge Base
CLASSIC
itself provides a relational interface for
retrieving and addingrole fillers. Givenan individual
and a role, the set of fillers can be retrieved: (clfillers<ind><role>). In manycasesonlyone
filler is returned. However,the result will alwaysbe a
set (actually a list) and the function first must
applied to get the list element itself. To hide the
repeating access to the first element, an additional
function will have to be written. Furthermore,in some
circumstances,it will be considered as an error if the
filler is not known.Unfortunately, additional code
mustbe written to checkthis. If nil (the emptyset)
returned, an error is likely to occur in subsequent
function calls whenan individual is expected. Again,
code must be written to avoid this. Instead of writing
this code manually, a more general mechanismis
advantageous. The way to access individuals should
be declaratively defined using generic functions and
corresponding low-level code for methods should be
automatically generated. The declaration form
defineacces sors has been introduced to specify
the access to individuals in that way.
(define-accessors<concept-name>
(<role-name><accessor-name>
[ :single-value-p<boolean> ]
[ :error-lf-null<boolean> ] )
(define-primitive-concept
ship classic-thing)
(define-primitive-role
has-position-xnil)
(define-primitive-role
has-position-ynil)
(define-accessorsship
(has-position-xposition-x
: single-value-p
t
:error-if-nullt)
(has-position-yposition-y
: single-value-p
t
:error-if-null
t)
As in CLOS,for accessing information of an object,
define-accessors
defines methods for generic
functions. Additional methods might be written by
the programmer(e.g. around methods or after and
before methods). CLASSICindividuals require
another dispatch mechanismwhich is realized by
extended generic functions.
2.2.
Generic Functions and Methods
The extended generic functions presented in this
paper can dispatch on CLASSICconcepts or CLOS
classes or both. The form define-generic- function is used to define a generic function with dispatching extended to CLASSIC
individuals.
The argument list of define-generic-function
indicates which arguments expect CLASSIC
dispatch
and which arguments use standard CLOSdispatch.
(define-generic-function
<function-name>
(<dispatched-argument-description>
...
[ <other-argument>... ] )
[ <option>...] )
A description for a dispatchingargumentis a list consisting of an argumentnameand a dispatch indicator
...)
For each role description mentionedafter the concept
name, a reader method and a serf writer method for
the generic function <accessor-name> is gener-
2. Theexplicit declaration of a generic aeeessor function is neeessary, for instance, whena special methodcombinationthat differs from the standard methodcombinationis to be used [10].
- 171-
(either :clos or :classic). Just as defgeneric
CLOS,define-generic-function alSO supports ordinary argumentswithout specializer (called
other-arguments). The optionsfor definefrom
generic-function are the same as for defge-
function can be defined as follows (comparethis to
initialize- instance from CLOS).
(define-methodinitialize-individual:after
((ind <concept-name>)&rest initargs)
., ,)
Initialization arguments can also be given to create-individual.
The list of "initargs" is a
sequence
ofrolenames
andcorresponding
setsof iniMethodscan be definedwith the form definetial
fillers)
neric.
Note that methodcombinations are also supported.
method.
(define-method<function-name>[ <qualifier>
( <dispatched-argument>
...
[ <other-argument>... ] )
2.4. Computation of the Concept Precedence
List
The TBoxdefines a partial order relation between
The syntax of a dispatched argument in a method concepts (subsumptionrelation). In order to define
parameterlist is identical to the syntax of arguments howmethoddispatch is handled, the multiple inheritfor defmethod of CLOS. The <qualifier> indiance lattice must be serialized by a concept prececates 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 function call is computed(see the detailed introduction in
from above.
[3]). A valid concept precedence list is any total
(define-generic-function
pos ( (ship :classic)
ordering
that obeys all partial orders defined by the
(deflne-method
pos ( (s ship)
(values(position-xs) (position-ys)
TBox.However,by this requirement only a small set
of constraints are defined. There are still several dif(define-generic-function
draw ((ship :classic)
ferent approaches to serialize a concept lattice. In
(stream :clos)))
CLOS
the notational order of superclasses in a class
(deflne-methoddraw ((ship ship)
(stream graphic-stream))
definition defines a set of additional order constraints.
, ,,)
However,from the viewpoint of Description Logics,
Ship is a CLASSICconcept(see above) and the direct superconcepts (the least general subsugraphic- stream is a CLOSclass.
mers) are unordered. Therefore, in the approach presented in this paper, the relation of parents with
2.3. Individual Creation and Initialization
respect to methoddispatch is left undefined. ProceCreating individuals using the primitives supplied by dural code must not depend on any notational order
between concept parents.
CLASSIC
(or KRSS)is somewhatcrude. From a software engineering point of view, a protocol for indi3. Implementation of Method Dispatch
vidual initialization
is needed. For individual
creation,
a function create-individual
with
A straightforward implementation for method disparameters(concept-name
&optional ( indpatch with individuals can be provided. CLASSIC
name (gensym)) &rest initargs) has
dispatch is reduced to CLOSdispatch.
supplied.
¯0 0 )
Whenan individual is created with create-individual,
the generic function initialize-individual is automatically called. A method for this
3. Theset of initial fillers for a role is representedby a list. If a
non-list is used, a singleton list is automaticallycreated.
- 172-
3.1. Reducing CLASSIC dispatch
dispatch
to CLOS
(DEFMETHOD F-METHOD
( (A
(# : TYPE6807 <CONCEPT-NAME>)
(B <CLOS-CLASS>)
The implementation of generic functions and method
dispatch for CLASSICis quite simple. 4 The form
...)
define-generic-function
is used to declare
which parameters are handled as ordinary CLOS The methodis defined for the "real" generic function
with suffix METHOD.
In the example, the specializer
instances and which parameters are CLASSICindiship
has
been
"moved"
to the second parameter. For
viduals. As a side effect of this declaration, a new
the original parameter no specializer is defined. It
function is created (a simple Common
Lisp function).
This "wrapper" function calls another function with specializes on t, the most general type in Common
the same nameconcatenated with the suffix METHOD. Lisp, and therefore, this parameter has no "discrimiThis function internally represents the generic func- nating power". Nevertheless, the original instance
tion and implements the method dispatch. For must be passed as an argument. In the body of the
method, the CLASSICindividual must be bound to
instance, the macroform:
IND.The corresponding additional parameter is used
(define-generic-function
only
for dispatching (its system-generated nameis
( (a :classic)
(b :clos)))
unintemed).Since the substitute specializer must be
CLOSclass (here the class A is used), for every
expands into
named CLASSICconcept a corresponding CLOS
( PROGN
(SETF (GET ’F :ARGUMENT-SIGNATURE)
class is automaticallycreated. The set of superclasses
’ ( :CLASSIC:CLOS)
of such a class is computedon the basis of the TBox
(DEFGENERIC F-METHOD (A # :TYPE6806 B)
classification process. Note that the list of super(DBFUN F (A
classes of a class might dynamically change whena
(FUNCALL (FUNCTION F-METHOD)
A
defined concept is automatically inserted into the
(COMPUTE- TYPE-ARG A)
subsumptionhierarchy by TBoxclassification.
B)))
The internal function F-METHOD
is applied to the
same argumentsas the wrapperfunction, but for each
parameter, which uses CLASSIC
dispatch, an additional parameter is inserted (for a this will be
#:type6806). For each CLASSICindividual,
an
associated CLOSinstance is computed with compute-type-arg. In a method definition, the additional argumentsare used for the "real dispatching".
Note that normal CLOSarguments are treated as
usual. The methoddefinition
The function compute-type-arg
(see the expansion of define-generic-function)
computesa
CLOSplaceholder
fora CLASSICindividual.
The
ideabehind
compute- type- arg is to get the concept of a CLASSIC
individual
(classic:cl-indparents), to derive a corresponding
CLOSclass,
andtousetheclass
prototype
ofthisclass.
Oneproblemis thata CLASSIC
individual
maybe subsumed
by more than one named concept, i.e. classic : cl-
expands into
ind-parentsreturns a list of concepts. Whenthis
happens, a new anonymousCLOSclass with corresponding superclasses must be created on the fly. The
prototype object of this class will then be used. A
memoization scheme (with a hash-table *classtable*) is used to avoid inflationary class creation.
4. Themain~eaisinspiredby~eimplemenmfion
~p~senmfiontypedispamh
M CUM(define-presentationgeneric-function
~ddefine-presentationmethod).
(defun compute-type-arg (ind)
(or (classic: :di-clos-instance ind)
(let ( (class-names
(mapcar # ’ classic : cl-name
(classic:cl-ind-parentsind) )
(if (null (rest class-names))
( find-class -prototype
(define-method
( (a <concept-name>)
(b <clos-class>)
,,,)
- 173-
(find-class(first class-names)
(let ((class (gethash class-names
*class-table*
))
( if class
(find-class-prototype
class)
(let* ( (class-name(gensym))
(class (find-class
class-name)
)
(ensure-clos-class
: name class-name
: superclassesclass-names)
(setf(classic: : di-clos-instance
ind)
( find-class-prototype
(find-class
type-name))
(setf (gethash class-names
*class-table*)
class)
(find-class-prototype
class)) ) )
three times slower than directly using CLASSIC’s
retrieval functions on the sameprocessor.
4.
Summary
The mainthesis of this paper is that in order to use
Description Logics in practical applications, a seamless integration with object-oriented system development methodologies must be realized. Extended
generic functions and multimethods with CLASSIC
dispatch not only allow an incremental way of software definition. In addition to this, they can even
been seen as a form of defining assertions that
enforce a safer systemarchitecture also for the procedural parts (the sameholds for CLOS
[4]).
References
With access to the internal data structures of CLASto Practice:
SIC (classic: : di- clos- instance),an individ- [1] Brachman,R.J., "Reducing"CLASSIC
Knowledge
RepresentationTheoryMeetsReality, in:
ual can be directly associated with its CLOS
Prec. KR’92Principles of Knowledge
counterpart, i.e. the procedure compute- type- arg
RepresentationandReasoning,Nebel,B., Rich, C.,
Swartout,W.(F_xls.) Morgan
Kaufrnann
Publ., 1992,
is used only whenthe individual is reclassified.
pp. 247-258.
CLASSIC
has been extended to reset the association
[2] Brill, D., LoomReferenceManual,Version2.0,
between an individual and its CLOSrepresentative
USC/ISI,4676AdmiraltyWay,Marinadel Rey, CA
90292, December,1993.
whenthe individual is reclassified.
[3] Keene,S.E., Object-OrientedProgramming
in
The definition of compute-type-arg
indicates that
CLOS:A Programmer’sGuide to CLOS,AddisonWesley,1989.
the straightforward implementation of CLASSIC
dis[4] Lamping,J., Abadi,M., Methodsas Assertions,
patch comesat a certain cost. In addition to static
XeroxPale Alto ResearchCenter, available as:
ftp ://parcftp. xerox, com/pub/
costs for the definition of CLOSclasses for named
openimp I ementat ion s/methods - as CLASSIC
concepts, there are some initial dynamic
assertions, ps. Z.
costs:
[5] M611er,R., A FunctionalLayerfor Description
Logics: KnowledgeRepresentationMeetsObject¯ some calls to retrievalfunctions (classic:clOriented Programming,
in: Prec. OOPSLA’96,
in
name, classic : cl- ind-parents),
press.
R., ExtendingCLASSIC
with Generic
¯ a complexhashing operation over a list of sym- [6] MOiler,
Functions and Methods, http://kogs bols,
www. informatik,
uni-hamburg, de/
~moeller/, 1996.
¯ possibly a dynamiccreation of a CLOSclass,
Systems:
[7] M611er,R., User Interface Management
The
CLIM
Perspective,
http
://kegs¯ the access to the CLOSclass prototype,
w-w-w, informatik,
uni-hamburg,
de/
~moeller/uimsclim/climintro,
html,
¯ and an additional CLOS
dispatch step for the sub1996.
stitute argument.
P.F., Swartout,B., Description
[8] Patel-Sclmeider,
Logic
Specification
fromthe KRSSEffort,
Furthermore, a lot of garbage is created (mapcar).
Measurements on a Symbolies MacIvory-Model-3
indicate that a dispatched access to a relation with a [9]
generic function created by define-accessors
takes less than one millisecond. This is approximately
ksl. stanford, edu :/pub/knowledgesharing/papers/dl- spec. ps.
Resnick,L.A., Borgida,A., Brachman,
R.J.,
McGuiness,
D.L., Patel-Schneider,P.F., Zalondek,
K.C., CLASSIC
Description and ReferenceManual
for the Common
Lisp Implementation,Version2.2,
1993.
Lisp - The Language,Second
[10] Steele, G.L., Common
Edition, Digital Press, 1990.
- 174-