DAI-List Digest Friday, 21 February 1992 Issue Number 69 Topics: KQML Performatives List Please send submissions to DAI-List@mcc.com. Send other requests, such as changes in your e-mail address, to DAI-List-Request@mcc.com. ------------------------------------------------------------------------ [Please review the following carefully, as it may have a large affect on the way we build agents and the interactions they may have - Huhns] Date: Fri, 14 Feb 92 21:30:27 EST From: mckay@PRC.Unisys.COM Subject: KQML Performatives List KQML Performatives Knowledge Sharing Effort External Interfaces Working Group Moderator: Don McKay Paramax Systems Corporation Based on a manuscript by: Stuart C. Shapiro and Hans Chalupsky Department of Computer Science and Center for Cognitive Science State University of New York at Buffalo 226 Bell Hall Buffalo, New York 14260 February 14, 1992 1 Moderator's Note: This preliminary list of "performatives" for KQML has been compiled and extracted from a more extensive manuscript (Stuart C. Shapiro and Hans Chalupsky, "KQML - Issues and Review", unpublished manuscript, Depart- ment of Computer Science, SUNY at Buffalo, December 1991) which will follow shortly. The intent is to provide a concise list of performatives; hopefully, this list along with the complete manuscript will prove useful. In the process of editing and condensing, I may inadvertently introduce errors and omissions; these are mine. 2 KQML Messages KQML messages are specified as lists written in Common-Lisp syntax. Mes- sages sent across a communication channel are messages of the communica- tion layer (as described in [Fritzson and Finin, 1991, Finin, 1991]) and are called packages. A package is specified as a list whose first element is the atom PACKAGE and whose remaining elements are alternating attribute-value pairs using the Common-Lisp keyword argument format. Possible keyword arguments are: (PACKAGE :FROM - The unique identifier of the sending agent, e.g., its Internet address. :TO - The unique identifier of the receiving agent. :ID - A unique identifier for this message. This should be generated at this layer by the facilitator and is used to refer to the message later. A package ID could be generated by concatenating the value of :FROM and a time stamp. :COMM - Specifies whether or not the communication is to be carried out in a synchronous or asynchronous mode. :CONTENT - a (DCL ...) or (MSG ...) expression. ) Here is an example package: (PACKAGE :FROM "ap001.cs.buffalo.edu" :TO "ap002.prc.unisys.com" :ID "ap001.cs.buffalo.edu 10:15:26.023" :COMM sync :CONTENT (MSG :TYPE query :CONTENT-LANGUANGE interlingua :CONTENT "(color ?X ?Y)")) Content expressions have a similar syntax to packages. They are lists whose first atom indicates the class of the expression. The two classes are messages identified by MSG as the first atom of the list, and declarations with DCL as the first atom. The body of a content expression is a list of attribute- value pairs using the Common-Lisp keyword format. The keywords and their values determine the semantics of a content expression. 3 KQML Performatives 3.1 Content Language The definition of the various KQML performatives described below is based on the following model of a knowledge base: A knowledge base (KB) is a set of sentences in a language L. L can be the object language of the knowledge base, or a set of sentences of another language for which a computable map- ping into L exists. Candidates for languages other than the object language of a KB are, for example, the Interlingua, or, if the object language for a KB are graphs, a linear notation describing these graphs. Since KQML is not assumed to be a superset of the Interlingua, it has to identify sentences of the KB by way of quoted sentences of a language that can be translated into the object language of the KB. This language is called the content language (CL). The languages for the contents of requests and replies can be declared with declare-content-languages: (MSG :TYPE - declare-content-languages :REQUEST-CONTENT-LANGUAGE - Declares what the content language for requests will be. From then on all content language sentences of requests received by the provider should be assumed to be in that language. The language for requests can be interlingua (the default), local to use the object language of the local KB of the provider, or a string that specifies some other content language known by the provider. This request can only be handled successfully if the provider knows how to translate sentences of the request CL into sentences of the object language of its local KB. :REPLY-CONTENT-LANGUAGE - Request what the content language for replies should be. Default is the content language used for requests. This request can only be handled successfully if the provider knows how to translate sentences of the object language of its local KB into sentences of the reply CL. ) 3.2 Discourse Contexts Requests and replies should be relativized to a current discourse context. A discourse context is a subset of the sentences that define the local KB of the provider. The following messages allow to establish a discourse context that con- tains a subset of the sentences of the local KB of the provider.* *With set-discourse-context we can explicitly set the current discourse context to a subset of the sentences that define the local KB: (MSG :TYPE - set-discourse-context :REQUEST-CONTENT-LANGUAGE - Content language to be used for this particular message. Default is the language set by a declare-content-languages message, or interlingua. :CONTENT - Request the current discourse context to be set to the set of all sentences which match the supplied sentence pattern in the local KB of the provider. We will assume that every knowledge representation language will have a notion of a pattern or an open sentence and a matching or unification operation associated with it. If the value of pattern is empty the current discourse context will be set to the empty set, if its value is all the whole KB of the provider will be used (the default). ) add-to-discourse-context allows to add additional sentences to the cur- rent discourse context: (MSG :TYPE - add-to-discourse-context :REQUEST-CONTENT-LANGUAGE - (see above) :CONTENT - Request that all sentences in the local KB of the provider which match the supplied sentence pattern are added to the current discourse context. ) assert allows to add a sentence which is not necessarily a member of the local KB to the current discourse context: (MSG :TYPE - assert :REQUEST-CONTENT-LANGUAGE - (see above) :CONTENT - Request the supplied sentence to be added as an assertion to the current discourse context. ) With remove-from-discourse-context we can remove a set of sentences from the current discourse context: (MSG :TYPE - remove-from-discourse-context :REQUEST-CONTENT-LANGUAGE - (see above) :CONTENT - Request that all sentences in the current discourse context which match the supplied sentence pattern are removed from the current discourse context. ) assign-truth-value allows to change truth values associated with sen- tences in the current discourse context: (MSG :TYPE - assign-truth-value :REQUEST-CONTENT-LANGUAGE - (see above) :TRUTH-VALUE - A CL phrase that describes a valid truth value which should get as- signed to the sentences identified by the :CONTENT slot (what a valid truth value is is defined by the local KB of the provider). Some KBs might not deal with truth values explicitly, but rather implicitly by assuming a sentence to be true if it is an element of the KB (or the current discourse context). A truth value does not necessarily have to be one of true or false, it could be a belief status, an assertion flag, or a numerical value representing some kind of certainty. :CONTENT - Request that all sentences in the current discourse context that match the supplied pattern get assigned the value of the :TRUTH-VALUE slot. ) 3.3 Definitions At the moment we will treat definitions as special cases of assertions which assert sentences that express definitions. However, this approach might be too simplistic and special performatives for definition and un-definition might be necessary. 3.4 Question Answering Once we have established a discourse context we want to ask questions. One type of question asks about the truth value of sentences. If the question is a closed sentence of the CL we want to know whether it has a certain truth value. If the question is an open sentence we are interested in a number of instances of the question that have a certain truth value. Some questions might be easy to answer, others might be very difficult or impossible to answer. To tell the provider how much work it should invest to find an answer we introduce the concept of a worklevel which is basically a specification of how much resources should be spent at the most to answer a question. Depending on the supplied worklevel the provider might choose a particular inference strategy suited for that level. Unless otherwise indicated for all the following messages it is assumed that derived answers will be automatically added to the current discourse context. query-sentence-status handles queries about the truth value (or belief status) of sentences: (MSG :TYPE - query-sentence-status :REQUEST-CONTENT-LANGUAGE - (see above) :REPLY-CONTENT-LANGUAGE - (see above) :WORKLEVEL - Answers to the query in the :CONTENT slot will be found by performing some kind of inference. The total amount of inference (or work) to be invested to find all requested answers is controlled by the value of :WORKLEVEL. Its value can be minimal to request quick but probably incomplete answers, maximal to request the provider to derive answers without any (or maximal) resource bounds, or a number that specifies a maximal number of work units to be invested by the provider. What a work unit is is defined by the local KB of the provider. :HOW-MANY - The provider should report new answers at the earliest possible point after it has derived at least :HOW-MANY new answers since the last report (default is 1). If the number of allotted resources got exhausted all answers derived so far will be reported. This kind of control is important if there is more than one answer, e.g., if the query is an open sentence or a pattern. :REPORT-MODE - Controls what the provider should do after it has reported a number of answers as specified by :HOW-MANY. If the value is suspend the provider will suspend its answering activity until it receives a continuation mes- sage. If the value is continuous the provider will continuously try to find new answers until either no more answers can be found, the allotted resources are exhausted, or it receives a control message that tells it to stop. New answers will be reported whenever at least :HOW-MANY new answers are available. :TRUTH-VALUES - <(phrase, phrase)> A pair of CL phrases that describe valid truth values. All derived answers are required to have a truth value that is within the range of truth values defined by the two supplied values. If the local KB of the provider does not have a notion of an ordering of truth values then the range is just the set of the two values. If the two values are identical this set will be a singleton set. The default is a special value any which indicates that answers of any truth value are acceptable. :CONTENT - This slot contains the actual query whose truth value should be found. If the query is an open sentence or a pattern then all instances of it that have the specified truth value are potential answers. ) Another type of question is topical in nature, i.e., it requests information related to a certain topic, for example, as in the question "tell me (everything you know) about dogs". Here we are not interested in the truth value of particular sentences, rather we want sentences that are related to the topic expressed by the question. Depending on the different levels of expertise of the requester and the provider there might be answers that the requester will not be able to understand. (MSG :TYPE - query-about-topic :REQUEST-CONTENT-LANGUAGE - (see above) :REPLY-CONTENT-LANGUAGE - (see above) :WORKLEVEL - (see above) :HOW-MANY - (see above) :REPORT-MODE - (see above) :TRUTH-VALUES - <(phrase, phrase)> (see above) :CONTENT - A CL phrase denoting some entity about which relevant information should be found. What is considered as relevant is defined by the local KB of the provider. If the supplied value is a pattern then it is to be viewed as something like a predicate that describes a class of entities about which answers should be found. ) The next message handles queries of the kind "what can you infer from X", that is some kind of forward inference. There are two variations to this kind of query: One where the answerer actually assumes the initial assertions as its own, and another one in which these assertions are only hypothetically assumed to answer the question: (MSG :TYPE - assert-and-infer :REQUEST-CONTENT-LANGUAGE - (see above) :REPLY-CONTENT-LANGUAGE - (see above) :WORKLEVEL - (see above) :HOW-MANY - (see above) :REPORT-MODE - (see above) :TRUTH-VALUES - <(phrase, phrase)> (see above) :ASSERTION-MODE - If the value of this slot is actual then the sentences will be added as normal assertions to the current discourse context of the provider. If the value is hypothetical the sentences will be hypothetically assumed in the current discourse context (added to it) until all the answers are reported. Then all these assumptions and the answers depending on them will be removed again. :CONTENT - Answers should be found by starting inference from the sentences supplied in this slot. ) 3.5 Control Messages control messages allow some control of ongoing work performed by the provider. (MSG :TYPE - control :CONTROL-TYPE - If the value of this slot is suspend then at the next possible point the provider should suspend working on the request identified by :REQUEST-ID and allow for a continuation if requested. If the request has already been completed this is a noop. If the value is continue then the provider should finish whatever it is doing right now and then continue to work on the request identified by :REQUEST-ID. If that request has already been finished this is a noop. It cannot be assumed that a previously suspended task will find the exact same state that existed when the interrupt occurred. If the value is stop then at the next possible point the provider should terminate to work on the request identified by :REQUEST-ID. If that request has already been finished this is a noop. :REQUEST-ID - Holds the ID of the package that contained the request to which this message refers. Defaults to the ID of the most recently sent request. ) 3.6 Replies Similar to requests we need a set of performatives for replies. Every reply has to refer to a particular request by the identifier of the package that contained the request. There are basically two kinds of answers: Success/Failure replies tell the requester whether a certain request could get handled successfully or not. Some requests only expect that kind of reply, e.g., the messages that deal with setting up a discourse context. Content replies contain a set of sentences that are answers to queries. An empty set indicates that no answers could be found. Yes/no type queries will get a singleton set as a reply if the answer was yes, an empty set otherwise. The possibility to supply a range of acceptable truth values to a query makes it necessary to indicate the truth value of a particular answer. Instead of associating sets of answers with sets of truth values we will assume that the truth value of an answer is expressed as part of the content language sentence. Success/Failure replies can be sent with the following message: (MSG :TYPE - success-reply :VALUE - :REQUEST-ID - Holds the ID of the package that contained the request to which this message refers. :EXPLANATION - If the value of :VALUE was failure this slot can be used to hold an english sentence that explains to any humans involved why a certain request could not be handled. ) content-reply messages transfer actual answers to queries back to the re- quester. (MSG :TYPE - content-reply :REQUEST-ID - (see above) :REPLY-NUMBER - The different report modes for queries allow for multiple replies to a particular query. The value of this slot indicates the number of this particular reply. Default is 1. :CONTENT - Contains a set of sentences that constitute replies to the query identified by :REQUEST-ID. ) 4 To Do So far the various performatives do not account for ontologies. Updated versions will have to account for them. References [Finin, 1991] Tim Finin. Re: KB interchange standards. E-Mail message to Gio Wiederhold et al. from Nov.26,91, November 1991. [Fritzson and Finin, 1991] Rich Fritzson and Tim Finin. Simple knowledge transfer protocol. Unpublished Draft, October 1991. [Genesereth and Fikes, 1991] Michael R. Genesereth and Richard Fikes. Knowledge Interchange Format. Computer Science Department, Stanford University, Stanford, CA 94305, version 2.2 edition, March 1991. [Neches et al., 1991] Robert Neches, Richard Fikes, Thomas Gruber, Ramesh Patil, Ted Senator, and William R. Swartout. Enabling tech- nology for knowledge sharing. AI Magazine, 12(3), Fall 1991.