1 Reuse of Knowledge - CiteSeerX

Plug-and-Play: Construction of Task-Speci c Expert-System Shells Using Sharable Context Ontologies Eckart Walther, Henrik Eriksson, and Mark A. Musen Medical Computer Science Group, Knowledge Systems Laboratory Stanford University Stanford, California 94305-5479 email: fwalther, eriksson, [email protected] April 30, 1992

Abstract

Previous approaches to the reuse of problem-solving methods have relied on the existence of a global data model to serve as the mediator among the individual methods. This hard-coded approach limits the reusability of methods and introduces implicit assumptions into the system architecture that make it dicult to combine reasoning methods in new ways. To overcome these limitations, the protege-ii system associates each method with an ontology that de nes the context of that method. All external interaction between a method and the world can be viewed as the mapping of knowledge between the method's context ontology and the ontologies of the methods with which it is interacting. In this paper, we describe a context-de nition language called model, and its role in the protege-ii system, a metatool for constructing task-speci c expert-system shells. We outline the requirements that gave rise to such a language and argue that sharable ontologies are a fundamental precondition for reusing knowledge, serving as a means for integrating problem-solving, domain-representation, and knowledge-acquisition modules. We propose an approach based on the kif ontology-sharing language for allowing developers to share knowledge-acquisition editors and problem-solving methods.

1 Reuse of Knowledge Over the past two decades, researchers have been looking for ways to increase the productivity of knowledge engineers. Early rule-based shells were realized to be the \assembly language" of knowledge engineering, providing increased exibility at the price of reduced understandability, maintainability, and reusability (Soloway et al., 1987). Instead, in an attempt to increase the knowledge bandwidth between the shell and the domain expert, researchers have turned to role-limiting architectures, replacing the generic rule-based architecture with task-speci c reasoning strategies and custom-tailored knowledge-acquisition editors (McDermott, 1988). Applications based on this architecture contain abstract, but in exible, data models that guide knowledge-acquisition and inference, enabling experts to manipulate knowledge at a high level of abstraction. We refer to these architectures as being driven by explicit, or strong, data models. Although such role-limiting architectures have been demonstrated to increase the productivity of system builders (Musen, 1989a), they are dicult to construct and, due to their commitment to a particular data model and problem-solving method, limited in the range of applications about which they can reason. The limitations of task-speci c architectures have led to the recent development of metatools (Eriksson and Musen, 1992). These tools perform knowledge acquisition at the meta 1

level; that is, they specify how knowledge should be represented, acquired, and processed. More speci cally, the knowledge engineer uses the tool to assemble task and domain-speci c expert-system shells (hereinafter referred to as task-speci c shells) from reusable modules. Such task-speci c shells are composed of a task-speci c problem-solving method, application ontology, and knowledge-acquisition interface. We can now view acquiring and processing expert knowledge as a two-step process. In the rst phase, the knowledge engineer de nes the architecture of a task and domain-speci c expert-system shell. In the second phase domain experts employ the custom-tailored shell to create new domain applications and to modify existing ones (Musen, 1989b). In this paper, we focus on the process of building task-speci c shells from reusable modules. After providing a brief overview of metatool architectures, we examine the role of data models in the assembly of task-speci c shells and propose a new metatool architecture for driving the integration of problem-solving, knowledge-representation, and knowledge-acquisition behavior. Finally, we describe the realization of this architecture in the form of the protege-ii metatool and the model knowledge-representation language.

2 Metatools Despite dierences in design and implementation, existing metatools generally share a signi cant number of architectural features, making it possible to de ne a common conceptual framework. Knowledge engineers start the process of meta-knowledge acquisition by selecting appropriate problem-solving, knowledge-acquisition, and domain-ontology modules from the metatool's library of reusable components. Problem-solving modules are similar to generic tasks (Chandrasekaran, 1986), problem-solving methods (Wielinga et al., 1991), and rolelimiting methods (Klinker et al., 1991; Musen and Tu, 1991); we can be think of them as generic reasoning modules, analogous to the forward or backward chainers of rule-based systems. Similarly, knowledge-acquisition modules correspond to the generic rule-editing interface of rule-based shells. They consist of reusable input modalities|such as tree and form editors, menus, or charts|that can be combined to create custom knowledge-acquisition interfaces. Finally, domain-ontology modules describe real-world domains (e.g., manufacturing, internal medicine) in terms of special-purpose, reusable knowledge-representation structures. Such ontologies consist of sets of de nitions of representational primitives|classes, relations, functions, and object constants|that specify the conceptualization of a knowledge-based system (Gruber, 1991). Ontologies allow a group of systems (and programmers) to commit to a set of terms in a consistent manner, de ning a vocabulary used in knowledge-level communication and data exchange (assertions and queries). These three module classes constitute the basic components of a task-speci c shell. For example, a shell for the diagnosis of electrical circuits might consist of a qualitative-diagnosis problem-solving module, an electrical-circuit domain-ontology module, and a graphical-editor knowledge-acquisition module for drawing circuit diagrams. Once the knowledge engineer has selected a set of appropriate modules, she must combine them to create a functional shell. First, the selected modules are con gured for a particular task, de ning information that is independent of the other modules. For example, for the previous diagnostic-shell example, the circuit-modeling ontology must be populated with with domain-speci c device models; likewise, the graphical editor must be associated with graphical images representing the individual device types. This con guration step is followed by module assembly, during which the knowledge engineer connects the individual modules into a consistent system, creating the application ontology that will be used by the task-speci c shell to represent application knowledge (Figure 1). The knowledge engineer connects modules by 2

Domain-Ontology Model1

Domain-Ontology Module2

Application Ontology Problem-Solving Module1

Knowlege-Acquisition Module1

Problem-Solving Module2

Knowledge-Acquisition Module2

Figure 1: Module assembly. The knowledge engineer assembles a task-speci c shell by de ning mappings among the con gured problem-solving (PS), domain-ontology (DO), and knowledgeacquisition (KA) modules, creating the application ontology (global data model). de ning mappings among the data objects accessed by the various modules. Such mappings not only focus on the transfer of data, but also operate at the knowledge level, de ning the meaning of the individual modules within the application being assembled. For example, the connection between a problem-solving module and its associated knowledge-acquisition modules requires the transformation from the problem-solving model to the knowledge-acquisition models of the KA editors. For the diagnosis example, appropriate mappings would connect the electrical-circuit domain model to the qualitative-simulator problem-solving module and to the graphical editor. The meta-knowledge acquisition phase is followed by domain-knowledge acquisition (hereinafter referred to as simply knowledge acquisition). Here, domain experts use the task-speci c shell to de ne knowledge, creating new applications and modifying existing ones. In the case of the diagnosis example, the expert would use the graph editor to enter or modify diagrams of the circuits to be diagnosed. These diagrams are then compiled into an application that assists users in identifying faults in electrical devices. Note that domain experts only instantiate their knowledge into the xed task knowledge-representation framework created by the metatool; they cannot modify the data model, since to do so would imply that they would also have to change the assembled problem-solving and knowledge-acquisition modules (there is no point in adding a new eld to a structure if it is not going to be used by the knowledge-acquisition or inference modules) (Musen, 1989b).

3 The Role of Global and Local Data Models All knowledge-based shells are driven by either implicit or explicit data models that de ne the interaction among the shell's knowledge-acquisition, knowledge-representation, and inference components. Such data models are usually implemented as global data structures that share a common interpretation by the components of the shell. For example, the oncocin system (Tu et al., 1989) contains a special data structure class called planning entity, both as a basis for representing task knowledge, and as a means to integrate the control structure of its episodic skeletal-plan re nement (espr) algorithm with its knowledge-representation and acquisition components. Espr is a problem-solving method, used by oncocin to formulate treatment 3

plans for patients with cancer. As implemented in oncocin, the espr method uses a collection of time-varying planning entities to represent hierarchical skeletal plans of the operators that can be applied, input data that are gathered from the environment, and task actions that can modify the instantiations of currently active planning entities in response to particular input data. Correspondingly, during module assembly, a metatool must create a data model that integrates the interaction among the various selected components. For example, if the knowledge engineer selects the espr problem-solving module, the planning entity concept must become part of the shell's data model and knowledge-acquisition interface. If such a problem-solving component is to be reused, all metatools must provide a means to describe the role of that module during assembly, specifying at least a list of input and output concepts for each such reusable module. We refer to this description as the local data model of the modules. During module assembly, this local data model is integrated with the global data model of the shell under construction, de ning the interactions among the various components of the shell (see Figure 1). Although this process may seem straightforward, the problem faced by the metatool is how to capture, share, and enforce the semantics of the concepts constituting the local data models. Unless a concept (e.g., integer) is already de ned as an integral part of the language, conventional knowledge-representation languages do not provide the appropriate information to de ne explicitly the role of a concept during module assembly. This problem is best illustrated by an example. Consider the espr module, which requires as one of its inputs a hierarchy of planning entities (Figure 2). Such a concept would be described as a structure with a eld that contains a list of pointers to further planning entities; it might be declared as the Lisp de nition: (defstruct planning-entity (subplanning-entities nil :type list))

This declaration of planning entity de nes a structure for sharing planning entity hierarchy information between the espr module and the corresponding knowledge-acquisition modules. The problem with this de nition is that the constraints that preclude a given planning entity from being its own parent are embedded only implicitly in the data model; during module assembly, the metatool would have no basis for selecting an appropriate knowledge-acquisition editor for a planning entity (other than \just knowing" that planning entities must be acquired as a strict tree hierarchy). Most existing knowledge-representation languages do not provide the means to express explicitly these types of constraints, causing the information to be hardcoded into the modules that manipulate the concepts. If we wish to share and reuse modules, however, this implicit information must be made an explicit part of the local data model of the components. More speci cally, we require local data models 1. To articulate the role of a module in the meta-engineering process 2. To describe domain knowledge required for a module to complete its task (i.e., the knowledge to be acquired from the domain expert) 3. To de ne the run-time input and output requirements of a module (e.g., inputs from end users and other modules) 4. To encapsulate module behavior in an architecture-independent manner so that a module can be shared across applications and metatools These requirements have led us to propose a metatool architecture that associates an explicit data model with every reusable module in the tool's libraries. Such a data model 4

superentity

Therapy subentities

superentity

superentity

Chemo

Radiation subentities

subentities

Figure 2: Planning entity hierarchy. Planning entities are part of the espr context ontology; they form a strict hierarchy of skeletal-plan actions. describes the externally visible aspects of every module1 , de ning a context ontology for reusing the module. This ontology does not need to be a formal speci cation of the function of the module, but rather must contain all necessary information for de ning the module's role in the module-assembly process. Consequently, the metatool module-assembly phase may now be viewed as the process of establishing mappings between the concepts in the various context ontologies and the global data model of the shell being constructed.

4 Requirements for Sharable Context Ontologies We have described context ontologies only in terms of their functionality, disregarding any questions about how to represent them. This section focuses on the issues involved in de ning and manipulating context ontologies. Principally, context ontologies do not dier signi cantly from any other knowledge-representation system: Every context contains sets of concepts (also called schemas, frames, or structures) that describe the basic terms used to encode knowledge in the ontology. Furthermore, each context contains a set of constraints that restricts the manner in which instances of these concepts may be created and combined. In addition to these basic functions, however, the role of context ontologies places a number of further requirements on the representation language.

4.1 Language Completeness

A representation formalism must be suciently expressive to de ne the appropriate terms and constraints for a particular context ontology. Unfortunately, this problem is open-ended, since certain modules might require arbitrarily complex constraints to de ne the concepts in their context ontology. For example, a formal description of the inputs of a circuit-simulator module might require constraints that specify the consistency of any input circuit. The de nition of such a constraint might be more dicult to implement than the actual simulation of the circuit would be. However, the actual complexity of context ontologies is bound by the meta-system's ability to understand, and by the modules' ability to enforce such constraints. We believe that the function of context ontologies is to capture the role of the module, rather than to provide Note that domain ontologies are identical to their context ontologies, serving as contexts for the realworld domains they represent. This de nition allows us to reuse problem-solving, knowledge-acquisition, and domain-ontology modules in a uniform manner. 1

5

Seconds Instance Mapping Minutes People Slot 1

Concept Mapping

Left-Handed-People Right-Handed

Slot 2 Slot 3 Slot Instance 1 Structure Mapping

NextInstancePtr Slot Instance 2 NextInstancePtr Slot Instance 3 NextInstancePtr

Figure 3: Mapping categories. Mapping is supported at three levels of complexity: slot mapping between two slots; concept mapping between an individual slot and any number of target slots; and structure mapping between arbitrary sets of slots. a formal guarantee for the correctness and consistency for the modules' inputs and outputs. Nonetheless, such a language should be extendable to accommodate the representational needs of future modules.

4.2 Context-Ontology Mapping

The second requirement for a representation language concerns the problem of assembling problem-solving, domain-ontology, and knowledge-acquisition modules by establishing mappings among concepts in the modules' context ontologies. Since the mapping of arbitrary concepts may require a complete transformation of those concepts, a generic solution to the problem can be achieved only through a of formal logic or transformation language. For example, the mapping between a board-level description of a circuit and a gate-level circuit simulator would require an extensive translation program. Researchers have dealt with this problem by creating concept-translation languages. For example, in the heterogeneous distributed database community, the Carnot system (Collet et al., 1991) uses the CycL language to de ne mappings between dierent distributed schemas. Similarly, we believe that we can increase the reusability of modules by complementing the conventional matching of equivalent data structures with exible mapping functions. In particular, if we would like to use modules written by other researchers, it will become increasingly important to de ne mappings to overcome the structural dierences between the various modules. To limit the scope of the general mapping problem, we distinguish context mapping at three dierent levels of complexity: (1) slot mapping, which involves the 1-to-1 mapping of slots between contexts (e.g., transforming seconds to minutes); (2) concept mapping, which is the 1-to-n mapping of one instance in a context to two or more instances in the other context (e.g., the people concept to the left-handed-people and right-handed-people concepts); and (3) structure mapping, which tries to establish arbitrary n-to-m mappings between multiple concepts in two contexts. This last class of mapping is the most complex, requiring that we restructure the knowledge to transfer it between the contexts. Despite this potentially arbitrary complexity, it is still possible to identify and to support directly certain common structure-mapping operations (e.g., set to list, list to tree; see Figure 3). 6

4.3 Context Portability

The representation language should form a basis for sharing and reusing context ontologies, not only among dierent applications of the same metatool, but also among dierent tool architectures. A number of researchers and committees are currently working on this problem by de ning standards for knowledge sharing (Neches et al., 1991). For example, the kif project (Genesereth and Fikes, 1991) is addressing the problem of de ning a standard language for sharing knowledge bases. The goal of this work is to provide a logic-based intermediate notation to facilitate the sharing of knowledge between among representation systems. In particular, the language will allow researchers to create and reuse large knowledge bases containing standard ontologies (e.g., large medical knowledge bases).

5 Ontolingua and the MODEL Language In an eort to balance the completeness, mapping, and portability goals with implementation and eciency considerations, we have selected a dual approach to representing context ontologies. To meet the exibility and portability criteria, we use the Ontolingua language (Gruber, 1991) to encode context ontologies. Ontolingua is an extension of the proposed kif knowledge-exchange format; it adds primitives to de ne classes, relations, functions, and instances. The language has been implemented as a public-domain tool that translates between a variety of knowledge-representation systems (e.g., LOOM, Epikit) and its own canonical form, serving as a gateway for sharing knowledge among the various formats. Ontolingua is not a representation system, but rather is a mechanism for translating from a standard syntax into multiple representation systems. It leaves to the target systems the inference tasks, such as checking constraints, performing inheritance, and maintaining inverse relations. Ontolingua recognizes certain patterns, termed second-order relations (e.g., subclass, inverse, transitive), in kif expressions, and translates them to appropriate operators in the target languages. For example, the following Ontolingua de nition speci es that instances of the slot called superplanning-entity must form a relation between two planning entities. The relation has been constrained further to form only directed acyclic graphs (DAGs) and to have an inverse named subplanning-entity. The terms anti-reflexive, anti-symmetric, and inverse are part of the second-order vocabulary that Ontolingua recognizes, whereas the terms planning-entity, superplanning-entity, and subplanning-entity are new terms in the target ontology being de ned. (define-relation superplanning-entity (?subnode ?supernode) :def (and (planning-entity ?subnode) (planning-entity ?supernode) (anti-reflexive ?relation) (anti-symmetric ?relation)) (inverse superplanning-entity subplanning-entity))

Ontolingua is based on the assumption that the representational primitives that are commonly used in ontologies and are supported with special syntax in target systems can be expressed in a portable form with these second-order relations. The set of these second-order terms is itself an ontology of object-centered languages, called the frame ontology. An Ontolingua compiler translates sentences using these second-order relations into the corresponding special forms handled by target systems. Any forms or relations that cannot be translated into the speci ed target system generate appropriate warnings. The current frame ontology is 7

based on a conceptualization that uni es relation- and object-centered representation systems, and is capable of expressing most common class and slot constraints. We are working with the Ontolingua group to extend the frame ontology with appropriate second-order relations for expressing the additional information required to de ne context ontologies. For example, using Ontolingua, we can now de ne the planning-entity concept (see Figure 2) as ;;; Class of all planning entities ;;; (define-class planning-entity (?node) "A planning entity occurs as a node in a planning-entity hierarchy. It is related to other planning entities by the relations superplanning-entity and subplanning-entity." :def (and ;; At most one superplanning-entity relation per node. (locally-single-valued planning-entity superplanning-entity) (domain-of planning-entity superplanning-entity) (domain-of planning-entity subplanning-entity))) ;;; Create a higher-level second-order constraint by combining existing ;;; frame-ontology constraints. ;;; (define-class DAG-relation (?relation) "A class of relations that can define directed acyclic graphs (DAGs) among nodes. Instances of DAG-relation are binary relations." :def (and (binary-relation ?relation) (anti-reflexive ?relation) (anti-symmetric ?relation) (transitive ?relation))) ;;; Create the relations connecting planning entities into a DAG ;;; (define-relation superplanning-entity (?subnode ?supernode) "A hierarchical relationship between planning entities" :def (and (planning-entity ?subnode) (planning-entity ?supernode) (DAG-relation superplanning-entity) ;; This constraint automatically defines the subplanning-entity relation (inverse superplanning-entity subplanning-entity))) ;;; Create a small example ;;; (define-instance ENTITY1 (planning-entity)) ; Define instance named ENTITY1 (define-instance ENTITY2 (planning-entity) ; Add child ENTITY2 to ENTITY1 :assertions ((subplanning-entity NODE1 NODE2))) ; from inverse -> (superplanning-entity NODE2 NODE1) holds

These Ontolingua de nitions declare the new concept planning-entity and the two transitive relations subplanning-entity and superplanning-entity that are used to build hierarchies of planning entities. Rather than just de ning the planning-entity concept as a structure with pointers to its sub- and superentities, the Ontolingua declaration encodes explicitly the constraints required by a knowledge editor to detect that a planning-entity structure can be acquired and edited by a network editor (i.e., that we can establish a mapping between the planning-entity concept and the concepts in the context ontology of the network editor knowledge-acquisition module.) 8

Although Ontolingua serves as a basis for de ning and sharing portable context ontologies, we must still select a target system that implements appropriate operators to constrain, assert, and query context onotologies. We are building a target knowledge-representation language called model, which is based on a modi ed version of the cool (NASA, 1991) frame-based representation system. Model is upward compatible with the existing cool syntax, extending the language with special slot and frame constraints to capture the knowledge-level relations of context ontologies. Currently, the model language supports the standard constraints oered by most frame-based languages (e.g., type restrictions, cardinality), as well as a number of higher-level constraints such as the following: grammar Restricts slot values to a particular grammar. Grammar is primarily used to

capture relationships that are too complicated to be expressed as explicit concepts of the ontology. This constraint acknowledges that there always will be knowledge that cannot be easily acquired graphically or selected from a list. Rather than adopting the usual approach of \procedural attachments" (i.e., Lisp code), this model constraint allows module designers to communicate the syntax of complex concepts directly. For example, the grammar constraint would allow the developer of an ontology to restrict the value of a slot to a legal SQL expression. acyclic Is one of a number of graph properties for capturing complex relations among multiple concepts. This particular constraint is usually expressed with the more primitive properties anti-symmetric and anti-reflexive (Gruber, 1991), and may be used to de ne tree and other directional relationships among one or more concepts. same-as De nes redundant views of a particular set of concepts. For example, it may be necessary to maintain both a tree view and list view of a particular set of nodes. inverse-of Constrains two relations to be the inverse relation of each other (i.e., back pointers). It may be used by graphical editors to detect and suppress redundant relations. As an example, the de nition of the planning-entity concept described earlier in Ontolingua can be translated into the following model target representation: (defclass planning-entity (slot superplanning-entity (type instance) (allowed-class planning-entity) (inverse-of (children)) (max-number-of-elements 1) (relation acyclic)) (slot subplanning-entities (type instance) (allowed-class planning-entity) (relation acyclic)))

Ontolingua and model form complementary parts of our approach to representing context ontologies. The former system maintains an extensible, sharable description of a context ontology that can be translated into a variety of representation languages, whereas the latter one provides an ecient, special-purpose representation for ecient asserting and querying context ontologies. In Section 6, we describe how a metatool can use such context ontologies to drive the assembly of task-speci c expert-system shells. 9

6 The PROTE GE -II Architecture We are implementing the ideas presented in the paper as a part of the protege-ii system. Protege-ii is a metatool that generates task-speci c expert-system shells from libraries of reusable problem-solving, domain-ontology, and knowledge-acquisition modules (Figure 4). Each of these reusable modules is associated with an Ontolingua-based context ontology that de nes the module's role during the module-assembly phase. When a module is retrieved from the library, its context is translated into model, the protege-ii knowledge-representation language. This process translates the potentially arbitrarily complex Ontolingua de nitions into a nite set of model constraints, alerting the knowledge engineer if some of the Ontolingua semantics could not be captured by model. After a module has been retrieved, it must be integrated into the architecture of the task-speci c shell being assembled. As part of this integration, the knowledge engineer must connect every concept in the retrieved module's context ontology. Depending on the concept's role in the task-speci c shell, we distinguish among three dierent types of connections: Global Mapping Establishes connections between the context-ontology concepts and the

task-speci c shell's global data module, the application ontology. Local Mapping Establishes connections among modules of the same class (e.g., problemsolving modules), sharing internal knowledge that does not aect the overall task-speci c shell architecture. Local mapping is used mainly to de ne the internal architecture of the problem-solving method and the knowledge-acquisition interface. Configuration Mapping Connects a concept to either constant information, or to other concepts in the same context ontology. Con guration mapping is commonly used by knowledge engineers to con gure modules before assembly. Although it is possible to assemble modules in any order, a knowledge engineer will generally start by assembling appropriate problem-solving and domain-ontology modules, de ning the application ontology of the shell. One of the goals of protege-ii is to use this assembled application ontology to at least partically synthesize a domain-speci c knowledge-acquisition interface. If necessary, the interface could then be re ned manually by the knowledge engineer. The assumption is that such an interface essentially consists of graphical knowledge editors custom-tailored to the domain (e.g., the domain terminology) and of problem-solving modules. We also assume that the knowledge editors are primarily used to create, edit, and inspect instances of classes in the ontology. There are, however, several obstacles to the generation of such knowledge editors from ontologies. One such problem is that ontologies are underspeci ed models of domain entities, the entities' relationships, and the operations on them. For example, an ontology does not necessarily describe how domain entities and problem-solving entities should be presented and edited|iconic representations of circuit components may not be relevant for diagnosing electrical devices, but such features may be important for their graphical presentation in a knowledge editor. There also are other aspects of knowledge-acquisition interfaces that cannot be derived directly from an ontology, such as the dialog structure of the user interface, the discourse of knowledge-acquisition sessions, and user preferences. We are developing a generator for graphical knowledge editors that will take as its input the model-based application ontology, augmented with information about the representation required by the generator. Note that we nd editor-related facets, such as font and screen coordinates, unsuitable for this augmented ontology. The idea is that information related to 10

PROTÉGÉ II Problem-Solving Module Library

Domain-Ontology Module Library

KA Module Library

Knowledge Engineer

Assembled Modules

Task & Domain-Specific Shells KA Editor

Domain Expert Application Ontology

Domain Knowledge

Advice Systems Problem-Solving Method

Domain Ontology

End User

Application Ontology

Figure 4: The protege-ii architecture. Knowledge engineers retrieve and assemble problemsolving, domain-ontology, and knowledge-acquisition (KA) modules to create domain and task-speci c expert-system shells. Domain experts use the knowledge-acquisition interface of these editors to create knowledge-based applications that oer advice to end users. modeling and knowledge representation should be stored in its proper place|the ontology| and that information related to the knowledge-acquisition task should be stated explicitly in a separate description (which can be used by the knowledge-acquisition{interface generator to guide the assembly process). After analyzing the application ontology, the generator automatically retrieves, con gures, and assembles knowledge-acquisition modules to create the domain- and task-speci c knowledge-acquisition tool. Sections 6.1 through 6.3 describe the three classes of reusable modules utilized by protege-ii. In particular, we discuss the role of context-ontologies for each module class.

6.1 Problem-Solving Methods

To build a task-speci c problem-solving method, the knowledge engineer creates task structures, which model some activity in the external environment. Tasks need to accomplish some goal, but do not stipulate how to achieve this goal. Instead, the knowledge engineer associates each task with a problem-solving module (called a method in protege-ii), potentially causing a task decomposition, which divides the original task into separate subtasks (Puerta et al., 11

Task

Method

Subtask B

Subtask A

Mechanism B

Mechanism A

Figure 5: Protege-ii Task Decomposition. A method imposes a task decomposition on the task that it solves; this task decomposition may then create further subtasks, which in turn must each be associated with a method. A method that cannot be decomposed further is called a mechanism. ress). This process is repeated until a method does not require further decomposition. Such leaf methods are termed mechanisms (Figure 5). Each method is associated with a context ontology that de nes its interactions with the rest of the task-speci c shell being assembled. During the module-assembly process, the knowledge engineer maps the method's concepts contained in its ontology to the method's parent ontology, to the global application ontology, or directly to concept instances. For example, a circuit-simulation method might receive three data inputs: (1) a model of the circuit, (2) a set of measurements, and (3) a parameter de ning the numerical precision of the simulation. The rst input would be mapped to the global representation of the circuit stored in the application ontology. Here, the method uses its context ontology to transfer its data model into the application domain. In contrast, the second parameter might be mapped to the context of the parent task (e.g., the input of a diagnosis-simulation method could be mapped to the output of a diagnosis method). In this case, the context is used to de ne the semantics for combining two potentially incompatible methods. Finally, the precision parameter would be mapped directly to a constant supplied by the knowledge engineer, using the context ontology to de ne local expertise for the method.

6.2 Domain Ontologies

After method assembly, the application ontology will already contain the mapped concepts of any previously created task-decomposition hierarchy. For example, the espr method would have introduced the notion of a planning-entity concept into the application ontology. Depending on the complexity of the domain being modeled, these concepts may already be sucient to represent the domain knowledge, and the knowledge engineer will be able to proceed and construct the knowledge-acquisition interface (Section 6.3). Otherwise, she must re ne the application ontology further, either by directly creating new concepts and mapping them to 12

the contexts of the task-decomposition hierarchy, or by retrieving prede ned domain-ontology modules from their library and mapping them into the application ontology. Protege-ii maintains libraries of such domain ontologies, both to reduce the work of building complex applications, and to promote the sharing and reuse of application-independent knowledge. For example, expert systems often require access to external knowledge, communicate with databases, or receive real-time information from other processes. Domain ontologies can serve as generic interfaces to this external information, translating the knowledge to and from the outside knowledge source. A second role of sharable domain ontologies is the creation of standard representations for application-independent knowledge and interapplication knowledge sharing. Ontologies allow a group of domain applications to commit to a set of terms in a consistent manner, de ning the vocabulary used in knowledge-level communication and data exchange. In this sense, ontologies can be viewed as a software interoperability mechanism (Gruber, 1991). Note that, due to the use of widely accepted terms, certain ontologies may appear to have application-independent \meaning" to external observers. For example, a knowledge engineer might claim that her domain-ontology module provides a standard ontology for representing circuit-diagram information. Although such a domain may employ standard terms to encode knowledge, in actuality, the knowledge engineer's expertise provides an implicit context for this module, making the module appear to have a universal interpretation (Clancey, 1991). From the viewpoint of the expert-system shell under assembly, however, such a domain-ontology module has no meaning until it is mapped to the current shell's application ontology. In protege-ii, mappings de ne the semantics of the assembled modules.

6.3 Generation of Knowledge-Acquisition Interfaces

The nal step in the assembly of a task-speci c shell is the creation of a custom knowledgeacquisition interface. Such an interface is created by retrieving appropriate knowledge-acquisition modules from the protege-ii library and by mapping their context ontologies to the application ontology. Although assembly can be performed manually by the knowledge engineer, an important question of our research is how to use the information contained in the application ontology to generate a task- and domain-speci c knowledge-acquisition interface. At the same time, we are identifying extensions to the model language that provide the necessary information to guide this automatic synthesis. When we speak of extended ontologies, we do not mean ontologies cluttered with speci cs about target tools, but rather we mean ontologies that more fully describe the roles of the various constructs in the ontology. We thus are building a qualitative model of the ontology and are reasoning about it to generate knowledge-acquisition tools. The generation of knowledge-acquisition tools from ontologies can be divided into six steps: (1) analysis of the ontology; (2) synthesis of the overall knowledge-editor structure; (3) selection of appropriate knowledge-acquisition modules for dierent parts of the ontology; (4) mapping of components of the application ontology (e.g., slots) to the components of the retrieved knowledge-acquisition modules (e.g., form elds); (5) instantiation of the knowledge-acquisition modules given the mapping between the application ontology and the editors under design; and (6) code generation for speci c environments and window systems. Additional speci cations and constraints can be added during the process to shape the resulting knowledge-acquisition interface. From a knowledge-representation perspective, steps 1 through 4 are the most signi cant. Internal references in the ontology must be complete to allow the generator to index the ontology (i.e., to follow up all internal references in the ontology and to index them in tables 13

for easy reference in subsequent generation steps). An initial version of the overall knowledgeeditor structure (i.e., the dialog structure) can then be outlined (step 2). Depending on the ontology and the policies for knowledge-editor generation, dierent operations on the knowledge-editor structure may be applied. For instance, the policy might be to prefer large compound forms over small nested forms that provide access to subforms. The selection of appropriate knowledge editors (step 3) depends largely on type and structure constraints on the ontology. An example of such a decision is the selection of graph editors versus forms for a given part of the ontology.

7 Discussion Until the advent of metatools, knowledge engineers had to choose between two types of problem-solving methodologies, using either a exible, unstructured data model of a generic (weak) inference engine (e.g., OPS5, EMYCIN), or the rigid, abstract model of a high-level problem-solving method (e.g., espr), also referred to as a role-limiting or strong method. The former approach has the advantage of being exible enough to be applicable to almost any type of problem situation, but it suers from an overly generic data model that requires the insertion of control knowledge into the knowledge base and provides little support for knowledge acquisition. In contrast, the role-limiting method increases the abstract power of the data model, but lacks the generality of the weak method. Metatools attempt to combine the advantages of both approaches by increasing the exibility of strong problem-solving methods, breaking them into reusable modules. One of the more dicult problems that we must solve to achieve reuse is the identi cation of appropriate architectures and models to guide the integration of these modules. Most of the approaches reported in literature have dealt with this integration issue by de ning global data types formed by the union of the data type requirements of the individual modules (Klinker et al., 1991; Wielinga et al., 1991; Chandrasekaran, 1986). These global data types form a framework for integrating problem-solving modules and (implicitly) their associated strong data models. Consequently, an individual module's data model has meaning only relative to the global data. Although this approach has been demonstrated to work, we believe that architectures based on this paradigm suer (although to a lesser degree) from the same limitations as the original role-limiting architectures, since they fail to create explicitly reusable data models in addition to the reusable methods. In particular, 1. Sharing modules with other metatool architectures is not possible, since modules' data models are implicitly imbedded in the metatool. Although it would be possible to port modules to other systems, the process may require the reimplementation of the required data types in the target architecture. 2. De ning new data types is cumbersome, since the semantics of each type are buried in the interpretation of the type by the components and the meta-system. In particular, combining the properties of two dierent types is not possible, since there is no way to combine the implicit constraints automatically. 3. Adding a new component to the library may require the creation of a new data type, and may force the knowledge engineer to extend the global data model programatically. Protege-ii attempts to overcome these problems by associating each component with a self-contained context ontology. This context (1) captures the role of the component during assembly, (2) describes the knowledge required by the component, (3) speci es the input

14

and output requirement of the component, and (4) encapsulates the component's behavior so that the component can be reused and shared. Context ontologies make it possible for protege-ii to maintain local strong data models of its reusable modules, while simultaneously providing knowledge engineers with a exible, weak global data model that is suciently generic to be applicable to a variety of dierent problems. In addition, the encapsulation of the modules through their context ontologies, in conjunction with the Ontolingua system, provides a basis for sharing modules across metatool architectures. However, before we can use context ontologies to achieve the goal of reusing modules, we must overcome a number of further problems.

7.1 Context Mapping

Abstractly, mappings represent models for consolidating diferences in syntax, vocabulary, and semantics among context ontologies (and their associated modules). We are identifying common sets of prede ned functions for performing common operations, such as mapping trees to lists. When creating this type of transformation, however, we must realize that we may be losing semantic features (e.g., mapping a tree to a list might lose information if the arrangement of the nodes in the tree de ned an implicit relationship among those nodes). Even the most expressive context-de nition language cannot capture all semantics of a context ontology, short of providing a formal description of the module's function. Furthermore, as outlined in Section 6.2, modules do not have a universal interpretation, but rather have meaning only relative to their role in a task-speci c shell. These restrictions suggest that we can never rely completely on the semantic correctness of a mapping. Altough mapping increases module reusability, it also can also place more responsibility on the knowledge engineer.

7.2 Module Portability

One of the most promising applications of context ontologies is the possibility of sharing problem-solving, domain-ontology, and knowledge-acquisition modules with other researchers| even if these modules were developed for dierent meta-architectures. Barring implementation requirements, any modules that use Ontolingua-based context ontologies to encapsulate their data model should be reusable within protege-ii or other meta-architectures that support the appropriate Ontolingua constraints. The feasibility of this vision is determined by our ability to identify a stable set of model constraints that is suciently expressive to describe all salient features of a module. Altough it should be possible to de ne a set of constraints that covers the representational needs of all modules in our protege-ii libraries, the question of how well these constraints scale up to address the more general problem of sharing modules among researchers is a part of our research. We are encouraged by the ndings of Klinker et al. (1991), who report that they have been able to identify a few dozens methods that cover most aspects of problem solving. Furthermore, even if a situation should arise where model does not meet the representational requirements of a particular module, the module designers can still create appropriate Ontolingua expressions that describe the intention of such a constraint. The module would remain usable; the knowledge engineer would merely receive a warning during the retrieval phase that part of the module's context ontology cannot be enforced. The new constraint type could then be added to model at a later time.

15

8 Summary We have described the utility of context ontologies for assembling task-speci c expert-system shells from reusable problem-solving, knowledge-acquisition, and domain-ontology modules. We believe that the use of contexts overcomes several of the exibility limitations of the global data-model architecture employed by other metatools, and provides a more powerful basis for module reuse. We are investigating the possibility of integrating context ontologies with the Ontolingua/kif knowledge-sharing work to produce libraries of portable problemsolving, domain-ontology, and knowledge-acquisition modules.

9 Acknowledgments This work has been supported in part by grant LM05157 from the National Library of Medicine, by grant HS06330 from the Agency for Health Care Policy and Research, and by a gift form Digital Equipment Corporation. Computer support was provided by the SUMEXAIM resource, supported by grant LM05208 from the National Library of Medicine. We thank John Egar, Angel Puerta, Yuval Shahar, and Samson Tu, who have greatly in uenced our thinking about context ontologies, and Thomas Gruber, who has provided insight into and assistance with the issues of knowledge sharing. Lyn Dupre's editing is gratefully acknowledged.

References Chandrasekaran, B. (1986). Generic tasks in knowledge-based reasoning: High-level building blocks for expert system design. IEEE Expert, 1(3):23{30. Clancey, W. J. (1991). The frame of reference problem in the design of intelligent machines. In VanLehn, K., editor, Automating Knowledge Acquisition for Expert Systems, pages 357{423. Lawrence Earlbaum Associates, Hillsdale, NJ. Collet, C., Huhns, M. N., and Shen, W.-M. (1991). Resource integration using a large knowledge base in Carnot. IEEE Computer, SE-11(11):55{62. Eriksson, H. and Musen, M. A. (1992). Conceptual models for automatic generation of knowledge-acquisition tools. In Proceedings of the Sixth European Knowledge Acquisition for Knowledge-Based Systems Workshop, EKAW'92, Kaiserslauten, Germany. Genesereth, M. R. and Fikes, R. (1991). Knowledge interchange format, version 2.2. Technical Report Logic-90-04, Computer Science Department, Stanford University, Stanford, CA. Gruber, T. R. (1991). Ontolingua: A mechanism to support portable ontologies. Technical Report KSL{91{66, Knowledge Systems Laboratory, Stanford University, Stanford, CA. Klinker, G., Bhola, C., Dallemagne, G., Marques, D., and McDermott, J. (1991). Usable and reusable programming constructs. Knowledge Acquisition, 3(2):117{135. McDermott, J. (1988). Preliminary steps toward a taxonomy of problem-solving methods. In Marcus, S., editor, Automating Knowledge Acquisition for Expert Systems, pages 225{256. Kluwer Academic Publishers, Norwell, Massachusetts. Musen, M. A. (1989a). Automated Generation of Model-Based Knowledge-Acquisition Tools. Morgan-Kaufmann, San Mateo, CA. 16

Musen, M. A. (1989b). Automated support for building and extending expert models. Machine Learning, 4:349{377. Musen, M. A. and Tu, S. W. (1991). A model of skeletal-plan re nement to generate taskspeci c knowledge-acquisition tools. Technical Report KSL{91{05, Knowledge Systems Laboratory, Stanford University, Stanford, CA. NASA (1991). CLIPS 5.0 Reference Manual. Software Technology Branch, Johnson Space Center, NASA, Houston, TX. Neches, R., Fikes, R., Finin, T., Gruber, T., Patil, R., Senator, T., and Swartout, W. R. (1991). Enabling technology for knowledge sharing. AI Magazine, 12(3):36{55. Puerta, A. R., Tu, S. W., and Musen, M. A. (in press). Modeling tasks with mechanisms. International Journal of Intelligent Systems. Soloway, E., Bachant, J., and Jensen, K. (1987). Assessing the maintainability of XCON-inRIME: Coping with the problems of a very large rule-base. In Proceedings of AAAI-87, pages 824{829, Seattle, WA. Tu, S. W., Kahn, M. G., Musen, M. A., Ferguson, J. C., Shortlie, E. H., and Fagan, L. M. (1989). Episodic skeletal-plan re nement based on temporal data. Communications of the ACM, 32(12):1439{1455. Wielinga, B., de Velde, W. V., Schreiber, G., and Akkermans, H. (1991). Towards a uni cation of knowledge modelling approaches. Technical Report KADS-II/T1.1/UvA/004/2.0, Dept. of Social Science Informatics, University of Amsterdam, Amsterdam, The Netherlands.

17