Available online at www.sciencedirect.

com

Knowledge-Based Systems 21 (2008) 391–397

www.elsevier.com/locate/knosys

Using frames for knowledge representation

in 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 2008

Available online 29 February 2008

Abstract

Frame knowledge model provides a natural way of clustering knowledge and particularly dynamic rules around frames which in turn
provides the natural way of distributing knowledge among networks hosts. Frame knowledge representation is very similar to traditional
object-oriented approach. In the present paper the general features of the frames are considered. The basic principles and the architecture
of the software tool for constructing knowledge-based systems are discussed. The application of planning techniques to maintain the
frame 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 mentation of the features and syntax defined by F-logic.

Frame knowledge representation is one of the primary
technologies used for large scale knowledge representation
in artificial intelligence (AI). Frame knowledge technique is
used to represent knowledge in many information and
experts systems. The theory of frame, which provides a
rather abstract idea, is introduced by Minsky in [13] in
1974. To use frame in real applications, a more concrete
design is required. In the past few decades AI researchers
in knowledge representation have implemented over 50
frame knowledge representation systems [18,21,22]. A few
large 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 support
knowledge-based systems [1,3,11,20]. The idea of a frame
system as a way to represent declarative knowledge has
been encapsulated in a series of frame-oriented knowledge
representation languages. Examples of such languages
include KRL, FRL, RLL, KL-ONE, KRYPTON and
FRAMEKIT [6,9,21,22]. FLORID [1] is a partial imple-
*
Tel.: +359 82 888 356; fax: +359 82 845 708.
E-mail address: MMarinov@ecs.ru.acad.bg
FLORID supports a powerful logic, departing form a
frame-based knowledge representation scheme, adopting
a style of programming that mixes intensional and exten-
sional definitions and supporting higher order syntactic
constructions. 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 shared
by many systems are based on the knowledge model of the
Open Knowledge Base Connectivity (OKBC) which aims
to give a common standard on the design of knowledge
models and access interface for frame-based knowledge
systems. OKBC is a protocol for accessing knowledge
bases in knowledge representation systems [24]. It consists
of set of operations that provide a generic interface to the
underlying 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, with
units 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

0950-7051/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved.
doi:10.1016/j.knosys.2008.02.003
392 M. Marinov / Knowledge-Based Systems 21 (2008) 391–397
database designed to support maintenance and sharing of
knowledge bases [2]. Unlike typical object-oriented dat-
abases, FramerD is optimized for pointer-intensive data
structures used by semantic networks, frame systems, and
many intelligent agent applications. FramerD provides basic
operations on units and slots: getting slot value, testing
whether the slot includes a value, adding an object to the slot
values, and removing an object from the slot values. Concep-
tually Oriented Design/Description Environment (CODE4)
is a general purpose knowledge management system [4]. The
knowledge representation used in CODE4 is based on con-
cepts of frame, conceptual graph, object orientation and
description logic. It differs from typical frame-based systems
in the generality and uniformity of the knowledge unit in
CODE4, called concept. Statements are treated as concepts
(with the subject role) that link properties (with the predicate
role) to concepts. Soshnikov [5] proposes a JULIA software
toolkit for building embedded and distributed knowledge-
based systems. The architecture is based on frame knowledge
representation and production rules. The approach allows
combining in one model static knowledge in the form of slot
values, 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 distributed
over the network and share different knowledge types
through the mechanisms of distributed frame hierarchies
and remote rules.
The Common Object Request Broker Architecture
(CORBA) [10,19] has been proposed as a standard by the
Object Management Group (OMG). CORBA is middle-
ware that enables interoperability and supports distributed
object computing. Many issues discussed in the distributed
database systems literature [7,14,17], are also relevant to
distributed knowledge-based systems, namely, the global
schema definition, communication among local databases,
fragmentation, allocation and heterogeneity. The heteroge-
neity to be treated by a distributed knowledge-based
system 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 CORBA
Interface Definition Language (IDL) that hides the under-
lying object implementation. A client of the object uses this
interface to invoke methods. It does not know nor care
about the hardware and software environment of the
object. This solves the platform heterogeneity problem.
On the other hand CORBA provides location transparency
that allows clients to access objects using CORBA naming
service and their object reference independent of their loca-
tion and communication protocols. This solves the hetero-
geneity problem at the communication level. The third level
of heterogeneity is among the database management sys-
tems based on different data models and query languages.
The semantic heterogeneity appears among independently
designed knowledge bases. Semantics of distributed infer-
ence in the model of distributed frame hierarchy is based
on inference semantics of systems with frame knowledge
representation. In order to establish communication
between knowledge base and database systems, each com-
ponent must depend on its own representation structures
and inference methods.
The present paper considers an architecture and imple-
mentation of a distributed CORBA-based toolkit, which
provides the basic set of functions for creating and manip-
ulating frames. The tool allows domain experts to create
appropriate frame-based knowledge quickly and without
knowledge of a programming language. The paper is orga-
nized as follows. Section 2 provides some specifications of
the general features of the frames. The architecture and
implementation of the tool are described in the next para-
graph. The maintenance of inheritance structure in the
frame hierarchy model is considered in Section 4. The con-
clusion summarises the author’s contributions and his
future 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 describes
an entity in some absolute sense or it represents the entity
from a particular point of view. Originally conceived by
Minsky [13,21], the frame representation was formulated
as a means of describing how humans might represent
and use knowledge. The frame is described as a network
of nodes and relations. The top levels of the frame repre-
sent attributes, which are always true about the situation
and so remain fixed. Lower levels of the frame have termi-
nals or slots, which must be filled by specific instances or
data. Each terminal may specify conditions requiring smal-
ler sub-frames. Collection of related frames may be linked
to form a frame-based system.
In many ways a frame represents a record. Like a
record, a frame consists of field-like components. These
components contain data. Unlike a record containing
fields, the elements of a frame are slots, facets and data.
Frames are more stratified than records. A frame can have
one or more slots. Each slot contains a particular kind of
data. If a frame describes an object, slot would describe a
characteristic of the object. The slots in the frame contain
information 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 new
objects fit the stereotype defined by the frame.
 Procedural information on use of the structure
described. An important feature of frames is the ability
to attach procedural code to a slot. If more information
is needed, an if_needed slot can be used to activate an
attached procedure to fill in the slot. This concept of
procedural attachment is closely related to the concept
of demons.
 M. Marinov / Knowledge-Based Systems 21 (2008) 391–397 393

 Frame default information. These are slot values that

are taken to be true when no evidence to the contrary User Interface
has been found.
 New instance information. Many frame slots may be left
Component Component
unspecified until given a value for a particular instance (Client) (Client)
or when they are needed for some aspect of problem
solving.
ORB
A facet is used to represent a characteristic of a slot.
This may be a little confusing, as fields do not usually have
IIOP
characteristics, only values. In fact, the most basic kind of
facet a slot can have is the value facet. The value facet is the
facet of a slot used to hold the data for the slot. A demon is TCP/IP
a procedure that is invoked as a side effect of some other Network
actions in the knowledge base. Demons are procedures,
which are activated at any time during a program execution
depending on conditions evaluated in the demon itself. IIOP
Examples of demons used in conventional programming
include error detection, default commands and end of file ORB
detection.

3. Implementation of the tool Component Component

Fig. 1 shows the most important modules that make up
a distributed knowledge-based system utilizing CORBA
architecture. The user interacts with the system through a
user interface that simplifies communication and hides
much of the system complexity. The knowledge base con-
tains the problem-solving knowledge of the particular
application. This knowledge is represented by frames in
the frame-based system. The knowledge base contains both
general knowledge as well as case-specific information (the
facts, conclusions and other information relevant to the
case under consideration). This includes the data given in
a problem instance, partial conclusions, and dead ends in
the search process. This information is separate from the
general knowledge base. In this paper an attempt is made
to incorporate the artificial intelligence techniques into
the design of frame hierarchies. We propose to use plan-
ning techniques (this issue is the subject of discussion in
Section 4) to create the frame hierarchy model, used as
input 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. Forward
chaining is usually used when a new fact is added to the
knowledge base and we want to generate its consequences,
which might result in other new facts. For a certain thing
we want to prove, the backward chaining inference finds
implication facts that would allow us to conclude it. It is
used for finding all answers to a question posed to the
knowledge base. Knowledge base editor assists in the addi-
tion of new knowledge, maintains correct knowledge struc-
ture and performs consistency checks on the updated
knowledge 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
(Client + Server) (Server)
Knowledge Inference engine
base editor
Frame Hierarchy Model
Planner & Executor
Knowledge base
Fig. 1. Architecture of a distributed knowledge-based system.
architecture is the Object Request Broker (ORB). The pri-
mary responsibility of the ORB is to resolve requests for
object references, enabling application components to
establish connectivity with each other. The major benefit
offered by the ORB is its platform-independent treatment
of data. The Interface Definition Language (IDL) is used
to define interfaces between application components. All
components of the architecture and all object type defined
in the architecture are defined and constructed as modules
with interfaces, which are specified in the IDL. CORBA
defines a wire protocol for making requests to an object
and for the object to respond to the application making
the 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 while
removing the need for network programming.
In a CORBA application, any component that provides
an implementation for an object is considered a server, at
least where this object is concerned. Being a CORBA server
means that the component (the server) executes methods
for a particular object on behalf of other components
(the clients). A client is a component that consumes services
provided by a server or servers. Frequently, an application
component can provide services to other application com-
ponents while accessing services from other components. In
this 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 in
CORBA IDL. Data passing between the client and the ser-
ver is defined as IDL structures. Clients communicate with
the object through an object reference. When an operation
is performed on the object reference, network communica-
tion occurs, operation parameters are sent to the server and
the actual distributed object executes the operation. It then
returns any appropriate data to the client. In the proposed
architecture the frame objects are passed by reference. This
means that the object itself remains ‘‘in place” while an
object reference for that object is passed. Operations on
the frame object through the object reference are actually
processed by the object itself. On CORBA clients, the stubs
are the automatically client-side generated code from an
IDL interface, it is a local mirror object of its correspond-
ing remote server-object. The stub acts as a proxy for an
object 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 from
an IDL interface providing the code needed to register and
activate an object.
In order to create a frame database the requirements in
many cases do not correspond to all requirements for
development of a standard database. This is due to the
fact that frame database can be neither included in the
relational model, nor in the hierarchical model. The frame
database is closest to the object data model, because the
pure-client client-server
Server-object
Object
Skele-
Implemen-
ton
remote tation
invocation
Client-object
Client-object
Stub
Stub
Fig. 2. CORBA clients and servers.
object model is a first attempt to relate the program
model to the database model since the object-oriented
design represents abstract data types and inheritance
mechanism in ways that traditional data models do not
support well. By creating a new frame database, a FRM
file is created first. The purpose of the file is to save the
frame database name as its own name, as this file has
the role of a file for additional information. After the cre-
ation of the FRM file, the files storing the table data are
created. Each frame database supports four relations. The
names of these files are formed by adding a suffix (F – for
frames, S – for slots, A – for facets and V – for values) to
the frame database name. The class inheritance in the
frame 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 entire
frame database. Descending from the root node is an edge
connecting the root to a node for each frame in the data-
base. Each frame may have one or more slots. For each slot
belonging to a frame, there is a node and an edge connect-
ing the frame to the slot node. Likewise, each slot can have
zero or more facets.
pure-server
Server-object
Object
Skele- Implemen-
ton tation
 M. Marinov / Knowledge-Based Systems 21 (2008) 391–397
The frame editor implements most of the basic frame
manipulation functions required for building databases
of frames. These include creating a new frame database,
opening an existing frame database, writing and deleting
frame information. To define a frame the user normally
follows these steps: define slots, define facets, define value.
There are four fields, which can be used to enter frame
elements. The first field is for specifying the name of a
new frame. The second field is used to name slots belong-
ing to the frame. The third field is for specifying facets of
the slot, and the last field is for entering the value of the
facet. Facets can have more than one value, so adding a
value to a facet with existing values causes the value to
be appended to the existing values in the frame. Users
may modify any locally defined slot or inherited slot.
Modifying an inherited slot causes the new definition to
be locally defined. A complete view of the database is pro-
vided in the frame contents list. This is a listing of all
frames, 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 is
achieved by locking slots in one of the following ways:
(1) the user sees the slot and has the option to provide a
value;
(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 slot
and default values of a class frame are inherited across the
class/subclass and class/member hierarchy. In the context
of 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 this
purpose. An a_kind_of slot represents an edge between
frames. Instead of a graphical representation (an arrow),
frames are connected by naming one frame in another
a_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 class
frame, or executing some procedure or demon to obtain
the instance value. The inheritance implies that a derived
class frame inherits data and operations from a base class
frame. The derived class frame may itself be a base class
for another layer of inheritance.
Developing a plan is defined as finding a sequence of
actions to accomplish a specified goal [12]. A planning
problem must first have a vocabulary of symbols and
notion in which the initial state, goal conditions and
operators may be specified. The goal of the planning
problem will be specified as an expression consisting of
logical connectives (AND) and instances of class frames.
395
The Planner constructs the plan which in itself is a
sequence of steps aimed at achieving the global goal.
In the domain of frame inheritance, the global goal
can be defined as the list of all leaf nodes (the frames
without derived frames). Each step is connected with cor-
responding actions. In our case the meaning of ‘step’ is
to be connected with a corresponding frame for which
the preconditions (base frames) and the expected results
(derived frames) have been formed. The plan is devel-
oped by the Planner through simulation of the derived
frames of the current frame over the Frame Hierarchy
Model (FHM). Starting with the current state of the
FHM, the Planner is trying to find such a sequence of
frames through which the global goal will be achieved.
By using the base frames (preconditions) and the derived
frames (expected results) of the frames, the Planner can
implement different branches in the plan. A successful
plan is the one which can be applied to the current state
of the FHM and can achieve the global goal. The plan is
a directed acyclic graph consisting of a set of nodes and
a set of arcs. An arc from node A to node B means that
the 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 node
corresponds to the base frames (preconditions). The goal
node which follows a particular frame node corresponds
to the derived frames (expected results) which are the
base 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 current
frame from the frame hierarchy; BaseList(CurFrame) – a
list 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;
attribute sequence 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. If
serious problems arise during the execution of the initial
plan, the Executor may reinvoke the Planner to revise
the 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 or
total ordering of the nodes of a directed graph whose arcs
represent a partial ordering relation of the nodes. The
Executor algorithm uses the following local data struc-
tures: GoalFrames – the global goal is defined as a list
of all frames with base frames, but without derived frames
in the FHM; InitList – a list of frames which defines the
initial state; DeriveList(CurFrame) – a list of the Cur-
Frame derived frames.
396 M. Marinov / Knowledge-Based Systems 21 (2008) 391–397

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 or
the state at which the plan has failed having in mind the global goal.
A new plan P is generated;

For each frame X of P

If 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.

The described generalized algorithms of the Planner and
Executor do not include all possible branches in them. The
author provides this part of the algorithms which might be
of interest to a wider range of readers.
5. Conclusion
In the present paper an architecture of a tool and its
implementation has been proposed. The tool has a highly
interactive and user-friendly interface. It provides the
domain experts with a simple and powerful tool to manip-
ulate frame database. The most important characteristics
of 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 frames
relationships can be monitored. It is possible to navigate
among the frames;
 views the content of the frame database as a hierarchical
structure;
 M. Marinov / Knowledge-Based Systems 21 (2008) 391–397
 is built on a modular object-oriented base so that the
tool could be decomposed in such a way as to make it
easily extensible. The experimental prototype of the
toolkit was created. The toolkit is implemented in Bor-
land C++ Builder programming environment.
The main advantage of using the planning techniques to
investigate the inheritance between frames in the frame
hierarchy model is that the frame hierarchies are guided
by the global structure of the plan which is produced auto-
matically by the Planner based partly on the information
about the frame hierarchy model.
The author’s further efforts will be aimed at extending
the functional capabilities of the toolkit prototype, improv-
ing the algorithms incorporated into the inference engine
and building the tool into a knowledge-based distributed
information 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 inference
system, 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 managing
conceptual knowledge, International Journal of Human–Computer
Studies 42 (4) (1995) 413–451.
[5] D. Soshnikov, An architecture of distributed frame hierarchy for
knowledge sharing and reuse in computer networks, in: Proc. IEEE
International 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.
397
[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 with
C++, 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 intelligent
systems, Automatica & Informatics, Sofia 5–6 (1997) 25–33 (in
Bulgarian).
[13] M. Minsky, A framework for representing knowledge, MIT-AI
Laboratory 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 the
envelope: challenges in a frame-based representation of human
anatomy, 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 Database
Systems, Prentice Hall, 1999.
[18] P. Kiatisevi, A distributed architecture for interactive robots based on
a knowledge software platform, Ph.D. Thesis, Department of
Informatics, Graduate University for Advanced Studies, SOKEN-
DAI, 2005.
[19] R. Geraghty, S. Joyce, T. Moriarty, G. Noone, COM-CORBA
Interoperability, 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 primitive
editor, International Journal of Man–Machine Studies 33 (1990) 607–
621.
[24] V.K. Chaudhri, A. Farquhar, R. Fikes, P.D. Karp, J. Rice, OKBC: a
programmatic 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 and
heterogeneous databases, in: Proc. Fifth IEEE Int. Conf. Engineering
of Complex Computer Systems, ICECCS’99, 1999, pp. 143–152.
Available from: http://doi.ieeecomputersociety.org/10.1109/
ICECCS.1999.802858.