From: IAAI-97 Proceedings. Copyright © 1997, AAAI (www.aaai.org). All rights reserved. Suzanne M. Paley, John ID. Eowrance and Peter ID. Karp Artificial Intelligence Center SRI International 333 Ravenswood Ave., EJ231 Menlo Park, CA 94025 fax: 415-859-3735, voice: 415-859-5708 {paley, lowrance, pkarp}@ai.sri.com Abstract- been realized to a limited extent; the ONTOLINGUA The GKB Editor is a generic editor and browser of project has produced a library of ontologies (Gru- knowledge bases (KBs) and ontologies - generic in the ber 1993), and the KIF project has produced a lan- sense that it is portable across several frame knowl- guage for knowledge interchange (Genesereth & Fikes edge representation systems (FRSs). This general- 1992), but actual examples of knowledge reuse are few. ity is possible because the GKB Editor performs all This paper reports a milestone of software reuse for KB access operations using a generic application pro- knowledge-based systems by describing a knowledge- gramming interface to FRSs called the Generic Frame base browser and editor that is reusable across several Protocol (GFP). To adapt the GKB Editor to a new different knowledge representation systems. FRS, we need only to create a GFP implementation for The knowledge representation (KR) community has that FRS - a task that is usually considerably sim- long recognized the need for graphical knowledge- pler than implementing a complete KB editor. The base browsing and editing tools to facilitate the GKB Editor also contains several relatively advanced development of complex knowledge bases (KBs). features, including three different viewers of KB rela- Frame knowledge representation systems (FRSs) from tionships, incremental browsing of large graphs, KB KREME (Abrett et a2. 1987) to KEE (Kehler & analysis tools, extensive customizability, complex se- Clemenson 1984) to CYCL (Lenat & Guha 1990) have lection operations, cut-and-paste operations, and both included graphical KB editors to assist users in devel- user- and KB-specific profiles. The GKB Editor is in oping new KBs, and in comprehending and maintain- active use in the development of several ontologies and ing existing KBs. More recently, the ontology move- KBs. This paper discusses the design of the GKB Ed- ment in AI has spurred the development of graphical itor from a graphical user interface point of view, and ontology editors. describes the difficulties encountered in achieving true However, the past approach of developing KB editors portability across multiple FRSs. that were tightly wedded to a single FRS is impractical. The substantial efforts required to create such tools be- Introduction come lost if the associated FRS falls into disuse. Since most FRSs share a common core functionality, a more In 1991 Neches et al. articulated a vision of enabling cost-effective approach is to amortize the cost of de- technology for knowledge sharing (Neches et al. 1991). veloping a single FRS interface tool across a number That vision involved a “Chinese menu” (not to be of FRSs. Another benefit of this approach is that it confused with Searls’ Chinese room) of interoperable, allows a user to access KBs created using a variety of reusable components that a system designer could mix FRSs through a single graphical user interface (GUI), and match to construct knowledge-based systems, in- thus reducing the barrier for a user to interact with a cluding knowledge representation systems, ontologies, new FRS. Finally, most past KB editors have imple- and reasoners. The paper argued that because the de mented essentially the same functionality, presumably novo construction of knowledge-based systems is in- because each new system must be built from scratch credibly time consuming, future knowledge-based sys- rather than building on a previous implementation. tems should be constructing by reusing and modifying The GKB Editor is a generic editor and browser of existing components. Five years later, this vision has KBs and ontologies - generic in the sense that it is Copyright @ 1997, American Association for Artificial portable across several FRSs. This generality is pos- Intelligence (www.aaai.org). All rights reserved. sible because the GKB Editor performs all KB access EMERGING APPLICATIONS 1045 and modification operations by using a generic applica- corresponding editing operation on the KB. (6) The tion programming interface to FRSs called the Generic interface should be intuitive for the novice user to un- Frame Protocol (GFP) (Karp, Myers, & Gruber 1995). derstand and manipulate, but not unduly burdensome To adapt the GKB Editor to a new FRS, we need only for the expert user. Shortcuts should be available for to create a GFP implementation for that FRS - a common operations. (7) The interface should be cus- task that is usually considerably simpler than imple- tomizable: the user should have control over both the menting a complete KB editor. The GKB Editor also kind and amount of information displayed, including contains a number of relatively advanced features, such incremental revealing, and the appearance of the dis- as incremental browsing of large graphs, KB analysis played information. tools, operation over multiple selections, cut-and-paste We assert that the design requirements for an ontol- operations, and both user- and KB-specific profiles. ogy editor and browser are subsumed by the design re- The GKB Editor is in active use in the development quirements for a KB editor and browser. That is, a sys- of military-application planning KBs and ontologies tem that adequately supports the design, development, for LOOM (MacGregor 1991) at several sites, includ- maintenance, comprehension, and reuse of KBs will ing a military-transportation planning ontology. It is adequately support the same tasks for ontologies. The used daily in the development of EcoCyc (Karp et al. reason is that although there may be semantic differ- 1997)) a biological KB containing more than 11,000 ences between ontologies and KBs (Guarino & Giaretta frames that is accessed daily via the WWW by scien- 1995), there are no substantial symbol-level differences tists from around the world2 (public access to EcoCyc between the two (as Guarino points out, ontologies can is provided by a biology-specific GUI). The editor also include both classes and instances). Given that FRSs works with the FRSs OCELOT (developed at SRI), can serve as implementation substrates for building on- SIPE-2 (Wilkins 1990), and THEO (Mitchell et al. tologies, the GKB Editor can therefore serve as an ed- 1989), and in read-only mode for ONTOLINGUA. itor and browser of ontologies. The converse is not GKB Editor development has benefited greatly from true: it is possible to develop ontology editors that are the feedback provided by the user community, incor- not adequate KB editors. For example, since KBs will porating a number of user suggestions into subsequent generally have larger scale than ontologies, an editor versions of the system. that is adequate for an ontology could easily prove in- This paper discusses the design of the GKB Editor adequate for a large KB. from a GUI point of view, and describes the difficulties encountered in achieving true portability across multi- Architecture ple FRSs. The GKB Editor is built upon a graph-display tool Design Goals called Grasper-CL (Karp et al. 1994). Portability among FRSs is achieved by using the Generic Frame The GKB Editor was designed to satisfy the follow- Protocol (GFP) to form a wrapping layer between the ing criteria. (1) It must be portable across multiple GKB Editor and the underlying FRSs. Figure 1 il- FRSs. (2) Users should be shielded from as many id- lustrates the overall architecture of the GKB Editor iosyncrasies of the underlying FRS as possible. (3) system. OCELOT, THEO and LOOM KBs can all Knowledge should be presented in the most natural be persistently stored in a relational DBMS (Karp & form, which is often graphical. There should be mul- Paley 1995). tiple ways to view data, depending on the user’s per- Our architecture naturally lends itself to distributed spective and the types of modifications they wish to operation, in three possible modes. In the first mode, make. (4) The GKB Editor should support the en- we insert a network connection at (A) in Figure 1 by tire life cycle of a KB or an ontology, including de- using remote X-windows. In this mode, the GKB Edi- sign, development, maintenance, comprehension, and tor and the FRS run in a LISP process on one machine, reuse. By “comprehension” we mean the task of un- and the X-window graphics flow over the network to derstanding a new and unfamiliar KB, which is usually the user’s workstation. In practice, this approach is the first step in reuse. (5) Where appropriate, editing slow but workable for cross-continent Internet connec- should be accomplished through direct pictorial ma- tions; it is quite acceptable over local-area networks. nipulation. For example, if a KB is represented as a Approach (B) uses a remote-procedure call implemen- graph, then we should be able to translate an editing tation of GFP. With the network link at (C), the LISP operation that is natural to perform on a graph to the process runs on the user’s workstation and communi- 2See www URL cates with the DBMS server over the network using http://www.ai.sri.com/ecocyc/ecocyc.html. SQL. This approach faults frames across the network; 1046 INNOVATIVEAPPLICATIONS they are cached in the LISP process. All three of these Editor to display them. Before attempting this oper- distributed modes have been implemented and tested; ation, however, the GKB Editor must first query an our group currently uses (A) and (C), both alone and FRS’s behavior profile to determine whether or not in combination. annotations are supported. The GFP model cannot incorporate all functional- The Generic Frame Protocol ities of all FRSs.