Advanced knowledge-base environments for large

database systems

E Laenens and D Vermeir

The funtionality and architecture of the KIWIS system is described. This is an advanced knowledge-base environment for large database systems, which is curr- ently being developed by a consortium of industrial and research organizations within the framework of the ESPRIT programme (P2424).

Keywords: knowledge-base environment, large data- base systems, ESPRIT programme

I N T R O D U C T I O N

This paper presents an overview of the KIWI system's functionality and architecture. The present section starts with a motivating example showing the need for a KIWIS environment. Then follows a summary of the functionality, the underlying knowledge/data model and the gross architecture. The following sections present an overview of our current understanding of each of the components of the system.

Motivation

Four independent travel agencies have decided to cooperate with one another. They are located in four different countries, Italy (Rome), Sweden (Stock- holm), The Netherlands (Eindhoven) and Greece (Crete). They have observed that they need better information resources in order to compete with the large international travel agencies. They intend to specialize individually by providing as complete a set of travel information about their particular part of the world as they can, and then sharing that information with each other. Eventually, in this way, they hope to have detailed, little known, travel information which covers Europe.

Each agency, being autonomous, needs to design its

ORIGIN/INTL.-MIDDLEWARE, Vestdijk 9, 5611 CA Eindhoven, The Netherlands Dept. of Mathematics and Computer Science, University of Ant- werp, UIA, Universiteitsplein 1, B2610 Wilrijk, Belgium

Paper received 5 February 1990. Accepted 6 August 1990.

own knowledge base according to the way it does its business. The other agencies will not know what the knowledge base schemas are. However, the knowledge base system they are using will facilitate the creation of agreements or 'contracts' which will specify what one agency is willing to share with another (bilateral contracts). The system will facilitate browsing and information sharing based on these agreements. In this way, each agency can protect its investment in know- ledge acquisitions while still permitting advantageous exchanges with other agencies.

Each will have the usual on-line sources of informa- tion that most travel agencies have, such as flight schedules and booking information. However, it is their goal to gain access to as many additional external information sources as they can find and afford. These external information sources may have any format, any DBMS. They may include traditional databases from which, for example, hotel and restaurant ratings may be obtained; they may be text databases for menus or tour descriptions; or possibly including graphical and pictorial information for maps and photographs. The knowledge-base system they will be using must provide these capabilities.

Another of their goals is to be able to answer their customer's queries quickly, accurately and as com- pletely as the contents of the knowledge base permits. The typical travel agency must search several paper brochures in order to begin to answer most customer questions. They believe that if a customer could ask any travel-related question and get the answer in a few minutes that the customers would be more likely to do their business with this travel agency.

In order to be able to answer any travel-related question, first an extensive knowledge base must be obtained. But that in itself is not enough. The knowledge-base system must have adequate query capabilities. Some examples of questions which cus- tomers ask, that the system should help to answer, are as follows:

• In order to have the lowest cost flight to Barcelona, how far ahead should I book my flight and in what

Vol 3 No 4 December 1990 0950-7051/90/040215-06 © 1990 Butterworth-Heinemann Ltd 215

time period? When do I get there, what kinds of things can I do?

• Where are all the places in the world, where I can enjoy a guided hike (walk)?

• Do you have a map which shows where the hotels and places of interest are in the city I want to go to? And could you mark the approximate prices of the hotels on the map? Do you have pictures of these three hotels that I think I might be interested in?

• Would you find (make) a tour to a place which is warm in the early fall which has a lot of archeological and historical interest? I hate bus travel, and would prefer a variety of transportation means on this tour.

Finally, since the owners and employees of the travel agency are not knowledge engineers (although they will hire some to design and implement their system), they need to be able to use their knowledge base easily. They need to be able to ask the above questions without having to know some strange logic language. They need to be able to browse in the knowledge base without having to know complex navigation techniques or the exact schema. They need to be able to do their usual business activities such as making reservations, invoicing customers and issuing tickets. In short, they need an excellent, tailored, user interface.

Functionality KIWI is a knowledge-base management system which can be used both as a sophisticated stand-alone 'personal knowledge machine' that supports know- ledge-based applications, as well as a 'window on the world' that provides a seamless integration of informa- tion coming from a wide variety of other sources with the local knowledge bases. The knowledge-base man- agement system's features include:

• an advanced graphical user interface design system that provides a smooth transition between default (generic) and special purpose (application) know- ledge base usage;

• a new knowledge representation and manipulation language, called LOCO 1, that is based on a tight integration between the object-oriented and the logic programming paradigm. In addition, the lan- guage supports features such as defeasible and default reasoning, making it suitable also for AI-fla- voured applications, such as expert systems;

• efficient query evaluation algorithms that extend the state-of-the-art in deductive database technology;

• an efficient underlying main-memory resident data- base management system, that is tuned to the requirements of the efficient manipulation of large numbers of complex objects and deductive queries.

Integration with external information sources is poss- ible in two ways:

• The first possibility provides a tight and transparent read-only interface to a variety of external informa- tion sources. These include traditional databases (relational, network or hierarchical), text or picture databases. These databases may reside on the same or remote systems, using traditional or 'new' devices

(such as CD-ROM). The interface module of the KIWI system is extendible so that the above list is not exhaustive. The second possibility provides for a federation of autonomous KIWI nodes, in which KIWI systems unite to form a network for information sharing and cooperation without a commitment to a centrally maintained global schema.

It should be stressed that in both cases, the imported information is, in the user's or LOCO programmer's view, completely integrated with the local knowledge base. This gives the opportunity for the user to enrich 'dumb' data from outside sources with local higher- level knowledge.

Objects and extendibility KIWI can be regarded as an object-oriented know- ledge-base management system enriched with the logic paradigm to express complex relationships and manipu- lations.

Objects come in two basic flavours:

• Primitive objects that are built-in and on which certain operations are supported. In a first prototype version, these include:

o numbers and strings with the usual operations, including data entry;

o texts with the usual textual information retrieval operations, such as matching a (set of) search terms, as well as edit operations;

o simple images (bitmaps), together with a limited number of operations such as display, entry, clip, paste, rotate, scale and zoom etc.;

o the set of primitive objects can be extended to include arbitrary objects, together with their operations and access methods, that are sup- ported by 'foreign' systems. Such objects will be called UFOs. UFOs are already used in the OVM-ESI interface (see below). As another example: to introduce complex numbers as pri- mitives, it will be sufficient to provide a set of library routines, make a suitable declaration to the system which describes these operations, and link the complex number library with the OVM binary. This UFO facility makes KIWI an extend- ible system.

• Complex objects that are specified by a set of (logical) properties that refer to other (primitive or complex) objects. For example, a document can be viewed as a complex object that is related to its contents, which could - in the simple case - be a primitive text object. It may however have addi- tional properties that specify things like author, a set of keywords, a set of related documents (this property would typically be specified using clauses) etc.

Architecture The KIWI system, as illustrated in Figure 1, contains the following modules:

216 Knowledge-Based Systems

ESI

CD-ROM

USER

INTERFACE

DEVELOPMENT

SYSTEM

ABSTRACTION

LAYER

J/ COOPERATIO)

MANAGER

BASIC

LANGUAGE

MACHINE

OBJECT

VIRTUAL

MACHINE

persistent

storage

Figure 1. Architecture of the KIWI system

• The basic language machine (BLM) implements a logic formalism supporting complex objects, inherit- ance and true negation. It is responsible for the intelligent manipulation of (sets of) objects, interp- reting rules, performing updates etc., using the OVM basic methods.

• The abstraction layer (AL) provides a variety of languages, possibly based on different paradigms, to access the underlying KB.

• The object virtual machine (OVM) manages a memory-resident knowledge base, including effici- ent access methods. This layer can be regarded as the 'object manager'.

• The external information source interface (ESI) module provides read-only access facilities to a variety of external information sources.

• The user interface development system (UIDS) supports a toolbox of user interface construction tools, which are used by the various AL languages in order to implement an environment that is consistent over languages and applications.

• The cooperation manager (CM) module gives the KIWI system the possibility to be part of a larger federated system.

In the remainder of this paper, we describe each of these modules in some more detail. Finally, the last section discusses the further design and implementation strategy.

BASIC LANGUAGE MACHINE

The basic language machine (BLM) can be regarded as the heart of the KIWI system as it is this layer that

defines and implements the KIWI knowledge model, which is based on a tight integration of the object oriented and logic programming (deductive) appro- aches. We look upon the BLM as an efficient logic interpreter where the logic must be powerful enough to support the above features, in addition to some extra facilities which are needed in a real-world system, such as type checking, daemons (triggers) and transactions. Thus the BLM has the following components.

• A 'single rule' interpreter which is responsible for subqueries involving a single rule. For example, this component devises and executes (by calling OVM) join strategies.

• A fixed point (FP) machine that implements efficient query evaluation for logic queries. It calls the 'single rule interpreter'.

• A third component is responsible for handling non-logical features such as update, trigger defini- tion and handling and the interpretation of certain built-in predicates.

The underlying logical formalism, called ordered logic (OL2'3), forms the theoretical background of the BLM OL is a non-monotonic logic which formalizes our intuition about several important aspects of object-ori- ented knowledge bases such as object identity, multiple inheritance and defaults. The main starting point is to consider objects as theories about their properties and to formalize the influence of the isa-relationship using an appropriate proof theory.

ABSTRACTION LAYER

The abstraction layer (AL) provides abstractions, i.e. languages, that allow more convenient access to the underlying (logic) knowledge base. Each of these languages may have its own specific area of use or application. However, it is required that a knowledge base which is set up using one language could be accessed using another one. Hence there is a need not only for compilers (translating a language L to BLM) but also for generators (translating BLM to a language L). Note that not every language has to be capable of representing the whole of BLM. There is a distingu- ished language whose capabilities match those of the BLM in a straightforward way. This language, which is called LOCO, forms the 'native language' of the KIWI system, much as C is considered the native language of Unix.

LOCO (logic for complex objects) 1 is a database programming language that combines the declarative elegance and power of logic programming with the advantages of object-oriented systems: object identity, inheritance, default reasoning, encapsulation etc. A LOCO program describes a knowledge base (schema and initial population) as a set of interrelated objects. We take the view that an object can be identified by its properties, i.e. relationships to other objects. The properties of an object are described using a logic program, hence, to LOCO, an object is just a theory, i.e. a set of clauses. However, the clauses in an object's definition do not constitute the entire knowledge about that object. A specificity relation defined on the objects allows for the introduction of some rules for knowledge

Vol 3 N o 4 D e c e m b e r 1990 217

flow between them. This specificity relation (also called subobject relation) is suffiently general and powerful to be useful to model e.g. delegation 4, classification and/or generalization hierarchies, etc. Therefore, the language does not enforce a particular modelling paradigm. The core of the language is based on a non-monotonic logic, called inheritance logic 5 which has been developed to provide a formal model for object-oriented concepts, within a logical framework.

OBJECT VIRTUAL MACHINE

The object virtual machine (OVM) is the software layer that supports the basic language machine (BLM) and communicates with the external information source interface (ESI). It is responsible for handling complex objects both in main and in secondary memory, managing the knowledge base (KB) of the system.

Representation of objects

One of the fundamental tasks of OVM is providing a suitable representation of a hierarchy of first-order theories, each related to an object, implementing an environment in which fast access and flexible manipula- tion of objects are possible. In particular, by exploiting the availability of a large main memory, advanced techniques for representing complex objects will be used, following an approach oriented to main memory- resident databases 6-8. No normalizations constraints will be retained, thus overcoming the limitations of the standard relational model.

Updating and querying support

Since objects are set in a partial order and inherit properties through a semantic network, full capabilities of navigating the network that materializes the object hierarchy must also be provided.

OVM will implement efficient access methods aimed at supplying fast addressing to either whole objects, or their properties, allowing one to create, delete and modify objects to any desired 'granularity' of their contents, as well as to retrieve them by inspecting the nodes of the semantic network 8,9 .

Management of the knowledge base

As for KB management, as long as it acts as the private persistent storage support of the KIWI system, the suitable protocols for its usage will be defined and realized. In particular, algorithms will be implemented deciding whether it is convenient to load the whole extension of objects into central memory or to leave them partially on secondary storage 1°. When the need arises, swapping involving suitably-sized buffers will supply the main memory with the necessary data.

EXTERNAL INFORMATION SOURCE INTERFACE (ESI) The external information source interface (ESI) is responsible for interfacing and providing a uniform read-only access to (possibly heterogeneous) external information bases. This is useful to allow the enhancing

and reusing of existing software and for coupling operational applications with novel knowledge-based ones. Moreover, it is stressed that the ESI must support the access to multimedia data (e.g. text).

Since the ESI has to cope with a wide range of systems and information types, a modular, extensible approach is followed. The ESI should then be seen as a toolkit for building (and running) programs that access external information bases and build corresponding OVM objects. In addition, architectural simplicity is considered a very desirable feature.

We expect ESI to work with a wide variety of applications, each with a potentially different query language. At the same time, the effort for interfacing a new system should be reasonably low. Thus, the ESI should provide for a simple form of extensibility 11,12. Generally enough, the ESI could be seen as a collection of functions ranging over the definition of an internal and an external object and returning an internal (OVM) object as a result. Such collection could be augmented by the DBA in view of the KIWI's needs. The ESI should also support a mechanism for browsing through the schemata of external databases, presenting them in the KIWI model.

USER INTERFACE DEVELOPMENT SYSTEM

Developing a single user interface is not an appropriate choice to interface the KIWI system, for a number of r e a s o n s 13 .

• The experience in the KIWI project 14,15 showed that different user interfaces are needed to fully and suitably represent and interact with different O O P S + 16,17 knowledge bases.

• If we want to support different classes of users that have different skill and experience levels, we need a flexible and customizable environment capable of tailoring the user interface according to the user profiles.

• Nevertheless, we want to provide the user with an interactive environment consistent across applica- tions (i.e., it feels always the same both with respect to the presentation and to the interaction tech- niques).

These observations suggest the need for a user interface development system 13,18, able to both provide default interfaces and customize such interfaces to the particu- lar applications while maintaining the consistency.

The user will interact with a KIWI system through an interaction environment which provides several kinds of high-level interaction paradigms such as browsing 19 , querying and data-entry support. Suitable combina- tions of these approaches allow us to define new interaction styles that overcome the limits of their separate use.

The customization tool serves to customize the different paradigms of the interaction environment. It consists of two parts, namely the customization defini- tion facility and the customizations interpreter. The former provides a set of customization commands which may be written directly to the system. Interactive support is provided to aid in the specification of a customized user interface. The commands consist of a

218 Knowledge-Based Systems

set of window definition objects which will be usable from within the different languages of the abstraction layer. These objects are strongly related to the ones of the NAU interface 2°. However, for the dialogue definitions the design is inspired by the work of Hill 21 .

COOPERATION MANAGER

The cooperation manager (CM) is the component in the KIWI architecture that allows two or more KIWI systems to unite and form a loosely coupled network, a KIWIS system. The overall objective is to provide information sharing between and cooperation among KIWI systems, without commitment to a centrally maintained global schema. The CM thus makes it possible to view a KIWIS system as a federated information system 22,23 in which each node is an autonomous KIWI system. Such a federation has the following characteristics.

• There is no central authority that controls the operation of individual KIWI nodes. Nodes engage in cooperative activities by making bilateral agree- ments resulting in contracts. In order to arrive at an agreement, the nodes perform a dialogue in which the terms of the resulting contract may be subject to negotiation 24,25 .

• Sharing is at the discretion of the individual node which means that nodes decide and explicitly declare what they are willing to share in the federation.

• In the absence of a global schema, a node maintains its own view of the federation in terms of the current topology and the information available at other nodes. This view is gradually built up through contracts.

• The topology of the federation may change dynamic- ally and nodes may enter or leave the federation depending on the possibilities available to establish and terminate contracts. The CM should provide a set of functions based on these properties. The functions can broadly be divided into:

0 A node should be able to examine information available at other nodes. This may require sup- port for explanation of schema semantics.

0 A facility is needed for conducting dialogues with another node to set up sharing contracts. This includes support for definition of import/export interfaces.

0 Imported information may need to be integrated with the local knowledge base. This includes support to handle structural as well as conceptual disparities.

0 The CM should provide applications access to imported knowledge.

IMPLEMENTATION

Prototype There are two approaches to systems design.

• Detailed specification of all the design details before implementation starts is the traditional approach.

• Fast prototyping is a more recent approach. Its rationale is that users do not really know what they

want until they have a prototype in front of them to experiment with.

Detailed specification is more appropriate in transac- tion-based environments where the same well known transactions are executed repeatedly. Fast prototyping is more appropriate for interactive environments, with ad hoc queries, many interfaces, and not well specified tasks 26. KIWI has several characteristics that make it appropriate for fast prototyping. A minimal system will be implemented soon, having all the major components of the system, although each component with limited functionality. This basic system will be useful in order to understand the functionality and interfaces between the system modules. It will be very helpful in clarifying several coordination aspects and flow of control among components in the minds of all participants.

Research will be pursued in parallel to expand and/or improve the functionality of each component individually. The expanded functionality will be imple- mented in later versions of the system.

Case study We will use a case study from the beginning of the project. The study we will use is travel agencies, similar to that described at the beginning of this paper. Using a case study, in conjunction with rapid prototyping, will serve three purposes. One is to allow all the partners to use consistent examples throughout the different com- ponents, allowing us to follow the example from a particular user/knowledge engineer's action down through all the components. This helps us to more easily ensure good interfaces between modules. We expect, too, that the partners will be able to communic- ate more easily as well. The second reason, is to ensure that the underlying architectures of the various com- ponents are sufficient to support a real application. The travel agency application has very interesting query opportunities. It has opportunities for inheritance and other types of relationships. And it has some transac- tional opportunities such as, bookings and ticketing. A third reason is to be able to communicate the value of this project and its prototypes to non-technical persons The use of an application is a better vehicle for explanation than trying to explain the technology simply.

In summary, we expect that the combined use of rapid prototyping and a case study from the beginning of the project, will enable:

• integration of the protypes; • more productive research to expand or improve

functionality; • the industrial usability of the technology; • our ability to communicate with each other and the

non-technical world.

ACKNOWLEDGEMENTS

The KIWIS project is performed by the following organizations: ORIGIN, ENIDATA, CRAI, the uni- versities of Antwerp, Calabria, Laquila and the tech- nical university of Crete. We gratefully acknowledge the support of our colleagues in all these organizations.

Vol 3 No 4 December 1990 219

REFERENCES

1 Laenens, E, Vermeir, D and Verdonk, B 'LOCO, a logic-based language for complex objects' in Pro- ceedings of the Esprit Conference (1989) pp 604-616

2 Laenens, E and Vermeir, D An overview of ordered logic University of Antwerp, UIA Tech, Report 89-37 (1989)

3 Laenens, E and Vermeir, D 'A fixpoint semantics of ordered logic' J. of Logic and Computation (1990) to appear

4 Stein, L 'Delegation is inheritance' OOPSLA '87 (1987) pp 138-146

5 Vermeir, D, Laenens, E, Verdonk, B and Cuyt, A 'A logic for objects and inheritence' in Proc. of the Advanced Database Symposium, Kyoto, Informa- tion Processing Society of Japan (1989)

6 DeWitt, Katz, Olken, Shapiro, Stonebraker and Wood 'Implementation techniques for main mem- ory database systems' in Proc. of the ACM SIGMOD 84 (1984)

7 Hanrahan, A and Krismamurthy, A 'Design of a memory resident dbms' in Proc. of the IEEE COMPCON San Francisco, USA (February 1985)

8 Weddell, A Physical Design and Query Compilation of a Semantic Data Model Assuming Main Memory Residence PhD Thesis, University of Toronto (1989)

9 Lehman, A and Carey, A 'Query processing in main memory DBMS's' in Proc. of the ACM SIGMOD 86 (1986)

10 Lehman, A and Carey, A 'A recovery Algorithm for a high performance memory resident database system' in Proc. of the ACM SIGMOD 87 (1987)

11 Carey, M, DeWitt, D et al 'The architecture of the EXODUS extensible DBMS' Proc. Intl. Workshop on Object Oriented Database Systems IEEE, Pacific Grove, (September 1986) pp 52-65

12 Sehwarz, P, Chang, W, Freytag, C, Lohman, G, McPherson, J, Mohan, C and Pirahesh, H 'Exten- sibility in the starburst database system' Proceed- ings of the Intl. Workshop on OODB Systems IEEE, Pacific Grove (September 1986) pp 85-92

13 Laenens, E, Staes, F and Vermeir, D 'Browsing a la carte in object-oriented databases' J. British Com- puter Association Vo132 No 4 (1989) pp 333-340

14 The KIWI Team 'A system for managing data and

knowledge bases' in Proceedings of the 1988 Esprit Technical Week North-Holland, Netherlands (1988) pp 826-845

15 Vermeir, D, Laenens, E, Staes, F and Snijders, J 'A case study in object oriented knowledge-base design using the KIWI system' in Proc. of the CASE89 conference (1989)

16 Vermeir, D and Laenens, E 'An overview of OOPS+, and object-oriented database program- ming language' in Proc. of the European Confer- ence on Object Oriented Programming Systems Oslo, Springer-Verlag, FRG (1988) pp 350-374

17 Vermeir, D and Laenens, E 'A language for object oriented programming' Journal Object Program- ming Vol 1 No 5 (1989) pp 18-28

18 Pfaff, G E 'User interface management systems' in Proc. of the Workshop on User Interface Manage- ment Systems Seeheim, Springer-Verlag, FRG (1983)

19 D'Atri, A, Laenens, E, Paoluzzi, A, Tarantlno, L and Snijders, J 'A graphical browser to object-ori- ented knowledge bases' Database Technology (1989)

20 Vermeir, D, Laenens, E and Staes, F 'A customiz- able window-interface to object-oriented databases' in Proc. of the ECOOP Conf (1989) pp 367-382

21 Hill, R D 'Supporting concurrency, communication, and synchronization in human-computer interac- tion: the Sassafras UIMS' ACM Transactions on Graphics Vol 5 No 3 (July 1986) pp 179-210

22 Heimbigner, D and McLeod, D 'A federated arch- itecture for information management' ACM Trans- actions on Office Information Systems Vol 3 No 3, (1985) pp 253-278

23 Heimbigner, D 'A federated system for software management' IEEE Database Engineering Bulletin Vol 10 No 3 (1987)

24 Hewitt, C and deJong, P 'Open Systems' in On Conceptual Modelling, Ed. Schmidt, J, Springer Verlag, FRG (1984) pp 147-164

25 Johannesson, P and Wangler, B The Negotiation Mechanism in a Decentralized Autonomous Cooper- ating Information Systems Architecture Tech. Re- port Nr. 62, SYSLAB, University of Stockholm, S-10691 Stockholm, Sweden (1988)

26 Boar, A Application Prototyping Wiley Inters- cience, USA (1984)

220 Knowledge-Based Systems