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