The semantic model underlying KQML is a simple, uniform context for agents to view each others' capabilities. Each agent appears, on the outside, as if it manages a knowledge base (KB). That is, communication with the agent is with regard to this KB base, e.g., questions about what a KB contains, statements about what a KB contains, requests to add or delete statements from the KB, or requests to use knowledge in the KB to route messages to appropriate other agents.
The implementation of an agent is not necessarily structured as a knowledge base. The implementation may use a simpler database system, or a program using a special datastructure, as long as wrapper code translates that representation into a knowledge-based abstraction for the benefit of other agents. Thus we say that each agent manages a virtual knowledge base (VKB).
When defining performatives, it is useful to classify the statements in a VKB into two categories: beliefs and goals. An agent's beliefs encode information it has about itself and its external environment, including the VKBs of other agents. An agent's goals encode states of its external environment that the agent will act to achieve. Performative definitions make reference to either or both of an agent's goals and beliefs, e.g., that the agent wants another agent to send it a certain class of information. The English-prose performatives in this document make reference to these terms, but this view of the VKB is especially important in the formal semantics of KQML [SEMANTICS].
Agents talk about the contents of theirs and other's VKBs using KQML, but the encoding of statements in VKBs can use a variety of representation languages. That is, the KQML performative tell is used to specify that a particular string is contained in an agent's belief store, but the encoding of that string can be a representation language other than KQML.
The only restrictions on such a representation is that it be sentential, so that expressions using that representation can be viewed as entries in a VKB, and that sentences have an encoding as an ascii string, so that sentences can be embedded in KQML messages. Fortunately, these restrictions appear to hold for the representations of interest to KQML users, including AI languages, database languages, object-oriented representations, and many CAD formats.
finin@cmsc
???
<preformative> ::= (<word> {<whitespace> : <word> <whitespace> <expression>}*)
<expression> ::= <word> | <quotation> | <string> |
(<word> {<whitespace> <expression>}*)
<word> ::= <character><character>*
<character> ::= <alphabetic> | <numeric> | <special>
<special> ::= < | > | = | + | - | * | / | & | ^ | ~ | _ | $ | % | : | . | ! | ?
<quotation> ::= '<expression> | ´<comma-expression>
<comma-expression> ::= <word> | <quotation> | <string> | ,<coma-expression>
(<word> {<whitespace> <comma-expression>}*)
<string> ::= "<stringchar>*" | #<digit><digit>*<ascii>*
<stringchar> ::= \<ascii> | <ascii>-\-<double-quote>
In this section, we define several reserved performatives. That is, they are reserved in the sense that if an implementation uses any of the following performative names in a way that is inconsistent with the following performative definitions, then that implementation is not compliant with KQML.
In this section, we describe performative semantics in English prose. Since English prose is often ambiguous and sometimes self-contradictory, we have developed a framework for formal definition of performatives. A full description appears in a separate paper [Genesereth et al.].
Definitions of new performatives should follow the style of the definitions in this section. That is, a definition should convey the following:
Performatives take parameters identified by keywords. This section defines the meaning of some common performative parameters, by coining their keywords and describing the meaning of the accompanying values. This will facilitate brevity in the performative definitions of performatives, since the following parameters are used heavily.
The following parameters are reserved in the sense that any performative's use of parameters with those keywords must be consistent with the definitions below.
NOTE: The specification of reserved parameter keywords is useful in at least two ways:
- to mandate some degree of uniformity on the semantics of common parameters, and thereby reduce programmer confusion;
- to support some level of understanding, by programs, of performatives with unknown names but with known parameter keywords.
:reply-with <expression> :in-reply-to <expression>
If the <expression> is the word nil or this parameter is absent from the performative, then the sender does not expect a reply. If the <expression> is the word t then the sender expects a reply. Otherwise, the sender expects a reply containing a :in-reply-to parameter with a value identical to <expression>.
:content <expression> :language <word> :ontology <word>
The :content parameter indicates the ``direct object'' (in the linguistic sense) of the performative. For example, if the performative name is tell then the :content will be sentence being told. The <expression> in the :content parameter must be a valid expression in the representation language specified by the :language parameter, or KQML if the :language parameter does not appear. Furthermore, the constants used in the expression must be a subset of those defined by the ontology named by the :ontology parameter, or the standard ontology for the representation language if the :ontology parameter does not appear.
NOTE: Both :language and :ontology are restricted to only take <word>s as values, and therefore complex terms, e.g., denoting unions of ontologies, are not allowed. We do believe that it will be important to support a calculus of ontologies and languages, but we feel that its proper place is in performatives that define new KQML names. This way, only those agents that can process extensional performatives are expected to understand such a calculus.
:force <word>
If the value of this parameter is the word permanent, then the sender guarantees that it will never deny the meaning of the performative. Any other value indicates that the sender may deny the meaning in the future. (This parameter exists to help agents avoid unnecessary truth-maintenance overhead.) The default value is tentative.
finin@cmsc
sender is S and recipient is R.
VKB means virtual knowledge base.
Basic responses performatives:evaluate - S wants R to simplify the sentence
ask-if - S wants to know if the sentence is in R's VKB
ask-about - S wants all relevant sentences in R's VKB
ask-one - S wants one of R's answers to a question
ask-all - S wants all of R's answers to a question
Multi-response query performatives:reply - communicates an expected reply
sorry - S cannot provide a more informative reply
error - S cannot understand the request
stream-about - multiple response version of ask-about
stream-all - multiple response version of ask-all
eos - "end of stream"
Basic informative performatives:
tell - the sentence in S's VKB
achieve - S wants R to make something true of their environment
deny - the embedded performative does not apply to S (anymore)
untell - the sentence is not in S's VKB.
unachieve -
standby - S want s R to be ready to respond to a performative
ready - S is ready to respond to R's previously mentioned performative
next - S wants R's next response to a previously mentioned performative
rest - S wants R's remaining responses to a previously mentioned performative
discard - S will not want R's remaining responses to a previous performative
generator - same as a standby for stream-all
Capability-definition performatives:
advertise - S is particularly suited to processing a performative
subscribe - S wants updates to R's response to a performative
monitor - S wants updates to R's response to a stream-all
register - S can deliver performatives to some named agent
unregister - a deny of a register
forward - S wants R to route a performative
broadcast - S wants R to send a performative over all connections
pipe -
break -
transport-address -
broker-one - S wants R to
process the request with the help of a specific broker
broker-all - S wants R to
process the request with the help of all suited brokers
recommend-one - S wants R to
suggest an agent suited to perform a specific task
recommend-all - S wants R to
suggest all the agents suited to perform a specific task
recruit-one - S wants R to
forward the task to a specific suited agent
recruit-all - S wants R to
forward the task to all suited agents
insert - S wants R to add a fact to its VKB
delete - S wants R to delete a fact from its VKB that match creteria
delete-one - S wants R to delete one fact from its VKB that match creteria
delete-all - S wants R to delete all facts from its VKB that match creteria
[fonte]
Exemplo 1O agente A pergunta algo ao agente B e recebe uma simples resposta.
O agente A envia ao agente B a seguinte performativa:
(evaluate :language KIF :ontology motors :reply-with q1 :content (val (torque motor1) (sim-time 5)) )
O agente B responde com:
(reply :language KIF :ontology motors :in-reply-to q1 :content (scalar 12 kgf) )
Exemplo 2
O agente A pergunta ao agente B tudo acerca de 'motor1'. O agente B responde com uma sequência de respostas terminadas por uma mensagem de finalização.
O agente A envia a seguinte performativa ao agente B:
(stream-about :language KIF :ontology motors :reply-with q1 :content motor1 )
O agente B responde com uma série de performativas:
(tell :language KIF :ontology motors :in-reply-to q1 :content (= (val (torque motor1) (sim-time 5) (scalar 12 kgf))) )(tell :language KIF :ontology structures :in-reply-to q1 :content (fastens frame12 motor1) )(eos :in-reply-to q1 )
Examplo 3
O agente A diz ao agente B para tentar atingir um estado, em que o 'torque" de 'motor1' deve ter um valor em particular.
O agente A envia ao agente B a seguinte performativa:
(achieve :language KIF :ontology motors :reply-with q1 :content (= (val (torque motor1) (sim-time 5)) (scalar 2 kgf))) )
Depois de atingir o objectivo, o agente B deve enviar ao agente A a seguinte performativa:
(tell :language KIF :ontology motors :content (== (val (torque motor1) (sim-time 5)) (scalar 2 kgf))) )
Exemplo 4
O agente A pede a B para se preparar para gerar uma sequência de toda a informação àcerca de 'motor1'. O agente B responde que está pronto e retorna um identificador para que o agente A use para requisitar cada um dos factos sobre 'motor1'. O agente A pede um conjunto de factos e termina, indicando que não necessita de mais.
O agente A envia ao agente B a seguinte performativa:
(standby :language KQML :ontology K10 :reply-with g1 :content (stream-about :language KIF :ontology motors :reply-with q3 :content motor1 ) )
O agente B responde com:
(ready :reply-with 2FOB :in-reply-to g1 )
O agente A continua a conversação, enviando:
(next :in-reply-to 2FOB )
Ao que o agente B responde com:
(tell :language KIF :ontology motors :in-reply-to q3 :content (== (val (torque motor1) (sim-time 5)) (scalar kgf))) )
e continua... até que o agente A envia a B:
(discard :in-reply-to 2FOB )
[fonte]
Última actualização: 02-05-2005