Articles

36 AI MAGAZINE

Rule-based

Logic-based

Frame-based

Hybrid

Analogic-based

Metalogic-based

Manufacturing

Electromechanical

Financial

Fluidics

Construction

Scheduler

Classifier

Planner

Diagnoser

Evaluator

2 Mbytes

3 Mbytes

6 Mbytes

2 Mbytes

10 Mbytes

17 Mbytes

10 Mbytes

8 Mbytes

5 Mbytes

4 Mbytes

6 Mbytes

5Mbytes

4 Mbytes

7 Mbytes

5 Mbytes

4 Mbytes

À LA CARTE SYSTEMS MENU

KNOWLEDGE REPS (select one or more)

ONTOLOGIES (select one or more)

REASONERS

Enabling Technology for Knowledge Sharing

Robert Neches, Richard Fikes, Tim Finin, Thomas Gruber, Ramesh Patil, Ted Senator, and William R. Swartout

Ever since the mid-seventies, researchershave recognized thatcapturing knowledgeis the key to buildinglarge and powerful AI

systems. In the yearssince, we have alsofound that represent-ing knowledge is difficult and timeconsuming. Althoughwe have developedtools to help withknowledge acquisi-tion, knowledge baseconstruction remainsone of the majorcosts in building anAI system: For almostevery system we build,a new knowledge basemust be constructedfrom scratch. As aresult, most systemsremain small to medium in size. Even if webuild several systems within a general area,such as medicine or electronics diagnosis, sig-nificant portions of the domain must bererepresented for every system we create.

The cost of this duplication of effort hasbeen high and will become prohibitive as weattempt to build larger and larger systems. Toovercome this barrier and advance the stateof the art, we must find ways of preservingexisting knowledge bases and of sharing,reusing, and building on them.

This article describes both near- and long-term issues underlying an initiative to addressthese concerns. First, we discuss four bottle-necks to sharing and reuse, present a visionof a future in which these bottlenecks havebeen ameliorated, and touch on the efforts ofthe initiative’s four working groups to addressthese bottlenecks. We then elaborate on thevision by describing the model it implies forhow knowledge bases and knowledge-basedsystems could be structured and developed.This model involves both infrastructure andsupporting technology. The supporting tech-nology is the topic of our near-term interestbecause it is critical to enabling the infras-tructure. Therefore, we return to discussingthe efforts of the four working groups of ourinitiative, focusing on the enabling technologythat they are working to define. Finally, weconsider topics of longer-range interest byreviewing some of the research issues raisedby our vision.

Sharing andReuse

There are manysenses in which thework that went intocreating a knowl-edge-based systemcan be shared andreused. Rather thanmandating one par-ticular sense, themodel described inthis article seeks tosupport several ofthem. One mode ofreuse is through theexchange of tech-niques. That is, thecontent of somemodule from thelibrary is not direct-ly used, but theapproach behind itis communicated in

a manner that facilitates its reimplementa-tion. Another mode of reuse is through theinclusion of source specifications. That is, thecontent of some module is copied into anoth-er at design time and compiled (possibly afterextension or revision) into the new compo-nent. A third mode is through the run-timeinvocation of external modules or services.That is, one module invokes another either as a procedure from a function library orthrough the maintenance of some kind ofclient-server relationship between the two(Finin and Fritzson 1989).

These modes of reuse do not work particu-larly smoothly today. Explaining how toreproduce a technique often requires commu-nicating subtle issues that are more easilyexpressed formally; whether stated formallyor in natural language, the explanationsrequire shared understanding of the intendedinterpretations of terms. The reuse of sourcespecifications is only feasible to the extentthat their model of the world is compatiblewith the intended new use. The reuse ofexternal modules is feasible only to theextent that we understand what requests themodules are prepared to accept. Let us con-sider these complexities in more detail byreviewing four critical impediments to shar-ing and reuse.

Impediment 1. Heterogeneous Represen-tations: There are a wide variety of approachesto knowledge representation, and knowledgethat is expressed in one formalism cannot

Attempting tomove beyondthe capabilitiesof currentknowledge-based systemsmandatesknowledgebases that aresubstantiallylarger thanthose we havetoday.

Articles

FALL 1991 37

Building new knowledge-based systems todayusually entails constructing new knowledgebases from scratch. It could instead be done byassembling reusable components. System devel-opers would then only need to worry about cre-ating the specialized knowledge and reasonersnew to the specific task of their system. Thisnew system would interoperate with existing systems, using them to perform some of its rea-soning. In this way, declarative knowledge, prob-lem-solving techniques, and reasoning servicescould all be shared among systems. Thisapproach would facilitate building bigger andbetter systems cheaply. The infrastructure tosupport such sharing and reuse would lead togreater ubiquity of these systems, potentiallytransforming the knowledge industry. This articlepresents a vision of the future in which knowl-edge-based system development and operation isfacilitated by infrastructure and technology forknowledge sharing. It describes an initiative currently under way to develop these ideas andsuggests steps that must be taken in the futureto try to realize this vision.

0738-4602/91/$4.00 ©1991 AAAI

if they lack shared vocabulary and domainterminology. For example, the type hierarchyof one knowledge base might split the conceptObject into Physical-Object and Abstract-Object, but another might decompose Objectinto Decomposable-Object, Nondecompos-able-Object, Conscious-Being, and Non-Con-scious-Thing. The absence of knowledgeabout the relationship between the two setsof terms makes it difficult to reconcile them.Sometimes these differences reflect differ-ences in the intended purposes of the knowl-edge bases. At other times, these differencesare just arbitrary (for example, differentknowledge bases use Isa, Isa-kind-of, Sub-sumes, AKO, or Parent relations, althoughtheir real intent is the same). If we coulddevelop shared sets of explicitly defined ter-minology, sometimes called ontologies, wecould begin to remove some of the arbitrarydifferences at the knowledge level. Further-more, shared ontologies could provide a basisfor packaging knowledge modules—describ-ing the contents or services that are offeredand their ontological commitments in a com-posable, reusable form.

A Vision: Knowledge Sharing

In this article, we present a vision of thefuture in which the idea of knowledge shar-ing is commonplace. If this vision is realized,building a new system will rarely involveconstructing a new knowledge base fromscratch. Instead, the process of building aknowledge-based system will start by assem-bling reusable components. Portions of exist-ing knowledge bases would be reused inconstructing the new system, and special-pur-pose reasoners embodying problem-solvingmethods would similarly be brought in. Someeffort would go into connecting these pieces,creating a “custom shell” with preloadedknowledge. However, the majority of thesystem development effort could becomefocused on creating only the specializedknowledge and reasoners that are new to thespecific task of the system under construction.In our vision, the new system could interop-erate with existing systems and pose queriesto them to perform some of its reasoning.

directly be incorporated into another formal-ism. However, this diversity is inevitable—thechoice of one form of knowledge representa-tion over another can have a big impact on asystem’s performance. There is no singleknowledge representation that is best for allproblems, nor is there likely to be one. Thus,in many cases, sharing and reusing knowl-edge will involve translating from one repre-sentation to another. Currently, the only wayto do this translating is by manually recodingknowledge from one representation to anoth-er. We need tools that can help automate thetranslation process.

Impediment 2. Dialects within LanguageFamilies: Even within a single family ofknowledge representation formalisms (forexample, the KL-One family), it can be diffi-cult to share knowledge across systems if theknowledge has been encoded in differentdialects. Some of the differences betweendialects are substantive, but many involvearbitrary and inconsequential differences insyntax and semantics. All such differences,substantive or trivial, impede sharing. It isimportant to eliminate unnecessary differ-ences at this level.

Impediment 3. Lack of CommunicationConventions: Knowledge sharing does notnecessarily require a merger of knowledgebases. If separate systems can communicatewith one another, they can benefit from eachother’s knowledge without sharing a commonknowledge base. Unfortunately, this approachis not generally feasible for today’s systemsbecause we lack an agreed-on protocol speci-fying how systems are to query each otherand in what form answers are to be delivered.Similarly, we lack standard protocols thatwould provide interoperability betweenknowledge representation systems and other,conventional software, such as database man-agement systems.

Impediment 4. Model Mismatches at theKnowledge Level: Finally, even if the language-level problems previously described areresolved, it can still be difficult to combinetwo knowledge bases or establish effectivecommunications between them. Theseremaining barriers arise when different primi-tive terms are used to organize them; that is,

Articles

38 AI MAGAZINE

Instead, the process of building a knowledge-based system willstart by assembling reusable components.

Furthermore, extensions to existing knowl-edge bases could be added to shared reposito-ries, thereby expanding and enriching them.

Over time, large rich knowledge bases, anal-ogous to today’s databases, will evolve. In thisway, declarative knowledge, problem-solvingtechniques and reasoning services could all beshared among systems. The cost to produce asystem would decrease. To the extent thatwell-tested parts were reused, a system’srobustness would increase.

For end users, this vision will change theface of information systems in three ways.First, it will provide sources of informationthat serve the same functions as books andlibraries but are more flexible, easier to update,and easier to query. Second, it will enable theconstruction and marketing of prepackagedknowledge services, allowing users to invoke(rent or buy) services. Third, it will make itpossible for end users to tailor large systemsto their needs by assembling knowledge basesand services rather than programming themfrom scratch.

We also expect changes and enhancementsin the ways that developers view and manipu-late knowledge-based systems. In particular,we envision three mechanisms that wouldincrease their productivity by promoting thesharing and reuse of accumulated knowledge.First among these are libraries of multiplelayers of reusable knowledge bases that couldeither be incorporated into software or remote-ly consulted at execution time. At a levelgeneric to a class of applications, layers insuch knowledge bases capture conceptualiza-tions, tasks, and problem- solving methods.Second, system construction will be facilitat-ed by the availability of common knowledgerepresentation systems and a means for translation between them. Finally, this newreuse-oriented approach will offer tools andmethodologies that allow developers to findand use library entries useful to their needs aswell as preexisting services built on theselibraries. These tools will be complementedby tools that allow developers to offer theirwork for inclusion in the libraries.

The Knowledge-Sharing Effort

We are not yet technically ready to realizethis vision. Instead, we must work toward itincrementally. For example, there is no con-sensus today on the appropriate form or con-tent of the shared ontologies that weenvision. For this consensus to emerge, weneed to engage in exercises in building sharedknowledge bases, extract generalizations fromthe set of systems that emerge, and capture

these generalizations in a standard formatthat can be interpreted by all involved. Thisprocess requires the development of someagreed-on formalisms and conventions at thelevel of an interchange format between lan-guages or a common knowledge representa-tion language.

Simply enabling the ability to share knowl-edge is not enough for the technology tohave full impact, however. The developmentand use of shared ontologies cannot becomecost effective unless the systems using themare highly interoperable with both AI andconventional software, so that large numbersof systems can be built. Thus, software inter-faces to knowledge representation systemsare a crucial issue.

The Knowledge-Sharing Effort, sponsoredby the Air Force Office of Scientific Research,the Defense Advanced Research ProjectsAgency, the Corporation for National ResearchInitiatives, and the National Science Founda-tion (NSF), is an initiative to develop thetechnical infrastructure to support the shar-ing of knowledge among systems. The effortis organized into four working groups, eachof which is addressing one of the four imped-iments to sharing that we outlined earlier.The working groups are briefly described hereand in greater detail later in the article.

The Interlingua Working Group is develop-ing an approach to translating betweenknowledge representation languages. Itsapproach involves developing an intermedi-ary language, a knowledge interchange formator interlingua, along with a set of translatorsto map into and out of it from existingknowledge representation languages. To mapa knowledge base from one representationlanguage into another, a system builderwould use one translator to map the knowl-edge base into the interchange format andanother to map from the interchange formatback out to the second language.

The Knowledge Representation SystemSpecification (KRSS) Working Group is takinganother, complementary tack toward pro-moting knowledge sharing. Rather thantranslating between knowledge representa-tion languages, the KRSS group is seeking topromote sharing by removing arbitrary dif-ferences among knowledge representationlanguages within the same paradigm. Thisgroup is currently working on a specificationfor a knowledge representation system thatbrings together the best features of languagesdeveloped within the KL-One paradigm. Sim-ilar efforts for other families of languages areexpected to follow.

The External Interfaces Working Group is

Articles

FALL 1991 39

er, the ultimate contribution of the group liesin developing an understanding of the groupprocesses that evolve such products and thetools and infrastructure needed to facilitatethe creation, dissemination, and reuse ofdomain-oriented ontologies.

Architectures of the FutureIn this section, we elaborate on our vision bydescribing what we hope to enable concern-ing both knowledge bases and the systemsthat use them. In doing so, we look at howthey are structured and the process by whichthey will be built. We also consider the rela-tionship of this vision to other views thathave been offered, such as Guha and Lenat’s(1990) Cyc effort, Stefik’s (1986) notion ofKnowledge Media, and Kahn’s notion ofKnowbots (Kahn and Cerf 1988). Finally, weoffer a view of the range of system modelsthat this approach supports.

Structural and Development Modelsfor Knowledge Bases

In a AAAI-90 panel on software engineering,John McDermott (1990) described how AI

could make software development easier:Write programs to act as frameworks for han-dling instances of problem classes.

Knowledge-based systems can provide suchframeworks in the form of top-level declara-tive abstraction hierarchies, which an applica-tion builder elaborates to create a specificsystem. Essentially, hierarchies built for thispurpose represent a commitment to providespecific services to applications that are will-ing to adopt their model of the world.

When these top-level abstraction hierar-chies are represented with enough informa-tion to lay down the ground rules formodeling a domain, we call them ontologies.An ontology defines the basic terms and rela-tions comprising the vocabulary of a topicarea as well as the rules for combining termsand relations to define extensions to thevocabulary. An example is the MKS genericmodel of manufacturing steps (Pan, Tenen-baum, and Glicksman 1989), illustrated infigure 1 along with a set of application-specif-ic extensions for semiconductor manufactur-ing. The frame hierarchy in MKs definesclasses of concepts that the system’s reason-ing modules (for example, schedulers anddiagnosers) are prepared to operate on. Theslots and slot restrictions on these framesdefine how one must model a particular man-ufacturing domain to enable the use of thesemodules.

investigating yet another facet of knowledgesharing. It is developing a set of protocols forinteraction that would allow a knowledge-based system to obtain knowledge fromanother knowledge-based system (or, possibly,a conventional database) by posting a queryto this system and receiving a response. Theconcerns of this group are to develop the pro-tocols and conventions through which suchan interaction could take place.

Finally, the Shared, Reusable KnowledgeBases Working Group is working on overcom-ing the barriers to sharing that arise from lackof consensus across knowledge bases onvocabulary and semantic interpretations indomain models. As mentioned earlier, theontology of a system consists of its vocabu-lary and a set of constraints on the way termscan be combined to model a domain. Allknowledge systems are based on an ontology,whether implicit or explicit. A larger knowl-edge system can be composed from twosmaller ones only if their ontologies are con-sistent. This group is trying to ameliorateproblems of inconsistency by fostering theevolution of common, shareable ontologies.A number of candidate reusable ontologiesare expected to come from this work. Howev-

Articles

40 AI MAGAZINE

Figure 1. The MKS Ontology of Manufacturing Operations, Elaborated withKnowledge Specific to Semiconductor Manufacturing.

Ontologies such as this one, in effect, lay the ground rules for modeling a domain bydefining the basic terms and relations that make up the vocabulary of this topic area.These ground rules serve to guide system builders in fleshing out knowledge bases,building services that operate on knowledge bases, and combining knowledge basesand services to create larger systems. For one system to make use of either the knowl-edge or reasoners of another system, the two must have consistent ontologies.

The MKS example is hardly unique. A numberof systems have been built in a manner con-sistent with this philosophy, for example,FIRST-CUT and NEXT-CUT (Cutkosky and Tenen-baum 1990), QPE (Forbus 1990), Cyc (Guhaand Lenat 1990), ARIES (Johnson and Harris1990), SAGE (Roth and Mattis 1990), CarnegieMellon University’s factory scheduling and

Articles

FALL 1991 41

project management system (Sathi, Fox, andGreenberg 1990), KIDS (Smith 1990), and EES

(Swartout and Smoliar 1989). The notion thatgeneric structure can be exploited in buildingspecialized systems has been argued for a longtime by Chandrasekaran (1983, 1986) andmore recently by Steels (1990). The notionhas also long been exploited in knowledge-

Figure 2. The Anatomy of a Knowledge Base.Application systems contain many different kinds and levels of knowledge. At the top level are ontologies, althoughoften represented only implicitly in many of today’s systems. The top-level ontologies embody representational choicesranging from topic independent (for example, models of time or causality) to topic specific but still application-inde-pendent knowledge (for example, domain knowledge about different kinds of testing operations represented in a man-ufacturing system or problem-solving knowledge about hypothesis classes in a diagnostic system). This top level ofknowledge is elaborated by more application-specific models (for example, knowledge about chip-testing operationsin a specific manufacturing application or failure modes in a circuit diagnosis system). Together, they define how aparticular application describes the world. At the bottom level, assertions using the vocabulary of these models capturethe current state of the system’s knowledge. Knowledge at the higher levels, being less specialized, is easier to shareand reuse. Knowledge at the lower levels can only be shared if the other system accepts the models in the levels above.

Structural and Development Modelsfor Knowledge-Based Systems

Figure 3 illustrates the envisioned organiza-tion of an individual knowledge-based appli-cation system. The local system consists of aset of services that operate on combined (orindistinguishable) knowledge bases anddatabases. One uniform user interface man-agement system mediates interactions withhumans, and a set of agents mediates interac-tion with other systems.

The services that make up the applicationconsist of various reasoning modules, whichcan be defined at either the level of genericreasoning and inference mechanism (forexample, forward chaining, backward chaining,unification) or the task level (for example,planners, diagnosers). These modules wouldtypically be acquired off the shelf. At eitherlevel, however, they can be augmented byspecial-purpose reasoning modules that pro-vide custom capabilities for exploiting partic-ular characteristics of the application domain.In addition to these reasoning modules, theapplication’s services are also likely to includea number of modules providing conventionalcapabilities, such as spreadsheets, electronicmail, hypermedia, calendar systems, statisti-cal packages, and accounting systems.

To perform the tasks of the overall system,modules will need to interact internally (thatis, knowledge base to knowledge base) andexternally (that is, knowledge base–databaseto other knowledge-based systems or arbitraryoutside software applications). For externalinteraction, the modules will need a languagefor encoding their communications. SQL

serves this function for conventional databaseinteractions, and it appears likely that it willcontinue to be used in the future. We call theanalogous programmatic interface for knowl-edge-based applications KQML (knowledgequery and manipulation language). KQML willconsist of a language for specifying wrappersthat define messages communicated betweenmodules. These wrappers will surround decla-rations that will express whatever knowledge

acquisition work, for example, in systemssuch as MORE (Kahn, Nowlan, and McDermott1984) and ROGET (Bennett 1984).

The range of knowledge captured withontologies is described in figure 2. There issome fuzziness in the figure’s distinctionbetween shared and custom ontologiesbecause they are relative terms—any givenknowledge base is custom with respect to theknowledge it extends and is shared with respectto the knowledge that extends it. Nevertheless,the essential idea is that application knowl-edge bases should consist of layers of increas-ingly specialized, less reusable knowledge. Asis argued later, explicitly organizing knowl-edge bases in this fashion is a step on the crit-ical path to enabling sharing and reuse.

There are a number of uses for ontologies.The primary uses today are in definingknowledge-based system frameworks in thespirit advocated by John McDermott (1990).However, a number of additional possibilitiesopen if libraries of these ontologies can bedeveloped because these libraries define thecommon models needed for combiningknowledge bases or successfully communicat-ing between independent modules. Ontolo-gies and knowledge bases can also be viewedas ends in themselves, that is, as repositoriesof information in the spirit suggested by Stefik’s(1986) discussion of knowledge media.

Although every knowledge-based systemimplicitly or explicitly embodies an ontology,ontologies are rarely shared across systems.Commonalities among existing systems can beidentified and made shareable. For example,Stanford’s Summer Ontology Project foundthat several of the collaborators had built sys-tems that used models of mechanical devicesbased on concepts such as module, port, andconnection (Gruber 1991). However, eachsystem used slightly different names and for-malisms. An ontology for lumped elementmodels that defines these concepts with con-sistent, shareable terminology is under con-struction. A library of such shared ontologieswould facilitate building systems by reducingthe effort invested in reconciliation and rein-vention.

Articles

42 AI MAGAZINE

An ontology defines the basic terms and relations comprising thevocabulary of a topic area…

Articles

FALL 1991 43

Figure 3. Architecture of a Knowledge-Based System.We envision that knowledge-based systems will be assembled from components rather than built from scratch. Thecomponents include a framework for local system software in which one or more local knowledge bases are tied to ashared ontology. Remote knowledge bases can be accessed and are understood by the local system by virtue of beingtied in to the ontology. Specialized reasoning modules (for example, a diagnostic system) and generic reasoning systems(that is, a representation system) are also tied to the knowledge base(s) through the ontology. In turn, these systemsare glued together with conventional services through specialized, custom application code. Larger systems can beobtained from smaller ones in this architecture by either expanding the contents of a local system or interlinking mul-tiple systems built in this fashion.

Articles

44 AI MAGAZINE

Figure 4. Envisioned Phases in Defining a Knowledge-Based System.With libraries of reusable knowledge-based software components, building an application could become much more ofa configuration task and, correspondingly, less of a programming activity. System builders could select specialized rea-soning modules and ontologies, converting them to the format required by the selected knowledge representation ifthey were not already in this format. This approach gives them a specialized shell with some knowledge built in. Thiscustom shell can then be utilized to build the application from a higher-level starting point.

the sending module must pass to the receiv-ing module.

The uniform KQML communication protocolwill facilitate modular construction of systemcomponents and, thus, facilitate the develop-ment of libraries of reusable components.Such libraries will contain generic reasonerssuch as truth maintenance systems, task-spe-cific reasoners (planners, diagnosers, and soon), and domain-specific reasoners (for exam-ple, electric circuit simulators). The librarieswill also contain a number of ontologies cov-ering both structural knowledge and problem-solving knowledge. Some will be domainoriented, and some will correspond to particu-lar reasoners. Also residing in these librarieswill be a collection of knowledge representa-tion system implementations to choose from.We expect that several different representation-al paradigms, or families, might be availablein the library. For each family, we expect mul-tiple implementations of a common core lan-guage, similar to Common Lisp (Steele 1984),which has a core specification and severalcompeting implementations of this specifica-tion, each of which offers various performance,environment, and function enhancements.

As figure 4 illustrates, application-specificsystems will be developed by assembling com-ponents from a library into a customizedshell, which is then used to develop the appli-cation. The first task of system developerswould be to configure this specialized shell.This process will involve selecting ontologies,specialized reasoning modules, and a knowl-edge representation system from the library.As in any configuration task, there are likelyto be constraints that must be respected. Forexample, a particular specialized schedulingmodule might assume that tasks to be sched-uled are modeled according to a particularontology. The entries in the library must pro-vide enough information about themselves toallow system developers to understand theseconstraints.

Once the ontologies, specialized reasoningmodules, and a knowledge representationsystem have been selected and assembled, thesystem developers have a specialized shell fortheir application. This shell differs from today’sshells in that it will come with built-in knowl-edge, not just specialized programming fea-tures. The system developers’ tasks are then toflesh out the knowledge base, add whatevercustom application code is necessary, andwrite software interfaces to any other systemsthe new application will work with.

In configuring this specialized shell, itwould be highly desirable if there were sup-port for translation between representations.

Articles

FALL 1991 45

Then, developers would not be obliged to usethe original implementation if their applica-tion had different performance or functionrequirements. For example, a common ontol-ogy of electromechanical devices could serveDRAMA (Harp et al. 1991), which analyzeslogistical implications of design changes, andCOMET (Feiner and McKeown 1990), whichgenerates multimedia how-to presentationsabout maintenance tasks. COMET needs devicemodels to access related device componentsand primarily requires efficient storage andretrieval from its representation language. Incontrast, DRAMA analyzes implications of largeamounts of changing knowledge and, there-fore, demands efficient inference mechanisms.

Note that the approach we have beendescribing scales with the evolution of infras-

Figure 5. Current versus Envisioned Models of the AI Software Life Cycle.Adding knowledge libraries represents a significant change in methodology for buildingknowledge-based systems. Knowledge librarians, a new category of participant in theprocess, would ensure that submitted ontologies and reasoners were ready for release.They would help system engineers browse the library and select modules. They wouldalso help tool builders create tools and development environments to assist in theseactivities.

will be difficult to achieve the level of relia-bility and stability needed for practical soft-ware development.

Adding a knowledge library represents asignificant change to knowledge base method-ology. It transforms the system-building process away from using power tools for con-structing essentially custom, one-of-a-kindsystems. Instead, system building becomes aprocess of selecting and combining a range ofcomponents. The system engineer becomesmuch more like a builder of homes and muchless like a sculptor. A home builder has a rangeof components and materials, from bricksand two-by-fours to prefabricated walls oreven rooms. A home builder has a choice ofbuilding each new home from small compo-nents that give a lot of design flexibility orfrom larger components that trade off reduceddesign options for reduced constructioneffort. Similarly, system engineers would finda range of grain sizes among objects in theknowledge library and would be empoweredto make analogous choices.

Comparison with Other Visions

The model of knowledge-based systems thatwe just described bears significant relation-ships to other notions that have been offered.

One recent example is MCC Corporation’sCyc Project (Guha and Lenat 1990), whichseeks to develop an extremely large knowl-edge base of commonsense knowledge underwhich all applications would be built. TheCyc Project provides a language, Cyc-L, forimplementing its ontology and developingan application-specific knowledge base.Because its scope is so broad, Cyc representsone extreme in the range of efforts compatiblewith the model we propose. In our scheme,Cyc’s knowledge base could be one largeentry in the library of components (or, per-haps, it might be broken into several smallermodules, or microtheories). Its implementationlanguage, Cyc-L, would be one of the entriesin the library of representation systems. Ifone chose to build a system entirely withinCyc, our model of the development processand that of the Cyc Project are largely consis-

tructure for knowledge sharing. It is feasiblewith existing technology. If and when commonknowledge representation systems becomeavailable, their use would broaden the porta-bility and reusability of a given library. Simi-larly, the development and dissemination oftechniques for translation between differentrepresentation languages would also broadenthe use of a library.

Figure 5 contrasts our model of the lifecycle for knowledge-based software with theapproach followed in expert system softwaretoday. The notion of libraries is a key differ-ence. In today’s models of expert systemsoftware development, exemplified by Water-man’s (1986) book on expert systems, thereare at least four classes of participants in thelife cycle. Tool builders create shells anddevelopment environments. System engi-neers take these tools and create an initialversion of a knowledge-based system by inter-viewing domain experts. Then, together withthe domain experts, the system engineerstest, extend, and refine the system. Finally,end users put the system to use. The visionwe propose changes the nature of the systemengineer’s work and has the potential tomerge roles by giving domain experts moreability to act as system engineers. It also addsa new participant to the infrastructure: aknowledge librarian, who serves as a keeperof reusable ontologies and implementationsof specialized reasoning methods.

The knowledge librarian works with toolbuilders on tools and development environ-ments to help system engineers browse andselect modules from the library. System engi-neers import, extend, and customize thesemodules. They can retain the customized elements in private libraries for sharing andreuse within a subcommunity. Alternatively,they can offer their developments to thelibrary for possible inclusion as extensions tothe existing set of knowledge.

One of the crucial functions that must beperformed in the management of a knowl-edge library is the determination of whensubmitted knowledge is ready for release. Ifknowledge is simply added and edited by allparticipants without some discipline, then it

Articles

46 AI MAGAZINE

Adding a knowledge library represents a significant change toknowledge base methodology.

tent. If one wishes to go outside Cyc, ourmodel is complementary. Potential usersmight use our knowledge-interchange formatto translate other knowledge bases into Cyc-Lor, conversely, to translate Cyc’s knowledgeinto some other representation system. Alter-natively, they might use external protocols toaccess a module built in Cyc and build othermodules through other means.

If successful, our approach would help makethe knowledge in Cyc accessible even to thosesystem developers who for one reason oranother do not choose to use the whole Cycknowledge base or represent their systems inCyc-L.

However, the model we propose also differssignificantly from the Cyc effort. Amongother things, it allows the development oflarge systems without having to first committo a particular knowledge representation for-malism; users do not even have to commit tohomogeneity. Furthermore, this approachallows for the development and use ofontologies and knowledge bases under a moreconservative, bottom-up development modelas an alternative to committing to a large,broad knowledge base. Thus, an alternativeuse of this model aims for the evolution ofsmaller, topic-specific ontologies intended forsharing by specialized communities. (Overtime, it is possible that these topic-specificontologies would grow and merge with others,so that an eventual end result might be abroadly encompassing ontology such as thatsought by the Cyc effort.)

Our vision owes a great deal to Mark Stefik’s(1986) view of knowledge bases as the nextmechanism of information exchange. Stefikwas interested, as are we, in both how sys-tems of the future will be built and what useswill be made of them. He suggested thatexpert systems were parts and precursors of anew knowledge medium, a set of interactivemultidisciplinary tools for informationmanipulation:

A knowledge medium based on AI

technology is part of a continuum. Booksand other passive media can simply storeknowledge. At the other end of the spec-trum are expert systems which can storeand also apply knowledge. In between area number of hybrid systems in which theknowledge processing is done mostly bypeople. There are many opportunities forestablishing human-machine partnershipsand for automating tasks incrementally.

In these interactive tools, the computer pro-vides storage, retrieval, and group communi-cations services as well as languages and toolsthat enable precision and explicitness in

manipulating knowledge about a topic.In producing the new knowledge medium,

Stefik argued that expert systems should beviewed as complex artifacts, such as automo-biles or airplanes, which are assembled fromhighly sophisticated materials and subassem-blies. A marketplace that supports the special-ized suppliers of component technologiesbenefits the manufacturer of the end product.The marketplace provides economies of scalethat make it possible to develop componenttechnologies of a quality and sophisticationthat would be unaffordable if the costs had tobe borne entirely within a single, built-from-scratch, one-of-a-kind product developmenteffort. Thus, by analogy, Stefik concluded that

…the “goods” of a knowledge market areelements of knowledge… To reduce thecost of building expert systems, we needto be able to build them using knowledgeacquired from a marketplace. Thisrequires setting some processes in placeand making some technical advances.In particular, Stefik urged combining work

on expert system shells with work on stan-dard vocabularies and ways of defining thingsin terms of primitives. This suggestion is simi-lar to the notion of ontologies proposed inthis article. However, Stefik questioned (as dowe) the feasibility of relying entirely on thedevelopment of standard vocabularies orontologies for domains. The key to theireffectiveness lies in how these ontologies areanalyzed, combined, and integrated to createlarge applications. Tools and methods areneeded to support this process. Our visionseeks to extend Stefik’s by trying to furtherdefine the process as well as the supportingtools and methods.

Our particular extensions also have somekinship to the architecture of the nationalinformation infrastructure envisioned byKahn and Cerf (1988) for the Digital LibrarySystem. Their vision of the library of thefuture consists of information collectionsbearing some analogies to Stefik’s knowledgemedia. The Digital Library System provides adistributed network architecture for accessinginformation. The architecture containsdatabase servers, various accounting andbilling servers, servers to support placingknowledge into the library and extractingknowledge from it, and servers for translatingknowledge flowing to and from the libraryinto different forms. The Digital LibrarySystem suggests a model for how our vision ofdevelopment, distribution, and disseminationof knowledge-based systems might be realizedin the future. At the same time, our visionproposes supporting technology—for example,

Articles

FALL 1991 47

engineering reasons can be handled by theseparation of modules as well as by the sameinternal structuring, as in the first case. Somecontrol regimes seemingly require that eachmodule know a great deal about the others;the duplication of information in eachmodule that is entailed is usually regarded asa potential maintenance bottleneck. However,the architecture provides natural mechanisms(ontologies and standard communicationscomponents) for encapsulating the knowledgeneeded for intermodule communication.

Over and above module structuring, systemmodels can vary along a number of otherdimensions in this scheme. These dimensionsinclude the choice of representation languagesused within modules, the homogeneity orheterogeneity of representation systems acrossmodules, the use of specialized reasoningmodules, the nature of ontologies, the con-tent of the knowledge bases, the partitioningof the knowledge bases, the tightness of cou-pling with databases, the degree of trans-parency of modules (black boxes versus glass

representation systems and translators— thatcould help realize the Digital Library System.

Supporting a Range of System Architectures

The technology described in this article isintended to provide enabling tools for build-ing a range of architectures for large, knowl-edge-based systems. Figure 6 illustrates onedimension of this range. Within the scope ofour vision, a system might be built as asingle, large, integrated, centralized package(as depicted in figure 4). In this model, shar-ing and reuse occur at design time. Software-engineering concerns such as modularity canbe achieved by partitioning the knowledge inthis system into multiple bases linked byshared ontologies. Alternatively, however, thelarge system could be factored into multipleseparate modules, communicating accordingto any of a number of alternative controlregimes. Sharing and reuse in this fashionoccur at run time. Modularity for software-

There are many

unansweredquestions

about howlarge-scale

systems canbest be built.

Articles

48 AI MAGAZINE

Figure 6. A Range of (potentially heterogeneous) System Models.The technology described in this article enables experimentation with alternative models for architectures of knowl-edge-based systems. Shared ontologies provide the basis for protocols that link separate modules.

boxes), and the locus of control.There are many unanswered questions

about how large-scale systems can best bebuilt. Although sharing and reuse are clearlyessential principles, the best way to makethem operational remains to be understood.What are the trade-offs between sharing ser-vices at run time versus sharing knowledgebases at design time? On what scale and underwhat circumstances is translation viable?When are shared formalisms, rather thantranslation, required? How do domain-specif-ic considerations drive choices of systemmodels? What are the constraints on theusability of knowledge originally recorded fordifferent purposes? What mechanisms bestfacilitate convergence between multiple userson a mutually satisfactory representation?

The intent behind the framework we out-lined is not to enshrine a particular set ofanswers to such questions. Rather, our goal isto identify enabling technologies that make iteasier to search the space of possible answers.The right answers will emerge only if we firstmake it easier for the AI community to explorethe alternatives empirically—by building anumber of large systems.

Working Groups in the Knowledge-Sharing Initiative

The desire to collaborate through knowledgesharing and reuse has arisen within a segmentof the broad knowledge representation com-munity that is interested in scaling up tolarger systems and that views the sharing andreuse of knowledge bases as a means to thisend. Closely related to this effort is a concernfor building embedded systems in whichknowledge representation systems supportcertain functions rather than act as ends inthemselves.

In particular, our goal is to support researchersin areas requiring systems bigger than a singleperson can build. These areas include engi-neering and design domains, logistics andplanning domains, and various integratedmodality areas (for example, multimediainterfaces). Researchers working on such topicsneed large knowledge bases that model com-plex objects; because these models drive com-plex systems, they cannot be skeletons. Puttingtogether much larger systems, of which vari-ous stand-alone systems being built today arejust components, is an interesting challenge.

The creation of such knowledge resourcesrequires communitywide effort. This effortengenders a need for agreed-on conventionsto enable us to build pieces that fit together.Eventually, in pursuing the goal of large,

shared knowledge bases as part of a nation-wide information infrastructure, these con-ventions might become objects of study forthe definition of more formal standards. (Forthose interested in the role of standards incomputing infrastructure, Cargill [1989] is auseful entry point into the topic.) Currently,however, the conventions are intended tosupport experiments in knowledge sharingamong interested parties.

The next part of this article focuses onmaking our vision operational by developingthese conventions. Doing so is an essentialprecursor to larger aspects of our vision, suchas libraries of ontologies, reasoning modules,and representation systems. This sectiondescribes the activities of our four workinggroups on these foundation-laying activities.For each group, we summarize the problembeing addressed, the approach being taken,and the outcomes sought.

Interlingua

The Interlingua Working Group is headed byRichard Fikes and Mike Genesereth, both ofStanford University.

Problem Formulation. The InterlinguaWorking Group focuses on the problemsposed by the heterogeneity of knowledge rep-resentation languages. Specifically, to inter-change knowledge among disparate programs(written by different programmers, at differ-ent times, in different languages), effectivemeans need to be developed for translatingknowledge bases from one specialized repre-sentation language into another. The goal ofthis group is to specify a language for com-municating knowledge between computerprograms (as opposed to a language for theinternal representation of knowledge withincomputer programs). This language needs (1) an agreed-on declarative semantics that is independent of any given interpreter, (2)sufficient expressive power to represent thedeclarative knowledge contained in typicalapplication system knowledge bases, and (3)a structure that enables semiautomated trans-lation into and out of typical representationlanguages.

Approach. This group is specifying a lan-guage (KIF [knowledge interchange format])that is a form of predicate calculus extendedto include facilities for defining terms, repre-senting knowledge about knowledge, reifyingfunctions and relations, specifying sets, andencoding commonly used nonmonotonic rea-soning policies. The group is also conductingknowledge-interchange experiments to sub-stantially test the viability and adequacy of

The creationof… knowl-edge resourcesrequires community-wide effort.

Articles

FALL 1991 49

is not trying to develop one language thatencompasses all approaches to knowledgerepresentation; rather, it seeks to create speci-fications that incorporate the good featureswithin families and develop a common ver-sion that is reasonably comprehensive yetpragmatic for each individual family. Anexample of one such family is the set of KL-One descendents, that is, object-centered lan-guages with definitional constructs, such asCLASSIC, LOOM, BACK, SB-One, and OMEGA. Theeffort should be viewed more as an attemptto develop a Common Lisp rather than a PL-1or Ada. The analogy to Common Lisp isimperfect, however. Knowledge representationsystems perform inference on the informa-tion represented within them; programminglanguages do not. Thus, specifying whatinferences should be performed is an addi-tional issue in specifying a knowledge repre-sentation system.

Approach. The goal of this group is toallow system builders working within afamily to provide a common set of featuresthat have consensus within this paradigm inaddition to the augmentations that theyregard as their research contribution. Theresulting language will serve as a medium forsharing knowledge bases as well as a meansfor communicating ideas and issues amongresearchers. Potential benefits are the abilitiesof users to more readily convert between sys-tems and to borrow models originally built torun in other systems. The trade-offs assumedby this group are the mirror image of thosefaced by the Interlingua Working Group:They eliminate the problem of translatingknowledge bases between systems but requireone to work within a given formalism toobtain this benefit.

Specifying a knowledge representationsystem poses the interesting challenge ofspecifying just what kinds of inference thesystem should perform. From Brachman andLevesque (1984), we know that if the systemis expressive enough to be useful, the infer-ences that its reasoner draws will be incom-plete. How should this incomplete inferencebe specified? The group’s approach is to con-struct a layered specification. There will be aninner core of the language, which will consist

the language. The experiments focus ondeveloping and testing a methodology forsemiautomatic translation to and from typi-cal representation languages and the use ofthe interchange format as an intermodulecommunication language to facilitate inter-operability.

Outcomes. The specification for interlinguawill evolve in a set of layers. The innermostlayer will be a core, analogous to the primi-tives in Lisp, providing basic representationaland language extension functions. The nextlayer will provide idioms and extensions thatmake the language more usable, analogous tothe set of functions provided by CommonLisp. This working group will be responsiblefor developing these specifications. Its outputwill be (1) a living document containing thecurrent KIF specification, describing openissues, and presenting current proposals formodification and (2) a corpus of documentedmicroexamples, using fragments of knowledgebases to illustrate how they translate into KIF

and to point out open issues.By the time this group has completed its

work, we expect that the documented inter-lingua specification will define a language inwhich the sharing and reuse of the contentsof individual knowledge bases can be accom-plished by transmitting specifications usingKIF as the medium for expressing these lan-guages. The language will be oriented towardsupporting translation performed with ahuman in the loop, and we expect that sever-al prototype translation aids will be devel-oped during the course of this work.

Knowledge Representation SystemSpecifications

The KRSS working group is headed by BillSwartout of University of Southern Califor-nia/Information Sciences Institute (USC/ISI)and Peter Patel-Schneider of AT&T Bell Labs.

Problem Formulation. This group is con-cerned with specification on a separatefamily-by-family basis of the common ele-ments within individual families of knowl-edge representation system paradigms. Theintent is not to develop a “be-all, end-all”knowledge representation system. The group

Articles

50 AI MAGAZINE

The goal… is to specify a language for communicating knowledgebetween computer programs…

of a few constructs. Because this inner corewill have limited expressivity, it will be possi-ble to perform complete inference on it.Another layer, the outer core, will be built onthe inner core. This layer will significantlyextend the expressivity of the language, butinference on it will be incomplete. To specifythe inferences that should be performed, thegroup will provide an abstract algorithm for drawing just those inferences that arerequired by the specification. Implementersof the specification must provide a reasonerat least as powerful as the one specified bythis algorithm.

Outcomes. The group is seeking to developa published specification and at least one ini-tial implementation of a common language.

External Interfaces

The External Interfaces Working Group,cochaired by Tim Finin of the Unisys Centerfor Advanced Information Technology andGio Wiederhold of Stanford University, focus-es on interfaces that provide interoperabilitybetween a knowledge representation systemand other software systems.

Problem Formulation. The time is endingwhen an intelligent system can exist as asingle, monolithic program that provides allthe functions necessary to do a complex task.Intelligent systems will be used and deployedin environments that require them to interactwith a complex of other software compo-nents. These components will include con-ventional software modules, operating systemfunctions, and database servers as well asother intelligent agents. There is a strongneed to develop standard interface modulesand protocols to make it easier to achieve thisinteroperability. The working group is con-cerned with three aspects of this problem:providing interoperability with other intelli-gent agents, conventional (for example, rela-tional) database management systems, andobject-oriented database systems.

Approach. To provide run-time interoper-ability between knowledge representation sys-tems, we need a language or protocol thatallows one system to pose queries or providedata to another. The group has begun thespecification of such a language, KQML. Theintent is that KQML will be to knowledge repre-sentation systems what SQL has become todatabase management systems—a high-level,portable protocol for which all systems willprovide interfaces. The current specification isorganized as a protocol stack in which thelowest information-conveying layer is based

on the interlingua. Higher layers in this stackprovide for modality (for example, assert,retract, query), transmission (for example, thespecification of the recipient agent or agents),and complex transactions (for example, theefficient transmission of a block of data).

The integration of AI and database manage-ment system technologies promises to play asignificant role in shaping the future of com-puting. As noted by Brodie (1988), this inte-gration is crucial not only for next-generationcomputing but also for the continued devel-opment of database management systemtechnology and the effective application ofmuch of AI technology. The need exists for (1)access to large amounts of existing shareddata for knowledge processing, (2) the effi-cient management of data as well as knowl-edge, and (3) the intelligent processing ofdata. The working group is studying themany existing interfaces between knowledgerepresentation systems and relational databas-es (for example, Mckay, Finin, and O’Hare[1990]) and is attempting to develop specifi-cations for a common one. The primary issueshere are the various ways in which the data inthe databases can best be mapped into theknowledge representation objects.

The third task that the group is looking at is providing interfaces between knowledgerepresentation systems and object-orienteddatabases. The goal here is to be able to usean object-oriented database as a substrateunder the knowledge representation systemto provide a persistent object store for knowl-edge base objects. This work is exploratory,but the potential benefits in the long run aresignificant. They include (1) building andmanaging knowledge bases much larger thanthe current technology will support and (2) providing controls for transactions andconcurrent access to knowledge bases at anobject level.

Outcomes. The External Interfaces WorkingGroup is concentrating on the developmentof the KQML protocol as its first goal. It hopesthat an early implementation will be used tohelp build test beds for several distributed,cooperative demonstration systems. Withregard to database interfaces, several workinggroup members are attempting to integrateexisting models for interfaces between knowl-edge representation systems and relationaldatabases and to produce a specification of acommon one. The working group is also plan-ning an experiment in which a simple inter-face will be built to allow an existingobject-oriented database to be used as a sub-strate under one of the representation systemsbeing investigated by the KRSS working

Articles

FALL 1991 51

device models). Some experiments will evalu-ate the use of ontologies as a mechanism forsharing (that is, for modularity and compos-ability of knowledge modules and the specifi-cation of their contents).

Outcomes. To these ends, the workinggroup is concentrating on three objectives.The first is a survey of the state of the art inresearch on knowledge sharing and reuse,which identifies the techniques currentlybeing explored and recommends research onthe critical problems to be solved. A secondoutcome is a set of results from the collabora-tive experiments on knowledge sharing,including the ontologies used for each experi-ment and lessons learned about tools andmethodologies for developing them. Animmediate subgoal for this outcome is todevelop a mechanism for representing theseontologies in portable form, building on thework of the other three working groups. Thethird, more long-term objective is to developa suite of exemplary shared ontologies andthe knowledge bases using them. Theseontologies will serve as research test beds,playing a role analogous to the E. coli bacteri-um in biology: a well-understood, completeexample on which to perform a variety ofexperiments.

Long-Term Research IssuesThe preceding description of the workinggroups focused on near-term issues. However,the goals proposed in this article suggest anumber of high-payoff research questions forthe entire research community. In this sec-tion, we want to focus on longer-term con-cerns by reviewing some of these questions.

A number of issues raised by this visionwere also identified by Ron Brachman (1990)in his AAAI-90 address on the future ofknowledge representation. High on his list ofissues were knowledge representation ser-vices, knowledge base management, and theusability of knowledge representation sys-tems. Brachman pointed out that the idea ofa single, general-purpose knowledge represen-tation system with optimal expressive power

group. This approach will provide a feasibilitytest and generate data for further exploration.

Shared, Reusable Knowledge Bases

The Shared, Reusable Knowledge Bases Groupis headed by Tom Gruber of Stanford Univer-sity and Marty Tenenbaum of EITech, Inc.

Problem Formulation. This group is work-ing on mechanisms to enable the develop-ment of libraries of shareable knowledgemodules and the reuse of their knowledge-level contents. Today’s knowledge bases arestructured as monolithic networks of highlyinterconnected symbols, designed for specifictasks in narrow domains. As a result, it is dif-ficult to adapt existing knowledge bases tonew uses or even to identify the shareablecontents. To enable the accumulation ofshareable knowledge and the use of thisknowledge by multiple systems, we need ameans for designing composable modules ofknowledge. The working group is chartered toidentify the barriers to the building and useof shared knowledge modules, characterizepotential approaches to overcoming thesebarriers, and conduct experiments exploringmechanisms for knowledge sharing.

Approach. The working group supportsthree kinds of activity. One is the identificationof important research issues for knowledgesharing, including problems of methodology(for example, multidisciplinary, collaborativeknowledge base design) as well as engineering(for example, scalability, shareability). Asecond activity is the development of ontolo-gies that define terminology used to representbodies of shareable knowledge. The taskincludes (1) identifying bodies of knowledgeworth the effort to formally represent andmake shareable and (2) defining coherent setsof terms that characterize the ontologicalcommitments and representational choicesfor modeling these bodies of knowledge. Athird type of working group activity is thecoordination of collaborative experiments inknowledge sharing in which multiple researchgroups attempt to share and use each other’sknowledge bases (for example, libraries of

Articles

52 AI MAGAZINE

… the goals proposed in this article suggest a number of high-payoff research questions for the entire research community.

might not meet real needs. Instead, he urged,we must look at different levels of service andunderstand what it means to offer them, howto characterize the capabilities of different ser-vices, and what the cost is of invoking them.The management of very large knowledgebases poses some fascinating research ques-tions, including methods for handling global-ly inconsistent but locally reasonableknowledge, higher-level principles for orga-nizing knowledge, and techniques for beliefrevision as knowledge bases evolve over time.As large knowledge bases come into widespreaduse, they will need to be built, extended, andused by a wider range of users. Because theseusers will likely be less forgiving than aca-demic researchers using products of their ownmaking, a number of questions arise concern-ing presenting knowledge, browsing, query-ing, and explaining.

Other relevant issues raised by Brachmaninclude the integration of multiple paradigms,extensible representation systems, and effi-ciency concerns. In addition, each of the fourworking groups has questions that presentchallenges to the research community.

The notion of translation implied by inter-lingua raises a number of questions abouttools and methodologies for translation. Asthe work on interlingua has progressed, amuch better understanding has grown aboutthe distinction between communicationcodes and representation codes (these twoterms were introduced into the discussion byPat Hayes). A communication code capturesknowledge for the purposes of exchanging itor talking about it, and a representation codeattempts to capture knowledge for the pur-pose of supporting the efficient implementa-tion of inference mechanisms. As the effortproceeds, it is likely to spawn a great deal ofwork on understanding and recording thedesign rationale behind representation codesto facilitate greater automation in translatingthem into and out of communication codes.

A number of issues in representation lan-guages remain as research topics. Belief hasalready been mentioned. Others includedefaults and inheritance, negation, disjunc-tion, metadescriptions, higher-order logics,

description of inference, predicate reification,causality, and time.

External interfaces present a range of bothshort- and long-term research issues. Exam-ples include the verification of protocols forasynchronous operation of multiple end userapplications with many knowledge bases, theassessment of possible degrees of parallelism,and deeper investigation into requirementsfor supporting interactive user interfaces.Longer-range issues include mechanisms forspecifying the quantity and quality of infor-mation to be returned by a knowledge base inresponse to a request, means for dealing withuncertainty, and methods for optimizing theperformance of distributed systems.

Finally, the notion of shared, reusableknowledge bases provides a tremendousamount of grist for the research mill. Mostobviously, researchers will be exploring ques-tions about the content of specific reusableontologies for some time to come. In addi-tion, there are a number of ancillary ques-tions: How is consensus on a group ontologybest achieved? How can consensus be main-tained as needs change over time? Whatkinds of automated assistance and interactivetools will be beneficial? How can we verifycompatibility with an ontology? How can wesupport correspondence theories that allowknowledge base developers to express andreason about mappings between differentontologies?

The efforts described in this article to devel-op conventions for sharing and reuse repre-sent the start—rather than the culmination—of a large body of research activity. We believethat this area is one in which conventionswill serve to focus and enable research, notcodify and terminate it.

ConclusionAttempting to move beyond the capabilitiesof current knowledge-based systems mandatesknowledge bases that are substantially largerthan those we have today. However, represent-ing and acquiring knowledge is a difficult andtime-consuming task. Knowledge-acquisition

Articles

FALL 1991 53

The time is ripe to start building the infrastructure for integrating AI software at the knowledge level.

Third, it will provide system builders withtools for translating between alternative rep-resentation systems. These tools will enablethem to create efficient, optimized systems bymaking choices about alternative implemen-tations without losing the opportunity toreuse representational work from other, dif-ferent formalisms.

Fourth, it will embed these interpreters andcompilers in architectures that support com-plete interoperability not just between multi-ple knowledge-based systems but also withconventional software systems. In particular,there will be a convenient, standard applica-tion programming interface and tight inter-connection with databases.

This article attempted to articulate a visionof the necessary knowledge representationsystem technology and a path to achieving it.It also argued that progress in this area willdramatically change for the better the waythat knowledge-based systems are built andthe way they are perceived by their users.Central to this vision is the notion of estab-lishing an information infrastructure for pro-moting the sharing and reuse of knowledgebases in the development and application oflarge, enterprise-level software systems.

Acknowledgments

This effort is supported by NSF grant IRI-900-6923, NASA-Ames contract NCC 2-520, and acooperative agreement between USC/ISI andthe Corporation for National Research Initia-tives. Steve Cross, Mike Genesereth, BobKahn, Bill Mark, Ron Ohlander, Peter Patel-Schneider, Marty Tenenbaum, and GioWiederhold deserve particular acknowledg-ment for their respective important roles inshaping the efforts presented in this article.The authors would like to acknowledge bene-ficial discussions with Brad Allen, GiuseppeAttardi, R. Bhaskar, Danny Bobrow, B. Chan-drasekaran, Randy Davis, Helen Gigley, PatHayes, Phil Hayes, Alan Lawson, Bob MacGregor, Elaine Rich, Luc Steels, Mark Stefik,Abe Waksman, Chuck Williams, and MikeWilliams. Sheila Coyazo’s copyediting assis-tance was extremely valuable.

References

Bennett, J. S. 1984. ROGET: Acquiring the Conceptu-al Structure of a Diagnostic Expert System. In Pro-ceedings of the IEEE Workshop on Principles ofKnowledge-Based Systems, 83–88. Washington,D.C.: IEEE Computer Society.

tools and current development methodolo-gies will not make this problem go awaybecause the root of the problem is that knowl-edge is inherently complex and the task ofcapturing it is correspondingly complex.Thus, we cannot afford to waste whateverknowledge we do succeed in acquiring. Wewill be hard pressed to make knowledge basesmuch bigger than we have today if we con-tinue to start from scratch each time we con-struct a new system. Building qualitativelybigger knowledge-based systems will be possi-ble only when we are able to share ourknowledge and build on each other’s laborand experience.

The time is ripe to start building the infras-tructure for integrating AI software at theknowledge level, independent of particularimplementations. Today, there is a significantbody of ongoing work in AI and applicationdomains on pieces of the problem, such asbasic knowledge representation; knowledge-acquisition tools; task-specific architectures;and domain-oriented, multiuse models. Whatis lacking is an integrating framework, themeans for describing, connecting, andreusing knowledge-based technology.

Addressing these concerns will open thedoors to the development of much larger-scale systems, structured in a fashion thatfacilitates their development, maintenance,and extension. Furthermore, it will eliminatebarriers to embedding AI components inlarger, mostly conventional software systems.This approach will lead to a great expansionin the range of applicability for AI technology,which, in turn, will greatly enhance its utilityand significantly expand the commercialmarketplace.

The knowledge representation technologythat supports these goals will have four keycharacteristics:

First, it will offer libraries of reusableontologies, that is, knowledge base frameworksconsisting of (1) formal definitions of theterms that can be used to model a domain orclass of domains and (2) assertions thatgovern the requirements and constraints forcreating valid models within a domain bycombining and relating terms and terminstances.

Second, it will offer powerful, expressive,and efficient interpreters and compilers forknowledge representation systems (knowledgebases combined with inference mechanisms)in which these ontologies are embedded.These systems will likely be structured as ser-vices oriented toward a client-server model ofinteraction.

Articles

54 AI MAGAZINE

Brachman, R. J. 1990. The Future of KnowledgeRepresentation. In Proceedings of the EighthNational Conference on Artificial Intelligence,1082–1092. Menlo Park, Calif.: American Associa-tion for Artificial Intelligence.

Brachman, R. J., and Levesque, H. J. 1984. TheTractability of Subsumption in Frame-BasedDescription Languages. In Proceedings of the ThirdNational Conference on Artificial Intelligence,34–37. Menlo Park, Calif.: American Association forArtificial Intelligence.

Brodie, M. 1988. Future Intelligent Information Sys-tems: AI and Database Technologies WorkingTogether. In Readings in Artificial Intelligence andDatabases, eds. J. Mylopoulos and M. Brodie,623–641. San Mateo, Calif.: Morgan Kaufmann.

Cargill, C. F. 1989. Information Technology Standard-ization: Theory, Process, and Organizations. Bedford,Mass.: Digital.

Chandrasekaran, B. 1986. Generic Tasks in Knowl-edge-Based Reasoning: High-Level Building Blocksfor Expert System Design. IEEE Expert 1(3): 23–30.

Chandrasekaran, B. 1983. Toward a Taxonomy ofProblem-Solving Types. AI Magazine 4(4): 9–17.

Cutkosky, M. R., and Tenenbaum, J. M. 1990. AMethodology and Computational Framework forConcurrent Product and Process Design. Mechanismand Machine Theory 25(3): 365–381.

Feiner, S. K., and McKeown, K. R. 1990. Coordinat-ing Text and Graphics in Explanation Generation.In Proceedings of the Eighth National Conferenceon Artificial Intelligence, 442–449. Menlo Park,Calif.: American Association for Artificial Intelligence.

Finin, T., and Fritzson, R. 1989. How to ServeKnowledge—Notes on the Design of a KnowledgeServer. Presented at the AAAI Spring Symposium onKnowledge System Tools and Languages, 28–30March, Stanford, Calif.

Forbus, K. 1990. The Qualitative Process Engine. InReadings in Qualitative Reasoning about Physical Sys-tems, eds. D. Weld and J. de Kleer, 220–235. SanMateo, Calif.: Morgan Kaufmann.

Gruber, T. R. 1991. An Experiment in the Collabora-tive Development of Shared Ontology, TechnicalReport, KSL 91-51, Knowledge Systems Laboratory,Stanford University. Forthcoming.

Guha, R. V., and Lenat, D. B. 1990. CYC: A Mid-TermReport. AI Magazine 11(3): 32–59.

Harp, B.; Aberg, P.; Benjamin, D.; Neches, R.; andSzekely, P. 1991. DRAMA: An Application of a Logis-tics Shell. In Proceedings of the Annual Conferenceon Artificial Intelligence Applications for MilitaryLogistics, 146-151. Williamsburg, Va.: AmericanDefense Preparedness Association. Forthcoming.

Johnson, W. L., and Harris, D. R. 1990. Require-ments Analysis Using ARIES: Themes and Examples.In Proceedings of the Fifth Annual Knowledge-Based Software Assistant Conference, 121–131. Liv-erpool, N.Y.: Rome Air Development Center.

Kahn, R. E., and Cerf, V. E. 1988. An Open Architec-ture for a Digital Library System and a Plan for ItsDevelopment, Volume I: The World of Knowbots,Technical Report, Corporation for NationalResearch Initiatives, Reston, Virginia.

Kahn, G.; Nowlan, S.; and McDermott, J. 1984. AFoundation for Knowledge Acquisition. In Proceed-ings of the IEEE Workshop on Principles of Knowl-edge-Based Systems, 89–96. Washington, D.C.: IEEEComputer Society.

McDermott, J. 1990. Developing Software Is LikeTalking to Eskimos about Snow. In Proceedings ofthe Eighth National Conference on Artificial Intelli-gence, 1130–1133. Menlo Park, Calif.: AmericanAssociation for Artificial Intelligence.

Mckay, D.; Finin, T.; and O’Hare, A. 1990. The Intel-ligent Database Interface. In Proceedings of theEighth National Conference on Artificial Intelli-gence, 677–684. Menlo Park, Calif.: American Asso-ciation for Artificial Intelligence.

Pan, J. Y.-C.; Tenenbaum, J. M.; and Glicksman, J.1989. A Framework for Knowledge-Based Comput-er-Integrated Manufacturing. IEEE Transactions onSemiconductor Manufacturing 2(2): 33–46.

Roth, S., and Mattis, J. 1990. Data Characterizationfor Intelligent Graphics Presentation. In Proceed-ings of CHI-90, The Annual Conference on Com-puter-Human Interaction, 193–200. New York:Association of Computing Machinery.

Sathi, A.; Fox, M. S.; and Greenberg, M. 1990. Rep-resentation of Activity Knowledge for Project Man-agement. IEEE Transactions on Pattern Analysis andMachine Intelligence PAMI-7(5): 531–552.

Smith, D. R. 1990. A Semiautomatic Program Devel-opment System. IEEE Transactions on Software Engi-neering SE-16(9): 1024–1043.

Steele, G. R. 1984. Common Lisp: The Language. Bed-ford, Mass.: Digital.

Steels, L. 1990. Components of Expertise. AI Maga-zine 11(2): 29–49.

Stefik, M. 1986. The Next Knowledge Medium. AIMagazine 7(1): 34–46.

Swartout, W. R., and Smoliar, S. 1989. Explanation:A Source for Guidance in Knowledge Representa-tion. In Knowledge Representation and Organization inMachine Learning, ed. K. Morik, 1–16. New York:Springer-Verlag.

Waterman, D. A. 1986. A Guide to Expert Systems.Reading, Mass.: Addison-Wesley.

Articles

FALL 1991 55

Thomas Gruber is a researchscientist in the Knowledge Sys-tems Laboratory, Stanford Uni-versity. His current researchinterests include the develop-ment of shared ontologies forknowledge sharing and reuse,the acquisition and generationof design rationale, and the

computer-assisted formulation of engineeringmodels. His earlier work at the University of Mas-sachusetts was in the areas of knowledge-basedcommunication prosthesis and automated knowl-edge acquisition for expert systems.

Ramesh Patil recently joinedthe Intelligent Systems Divisionof USC/ Information SciencesInstitute as a project leader afterserving as an associate professorof computer science at MIT. HisPh.D. work on multilevel causalreasoning systems for medicaldiagnosis, performed in the

Computer Science Department at MIT, was thebasis for his receiving the American Association forMedical Systems and Informatics Young Investiga-tor Award in Medical Knowledge Systems. His cur-rent research interests include knowledgerepresentation, signal interpretation, qualitativereasoning, and diagnostic reasoning in medicineand electronics.

Ted Senator is chief of the Artificial IntelligenceDivision in the Financial Crimes Enforcement Net-work of the U.S. Treasury Department. In his priorposition with the Department of the Navy, he man-aged the Navy’s applications under the StrategicComputing Initiative.

William R. Swartout is directorof the Intelligent Systems Divi-sion and an associate researchprofessor of computer science atUSC/Information Sciences Insti-tute. He is primarily known forhis work on explanation andnew expert system architectures.Swartout was co–program chair

for the 1990 National Conference on ArtificialIntelligence and is currently serving on the Boardof Councilors of the American Association of Artifi-cial Intelligence.

Robert Neches is head of theIntegrated User-Support Envi-ronments Group at USC/Infor-mation Sciences Institute and aresearch associate professor inthe Computer Science Depart-ment at USC. His currentresearch topics include intelli-gent interfaces and develop-

ment methodologies for large systems integratingAI and conventional technology. Since November1989, he has been serving as coordinator for a uni-versity, government, and private industry effort todevelop conventions that facilitate the sharing andreuse of AI knowledge bases and knowledge repre-sentation system technology.

Richard Fikes is a research pro-fessor in the Computer ScienceDepartment at Stanford Univer-sity and is co-director of theHeuristic Programming Projectin Stanford’s Knowledge Sys-tems Laboratory. Fikes is afellow of the American Associa-tion for Artificial Intelligence

and is prominently known as co-developer of theSTRIPS automatic planning system and one of theprincipal architects of IntelliCorp’s KEE system.

Tim Finin is professor andchairman of the Computer Sci-ence Department at the Univer-sity of Maryland. Prior tojoining the University of Mary-land, he was a technical directorat the Unisys Center forAdvanced Information Technol-ogy, a member of the faculty of

the University of Pennsylvania, and on theresearch staff of the Massachusetts Institute ofTechnology AI Laboratory. He has had over 20 yearsof experience in the applications of AI to problemsin database and knowledge base systems, expertsystems, natural language processing, and intelli-gent interfaces. Finin holds a B.S. degree in electri-cal engineering from the Massachusetts Institute ofTechnology and a Ph.D in computer science fromthe University of Illinois.

Articles

56 AI MAGAZINE