Toward Distributed Use of Large-Scale Ontologiest

Bill Swartout

Ramesh PatilKevin Knight

Tom Russ

USC/Information Sciences Institute4676 Admiralty Way

Marina del Rey, CA 90292{ swartout, ramesh, knight, tar} @isi.edu

AbstractLarge scale knowledge bases systems are difficult andexpensive to construct. If we could share knowledgeacross systems, costs would be reduced. However,because knowledge bases are typically constructedfrom scratch, each with their own idiosyncraticstructure, sharing is difficult. Recent research hasfocused on the use of ontologies to promote sharing.An ontology is a hierarchically structured set of termsfor describing a domain that can be used as a skeletalfoundation for a knowledge base. If two knowledgebases are built on a common ontology, knowledge canbe more readily shared, since they share a commonunderlying structure. This paper outlines a set ofdesiderata for ontologies, and then describes how wehave used a large-scale (50,000+ concept) ontology develop a specialized, domain-specific ontology semi-automatically. We then discuss the relation betweenontologies and the process of developing a system,arguing that to be useful, an ontology needs to becreated as a "living document", whose development istightly integrated with the system’s. We concludewith a discussion of Web-based ontology tools we aredeveloping to support this approach.

Introduction

Current knowledge bases are difficult to share or re-use,even when they are expressed in the same formalism andcover the same domain. In our view, this problem stemsfrom the lack of a shared terminology and structure for theknowledge bases. In building a knowledge base, there aremany intermediate concepts that a system builder mustcreate and organize to get from specific domain level termsand the very high level concepts that a knowledgerepresentation system provides by default (like "THING").The decisions about just what those intermediate conceptsshould be, and how they should be structured, may seem to

KB 1 KB 2

Figure 1: Two ways to represent a "strut"

be somewhat arbitrary since there are many possibleorganizations that can work.

For example, consider the two knowledge base fragmentsshown in Figure 1. Both of these fragments represent theconcept of a "strut" such as might be part of an aircraftlanding gear assembly, but the intermediate concepts usedare completely different. KB 1 reflects an orientation basedon the semantics of natural language, while KB2 usescommonly occurring domain terms. This difference instructure and terminology makes it difficult to share orcombine these two knowledge base fragments.

We as well as others [Neches et al 1991; Gruber 1993;Swartout et al 1993] have suggested that basing arepresentation on an ontology or set of ontologies mightprovide the answer. An ontology is a set of structuredterms that describes some domain or topic. The idea is thatan ontology provides a skeletal structure for a knowledgebase. If two system builders build their knowledge bases ona common ontology, the systems will share a commonstructure, and it will be easier to merge and share theknowledge bases.

Although the use of ontologies suggests a possibleapproach to building sharable knowledge bases, it alsoraises a number of questions:

¯ Where does an ontology come from?

A longer version of this paper appeared in the Proceedings of the 1996 Banff Knowledge Acquisition Workshop.

138

From: AAAI Technical Report SS-97-06. Compilation copyright © 1997, AAAI (www.aaai.org). All rights reserved.

¯ How should it be organized?

¯ What tools are needed to support its use indistributed, collaborative efforts?

In this paper, we discuss our experiences in using a large(50,000+ concept) ontology and the tools we aredeveloping to support the use of ontologies during systemdevelopment. We begin with a discussion of somedesiderata for ontologies.

Desiderata for Ontologies

We begin this discussion by drawing a distinction betweentwo different types of ontologies. Domain ontologiesprovide a set of terms for describing some domain, such asmedicine, air campaign planning, or computermaintenance. Domain ontologies can be very large andinclude thousands of concepts. Theory ontologies, on theother hand, provide a set of concepts for representing someaspect of the world, such as time, space, causality, or plans.Theory ontologies tend to be more abstract and smallerthan domain ontologies. Domain ontologies can bethought of as providing a taxonomy of the relevant objectsin some domain, while theory ontologies specify anapproach to representation of some aspect. Most of ourwork concerns domain ontologies, while others (see[Gruber 1992; Tate 1996]) have investigated theoryontologies. Our desiderata apply primarily to domainontologies.

To be useful throughout the lifecycle of a system, there area number of characteristics that an ontology should have:

1. An ontology should not "over commit" onrepresentational choices. A common error in buildinga knowledge based system is to attempt to design indetail the various elements of the knowledge base,such as the roles and relations on concepts, constraintsamong them and so forth, before considering how (orif) those elements would be used in problem solving.In the best case, this just results in wasted effort, sincesome of the structure that is created turns out to beirrelevant. In the worst case, major portions of theknowledge base may have to be redone since thestructures chosen beforehand will not work for theproblem solving that needs to be done. Since anontology is, in essence, a pre-package design for aknowledge base, it is important that it leave somerepresentational choices open so that they can be madelater, based on how knowledge will actually be used inproblem solving. In the ontologies we havedeveloped, the subsumption (a-kind-of) relationsbetween concepts are specified, but the relations onconcepts (that is, their "slots") is not specified, sincethe particular kind of problem solving that will bedone usually dictates what relations are mostappropriate. We conjecture that one of the reasons

why KADS [Wielinga and Breuker 1986] has been sowidely accepted is that it started out as an informal,"on paper" approach that provided guidance to systembuilders without over-constricting their design choices(as might have happened in a more formal method).

2. An ontology should be extensible. Because it isdifficult to envision in advance how an ontology mightbe used, it should be possible to extend the ontology tocover new areas as they arise. Extension should bepossible both at a low level, by adding domain-specificsubconcepts, or at high level by adding intermediate orupper level concepts that cover new areas.

3. The ontology should be extended based on needsidentified during actual use. In general, there areseveral possible ways that an ontology might beextended. For example, to capture a causal relation onecould choose to represent it as a relation between twoconcepts, or one could reify the relation as a concept.How should a system builder choose among them?These seemingly arbitrary choices are a problem,particularly if the ontology is developedcollaboratively by more than one individual, since ifthe collaborators make different choices theknowledge base will not be consistent. On the otherhand, the choice becomes clearer, if one takes intoaccount the kinds of reasoning that the system mustsupport and the problem solving methods that providethat reasoning, since some of the representationalchoices will not support the required reasoning. Thus,if extension is guided by real use, it constrains thepossible extensions that might be made, and helpsensure that the extensions are consistent and coherent.

4. Ontologies should not be "stovepipes." The derisiveterm "stovepipe system" is used to describe a systemthat may be vertically integrated but cannot beintegrated horizontally with other systems. We want amethodology for building ontologies that will allow usto integrate two independently developed ontologies,even if the need to integrate the ontologies was notanticipated in advance.

5. An organizing principle (or principles) should be usedto structure an ontology. In building an ontology (orany knowledge base) many of the design decisions,such as what concepts to use, may seem arbitrary.Indeed, without some guiding principles, decisionsmay be made inconsistently in different parts of theontology, reducing its coherence. In our ontologywork, we have used linguistics as a guide foridentifying the concepts that should be in the ontology(particularly the upper level concepts). Linguistics not the only guidance that could be used. It might bepossible, for example, to use conceptual clustering[Michalski 1980] as a guide for ontology structure.

We have used these desiderata to guide our development ofboth ontologies and the tools that make them useful inbuilding systems. The next three sections describe an

139

experiment we performed using a large-scale ontology tocreate a specialized domain ontology.

Approach to Ontology Construction

Our approach to ontology construction has been to startwith a broad coverage, skeletal ontology that contains over50,000 concepts. This ontology includes both high andintermediate level terms, but it generally does not includedomain specific terms. We then link domain specificterms to the ontology and extend it as the needs of aparticular domain require (see

Figure 2). To reduce storage requirements and increaseefficiency, we then prune out irrelevant concepts from thebroad coverage ontology to produce a focused ontologythat includes domain level terms organized by the upperlevel terms in the broad coverage ontology.

A major advantage of this approach is that it helps us avoid"stovepipe" ontologies. If we start in one domain such asair campaign planning, the broad coverage ontologyprovides a pre-existing structural base that will allow us togrow our initial ontology to cover other areas.Alternatively, if two ontologies are developedindependently (such as logistics and transportationplanning in the figure) the broad coverage ontology can actas a "hinge" that couples the terminology and organizationof one ontology with the other.

But where does the broad coverage ontology come from?The next section addresses that issue.

SENSUS: A Broad Coverage Ontology

SENSUS is a natural language based ontology that theNatural Language group at ISI is developing to provide abroad conceptual structure for work in machine translation[Knight and Luk 1994; Knight et al. 1995]. It includesboth high-level terms (such as "inanimate object") as wellas specific terms (such as "submarine"). The terms areorganized into an AKO (subsumption) lattice. Eachconcept in the lattice corresponds to a word sense. Thus,for the word "strut", SENSUS contains three conceptscorresponding to the different meanings of the word"strut". Currently, SENSUS contains well over 50,000concepts.

In contrast to other broad coverage ontologies, such as theontology that is part of CYC [Lenat and Guha 1990],SENSUS was developed by extracting and merginginformation from existing electronic resources, rather thanconstructed from scratch. We will present a review of theconstruction process here; the original work is described in[Knight and Luk 1994].

SENSUS provides a hierarchically structured concept basewhose terms are used as tokens in interlingua expressionsfor machine translation. The abstract terms at the top of the

Figure 2: Linking Domain Terms to a Broad CoverageOntology

hierarchy reflect linguistic generalizations, while theintermediate and lower level terms are familiar, "everyday"terms. Because the machine translation system operates inunrestricted domains, the concept base needs to be verybroad.

In building SENSUS, it was found that a number ofexisting resources had some of the necessarycharacteristics, but none of them had them all. ThePENMAN Upper Model [Bateman et al 1989] and ONTOS[Nirenburg and Defrise 1992] were two very high level,linguistically-based ontologies. They could provide a highlevel organization, but since each contained only a fewhundred concepts, they lacked the necessary broadcoverage. WordNet [Miller 1990], a thesaurus-likesemantic net, had broad coverage, and was hierarchicallyorganized, but lacked the upper level structure. Electronicnatural language dictionaries also had broad coverage andsemantic categories that associated certain word senseswith particular fields, by identifying, for example, termsfrom medicine or biology.

~ySemantic II PENMAN I Categories I

Upper ModelI

\I Ontology BaseI IdictionaryEnglish I

Kenkyush~

Figure 3: SENSUS Merging Strategy

Since each of these resources had some of the requiredfeatures, but none had all of them, [Knight and Luk 1994]created SENSUS by merging the resources, so thatSENSUS would bring together the needed characteristics.This process began by merging the PENMAN UpperModel, ONTOS and the semantic categories from the

140

3 senses of strut as nounSense 1"strut, swagger" I swagger, strut

=>"manner of walking" I walk, manner of walking=>"bearing, carriage" I carriage, bearing

Sense 2"strut/brace" I strut

=>"brace, bracing" I brace, bracing=>"structural member" I structural_member

=>"support/supporting structure" I support=>"supporting structure" I supporting_structure

=>"construction, structure" I structure, construction=>"instrumentality/artefact" I instrumentality=>"artifact" I artifact, article, artefact=>"inanimate object" I object, inanimate_object, physical_object, thing=>entity

Sense 3"prance/gait" I strut, prance, swagger

Figure 4: Looking up "strut" in SENSUSdictionary by hand to produce an ontology base (see Figure3). WordNet was then merged (again by hand) with Ontology Base.

A merging tool was then used to merge WordNet with theEnglish dictionary. The tool is semi-automatic in the sensethat it looks for corresponding terms in two ontologies andproposes them to a user for confirmation. The reason whyit is difficult to find correspondences is that many Englishwords have multiple senses. The tool must try to figure outwhether "bank - sense 1" in one ontology corresponds to"bank - sense 3" or "bank - sense 5" in the other ontology.The merging tool uses two techniques to try to identifymatches. The first tries to find matches by looking forsimilarities in the textual definitions that are associatedwith the concepts in each ontology. The second technique,which is more reliable, uses the hierarchical structure ofthe ontologies. It begins by identifying the correspondencebetween unambiguous terms in both ontologies (such as"sandpiper"). The tool then moves up and down thehierarchy from these fixed points. If it finds ambiguousterms that are in structurally similar positions it proposesthem as possible correspondences. For example, if "bird -sense 1" in one ontology and "bird - sense 5" in the otherontology are both parents of the term "sandpiper" in theirrespective ontologies, the tools proposes that the twosenses of bird are in correspondence. To support machinetranslation, the result of this merge was then augmented bySpanish and Japanese lexical entries from the CollinsSpanish/English dictionary and the KenkyushaJapanese/English dictionary.

SENSUS has provided the lexicon and interlingua neededfor ISI’s Japanese/English machine translation system[Knight et al. 1995]. Further, it helped coordinate thedevelopment of a Spanish/English translation system,which was a distributed effort, involving three differentresearch groups at ISI, CMU and NMSU working together.SENSUS helped standardize the terminology andrepresentations that were used among the three sites.

Thus, SENSUS is valuable as anontology for machine translation.But with over 50,000 concepts,SENSUS also contained many ofthe concepts that one might needin building a knowledge basedsystem. An interestingpossibility occurred to us: CouldSENSUS provide the basis for anontology for a knowledge basedsystem? Informal initialexaminations of SENSUS lookedpromising. For example, lookingup "strut" in SENSUS producedthe results shown in Figure 4

Sense 2 of "strut" is clearly thesense we had in mind in theexample of Figure 1. It isinteresting to note that thestructure above "strut" in

SENSUS is substantially more extensive than in eitherexample in Figure 1. While those examples are admittedlystrawmen, we argue that they are not atypical of the sortsof structures one finds in many knowledge based systems.It seemed that a larger test of SENSUS as an ontology forknowledge based systems might be revealing.

SENSUS as a basis for a domain-specificontology

As a test, we decided to use SENSUS to construct anontology for military air campaign planning. We decidedthat it would not be practical to start with SENSUS andjust add domain specific terms to it as needed. A 50,000+concept ontology like SENSUS is somewhat unwieldy, andstoring and manipulating it consumes considerablecomputing resources. If we were to deliver an ontologythat included all of SENSUS and the domain specific termsas well, we felt that system builders would not beenthusiastic about the performance cost, particularly ifmost of the concepts in the ontology are irrelevant to theirconcerns, as will be the case for most domains. To makeSENSUS usable as a basis for a domain-specific ontology,we needed a way to identify the terms in SENSUS thatwere relevant to a particular domain, and then prune theontology so that it included only those terms.

We began with approximately 60 "seed" terms that domainexperts in air campaign planning identified for us. Theseseed terms were linked by hand to SENSUS, as shown inFigure 5, where the seed terms are cross-hatched. (Thesefigures are intended to be illustrative. The number ofconcepts actually involved was far greater than can easilybe shown graphically.) We included all the concepts onthe path from the seed terms to the root of SENSUS, asshown in Figure 6. The semantic categories derived fromthe English dictionary included a category for "military"

141

i

Figure 5: Linking domain terms to SENSUS Figure 6: Including nodes on path to root

I

Figure 7: Adding "military terms I Figure 8: Adding entire subtree

Key: terms. Since air campaignplanning is a military domain,we included all the militaryterms. These are shown in darkgray in Figure 7. Finally, forthose nodes that had a largenumber of paths through themwe decided in some cases toinclude the entire subtree underthe node (see Figure 8), based the idea that if many of the nodes

in a subtree had been found to be relevant, then the othernodes in the subtree were likely to be relevant as well.This step was done manually, since it seemed to requiresome understanding of the domain to make the decision.(Note that very high level nodes in the ontology willalways have many paths through them, but it is almostnever appropriate to include the entire subtrees under thesenodes.)

O SENSUS Term

~) ACP Seed Term

I~) Path to Root

O Military Terms

O Frequent Parent

O Subtree Terms

Air Campaign Ontology Results

Starting with roughly 60 seed terms, we used the processoutlined above to generate an ontology. The resultingontology contained approximately 1600 concepts. Thisincluded high-level organizational terms, such as"inanimate object" as well as domain-specific terms thatwere not in the original seed terms, such as: aircraft carrier,ammunition, and battle group. The entire process ofgenerating the ontology from the seed terms tooksubstantially less than one person-week of effort.

As an example, some fragments of the knowledge baseshowing high-level terms in the ontology, location/spatialterms, and military structure terms are contained in Figure9 through Figure 10. To us, one of the most surprisingthings about this exercise was the range of relevantconcepts that appeared in the final ontology, even thoughthey were not part of the initial seed set. On the otherhand, it should be understood that the pruning mechanismwe used was heuristic, and some concepts that wererelevant in only a humorous way managed to sneak in,such as "Col. Blimp" (who crept in as a military person)and "pirate ship" (which got in when we included thesubtree under ship).

142

: : : OBJECT: : : : CONCEPT_0003: : : : : CONSCIOUS-BEING: : : : : : ANIMAL: : : : : : : MALE-ANIMAL-OR-FEMALE-ANIMAL: : : : : : : : FEMALE-ANIMAL: : : : : : : : : female person...*: : : : : : : : : female/animal...*: : : : : : : : MALE PERSON-OR-FEMALE PERSON...*: : : : : : : : MALE-ANIMAL: : : : : : : : : male person...*: : : : : : : : : male/animal...*: : : : : : : animate being...*: : : : : : : someone...*: : : : : NON-CONSCIOUS-THING: : : : : : SPATIAL-TEMPORAL: : : : : : : ASPECTUAL: : : : : : : : DURATION-ASPECT: : : : : : : : : MOMENTARY: : : : : : : : : PROLONGED: : : : : : : : ITERATION-ASPECT

Figure 9: High-level terms

: : : : : construction, structure: : : : : : building complex: : : : : : : establishment/building complex: : : : : : : : facility/establishment: : : : : : : : : military installation: : : : : : : : : : armory, arsenal: : : : : : : : : : base of operations: : : : : : : : : : : air station: : : : : : : : : : : army base: : : : : : : : : : : firebase: : : : : : : : : : : navy base: : : : : : : : : : emplacement/installation

: : : : : : : : : : : gun emplacement: : : : : : : : : : : : nest/gun emplacement: : : : : : : : : : : : pillbox/gun emplacement

: : : : : : : : : : military headquarters

Figure 10: Military structures Fragment: : : : : : : SPACE-INTERVAL: : : : : : : : CONCEPT_0058: : : : : : : : : ONE-OR-TWO-D-LOCATION

: : : : : : : : : : area, region

: : : : : : : : : : : district, territory

: : : : : : : : : : : : administrative division: : : : : : : : : : : : : province, state

: : : : : : : : : : : geographical area

: : : : : : : : : : : scene/area: : : : : : : : : : : : THEATER-OF-WAR

: : : : : : : : : ¯ line/location

: : : : : : : : : : surface/location: : : : : : : : : THREE-D-IX)CATION: : : : : : : SPACE-POINT: : : : : : : point/location: : : : : : : : mathematical point

: : : : : : : : : midpoint

: : : : : : : : : : centre of gravity

: : : : : : : : : : : CENTER-OF-GRAVITY: : : : : : : : topographic point: : : : : : : : : target area

Figure 11: Location/Spatial Terms Fragment

In this section, we’ve shown how a large-scale ontologycan help in rapidly creating an extensible domain-specificontology. However, creating the ontology is only part ofthe story. For an ontology to actually be used, tools areneeded that integrate the ontology into a system’sdevelopment process. In the next section, we discuss ourvision for how ontologies can be used in systemconstruction and some of the tools we have constructed tosupport that vision.

Toward Usable Ontologies

Recent research initiatives, such as the DARPA/RomePlanning Initiative (ARPI) [Fowler et al, 1995], haveinvolved teams of researchers working in a commondomain with the goal of integrating their systems toproduce a much larger and more capable system than anygroup could produce alone. This approach is a contrast toearlier efforts in which researchers tended to work largelyindependently. Within ARPI, several ontologies have beendeveloped. The hope was that these ontologies would servethree important roles. First, they could help researchersbecome familiar with a domain by browsing the ontologyto learn the terminology and some of the semantics of thedomain. This could reduce the amount of time that wasspent with domain experts, who are generally a scarceresource. Second, the ontology could speed systemdevelopment, by providing system builders with a largebase to build upon. Third, when it came time to integratesystems, the ontology could help by providing commonterminology to support inter-system communication.

Although the ontologies developed within the ARPI efforthave been used somewhat, it is fair to say that they havenot been used widely and the hopes for them have not beenrealized. Several reasons can be identified for thisproblem:

¯ Lack of early ontology support. Generally, ontologydevelopment efforts and the research projects started atabout the same time. As a result, developers willmade up their own knowledge-bases in order toproceed with their individual projects. Thus, evenwhen a satisfactory common ontology was eventuallydeveloped, reconciling the differences between earlyontological commitment made by individualresearcher with the common ontology was, in manycases, too much effort.

¯ Lack of browsing tools: Early ontologies were oftendistributed as source code in a particular representationlanguage. Only the support tools present in the KRsystem used for encoding the ontologies wereavailable. As a result, it was very difficult for systemdevelopers to understand the ontology. We believe,that support tools for browsing ontologies (designedspecifically with large ontologies in mind) areessential, particularly for the domain familiarizationrole of ontologies. Users should be able to browse

143

through an ontology in order to understand its scope,structure and content. They should be able to rapidlysearch the ontology for terms of interest and relatedterms, much in the fashion of on-line dictionaries andthesauruses. Only when the users are familiar with thecontents and are able to locate the terms of immediateneed, will an ontology be used as the terminologicalfoundation for other systems.

¯ Lack of translators: Ontologies were delivered insome particular representation language, but systemdevelopers used a variety of knowledge-representationsystems and programming languages to support theirindividual needs. In the previous efforts, it was left upto individual developers to translate and incorporatethe ontologies within their systems. This requiredsignificant up-front effort on tile part of the developers(if it was done at all). To overcome this we need toolsfor specifying and extracting subset of ontologyrelevant to a given application, and translators that cantranslate descriptions out of ontologies in formatssuitable for system developers (e.g., Ontolingua, C++and IDL).

¯ A one-shot or release-based approach to ontologydevelopment. Rather than growing with the systems ina tightly-coupled fashion, ontologies were eitherreleased once and not extended, or versions of anontology were made available at periodic intervals. Ifa particular system builder wanted to extend theontology, it took a long time for his extension to bereflected in the shared ontology, Furthermore, when anew version of an ontology was released, developerswere reluctant to take on the burden of updating theirsoftware to track changes in the ontology. As a result,the ontology and the implementations diverged, thusnegating the advantages of shared ontology.

The problems above all stem from the failure to integrateontology use and development directly into the process ofsystem development itself. That is, rather than regardingthe ontology as a separate resource that is updatedperiodically, the development and extension of theontology should occur as part of system development. Inthis way, the ontology becomes a "living document" that isdeveloped collaboratively and, at any given time, reflectsthe terminology that is shared by developers within aneffort. Thus, if a system builder needs to extend theontology, he should be able to do so, perhaps on a privatecopy of the ontology initially, and then make hisaugmentations available to others by integrating hischanges into the shared ontology.

To support this collaborative view of integrated system andontology development, it is important that the ontology,and the ontology development environment itself, supportgroup activity, such as, simultaneous viewing, editing andupdates. Towards this end, the ontology server mustsupport, version control, ability to check in and outmodules for local updates. Additional tools are needed thatcan guide in the task of adding new knowledge, verifying

that the new knowledge is coherent and consistent with theexisting base, and in tracking the evolution of ontology byhighlighting differences between ontologies (e.g., identifyconcepts that have been added, deleted or modified) anddifferences between concept definitions.

The vision of distributed collaborative ontologydevelopment was initially explored by the Ontolinguagroup at Stanford [Farquhar et ai. 1995] under theKnowledge Sharing Effort [Neches et.al. 1991]. A WebBased ontology browsing and editing environment forOntolingua [Gruber 1992] has been in operation sinceJanuary 1995 and has been received considerable attentionwithin the knowledge sharing community[Rice et al. 1996;Farquhar et al. 1996]. In addition, tools have beendeveloped to translate Ontolingua into and out of otherlanguages such as Loom and IDL. The Ontolingua systemhas been used to develop sharable foundation ontologies inmany areas, such as abstract algebra, units and dimension,component-connection models, and configuration problemsolving [Gruber 1993].

A key difference in the approach we are advocating is theuse of broad coverage general ontologies as a starting pointfor constructing domain-specific ontologies. Ourexperience with SENSUS ontology and the knowledgesharing ontology library [Gruber 199] suggests that carefuldevelopment of foundational ontologies for high leveldomain concepts such as the time, space, and mathematicalconcepts must be complemented by broad coverageontologies that address everyday concepts and vocabularyof a domain. These two extremes in a continuum of theontology development require different considerations: thefoundational ontologies tend to be small but requireconsiderable deliberation and analysis in their developmentwhereas the domain ontologies tend to be massive, requireconsiderable domain knowledge and close participation ofdomain experts in their development. The terminology, thestructure and organization of the domain, and a crispdefinition for each term in the ontology play central role indomain ontologies. A concept definition in a domainontology tends to be fairly straightforward. In contrast,defining a concept in a foundational ontology may raisesubtle issues that need to be addressed. An additionalconsideration stems from the respective sizes offundamental and domain ontologies. Fundamentalontologies tend to be quite small, but domain ontologiesmay involve thousands of concepts. This distinctionchanges the need for tools to help maintain the ontology.While a tool for maintaining the concept hierarchy, such asthe Loom classifier [MacGregor 1991; 1994] may behelpful for a small fundamental ontology, it is much morecritical for maintaining a large domain ontology, since itsscale makes it much harder to maintain manually. Thus,the tools and techniques for rapid development of domainontologies demand a different focus than those for thefoundational ontologies.

144

The Ontosaurus Browser

This section describes our work in constructing adistributed ontology browser and editor. To support ourcollaborative vision of ontology development, an ontologymust be widely available and editable, yet to maintaincoherency and consistency, it should be centrallymaintained. To us, Web-based technology (HTTP/HTML)seems ideal for achieving such seemingly conflictingdemands. The ontology environment consists of two parts:an ontology server, and ontology browser clients.

The Ontology Server (called Ontosaurus) is implementedusing CL-HTTP [Mallery 1994] a highly programmableobject-oriented Common-Lisp-based Web server, theLoom knowledge representation system [MacGregor1991 a,b], and Lisp code that interfaces Loom to CL-HTTPfor browsing, editing, querying, translating, and otherLoom knowledge base maintenance functions.

The client is the widely available NetScape 2.0 (or laterversion) browser. In response to queries from a user, theOntosaurus server dynamically creates HTML pages thatdisplay the ontology hierarchy and it uses HTML forms toallow the user to edit the ontology. By using the Web, and

~:.~.~::::=:~..:~:~. ......................................................................Netscape: 0ntoSauru$ Loom ............................................................................... I~

’ Back Forwird HomeI I I Reloed Irneges OpenI , I ,I Find ~: :I Loo&tfim http ://tndra.tst.edu :8000/loom/shuttle.html

EI

Concept ATTACK-AIRCRAFT

Edit Conce~t ~Create Insttace ~ Find Ma~hi~ Instances

Theory: AIRCRAFT Package: TEST

Definition

(def concept ATTACK-AIRCRAFT:IS (:AN]) FIXED-WING-AIRCRAFT

(:SOME MISSION CO.AT-MISSION ( : SOME ~SSION

( : ONE-OF SEAD ) )

iii0Docunenltlion A- I 0

The A-IO and OA-10 Thunderbolt IIs are the firstEdit Concept ~xeate Instance ~m~ ~ Instances

Air Force alrcmft specially designed for close a~rsupport of ground forces. They am simple, effec~veand survivable tw~n-englne jet aircraft that can be ~ubconsept#used against ell ground ~argets, including tanks end

ATTACK-AIRCRAFT

other armored vehicles./A~d/e.

Theory: AIRCRAFT Package: TEST 3upe~:oneepts ATtACK-AIRCRAFT

BOMBERCOMB AT-AIRCRAFT

Asserted: FIXED-WING-AIRCRAFT AIRCRAFT

Direct: BO.~.B.FJ2 PILOTED-AIA~YRAFTFLYIH~-OB JECT

p~q¥~ICAL-ENTITYENTITY

THING

Role FillersVEHICLE

A-tO PHySICAL-ENTITYENTITY

tm CEILING 1,000ftTHING

FIXED-WING-AIRCRAFTc= COST $8,800,000 AIRCRAFT

"" CREW- SIZE 1 FLYINO-OB JECT

¢,1 ~(]::]::iii!! ii:!ii;:ii!i’i ~ii:’~!ii: ii:i]’:i]!*.i:] ,~!i!!i!! i iii :i:ii !it!It, PHY SICAL-ENTITY

~!,:’~","T~

- ~-~

Figure 12: The Ontosaurus Browser

145

Netscape as our client, the ontology can be examined andedited on many platforms anywhere a network connectionis available, yet the ontology itself is centralized in theserver.

As shown in Figure 12, the browser is made up of threeframes. The top frame consists of a control panel, whichprovides a variety of menus and buttons. The control panelallows the user to select an ontology from the library("theory"), display the documentation page for theontology ("show"), load an ontology, save changes to ontology, move the contents of the lower two panes ("holdwindow"), and search for concept, relation, or instances inthe ontology. In addition, the graphic icons on the controlpanel provide ready access to help documents forOntosaurus, Loom, and the on-line Loom referencemanual.

The two panes below are used to display the contents.Whenever a new document is requested, it is displayed inthe lower right frame (called the CONTENT frame). If user wishes to hold a page in view while exploring variouslinks on the page, he may move the content to the lowerleft frame (called the TOC frame). Furthermore, whileediting a concept or entering a new concept, the two framesallows a user to simultaneous access to the editing form aswell as the ontology. Thus, the two lower frames providesa nice environment for navigating, exploring or updatingthe contents of the ontology, while a static top paneprovides ready access to the controls without the need forscrolling through pages.

Because we envision that the ontology will be used bothfor domain familiarization as well as a formalrepresentation for a knowledge based system, we haveincluded in the ontology items like graphics and textualdocumentation that are not normally part of a formalrepresentation. Thus, in Figure 12, the left pane shows apicture of an A-10 as well as text documentation for it.

Our design philosophy is that each dynamically generatedpage should be a complete document, that is, it shouldbring together all the information relevant to an item. Forexample, the documentation page for a concept contains (i)image and textual documentation associated with theconcept, reference links to other related source documentsand references used in formalizing the concept, (ii) concept definition with hyperlinks to other concepts andrelations used in the definition, (iii) its super-concepts, sub-concepts, and sibling concepts, (iv) applicable roles (slots),and (v) instances of the concepts in the knowledge base.Furthermore, we use typographical conventions todistinguish between information that is asserted (standardface), and that is inferred by the Loom classifier (italic).For example, in Figure 12, an A-10 is asserted to be aFIXED-WING-AIRCRAFT, but it is inferred to be aBOMBER and a PILOTED-AIRCRAFT. All objects(concepts, relations, instances) are hyper-linked (appear link color), whereas data (i.e. constants such as strings,numbers etc.) are not. Finally, we have designed collection of character height icons to compactly provide

additional information such as single-valued vs. multi-valued relations.

If the user wants to edit a concept or instance, he clicks onthe edit button. Fields are provided to edit role restrictionsand super-concepts. In addition, a text window is providedfor more complex Loom forms.

Because the Ontosaurus server incorporates Loom, it cantake full advantage of Loom’s reasoning capabilities. Inparticular, when a new concept is added or an existingconcept modified, Loom is used to classify the newdescription in its proper place in the ontology and to verifythat the new description is coherent, and the results of theclassification become available to all users of the system.

Our current implementation of the browser thus providescapabilities for browsing, and editing of Loom basedontologies. Translators from Loom to Ontolingua [Gruber1992], and KIF[Genesereth and Fikes 1992; Genesereth1991] and KRSS [Patel-Schneider et al. 1993] have beendeveloped that can translate individual Loom objects ondemand, and have been incorporated with the browser toallow a user to simultaneously view Loom and itstranslation during browsing, or to request that a KB besaved in one of these languages for use by other system’s.Additionally translation of a Loom knowledge base to aC++ object schema has also been implemented to allowusers to generate appropriate C++ ".h" and ".C" files thatcan be compiled to create C++ object classes and instancescorresponding to concepts and instances in the Loom KB.

We are currently working on providing tools for comparingand contrasting different versions of an ontology as itevolves. In addition, we are extending Loom’s built-inontology to support on-line collaboration, such as an "edithistory" and documentation of issues. Additional tools forsemi-automatic merging of ontologies, and extractingsubsets from the ontology (as mentioned earlier) are alsoplanned.

Related Work

The development of Ontosaurus was inspired by theStanford Ontology sever {http://www.ksl.stanford.edu/}based on Ontolingua. Like the Ontolingua browser,Ontosaurus provides full access to ontologies, allows on-line editing, and provides various translation and ontologymanagement tools. Also like the Stanford Ontolinguaserver, it is intended to provide an environment fordistributed collaborative development and maintenance ofontologies. One difference is that Ontosaurus is intendedto help people become familiar with a domain and thus thebrowser provides support for documentation and graphicsto help people become acquainted with domain objects. Amore significant difference is that Ontosaurus is built onLoom, a fully functional KR system. Using Loom as anintegral part of the ontology development environmentallows us to provide the range of reasoning capabilitiesassociated with Loom and to leverage them for providing

146

ontology maintenance services such as the automaticdetection of incoherence, inconsistency, and missingdefinitions.

The ontology development approaches taken in Ontolinguaand Ontosaurus also differ significantly. The Ontolinguaapproach is to construct a collection of relatively smallcontent rich theory ontologies, and to compose themtogether to form larger ontological structures. Theapproach taken in Ontosaurus is to develop a largecomprehensive linguistically motivated ontology thatprovides a common organizational framework for thedevelopment of a knowledge base. This structure is thenenriched with domain terms and facts to generate richontologies. We believe that providing a carefully organizedoverarching framework will greatly simply the task ofintegrating independently developed systems, and facilitatecommunication between systems.

KSSn[Gaines 1994, 1995] is also similar to Ontosaurus.KSSn provides many of the KL-One like inference servicespresent in Loom. In addition to web-based browsing andediting capabilities, KSSn, also provides web-basedgraphical editing capabilities (using application plug-ins).

A number of other researchers are also exploringknowledge-based collaborative engineering. In particularthe SHADE.[McGuire et al. 1993] system uses an ontologybased approach to facilitate collaboration between productdevelopment and integrated manufacturing. Shadeprovides a rich collection of tools for tracking andpropagating design changes and allowing distributed teamsof engineers to resolve changes to the overall design. Theemphasis in SHADE is to support distributed collaborationenvironment for computer aided engineering. The focus ofOntosaurus is to provide similar support to knowledge-based system engineering.

Summary

Much work remains to be done before the use of ontologiesis commonplace. Nevertheless, we can already begin tosee a number of benefits that may come from the use ofontologies to support system construction. First, itrepresents a new paradigm for model construction, wherethe focus is on linking domain specific terms to an existingontology and extending it, rather than on building a modelfrom scratch. We argue that this is much easier to do.Second, we think this approach can provide a kind ofguidance for representation. The organization of the termsin a large-scale ontology like SENSUS can help organizethe domain specific terms that a system builder may attach.Further, some of the distinctions SENSUS draws betweenword senses may force a system builder to think morecarefully about what he is representing, and whether or nothe is drawing all the appropriate distinctions. Third, thefew "seed" terms that the domain expert provides canidentify entire subtrees of the model that are relevant toinclude. Thus, our approach acts as a kind of concept

multiplier, which can greatly speed up model construction.Forth, our approach promotes sharability of models. Thiscould occur within some domain, or by using the ontologybase as common underpinning, even models developed indifferent domains will be easier to share. Fifth, our use ofa natural language based ontology means that much of theinformation that is needed to generate paraphrases andexplanations automatically is already represented in theontology base. This information would have to berepresented explicitly otherwise. By easing the productionof paraphrases and explanations understandability can beenhanced.

ACKNOWLEDGMENTS

The authors would like to thank Richard Whitney for hisinsights and help with programming and Eduard Hovy andLou Hoebel for comments, suggestions and valuablediscussions. All of them contributed greatly to thisresearch.

The work described here has been supported by theDefense Advanced Research Projects Agency undercontracts DABT63-91-C-0025, DABT63-95-C-0059 andNAG2-581.

REFERENCES[Abbrett and Burstein, 1987] G. Abbrett and MarkBurstein. The KREME knowledge editing environment. InInternational Journal of Man-Machine Studies (1987) 27,pp. 103-126.[Bateman et. al. 1989] J. A. Bateman, R.T. Kasper, J.D.Moore, and R.A. Whitney. A General Organization ofKnowledge for Natural Language Processing: The PenmanUpper Model. Unpublished research report,USC/Information Sciences Institute, Marina del Rey.1989.[Farquhar et al. 1995] A. Farquhar, R. Fikes, W. Pratt, andJ. Rice. "Collaborative Ontology Construction forInformation Integration" Knowledge Systems Laboratory,Department of Computer Science, Stanford University,KSL-95-63, August 1995.[Farquhar et al. 1996] Farquhar, A., R. Fikes, J. Rice. TheOntolingua Server: a Tool for Collaborative OntologyConstruction. In KAW96. November 1996. Also availableas KSL-TR-96-26.[Fowler, Cross and Owens 1995] N. Fowler III, S. E. Crossand C. Owens. The ARPA-Rome Knowledge BasedPlanning and Scheduling Initiative, IEEE Expert, 10(1) 9. February 1995.[Gaines 1994] B.R. Gaines. Class library implementationof an open architecture knowledge support system.International Journal of Human-Computer Studies 41 (1/2)59-107, 1994.[Gaines and Shaw 1995] B. R. Gaines and M. L. G. Shaw.WebMap Concept Mapping on the Web. In theProceedings of the Fourth International World Wide WebConference, Boston, Massachusetts. 1995.

147

[Genesereth 1991] M. R. Genesereth. KnowledgeInterchange Format. Principles of KnowledgeRepresentation and Reasoning: Proceedings of the SecondInternational Conference, Cambridge, MA, pages 599-600.Morgan Kaufmann, 1991.

[Genesereth and Fikes 1992] M. R. Genesereth, R. E.Fikes (Editors). Knowledge Interchange Format, Version3.0 Reference Manual. Computer Science Department,Stanford University, Technical Report Logic-92-1, June1992.[Gruber 1993] T. R. Gruber. Toward principles for the

design of ontoiogies used for knowledge sharing. InFormal Ontology in Conceptual Analysis and KnowledgeRepresentation, N. Guarino and R. Poli, editors, KluwerAcademic, in preparation. Original paper presented at theInternational Workshop on Formal Ontology, March 1993.Available as Stanford Knowledge Systems LaboratoryReport KSL-93-04.

[Gruber and Tenenbaum] T. R. Gruber, J. M. Tenenbaum,and J. C. Weber. Toward a knowledge medium forcollaborative product development. Proceedings of theSecond International Conference on Artificial Intelligencein Design, Pittsburgh, pages 413-432. Kluwer Academic,1992.[Gruber 1992] T. R. Gruber. Ontolingua: A mechanism tosupport portable ontologies. Stanford University,Knowledge Systems Laboratory, Technical Report KSL-91-66, March 1992.[Hatzivassiloglou and Knight 1995] V. Hatzivassiloglouand K. Knight. Unification-Based Glossing. Proceedings ofthe 14th IJCAI Conference. Montreal, Quebec. 1995.[Knight and Luk] K. Knight. and S. Luk. Building a Large

Knowledge Base for Machine Translation. Proceedings ofthe American Association of Artificial IntelligenceConference (AAAI-94). Seattle, WA. 1994.[Knight et. ah 1995] K. Knight, I. Chander, M. Haines, V.Hatzivassiloglou, E. H. Hovy, M. Iida, S.K. Luk, R.A.Whitney, and K. Yamada. 1995. Filling Knowledge Gapsin a Broad-Coverage MT System. Proceedings of the 14thIJCAI Conference. Montreal, Quebec.[Lenat and Guha 1990] D. B. Lenat and R. V. Guha.Building Large Knowledge-Based Systems: Representationand Inference in the CYC Project. Addison-WesleyPublishing Company, Inc., Reading, Massachusetts. 1990.[MacGregor 94] R. M. MacGregor. A DescriptionClassifier for the Predicate Calculus. in Proceedings of theTwelfth National Conference on Artificial Intelligence,(AAAI-94), 1994.[MacGregor 1991a] R. M. MacGregor. Using a DescriptionClassifier to Enhance Deductive Inference in Proceedingsof the Seventh IEEE conference on AI Applications, 1991.[MacGregor 1991b] R. MacGregor. The EvolvingTechnology of Classification-Based RepresentationSystems. In J. Sowa (ed.), Principles of SemanticNetworks: Explorations in the Representation ofKnowledge. Morgan Kaufmann, 1990.

[Mallery 1994] John C. Mallery. A Common LISPHypermedia Server, in Proceedings of the FirstInternational Conference on The World-Wide Web, GenevaCERN, May 25, 1994.

[McGuire et. al. 1993] J. G. McGuire, D. R. Kuokka, J. C.Weber, J. M. Tenenbaum, T. R. Gruber, G. R. Olsen.SHADE: Technology for Knowledge-Based CollaborativeEngineering. Journal of Concurrent Engineering:Applications and Research (CERA), 1 (2), September 1993.[Michalski 1980] R. S. Michalski. Knowledge AcquisitionThrough Conceptual Clustering: A Theoretical Frameworkand an Algorithm for Partitioning Data into ConjunctiveConcepts. Policy Analysis and Information Systems, 4(3)219-244, 1980.[Miller 1990] G. Miller. WordNet: An on-line lexicaldatabase. International Journal of Lexicography , 3(4).(special Issue). 1990.

[Neches et. al. 1991] R. Neches, R. Fikes, T. Finin, T.Gruber, R. Patil, T. Senator, & W. R. Swartout. Enablingtechnology for knowledge sharing. Enabling technologyfor knowledge sharing. AI Magazine, 12(3): 16-36, 1991.[PateI-Schnider et. al. 1993] DRAFT of the specificationfor Description Logics, produced by the KRSS workinggroup of the DARPA Knowledge Sharing Effort. updatedJuly 1993.[Rice et al 1996] J. Rice, A. Farquhar, P. Piernot, & T.Gruber. Lessons Learned Using the Web as an ApplicationInterface. Knowledge Systems Laboratory, KSL-95-69,September 1995. In CHI96, April 1996.[Swartout et. al. 1993] W. R. Swartout, R. Neches and R.

Patih Knowledge Sharing: Prospects and Challenges. InProceedings of the International Conference on Buildingand Sharing of Very Large-Scale Knowledge Bases ’93,Tokyo, Japan 1993.[Tate 1996] A. Tate. Towards a Plan Ontology. Journal ofthe Italian AI Association (AIIA) January 1996.[Wielinga and Breuker, 1986] B.J. Wielinga and J.A.

Breuker, Models of Expertise, ECAI 1986, 497-509.

148