Introduction

This demo will illustrate the use of Ontosaurus, a web-based tool that we have developed for browsing and editing ontologies and knowledge bases. Ontosaurus works with Loom knowledge bases, but other knowledge representations (such as the SENSUS knowledge representation) can be supported as well.

In our view, ontologies can be useful in a number of different ways. Ontologies are useful in helping developers become familiar with a domain, they can provide a sharable structure for a knowledge base, and they can provide a common language for communication between collaborating systems. To continue to be useful as system development progresses, it must be possible to augment and modify an ontology as needs change and understanding of the domain deepens. Ideally, an ontology should serve as a "living document" that tracks the development of a system.

Ontosaurus is web-based to allow ready access to an ontology from any Netscape-capable machine connected to the web. Additionally, the server-based architecture allows an ontology to be stored in one central location, easing problems of consistency maintenance. Although a web-based implementation has clear advantages, it also introduces some problems, such as network latency, that must be considered in the design of a browser.

Ontosaurus uses the CL-HTTP web server. It dynamically generates the pages used in browsing and editing from the underlying knowledge base, thus insuring that the pages displayed are consistent with the KB. In addition, Ontosaurus can display conventional, static web pages, which we use primarily for documentation.

In this demo, we will show how Ontosaurus can be used to become familiar with a domain by browsing an ontology and how the ontology can be edited and augmented using Ontosaurus.

For an online demonstration of Ontosaurus go to the Ontosaurus home page.

Figure 1 shows the initial screen of the Ontosaurus Loom ontology browser and editor.

This tool uses Netscape Frames. The Web browser window is divided into three panes. The top pane contains the control panel. The left and right panes are used for displaying content, such as the structure of an ontology or documentation of various sorts. The use of two panes allows a user to simultaneously see, for example, a detailed description of a concept in one frame and a overview of the ontology structure in the other. This directly addresses the network latency problem by reducing the amount of loading and reloading of pages that would be necessary in a single frame browser.

In Figure 1, the left pane shows the Loom Project home page, while the right pane describes the function of the various icons that are used in Ontosaurus. Additional documentation details about Ontosaurus are provided in the appendix at the end of this paper.

In Figure 2, the user has selected the AIRCRAFT ontology using the theory selection menu in the control panel. When an ontology is selected, a top level page is displayed that shows any items that have not yet been defined in the ontology as well as top level concepts in the ontology. In addition, an ontology creator may provide both textual and graphic documentation for the ontology, as shown in Figure 2. The user can browse the ontology by clicking on one of the top level concepts, or he can search for concept names in which he is interested by specifying a regular expression in the search form in the control panel. In Figure 2, the user has specified a search for those concepts whose names begin with "AIR". The results of this search are shown in the right frame.

Clicking the Hold Window button moves the contents of the right frame to the left. The user then clicks on "Fixed Wing Aircraft" and the concept is displayed in the frame on the right, as shown in Figure 3. When Ontosaurus displays a concept, it displays the concept definition, any documentation, superconcepts, subconcepts, siblings, roles, and instances of the concept. Because so much information is displayed, it usually will not all fit on the screen, and the user must use scroll to the information he needs. We decided to take the approach of displaying all the relevant information about a concept on a single page to improve performance when interacting with the server. The alternative approach would be to display a compact top level page for a concept with links to other pages showing its subconcepts, roles and so forth. The disadvantage of that approach is that each request to display some new aspect of the concept requires interaction with the server which significantly adds to the system's latency.

In Figure 4, the user selects the concept "BOMBER" for display. Scrolling down in that display, Figure 5 shows the roles on BOMBER and instances of BOMBER. The user selects an A-10 for display, which is shown in Figure 6.

To help with domain familiarization, the browser displays a graphic of the airplane in Figure 6 as well as documentation about the airplane (derived from Air Force fact sheets published on the web). In addition, the display indicates the concepts (types) that this instance is a kind of. Those types that have been inferred by the Loom classifier using the definition of the concept are displayed in italics, while the those that have been directly asserted are shown in regular text. At this point, the user notices that an A-10 is not a type of ATTACK-AIRCRAFT, and wonders why this inference was not made.

Figure 7 shows the definition of an ATTACK-AIRCRAFT. The user notices a modeling bug: the existing definition says that any aircraft that has SEAD as its mission-type is a kind of ATTACK-AIRCRAFT, but the entry should actually be either SEAD or CAS (close air support). If that bug is fixed, then an A-10 will classify correctly as an ATTACK-AIRCRAFT. The user clicks on the edit unlock button to allow him to edit the concept. Note that a number of new options are added when the unlock button is clicked.

Figure 8 shows the form used for editing concepts. The form shows how the concept is currently defined, and allows a user to edit the definition. In Figure 9, the user adds CAS to the types of mission for an ATTACK-AIRCRAFT. When he then submits this form, the definition of the concept is updated, and the Loom classifier now infers that an A-10 is a kind of ATTACK-AIRCRAFT, as shown in Figure 10.