Available online at www.sciencedirect.com

www.elsevier.com/locate/knosys

Knowledge-Based Systems 21 (2008) 391–397

Using frames for knowledge representationin a CORBA-based distributed environment

Milko Marinov *

Department of Computer Systems, University of Rousse, 8 Studentska Street, 7017 Rousse, Bulgaria

Received 25 March 2006; accepted 20 February 2008Available online 29 February 2008

Abstract

Frame knowledge model provides a natural way of clustering knowledge and particularly dynamic rules around frames which in turnprovides the natural way of distributing knowledge among networks hosts. Frame knowledge representation is very similar to traditionalobject-oriented approach. In the present paper the general features of the frames are considered. The basic principles and the architectureof the software tool for constructing knowledge-based systems are discussed. The application of planning techniques to maintain theframe hierarchy model is specified and further developed by defining a generalized algorithm of the Planner and Executor.� 2008 Elsevier B.V. All rights reserved.

Keywords: Frame knowledge representation; CORBA-based architecture; Planning techniques

1. Introduction

Frame knowledge representation is one of the primarytechnologies used for large scale knowledge representationin artificial intelligence (AI). Frame knowledge technique isused to represent knowledge in many information andexperts systems. The theory of frame, which provides arather abstract idea, is introduced by Minsky in [13] in1974. To use frame in real applications, a more concretedesign is required. In the past few decades AI researchersin knowledge representation have implemented over 50frame knowledge representation systems [18,21,22]. A fewlarge hybrid tools such as KEE, ART, SRL and PRED[3,8,23] represent facts as frames. A number of frame lan-guages have been developed in recent years to supportknowledge-based systems [1,3,11,20]. The idea of a framesystem as a way to represent declarative knowledge hasbeen encapsulated in a series of frame-oriented knowledgerepresentation languages. Examples of such languagesinclude KRL, FRL, RLL, KL-ONE, KRYPTON andFRAMEKIT [6,9,21,22]. FLORID [1] is a partial imple-

0950-7051/$ - see front matter � 2008 Elsevier B.V. All rights reserved.

doi:10.1016/j.knosys.2008.02.003

* Tel.: +359 82 888 356; fax: +359 82 845 708.E-mail address: MMarinov@ecs.ru.acad.bg

mentation of the features and syntax defined by F-logic.FLORID supports a powerful logic, departing form aframe-based knowledge representation scheme, adoptinga style of programming that mixes intensional and exten-sional definitions and supporting higher order syntacticconstructions. The notion of schema is formed by the def-inition of class signatures and class hierarchies, and no dis-tinction is made between data and schema declarations.

The common parts of the frame model which are sharedby many systems are based on the knowledge model of theOpen Knowledge Base Connectivity (OKBC) which aimsto give a common standard on the design of knowledgemodels and access interface for frame-based knowledgesystems. OKBC is a protocol for accessing knowledgebases in knowledge representation systems [24]. It consistsof set of operations that provide a generic interface to theunderlying knowledge representation systems. Protege-2000 is an OKBC-compatible knowledge-base-editing envi-ronment [15,16]. The goal of this system is to achieve inter-operability with other knowledge representation systems.The knowledge model of Protege-2000 is frame-based, withunits like classes, slots, facets, axioms and instances. Clas-ses are concepts in the domain. Slots are properties or attri-butes of classes. FramerD is a distributed object-oriented

392 M. Marinov / Knowledge-Based Systems 21 (2008) 391–397

database designed to support maintenance and sharing ofknowledge bases [2]. Unlike typical object-oriented dat-abases, FramerD is optimized for pointer-intensive datastructures used by semantic networks, frame systems, andmany intelligent agent applications. FramerD provides basicoperations on units and slots: getting slot value, testingwhether the slot includes a value, adding an object to the slotvalues, and removing an object from the slot values. Concep-tually Oriented Design/Description Environment (CODE4)is a general purpose knowledge management system [4]. Theknowledge representation used in CODE4 is based on con-cepts of frame, conceptual graph, object orientation anddescription logic. It differs from typical frame-based systemsin the generality and uniformity of the knowledge unit inCODE4, called concept. Statements are treated as concepts(with the subject role) that link properties (with the predicaterole) to concepts. Soshnikov [5] proposes a JULIA softwaretoolkit for building embedded and distributed knowledge-based systems. The architecture is based on frame knowledgerepresentation and production rules. The approach allowscombining in one model static knowledge in the form of slotvalues, structural knowledge in the form of frame hierarchy,and dynamic knowledge in the form of attached procedures.The main feature of this toolkit is the ability to be distributedover the network and share different knowledge typesthrough the mechanisms of distributed frame hierarchiesand remote rules.

The Common Object Request Broker Architecture(CORBA) [10,19] has been proposed as a standard by theObject Management Group (OMG). CORBA is middle-ware that enables interoperability and supports distributedobject computing. Many issues discussed in the distributeddatabase systems literature [7,14,17], are also relevant todistributed knowledge-based systems, namely, the globalschema definition, communication among local databases,fragmentation, allocation and heterogeneity. The heteroge-neity to be treated by a distributed knowledge-basedsystem exists at four levels [25]: platform level, communica-tion level, database system level and the semantic level.CORBA provides implementation and platform transpar-ency. An object’s interface is defined through the CORBAInterface Definition Language (IDL) that hides the under-lying object implementation. A client of the object uses thisinterface to invoke methods. It does not know nor careabout the hardware and software environment of theobject. This solves the platform heterogeneity problem.On the other hand CORBA provides location transparencythat allows clients to access objects using CORBA namingservice and their object reference independent of their loca-tion and communication protocols. This solves the hetero-geneity problem at the communication level. The third levelof heterogeneity is among the database management sys-tems based on different data models and query languages.The semantic heterogeneity appears among independentlydesigned knowledge bases. Semantics of distributed infer-ence in the model of distributed frame hierarchy is basedon inference semantics of systems with frame knowledge

representation. In order to establish communicationbetween knowledge base and database systems, each com-ponent must depend on its own representation structuresand inference methods.

The present paper considers an architecture and imple-mentation of a distributed CORBA-based toolkit, whichprovides the basic set of functions for creating and manip-ulating frames. The tool allows domain experts to createappropriate frame-based knowledge quickly and withoutknowledge of a programming language. The paper is orga-nized as follows. Section 2 provides some specifications ofthe general features of the frames. The architecture andimplementation of the tool are described in the next para-graph. The maintenance of inheritance structure in theframe hierarchy model is considered in Section 4. The con-clusion summarises the author’s contributions and hisfuture research intentions.

2. General features of the frames

A frame is a collection of attributes (usually called slots)and associated values (and possibly constraints on values)that describes some entity in the world. A frame describesan entity in some absolute sense or it represents the entityfrom a particular point of view. Originally conceived byMinsky [13,21], the frame representation was formulatedas a means of describing how humans might representand use knowledge. The frame is described as a networkof nodes and relations. The top levels of the frame repre-sent attributes, which are always true about the situationand so remain fixed. Lower levels of the frame have termi-

nals or slots, which must be filled by specific instances ordata. Each terminal may specify conditions requiring smal-ler sub-frames. Collection of related frames may be linkedto form a frame-based system.

In many ways a frame represents a record. Like arecord, a frame consists of field-like components. Thesecomponents contain data. Unlike a record containingfields, the elements of a frame are slots, facets and data.Frames are more stratified than records. A frame can haveone or more slots. Each slot contains a particular kind ofdata. If a frame describes an object, slot would describe acharacteristic of the object. The slots in the frame containinformation such as:

� Frame identification information.� Relationship of the current frame to other frames.� Descriptors of requirements for frame match. These

requirements may be used to determine when newobjects fit the stereotype defined by the frame.� Procedural information on use of the structure

described. An important feature of frames is the abilityto attach procedural code to a slot. If more informationis needed, an if_needed slot can be used to activate anattached procedure to fill in the slot. This concept ofprocedural attachment is closely related to the conceptof demons.

IIOP

IIOP

Component(Client)

ORB

TCP/IP Network

Component(Client)

User Interface

Component(Client + Server)

ORB

Knowledgebase editor

Component(Server)

Inference engine

Knowledge base

Frame Hierarchy Model

Planner & Executor

Fig. 1. Architecture of a distributed knowledge-based system.

M. Marinov / Knowledge-Based Systems 21 (2008) 391–397 393

� Frame default information. These are slot values thatare taken to be true when no evidence to the contraryhas been found.� New instance information. Many frame slots may be left

unspecified until given a value for a particular instanceor when they are needed for some aspect of problemsolving.

A facet is used to represent a characteristic of a slot.This may be a little confusing, as fields do not usually havecharacteristics, only values. In fact, the most basic kind offacet a slot can have is the value facet. The value facet is thefacet of a slot used to hold the data for the slot. A demon isa procedure that is invoked as a side effect of some otheractions in the knowledge base. Demons are procedures,which are activated at any time during a program executiondepending on conditions evaluated in the demon itself.Examples of demons used in conventional programminginclude error detection, default commands and end of filedetection.

3. Implementation of the tool

Fig. 1 shows the most important modules that make upa distributed knowledge-based system utilizing CORBAarchitecture. The user interacts with the system through auser interface that simplifies communication and hidesmuch of the system complexity. The knowledge base con-tains the problem-solving knowledge of the particularapplication. This knowledge is represented by frames inthe frame-based system. The knowledge base contains bothgeneral knowledge as well as case-specific information (thefacts, conclusions and other information relevant to thecase under consideration). This includes the data given ina problem instance, partial conclusions, and dead ends inthe search process. This information is separate from thegeneral knowledge base. In this paper an attempt is madeto incorporate the artificial intelligence techniques intothe design of frame hierarchies. We propose to use plan-ning techniques (this issue is the subject of discussion inSection 4) to create the frame hierarchy model, used asinput data by the inference engine. The inference engine

applies the knowledge to the solution of actual problems.This is an interpreter for the knowledge base. Forwardchaining is usually used when a new fact is added to theknowledge base and we want to generate its consequences,which might result in other new facts. For a certain thingwe want to prove, the backward chaining inference findsimplication facts that would allow us to conclude it. It isused for finding all answers to a question posed to theknowledge base. Knowledge base editor assists in the addi-tion of new knowledge, maintains correct knowledge struc-ture and performs consistency checks on the updatedknowledge base.

The CORBA architecture is designed to support the dis-tribution of objects implemented in a variety of program-ming languages. A fundamental part of the CORBA

architecture is the Object Request Broker (ORB). The pri-mary responsibility of the ORB is to resolve requests forobject references, enabling application components toestablish connectivity with each other. The major benefitoffered by the ORB is its platform-independent treatmentof data. The Interface Definition Language (IDL) is usedto define interfaces between application components. Allcomponents of the architecture and all object type definedin the architecture are defined and constructed as moduleswith interfaces, which are specified in the IDL. CORBAdefines a wire protocol for making requests to an objectand for the object to respond to the application makingthe request. The Internet Inter-ORB Protocol (IIOP)ensures interoperability between client application and ser-ver-based objects. The IIOP runtime communication pro-tocol provides a standard based data representation,

394 M. Marinov / Knowledge-Based Systems 21 (2008) 391–397

which allows the objects to be located anywhere whileremoving the need for network programming.

In a CORBA application, any component that providesan implementation for an object is considered a server, atleast where this object is concerned. Being a CORBA servermeans that the component (the server) executes methodsfor a particular object on behalf of other components(the clients). A client is a component that consumes servicesprovided by a server or servers. Frequently, an applicationcomponent can provide services to other application com-ponents while accessing services from other components. Inthis case, the component is acting as a client of one compo-nent and as server to the other components (Fig. 2). In fact,two components can simultaneously act as clients and serv-ers to each other. A server is defined as an interface inCORBA IDL. Data passing between the client and the ser-ver is defined as IDL structures. Clients communicate withthe object through an object reference. When an operationis performed on the object reference, network communica-tion occurs, operation parameters are sent to the server andthe actual distributed object executes the operation. It thenreturns any appropriate data to the client. In the proposedarchitecture the frame objects are passed by reference. Thismeans that the object itself remains ‘‘in place” while anobject reference for that object is passed. Operations onthe frame object through the object reference are actuallyprocessed by the object itself. On CORBA clients, the stubs

are the automatically client-side generated code from anIDL interface, it is a local mirror object of its correspond-ing remote server-object. The stub acts as a proxy for anobject that may be implemented by the same process,another process, or on another (server) machine. The skel-

etons are the automatically server-side generated code froman IDL interface providing the code needed to register andactivate an object.

In order to create a frame database the requirements inmany cases do not correspond to all requirements fordevelopment of a standard database. This is due to thefact that frame database can be neither included in therelational model, nor in the hierarchical model. The framedatabase is closest to the object data model, because the

Stub

Client-object

pure-client

ObjeImplem

tatio

Skele-ton

client-server

Server-object

Client-object

Stub

remoteinvocation

Fig. 2. CORBA clie

object model is a first attempt to relate the programmodel to the database model since the object-orienteddesign represents abstract data types and inheritancemechanism in ways that traditional data models do notsupport well. By creating a new frame database, a FRMfile is created first. The purpose of the file is to save theframe database name as its own name, as this file hasthe role of a file for additional information. After the cre-ation of the FRM file, the files storing the table data arecreated. Each frame database supports four relations. Thenames of these files are formed by adding a suffix (F – forframes, S – for slots, A – for facets and V – for values) tothe frame database name. The class inheritance in theframe database is defined as IDL interfaces in the follow-ing manner:

interface Frame{

attribute string frameName;. . .. . .. . .. . .. . .. . .. . .. . .. . . . . .

};interface Slot: Frame {attribute string slotName;. . .. . .. . .. . .. . .. . .. . .. . .. . . . . ..

};interface Facet: Slot {attribute string facetName;. . .. . .. . .. . .. . .. . .. . .. . .. . . . . ..

};interface Value: Facet {attribute string value;htypei valueType;. . .. . .. . .. . .. . .. . .. . .. . .. . . . . ..

};

The hierarchy is rooted at a node representing the entireframe database. Descending from the root node is an edgeconnecting the root to a node for each frame in the data-base. Each frame may have one or more slots. For each slotbelonging to a frame, there is a node and an edge connect-ing the frame to the slot node. Likewise, each slot can havezero or more facets.

cten-

n

ObjectImplemen-

tation

Skele-ton

Server-object

pure-server

nts and servers.

M. Marinov / Knowledge-Based Systems 21 (2008) 391–397 395

The frame editor implements most of the basic framemanipulation functions required for building databasesof frames. These include creating a new frame database,opening an existing frame database, writing and deletingframe information. To define a frame the user normallyfollows these steps: define slots, define facets, define value.There are four fields, which can be used to enter frameelements. The first field is for specifying the name of anew frame. The second field is used to name slots belong-ing to the frame. The third field is for specifying facets ofthe slot, and the last field is for entering the value of thefacet. Facets can have more than one value, so adding avalue to a facet with existing values causes the value tobe appended to the existing values in the frame. Usersmay modify any locally defined slot or inherited slot.Modifying an inherited slot causes the new definition tobe locally defined. A complete view of the database is pro-vided in the frame contents list. This is a listing of allframes, slots, facets and values in the frame database.They are arranged by frame, with slots, facets and values,listed under the frame.

Once a knowledge description is created it can be custom-ized to capture a particular aspect of the knowledge. This isachieved by locking slots in one of the following ways:

(1) the user sees the slot and has the option to provide avalue;

(2) the user sees the slot and must provide a value;(3) the user does not see the slot.

4. Maintenance of frame hierarchy model

Frame-based systems support class inheritance. The slotand default values of a class frame are inherited across theclass/subclass and class/member hierarchy. In the contextof frames inheritance means one frame can inherit informa-tion from another frame. This does not happen automati-cally – a special slot (named a_kind_of) is needed for thispurpose. An a_kind_of slot represents an edge betweenframes. Instead of a graphical representation (an arrow),frames are connected by naming one frame in anothera_kind_of slot. When an instance of the class frame is cre-ated the system will attempt to fill its slots, either by query-ing the user, accepting the default value from the classframe, or executing some procedure or demon to obtainthe instance value. The inheritance implies that a derivedclass frame inherits data and operations from a base classframe. The derived class frame may itself be a base classfor another layer of inheritance.

Developing a plan is defined as finding a sequence ofactions to accomplish a specified goal [12]. A planningproblem must first have a vocabulary of symbols andnotion in which the initial state, goal conditions andoperators may be specified. The goal of the planningproblem will be specified as an expression consisting oflogical connectives (AND) and instances of class frames.

The Planner constructs the plan which in itself is asequence of steps aimed at achieving the global goal.In the domain of frame inheritance, the global goalcan be defined as the list of all leaf nodes (the frameswithout derived frames). Each step is connected with cor-responding actions. In our case the meaning of ‘step’ isto be connected with a corresponding frame for whichthe preconditions (base frames) and the expected results(derived frames) have been formed. The plan is devel-oped by the Planner through simulation of the derivedframes of the current frame over the Frame Hierarchy

Model (FHM). Starting with the current state of theFHM, the Planner is trying to find such a sequence offrames through which the global goal will be achieved.By using the base frames (preconditions) and the derivedframes (expected results) of the frames, the Planner canimplement different branches in the plan. A successfulplan is the one which can be applied to the current stateof the FHM and can achieve the global goal. The plan isa directed acyclic graph consisting of a set of nodes anda set of arcs. An arc from node A to node B means thatthe fulfilment of A has to precede the fulfilment of B.The nodes of the graph are two types: frames and goals.The goal node which precedes a particular frame nodecorresponds to the base frames (preconditions). The goalnode which follows a particular frame node correspondsto the derived frames (expected results) which are thebase frames for the following frame node.

Let us discuss in greater detail the summarized algo-rithm of the Planner (Fig. 3). The algorithm uses the fol-lowing local data structures: CurFrame – the currentframe from the frame hierarchy; BaseList(CurFrame) – alist of the CurFrame base frames; BaseFramesList – a tem-poral list structure; InheritTable – a table with the follow-ing structure:

InheritTable:attribute string FrameName;attribute sequence hstringi BaseFrames;attributesequence hstringi DerivedFrames;

In the initial state the DerivedFrames list is empty, i.e.for each frame only the base frames are defined.

The Executor uses a plan created by the Planner. Ifserious problems arise during the execution of the initialplan, the Executor may reinvoke the Planner to revisethe plan. If the plan fails then there are integrity con-straints in the frame inheritance. The Executor algorithm(Fig. 4) is based on a procedure for producing a linear ortotal ordering of the nodes of a directed graph whose arcsrepresent a partial ordering relation of the nodes. TheExecutor algorithm uses the following local data struc-tures: GoalFrames – the global goal is defined as a listof all frames with base frames, but without derived framesin the FHM; InitList – a list of frames which defines theinitial state; DeriveList(CurFrame) – a list of the Cur-

Frame derived frames.

Let BaseFramesList be empty; Let BaseList(CurFrame) be empty;Select CurFrame from the set of frames, incorporated into the FHM;

CurFrame has to be with at least one base frame; Copy InheritTable.BaseFrames[CurFrame] to BaseList(CurFrame);Copy BaseList(CurFrame) to BaseFramesList;While BaseFramesList is not empty Do {

While BaseList(CurFrame) is not empty Do {

Add CurFrame to the InheritTable.DerivedFrames[x]of the correspondent base frame X;

Delete the base frame from BaseList(CurFrame);} Set a frame from BaseFramesList to CurFrame;Delete CurFrame from BaseFramesList;An attempt is made by continuing the planning in depth; Copy InheritTable.BaseFrames[CurFrame] to BaseList(CurFrame);Copy BaseList(CurFrame) to BaseFramesList;

}

Fig. 3. Planner algorithm.

Create GoalFrames;

While GoalFrames is not empty Do {

Planning is done following the algorithm described in pseudo-code in Fig. 3, depending on the initial state of the Frame Hierarchy Model orthe state at which the plan has failed having in mind the global goal.A new plan P is generated;

For each frame X of PIf InheritTable.BaseFrames[x] is empty

then Add X to InitList;While InitList is not empty Do {

If GoalFrames is empty, TERMINATE;Select a frame from InitList and set it to CurFrame;Delete CurFrame from InitList;Copy InheritTable.DerivedFrames[CurFrame] to

DeriveList(CurFrame);While DeriveList(CurFrame) is not empty Do { Select a frame from DeriveList(CurFrame) and set it to CurFrame; Delete CurFrame from DeriveList(CurFrame); If CurFrame is in GoalFrames then

Delete CurFrame from GoalFrames;}

} }

Fig. 4. Executor algorithm.

396 M. Marinov / Knowledge-Based Systems 21 (2008) 391–397

The described generalized algorithms of the Planner andExecutor do not include all possible branches in them. Theauthor provides this part of the algorithms which might beof interest to a wider range of readers.

5. Conclusion

In the present paper an architecture of a tool and itsimplementation has been proposed. The tool has a highlyinteractive and user-friendly interface. It provides thedomain experts with a simple and powerful tool to manip-

ulate frame database. The most important characteristicsof the proposed interactive tool are that it:

� allows multiple inheritance;� has some mechanism for internal consistency checking.

Frames can be added, retrieved, changed and deleted.The tool maintains the database integrity and framesrelationships can be monitored. It is possible to navigateamong the frames;� views the content of the frame database as a hierarchical

structure;

M. Marinov / Knowledge-Based Systems 21 (2008) 391–397 397

� is built on a modular object-oriented base so that thetool could be decomposed in such a way as to make iteasily extensible. The experimental prototype of thetoolkit was created. The toolkit is implemented in Bor-land C++ Builder programming environment.

The main advantage of using the planning techniques toinvestigate the inheritance between frames in the framehierarchy model is that the frame hierarchies are guidedby the global structure of the plan which is produced auto-matically by the Planner based partly on the informationabout the frame hierarchy model.

The author’s further efforts will be aimed at extendingthe functional capabilities of the toolkit prototype, improv-ing the algorithms incorporated into the inference engineand building the tool into a knowledge-based distributedinformation system to support the meta-knowledge.

References

[1] B. Ludascher, H. Himmeroder, G. Lausen, W. May, C. Schlepphorst,Managing semi-structured data with FLORID: a deductive object-oriented perspective, Information Systems 23 (8) (1998) 1–25.

[2] Beingmeta, FramerD, 2005. Available from: <http://www.framer-d.org/>.

[3] D.M. Russinoff, Proteus: a frame-based non-monotonic inferencesystem, in: Won Kim, F. Lochovsky (Eds.), Object-Oriented Concepts,Databases and Applications, Addison-Wesley, 1989, pp. 127–150.

[4] D. Skuce, T.C. Lethbridge, CODE4: a unified system for managingconceptual knowledge, International Journal of Human–ComputerStudies 42 (4) (1995) 413–451.

[5] D. Soshnikov, An architecture of distributed frame hierarchy forknowledge sharing and reuse in computer networks, in: Proc. IEEEInternational Conference on Artificial Intelligence Systems,ICAIS’02, 2002, pp. 115–119.

[6] E. Rich, K. Knight, Artificial Intelligence, McGraw-Hill, 1993.[7] E. Shakshuki, H. Ghenniwa, M. Kamel, An architecture for

cooperative information systems, Knowledge-Based Systems 16(2003) 17–27.

[8] G. Abrett, M.H. Burstein, The KREME knowledge editing environ-ment, International Journal of Man–Machine Studies 27 (1990) 103–126.

[9] K.W. Tracy, P.M. Bouthoorn, Object-Oriented Artificial Intelligence,Using C++, W.H. Freeman, 1997.

[10] M. Henning, S. Vinoski, Advanced CORBA(R) Programming withC++, Addison-Wesley Professional, 2001.

[11] M. Marinov, An interactive tool for frame representation, Informa-tion Technologies & Control 1 (2003) 16–19.

[12] M. Marinov, Analysis of planning techniques used in intelligentsystems, Automatica & Informatics, Sofia 5–6 (1997) 25–33 (inBulgarian).

[13] M. Minsky, A framework for representing knowledge, MIT-AILaboratory Memo 306 (1974).

[14] M. Stonebraker, P.M. Aoki, W. Litwin, A. Pfeffer, A. Sah, J. Sidell,C. Staelin, A. Yu, Mariposa: a wide-area distributed database system,The VLDB Journal 5 (1996) 48–63.

[15] N.F. Noy, M.A. Musen, J.L.V. Mejino Jr., C. Rosse, Pushing theenvelope: challenges in a frame-based representation of humananatomy, Data & Knowledge Engineering 48 (3) (2004) 335–359.

[16] N. Noy, R. Fergerson, M. Musen, The knowledge model of Protege-2000: combining interoperability and flexibility, 2000. Available from:<http://citeseer.ist.psu.edu/noy01knowledge.html/>.

[17] O.M. Tamer, P. Valduriez, Principles of Distributed DatabaseSystems, Prentice Hall, 1999.

[18] P. Kiatisevi, A distributed architecture for interactive robots based ona knowledge software platform, Ph.D. Thesis, Department ofInformatics, Graduate University for Advanced Studies, SOKEN-DAI, 2005.

[19] R. Geraghty, S. Joyce, T. Moriarty, G. Noone, COM-CORBAInteroperability, Prentice Hall, 1999.

[20] R.M. Kaplan, Intelligent Multimedia Systems, A Wiley Company,Jossey Bass, 1997.

[21] S.C. Shapiro (Ed.), Encyclopedia of Artificial Intelligence, Wiley,New York, 1992.

[22] S.J. Russell, P. Norvig, Artificial Intelligence: A Modern Approach,Prentice-Hall, 2002.

[23] S. Xie, D. Dumareso, P. Winne, PRED: A frame-based primitiveeditor, International Journal of Man–Machine Studies 33 (1990) 607–621.

[24] V.K. Chaudhri, A. Farquhar, R. Fikes, P.D. Karp, J. Rice, OKBC: aprogrammatic foundation for knowledge base interoperability,AAAI/IAAI, 1998 600–607. Available from: <http://citeseer.ist.psu.edu/chaudhri98okbc.html/>.

[25] X. Wu, A CORBA-based architecture for integrating distributed andheterogeneous databases, in: Proc. Fifth IEEE Int. Conf. Engineeringof Complex Computer Systems, ICECCS’99, 1999, pp. 143–152.Available from: http://doi.ieeecomputersociety.org/10.1109/ICECCS.1999.802858.