KQML - A Language and Protocol forKnowledge and Information Exchange

Tim Finin and Rich FritzsonComputer Science Department

University of Maryland, UMBCBaltimore MD 21228

Don McKay and Robin McEntireValley Forge Engineering Center

Unisys CorporationPaoli PA 19301

Abstract. This paper describes the design of and experimentation with the Knowledge Query and ManipulationLanguage (KQML), a new language and protocol for exchanging information and knowledge. This work is part a larger effort, the ARPA Knowledge Sharing Effort which is aimed at developing techniques and methodology forbuilding large-scale knowledge bases which are sharable and reusable. KQML is both a message format and amessage-handling protocol to support run-time knowledge sharing among agents. KQML can be used as alanguage for an application program to interact with an intelligent system or for two or more intelligent systems toshare knowledge in support of cooperative problem solving.

KQML focuses on an extensible set of performatives, which defines the permissible operations that agents mayattempt on each other’s knowledge and goal stores. The performatives comprise a substrate on which to develophigher-level models of inter-agent interaction such as contract nets and negotiation. In addition, KQML provides abasic architecture for knowledge sharing through a special class of agent called communication facilitators whichcoordinate the interactions of other agents The ideas which underlie the evolving design of KQML are currentlybeing explored through experimental prototype systems which are being used to support several testbeds in suchareas as concurrent engineering, intelligent design and intelligent planning and scheduling.

Introduction

Many computer systems are structured as collections ofindependent processes these are frequently distributedacross multiple hosts linked by a network. Databaseprocesses, real-time processes and distributed AI systemsare a few examples. Furthermore, in modern networksystems, it should be possible to build new programs byextending existing systems; a new small process should beconveniently iinkable to existing information sources andtools (such as filters or rule based systems).

The idea of an architecture where this is easy to do is quiteappealing. (It is regularly mentioned in science fiction.)Many proposals for intelligent user-agents such asKnowbots [Kahn] assume the existence of this type ofenvironment. One type of program that would thrive insuch an environment is a mediator [Wiederhold].Mediators are processes which situate themselves between

"provider" processes and "consumer" processes andperform services on the raw information such as providingstandardized interfaces; integrating information fromseveral sources; translating queries or replies. Mediators(also known as "middleware") are becoming increasinglyimportant as they are commonly proposed as an effectivemethod for integrating new information systems withinflexible legacy systems.

However, networks environments which support "plug andplay" processes are still rare, and most distributed systemsare implemented with ad hoe interfaces between theircomponents. Many Internet resources, such as librarycatalog access, finger, and menu based systems aredesigned to support only process-to-user interaction.Those which support process-to-process communication,such as ftp or the Mosaic world wide web browser, rely onfairly primitive communication protocols. The reason forthis is that there are no adequate standards to support

- 93 -

From: AAAI Technical Report WS-94-02. Compilation copyright © 1994, AAAI (www.aaai.org). All rights reserved.

complex communication among processes. Existingprotocols, such as RPC, are insufficient for severalreasons. They are not all that standard; there are currentlyseveral successful and incompatible RPC standards (e.g.ONC and DCE). They are also too low level; they do notprovide high level access to information, but are intendedonly as "remote procedure calls."

Nor are there standard models for programming in anenvironment where some of the data is supplied byprocesses running on remote machines and some of theresults are needed by other similarly distant processes.While there are many ad hoc techniques foraccomplishing what is needed, it is important thatstandard methods are adopted as early as is reasonable inorder to facilitate and encourage the use of these newarchitectures. It is not enough for it to be possible tocommunicate, it must be easy to communicate. Not onlyshould low level communication tasks such as errorchecking be automatic, but using and observing protocolshould be automatic as well.

KQML is a language and a protocol that supports this typeof network programming specifically for knowledge-basedsystems or intelligent agents. It was developed by theARPA supported Knowledge Sharing Effort [Neches 91,Patti 92] and separately implemented by several researchgroups. It has been successfully used to implement avariety of information systems using different softwarearchitectures.

The Knowledge Sharing Effort

The ARPA Knowledge Sharing Effort (KSE) is consortium to develop conventions facilitating the sharingand reuse of knowledge bases and knowledge basedsystems. Its goal is to define, develop, and testinfrastructure and supporting technology to enableparticipants to build much bigger and more broadlyfunctional systems than could be achieved working alone.

Current approaches for building knowledge-based systemsusually involve constructing new knowledge bases fromscratch. The ability to efficiently scale up AI technologywill require the sharing and reuse of existing components.This is equally true of software modules as well asconceptual knowledge. AI system developers could thenfocus on the creation of the specialized knowledge andreasoners new to the task at hand. New systems couldinteroperate with existing systems, using them to performsome of its reasoning. In this way, declarative knowledge,problem solving techniques and reasoning services could

all be shared among systems. The ability to build, manageand use sharable and reusable knowledge resources isthought to be a key to the realization of large-scaleintelligent systems. The definition of conventionsenabling sharing among collaborators is the essential firststep toward these goals.

The KSE is organized around four working groups each ofwhich is addressing a complementary problem identifiedin current knowledge representation technology:

¯ The Interlingua Group is concerned with translationbetween different representation languages, withsub-interests in translation at design time and at run-time.

¯ The KRSS Group (Knowledge RepresentationSystem Specification) is concerned with definingcommon constructs within families of representationlanguages.

¯ The SRKB Group (Shared, Reusable KnowledgeBases) is concerned with facilitating consensus onthe contents of sharable knowledge bases, with sub-interests in shared knowledge for particular topicareas and in topic-independent developmenttools/methodologies.

¯ The External Interfaces Group is concerned withrun-time interactions between knowledge basedsystems and other modules in a run-timeenvironment, with sub-interests in communicationprotocols for KB-to-KB and for KB-to-DB.

The KQML language is one of the main results whichhave come out of the external interfaces group of the KSE.

KQML

We could address many of the difficulties ofcommunication between intelligent agents described in theIntroduction by giving them a common language. Inlinguistic terms, this means that they would share acommon syntax, semantics and pragmatics.

Getting information processes, especially AI processes, toshare a common syntax is a major problem. There is nouniversally accepted language in which to representinformation and queries. Languages such as KIF[Genesereth et. al. ’92], extended SQL, and LOOM[McGreggor] have their supporters, but there is also astrong position that it is too early to standardize on anyrepresentation language. As a result, it is currentlynecessary to say that two agents can communicate with

.94-

Query

Reply

or a reasoner which can produce a sequence ofinstantiations in response to a query. Although thisexchange requires that the server maintain some internalstate, the individual transactions are each the same as inthe single reply case. I.e., each transaction is a "send-a-query / wait / receive-a-reply" exchange. We refer to thesetransactions as being synchronous because messages arrive

Figure 1 - In this example of a synchronous communicationquery, a blocking query waits for an expected reply.

each other if they have a common representation languageor use languages that are inter-translatable.

Assuming a common or translatable language, it is stillnecessary for communicating agents to share a frameworkof knowledge (i.e. a shared structured vocabulary) in orderto interpret the messages they exchange. This is not reallya shared semantics, but a shared ontology. There is notlikely to be one shared ontology, but many. Sharedontologies are under development in many importantapplication domains such as planning and scheduling,biology and medicine.

Pragmatics among computer processes includes

1) knowing who to talk with and how to find them

2) knowing how to initiate and maintain an exchange.

KQML is concerned primarily with pragmatics (andsecondarily with semantics). It is a language and a set ofprotocols which support computer programs inidentifying, connecting with and exchanging informationwith other programs.

KQML Protocols

There are a variety of interprocess information exchangeprotocols. There is the simple case of one process (aclient) sending a query to another process (a server) waiting for a reply as is shown in Figure 1. This occurscommonly when a backward-chaining reasoner retrievesinformation from a remote source. As it needs data, itplaces queries and waits for the replies before attemptingany further inferences. A far as protocol is concerned, thiscase includes those where the server’s reply messageactually contains a collection of replies.

Another common case is when the server’s reply is not thecomplete answer but a handle which allows the client toask for the components of the reply, one at a time asshown in Figure 2. A common example of this type ofexchange is a simple client querying a relational database

Query

ReplyNext~1~ Reply

Figure 2 - The remote server can maintain state byremembering the partial answer. Replies are sentindividually, each at the request of the client.

at the client only when they are expected.

It is a different situation in real-time systems, amongothers, where the client subscribes to a server’s output andthen an indefinite number of replies arrive at irregularintervals in the future, as shown in Figure 3. In this case,

Rep’y i

~1 ~91--~ Reply ~

Figure 3 - Using an asynchronous communication protocol, anon-blocking subscribe request can result in an irregularlyspaced, indeterminate number of incoming messages.

the client does not know when each reply message will bearriving and may be busy performing some other taskwhen they do. We refer to these transactions as beingasynchronous.

There are other variations of these protocols. For example,messages might not be addressed to specific hosts, butbroadcast to a number of them. The replies, arrivingsynchronously or asynchronously have to be collated and,

- 95 - ,

optionally, associated with the query that they are replyingto.

The KQML Language

KQML supports these protocols by making them anexplicit part of the communication language. When usingKQML, a software agent transmits messages composed inits own representation language, wrapped in a KQMLmessage.

KQML is conceptually a layered language. The KQMLlanguage can be viewed as being divided into three layers:the content layer, the message layer and thecommunication layer. The content layer is the actualcontent of the message, in the programs ownrepresentation language. KQML can carry anyrepresentation language, including languages expressed asASCII strings and those expressed using a binary notation.All of the KQML implementations ignore the contentportion of the message except to the extent that they needto determine its boundaries.

The communication level encodes a set of features to themessage which describe the lower level communicationparameters, such as the identity of the sender andrecipient, and a unique identifier associated with thecommunication.

The message layer forms the core of the language. Itdetermines the kinds of interactions one can have with aKQML-speaking agent. The primary function of themessage layer is to identify the protocol to be used todeliver the message and to supply a speech act orperformative which the sender attaches to the content. The

(performative or speech act)

communication (inagreed upon language, e.g.,KIF, KRSL, etc.)

Figure 4 - The KQML language can be viewed as being dividedinto three layers: the content layer, the message layer and thecommunication layer.

performative signifies that the content is an assertion, aquery, a command, or any of a set of knownperformatives. Because the content is opaque to KQML,this layer also includes optional features which describe

the content: its language, the ontology it assumes, andsome type of more general description, such as adescriptor naming a topic within the ontology. Thesefeatures make it possible for KQML implementations toanalyze, route and properly deliver messages even thoughtheir content is inaccessible.

Conceptually, a KQML message consists of aperformative, its associated arguments which include thereal content of the message, and a set of optionalarguments which describe the content in a manner whichis independent of the syntax of the content language. Forexample, a message representing a query about thelocation of a particular airport might be encoded as:

(ask-one :content (gooloe lax (7long ?lat)):ontology gee-model3)

In this message, the KQML performative is ask-one, thecontent is (geoloc lax (?long ?lat)) and the assumedontology is identified by the token :geo-model3. The samegeneral query could be conveyed using standard Prolog asthe content language in a form that requests the set of allanswers as:

(ask-all :content "geoloc(lax,[Long,Lat])":language standard_prolog:ontology gee-model3)

The syntax of KQML is based on a balanced parenthesislist. The initial element of the list is the performative andthe remaining elements are the performative’s argumentsas keyword/value pairs. Because the language is relativelysimple, the actual syntax is relatively unimportant and canbe changed if necessary in the future. (The current syntaxwas selected because most of the original implementationefforts were done in Common Lisp.)

The set of KQML performatives is extensible. There is aset of reserved performatives which have a well definedmeaning. This is not a required or minimal set; a KQMLagent may choose to handle only a few (perhaps one ortwo) performatives. However, an implementation thatchooses to implement one of the reserved performativesmust implement it in the standard way. A community ofagents may choose to use additional performatives if theyagree on their interpretation and the protocol associatedwith each.

Some of the reserved performatives are shown in Figure5. In addition to standard communication performativessuch as ask, tell, deny, delete, and more protocol orientedperformatives such as subscribe, KQML containsperformatives related to the non-protocol aspects ofpragmatics, such as advertise - which allows an agent to

- 96 -

announce what kinds of asynchronous messages it iswilling to handle; and recruit - which can be used to findsuitable agents for particular types of messages.

For example, agent B might send the followingperformative to agent A:

Basic query performatives:evaluate, ask-if, ask-in, ask-one, ask-allMulti-response query performatives:stream-in, stream-all

Response performatives:reply, sorryGeneric informational performatives:tell, achieve, cancel, untell, unachieveGenerator performatives:standby, ready, next, rest, discard, generatorCapability-definition performatives:advertise, subscribe, monitor, import, export

Networking performatives:register, unregister, forward, broadcast, route

Figure 5 - There are about two dozen reservedperformative names which fall into seven basiccategories.

(advertise:language KQML:ontology K10:content (subscribe :language KQML

:ontology K10:content (stream-about

:language KIF:ontology motors:content motor 1)))

to which agent B might respond with:

(subscribe :reply-with sl:language KQML:ontology K10:content(stream-about

:language KIF:ontology motors:content motorl))

Agent A would then send B a stream of tell and untellperformatives over time with information about motor1, asin:

(tell :language KIF:ontology motors:in-reply-to s 1:content (= (val (torque motorl) (sim-time

(scalar 12 kgf))(tell :language KIF

:ontology structures:in-reply-to sl:content (fastens frame l 2 motor 1))

(untell :language KIF:ontology motors

:in-reply-to sl:content (= (val (torque motorl) (sim-time

(scalar 12 kgf))

KQML Semantics. Currently there are no formalsemantics defined for the basic KQML performatives orfor the protocols associated with them. A semantic modelis under development that assumes that a KQML-speakingagent has a virtual knowledge base with two separatecomponents: an information store (i.e., "beliefs") and goal store (i.e., "intentions"). The primitiveperformatives are defined in terms of their effect on thesestores. A TELL(S), for example, is an assertion by thesending agent to the receiving agent that the sentence S isin its virtual belief store. An ACHIEVE(S) is a request the sender to the receiver to add S to its intention store.

The protocols that govern the allowable responses whenan agent receives a KQML message must also be defined.These are currently defined informally in Englishdescriptions, but work is underway to provide formaldefinitions in terms of a grammar using the definiteclause grammar (DCG) formalism.

KQML Internal Architectures

KQML was not defined by a single research group for aparticular project. It was created by a committee ofrepresentatives from different projects, all of which wereconcerned with managing distributed implementations ofsystems. One project was a distributed collaboration ofexpert systems in the planning and scheduling domain.Another was concerned with problem decomposition anddistribution in the CAD/CAM domain. A commonconcern was the management of a collection ofcooperating processes and the simplification of theprogramming requirements for implementing a system ofthis type. However, the groups did not share a commoncommunication architecture. As a result, KQML does notdictate a particular system architecture, and severaldifferent systems have evolved.

- 97.

Our group has two implementations of KQML. One is communication channel is currently implemented by awritten in Common Lisp, the other in C. Both are fullyinteroperable and are frequently used together.

The design of these two implementations was motivatedby the need to integrate a collection of preexisting expertsystems into a collaborating group of processes. Most ofthe systems involved were never designed to operate in acommunication oriented environment. Thecommunication architecture is built around twospecialized programs, a router and a facilitator, and alibrary of interface routines, called a KRIL.

KQML Routers. Routers are content independent!::message routers. Each KQML-speaking software agent i s iassociated with its own separate router process. All routers :~are identical; each is just an executing copy of the sameprogram. A router handles all KQML messages going toand from its associated agent. Because each program hasan associated router process, it is not necessary to makeextensive changes to the program’s internal organizationto allow it to asynchronously receive messages from avariety of independent sources. The router provides thisservice for the agent and provides the agent with a singlepoint of contact for communicating with the rest of thenetwork. It provides both client and service functions forthe application and can manage multiple simultaneousconnections with other agents.

The router never looks at the content fields of themessages it handles. It relies solely on the KQMLperformatives and its arguments. If an outgoing KQMLmessage specifies a particular Internet address, the routerdirects the message to it. If the message specifies aparticular service by name, the router will attempt to findan Internet address for that service and deliver themessage to it. If the message only provides a description ofthe content (e.g. query, :ontology "geo-domain-3",:language "Prolog", etc.) the router may attempt to find server which can deal with the message and it will deliverit there, or it may choose to forward it to a smartercommunication agent which may be willing to route it.Routers can be implemented with varying degrees ofsophistication -- they can not guarantee to deliver allmessages.

In the C implementation, a router actually is a separateUNIX process. It is a child process which is forked by theapplication. The communication channel between therouter and the application carries KQML messages butmay carry more than is specified by the formal protocol.That is, since it is a private channel between the routerand application it does not have to observe KQMLprotocol. The router only has to observe the formal KQMLrules when speaking to the outside world. The

UNIX pipe, but we are planning on experimenting with ahigher bandwidth channel which can be implemented withshared memory.

The Lisp implementation uses Lucid’s multitaskingprimitives to implement the router as a separate Lisp taskwithin the application’s Lisp image. It would be tooinefficient to fork a separate Lisp image for the router.However, we are planning on experimenting with usingthe C router with Common Lisp applications.

Router

Network KQMLConnections objects

Network

Figure 6 - A router gives an application a single interfaceto the network, providing both client and servercapabilities, managing multiple simultaneousconnections, and handling some KQML interactionsautonomously.

KQML Facilitators. To deliver messages that areincompletely addressed, routers rely on facilitators. Afacilitator is a network application which provides usefulnetwork services. The simplest service it provides is tomaintain a registry of service names; routers rely onfacilitators to help them find hosts to route information to.In this role, facilitators serve only as consultants to thecommunication process.

However, facilitators can provide many othercommunication services. On request, a facilitator mayforward messages to named services. Or, it may providematchmaking services between information providers andconsumers. They include

content based routing of information between agents,

brokering of information between an advertisingsupplier and an advertising consumer,

recruiting suppliers to deal directly with advertisingconsumers,

smart multicasting of information to interested agents

~- 98 -

These activities can be performed in a relatively simplemanner (as shown in Figure 8) or they may be performedby an intelligent agent capable of synthesizing informationfrom multiple sources.

Facilitators are actual network software agents; they havetheir own KQML routers to handle their traffic and theydeal exclusively in KQML messages. There is typicallyone facilitator for each local group of agents. This cantranslate into one facilitator per local site or one perproject; there may be multiple local facilitators to provideredundancy. The facilitator database may be implementedin any number of ways depending on the number of hostsserved and the quality of service required. An early

ask(X)

tell(X)

Content BasedRouting

¯ broker( ask(:~tk..._ ~il~’er rise. (~k(X)) IBrokering ~~

Recruiting ~br°ker(ask( vertlse. (&~k(X) ]tell(X)

Figure 7 - Facilitators are agents that deal in knowledgeabout the information services and requirements of otheragents. They can offer services such as forwarding,brokering, recruiting and content-based routing.

implementation of a facilitator replicated the database onevery machine in the local net, to reduce communicationoverhead for routing. This was replaced with a morecentralized implementation which is supplemented bycaching of information in the routers. For larger networks,and for facilitators serving multiple networks, adistributed implementation (analogous to the Internetdomain name service) may be more appropriate.

When each application starts up, its router announcesitself to the local facilitator so that it is registered in thelocal database. When the application exits, the routersends another KQML message to the facilitator, removingthe application from the facilitator’s database. In this wayapplications can find each other without there having to bea manually maintained list of local services.

KQML KRILs. Since the router is a separate processfrom the application, it is necessary to have aprogramming interface between the application and therouter. This interface is called a KRIL (KQML RouterInterface Library). While the router is a separate process,

with no understanding of the content field of the KQMLmessage, the KRIL is embedded in the application and hasaccess to the application’s tools for analyzing the content.While there is only one piece of router code, which isinstantiated for each process, there can be various KRILs,one for each application type or one for each applicationlanguage. The general goal of the KRIL is to make accessto the router as simple as possible for the programmer.

Facilitator

Network

Figure 8 - A communication Facilitator is an agent that performsvarious useful services, e.g. maintaining a registry of servicenames, forwarding messages to named services, routing messagesbased on content, providing "matchmaking" betweeninformation providers and clients, and providing mediation anltranslation services.

To this end, a KRIL can be as tightly embedded in theapplication, or even the application’s programminglanguage, as is desirable. For example, an earlyimplementation of KQML featured a KRIL for the Prologlanguage which had only a simple declarative interface forthe programmer. During the operation of the Prologinterpreter, whenever the Prolog database was searched forpredicates, the KR1L would intercept the search;determine if the desired predicates were actually beingsupplied by a remote agent; formulate and pose anappropriate KQML query; and return the replies to theProlog interpreter as though they were recovered from theinternal database. The Prolog program itself contained nomention of the distributed processing going on except forthe declaration of which predicates were to be treated asremote predicates. Figure 9 shows an example of thistogether with a facilitation agent which provides a centralcontent-based routing service.

It is not necessary to completely embed the KRIL in theapplication’s programming language. A simple KRIL fora language generally provides two programmatic entries.For initiating a transaction there is a send-kqml-message

\

Know~ "P if Q and R"

export(p/2).import(q/I).import(r/l).

/q(a)Kn°ws Q I

I~)port(q

2.~.~

¯ ¯ to know PApplication ?- p(A,B)

A6 A1 import(p/2)

Knows who knows what

Knows [¢ :~ name(al.A4 128.62.39.4) ...

r(b)import(al,p/2)

~}port(r export(a4,r/1)export. (a6,p2)...

Figure 9 - This example shows the use of a facilitator to do content-based routing allowing a set of Prolog-based agents to worktogether to prove goals.

function. This accepts a message content and as muchinformation about the message and its destination as canbe provided and returns either the remote agent’s reply (ifthe message transmission is synchronous and the processblocks until a reply is received) or a simple codesignifying the message was sent. For handling incomingasynchronous messages, there is usually a declare-message-handler function. This allows the applicationprogrammer to declare which functions should be invokedwhen messages arrive. Depending on the KR/L’scapabilities, the incoming messages can be sortedaccording to performative, or topic, or other features, androuted to different message handling functions.

In addition to these programming interfaces, KRILs acceptdifferent types of declarations which allow them toregister their application with local facilitators and contactremote agents to advise them that they are interested inreceiving data from them. Our group has implemented avariety of experimental KRILs, for Common Lisp, C,Prolog, Mosaic, SQL, and other tools.

KQML Performance. We have developed a simpleperformance model, shown in Figure 11, for KQMLcommunication which has allowed us to analyze theefficiency of communication and to identify and eliminatebottlenecks by tuning the software and adding additionalcapabilities. For example, various compressionenhancements have been added which cut thecommunication costs by reducing the message sizes and

also by eliminating a substantial fraction of symbol lookupand string duplication.

fimction

Network objects

Figure 10 -The KRIL is part of the application and has access toits internals. It provides internal access points to which therouter delivers incoming messages, analyzes outgoing messagesfor appropriate domain tagging and routing, and providesapplication specific interface and procedures for communicationaccess.

Experiences with KQML

We have used KQML as the communication language inseveral technology integration experiments in the

ARPA/Rome Lab Planning Initiative. These experimentslinked a planning agent (in SIPE), with a scheduler (inCommon Lisp), a knowledge base (in LOOM), and a casebased reasoning tool (in Common Lisp). All of thecomponents integrated were preexisting systems whichwere not designed to work in a distributed environment.

We have also successfully used KQML in demonstrationsfor the ARPA-supported Integrated Weapons SystemsDatabase, integrating distributed clients (in C) withmediators which were retrieving data from distributeddatabases. Additional work was done under this projectusing KQML to link a World Wide Web browser withmediators designed to locate documents for them.

The Computer Systems Division of the Aerospace Corp.has used KQML to integrate commercial off-the-shelf

~greply .~oding & writing reply

Waltln~ ~quer~~.~

Figure 11 - A simple performance model for KQMLcommunication has allowed us to analyze the efficiency ofKQML-based communication and to eliminate bottlenecks.

software into systems by wrapping them in KQML-speaking shells.

The Lockheed AI Center and the Palo Alto CollaborationTestbed have also made extensive use of KQML todecompose and distribute problems in the CAD/CAMdomain.

Conclusion

This paper has described KQML -- a language andassociated protocol by which intelligent software agentscan communicate to share information and knowledge.We believe that KQML, or something very much like it,will be important in building the distributed agent-oriented information systems of the future. One must askhow this work is to be differentiated from the work in tworelated areas -- distributed systems (DS) and distributedAI (DAI).

KQML and DS. KQML offers an abstraction of aninformation agent (provider or consumer) at a higher levelthat is typical in other areas of Computer Science. Inparticular, KQML assumes a model of an agent as aknowledge-based system (KBS). Although this will notseem to be surprising or profound in our AI community, it

is a significant advance (we hope!) for the general community. The KBS model easily subsumes a broadrange of commonly used information agent models,including database management systems, hypertextsystems, server-oriented software (e.g. finger demons,mail servers, HTML servers, etc), simulations, etc. Suchsystems can usually be modeled as having two virtualknowledge bases -- one representing the agent’sinformation store (i.e., beliefs) and the other representingits intentions (i.e., goals).

We hope that future standards for interchange andinteroperability languages and protocols will be based onthis very powerful and rich model. This will avoid thebuilt-in limitations of more constrained models (e.g., thatof a simple remote procedure call or relational databasequery) and also make it easier to integrate truly intelligentagents with simpler and more mundane informationclients and servers.

In addition to having something to offer, KQML also hassomething it seeks from distributed systems work -- theright abstractions and software components to providebasic communication services. Current KQML-basedsystems have been built on the most common transportlayers in use today -- TCP/IP and EMAIL. The realcontributions that KQML makes are independent of thetransport layer. We anticipate that KQML interfaceimplementations will be based on whatever is seen as thebest transport mechanism.

KQML and DAI. The contribution that KQML makes toDistributed AI research is to offer a standard language andprotocol that intelligent agents can use to communicateamong themselves as well as with other informationservers and clients. We believe that permitting agents touse whatever content language they prefer will makeKQML appropriate for most DAI research. In designingKQML, our goal is to build in the primitives necessary tosupport all of the interesting agent architectures currentlyin use. If we have been successful, then KQML shouldprove to be a good tool for DAI research, and, if usedwidely, should enable greater research collaborationamong DAI researchers.

KQML and the Future. The ideas which underlie theevolving design of KQML are currently being exploredthrough experimental prototype systems which are beingused to support several testbeds in such areas asconcurrent engineering [Cutkowski, McGuire,Tenenbaum, Kuokka], intelligent design [Genesereth] andintelligent planning and scheduling. Figure 12 shows the

.101-

architecture of a system in which KQML is being used tosupport the interchange of knowledge among a planner, aplan simulator, a plan editor and a knowledge server,which is the repository for the shared ontology and accesspoint to common databases through the IntelligentDatabase Interface [McKay, Pastor].

Figure 12 - KQML has been used in the ARPA Rome PlanningInitiative to support communication between components of anintelligent planning system.

The design of KQML has continued to evolve as the ideasare explored and feedback is received from the prototypesand the attempts to use them in real testbed situations.Furthermore, new standards for sharing persistent object-oriented structures are being developed and promulgated,such as OMG’s CORBA specification and Microsoft’sOLE 2.0. Should any of these become widely used, it willbe worthwhile to evoNe KQML so that its key ideas -- thecollection of reserved performatives, the support for avariety of information exchange protocols, the need for aninformation based directory service -- can enhance thesenew information exchange languages.

Bibliography

External lnterfac.es Working Group ARPA Knowledge SharingEffort. KQML Overview. Working paper, 1992.

External Interfaces Working Group ARPA Knowledge SharingEffort. Specification of the KQML agent-communicationlanguage. Working paper, December 1992.

S. Bussmann and J. Mueller. A communication architectute-~m-cooperating agents. Computers and Artificial Intelligence,12:37--53, 1993.

M. Cutkosky, E. Engelmore, R. Fikes, T. Gruber, M.Genesereth, and W. Mark. PACT: An experiment in integratingconcurrent engineering systems. 1992.

Edmund H. Durfee, Victor R. Lesser, and Daniel D. Corkill.Trends in cooperative distributed problem solving. IEEETransactions on Knowledge and Data Engineering, 1(!):63--83,March 1989.

Dan Kuokka et. al. Shade: Technology for knowledge-basedcollaborative. In AAAI Workshop on AI in CollaborativeDesign, 1993.

James McGuire et. al. Shade: Technology for knowledge-basedcollaborative engineering. Journal of Concurrent Engineering:Research and Applications, to appear.

Tim Finin, Rich Fritzson, and Don McKay et. al. An overviewof KQML: A knowledge query and manipulation language.Technical report, Department of Computer Science, Universityof Maryland Baltimore County, 1992.

Tim Finin, Rich Fritzson, and Don McKay. A language andprotocol to support intelligent agent interoperability. InProceedings of the CE& CALS Washington "92 Conference.June 1992.

Tim Finin, Don McKay, Rich Fritzson, and Robin McEntire.KQML: an information and knowledge exchange protocol. InInternational Conference on Building and Sharing of Very Large-Scale Knowledge Bases, December 1993.

M. Genesereth and R. Fikes et. al. Knowledge interchangeformat, version 3.0 reference manual. Technical report,Computer Science Department, Stanford University, 1992.

Mike Genesereth. Designworld. In Proceedings of the IEEEConference on Robotics and Automation, pages 2,785--2,788.IEEE CS Press.

Mike Genesereth. An agent-based approach to softwareinteroperability. Technical Report Logic-91-6, Logic Group,CSD, Stanford University, February 1993.

Carl Hewitt and Jeff Inman. DAI betwixt and between: From"’intelligent agents" to open systems science. IEEE Transactionson Systems, Man and Cybernetics, 21(6), December 1991.(Special Issue on Distributed AI).

Michael N. Huhns, David M. Bridgeland, and Natraj V. Arni. ADAI communication aide. Technical Report ACT-RA-317-90,MCC, Austin TX, October 1990.

R. E. Kahn, Digital Library Systems, Proceedings of the SixthConference on Artificial Intelligence Applications CAIA-90(Volume II: Visuals), Santa Barbara CA, pp. 63-64, 1990.

Robert MacGregor and Raymond Bates, The Loom KnowledgeRepresentation Language, Proceedings of the Knowledge-BasedSystems Workshop, St. Louis, Missouri, April, 1987.

Don McKay, Tim Finin, and Anthony O’Hare. The intelligentdatabase interface. In Proceedings of the 7th NationalConference on Artificial Intelligence, August 1990.

r ~r - --

R. Neches, R. Fikes, T. Finin, T. Gruber, R. Patil, T. Senator,and W. Swartout. Enabling technology for knowledge sharing.AI Magazine, 12(3):36 -- 56, Fall 1991.

Jeff Y-C Pan and Jay M. Tenenbaum. An intelligent agentframework for enterprise integration. IEEE Transactions onSystems, Man and Cybernetics, 21(6), December 1991. (SpecialIssue on Distributed AI).

Mike P. Papazoglou and Timos K. Sellis. An organizationalframework for cooperating intelligent information systems.International Journal on Intelligent and Cooperative InformationSystems, 1(1), (to appear) 1992.

Jon Pastor, Don Mckay and Tim Finin, View-Concepts:Knowledge-Based Access to Databases, First InternationalConference on Information and Knowledge Management,Baltimore, November 1992.

R. Patil, R. Fikes, P. Patel-Schneider, D. McKay, T. Finin, T.Gruber, and R. Neches. The darpa knowledge sharing effort:Progress report. In B. Nebel, C. Rich, and W. Swartout, editors,Principles of Knowledge Representation and Reasoning:Proceedings of the Third Intemational Conference (KR’92), SanMateo, CA, November 1992. Morgan Kaufmann.

J. R. Searle. What is a speech act? In M. Black, editor, FromPhilosophy in America, pages 221--239. Allen & Unwin, Ort??,1965.

Reid G. Smith. The contract net protocol: High-levelcommunication and control in a distributed problem solver.IEEE Transactions on Computers, C-29(12):1104--1113,December 1980.

Reid G. Smith and Randall Davis. Framework for cooperationin distributed problem solving. IEEE Transactions on System,Man, and Cybernetics, SMC-11 (1):61--70, January 1981.

M.Tenenbaum, J. Weber, and T. Gruber. Enterprise integration:Lessons from shade and pact. In C. Petrie, editor, EnterpriseIntegration Modeling. MIT Press, 1993.

Gio Wiederhold Peter Wegner and Stefano Ceri. Towardmegaprogramming. Communications of the ACM, 33(11):89--99, November 1992.

Steven T. C. Wong and John L. Wilson. COSMO: acommunication scheme for cooperative knowledge-basedsystems. IEEE Transactions on Systems, Man and Cybernetics,to appear.

- 103 -