Next: The Supply Chain Demonstrator Up: No Title Previous: Supply Chain Terminology

COOL

Syntax

Agents

The syntax of the agent definitions in COOL:

<agent-definition>::=
(def-agent <name>
  :conversation-classes <list of conversation classes>
  :conversations <list of conversations>
  :continuation-rules <list of continuation-rules>
  :continuation-rules-incomplete <T or nil>
  :continuation-control <name of control fn>[default: agent-control]
)

Explanation of the non-terminals:

<name>: is the global name of the defined agent in the COOL environment. Different agents must have different names.
<list of conversation classes>: is the list of names of the conversation classes (see own section below) this agent has. In order for an agent to use a conversation class, it must had been declared in this way. The conversation classes must had been declared before use. Alternatively, to avoid problems of forward referencing, COOL provides a def-associations construct allowing one to declare conversation classes for an agent at the end of the program, after the agent and the conversation classes have been declared (see section ).
<list of conversations>: list of actual conversations of an agent. Must had been defined before use, but to avoid referencing problems the def-associations construct can be used.
<list of continuation-rules>: list of continuation rules for this agent. Same observations as for conversation classes wrt. prior declaration and type use of def-associations.
<T or nil>: flag specifying whether the set of continuation rules of this agent is complete or not. Note that this flag marks the entire set as incomplete, so even if every individual rule is complete the knowledge acquisition interface for continuation rules will still be popped up (under the assumption that new rules may be added or existing ones deleted, see section ).
<name of control fn>: [default: agent-control] This is the name of the pluggable function used as the interpreter of continuation rules. It can be defaulted to a standard interpreter like agent-control, provided with the language implementation.

Conversation Managers

Declaration of a conversation manager having the unique global name <name>:

(def-conversation-manager <name>
  :agents <list of agents>
  :trace-agent <list of traced agents>
  :trace-message <list of traced messages>
  :trace-conv <list of traced connversations>
  :trace-conv-rule <list of traced conversation rules>
  :trace-err-rule <list of traced error recovery rules>
  :trace-cont-rule <list of traced continuation rules>
  :trace-conv-class <list of traced conversation classes>
)

The other arguments describe various tracing options. These options belong more to the particular implementation, but for orientation should always include message tracing which is of major interest. (See Figure for example of message trace).

Conversation Classes

The COOL syntax for defining a conversation class:

(def-conversation-class <name>
  :content-language <language name>
  :speech-act-language <language name>
  :ontology <ontology name>
  :rules <list of conversation rules>
  :rules-incomplete <T or nil>
  :control <conversation rule control fn>[default  
   interactivechoice-control]
  :initial-state <state name>
  :final states <list of state names>
  :variables <list of variables>
  :recovery-rules <list of recovery rule names>
  :recovery-rules-incomplete <T or nil flag>
  :recovery-control <recovery rules control fn>[default 
   recoverycontrol]
  :intent-check <intent check fn>
)

Explanation of the non-terminals:

<name>: is the unique name of the conversation class
<language name>: is the name of the content language or the speech-act-language.The speech-act-language is usually KQML. The content language is at the discretion of the user. If the :content-language is specified, the system will automatically insert it in the KQML messages that are received or sent by the conversation.
<ontology name>: is the ontology used by the conversation. If given, it will be automatically inserted into messages received or sent by any conversation described by this class. This simplifies writing the message patterns for received messages and the output messages.
<list of conversation rules>: list of conversation rule unique names for this conversation class. Rules are given associated with the state for which they apply. To avoid problems of forward referencing def-associations can be used.
<T or nil>: value of a flag that specifies the incomplete status of a rule. Value T means the rule is incomplete, nil means the rule is complete.
<conversation rule control fn>: name of a function used as the interpreter for conversation rules. This is a pluggable interpreter and is defaulted by the system. The default interpreters should be accessible as the value of some parameter that users can set at will.
<state name>: for the initial state, this is its name. This is the state a conversation starts in.
<list of state names>: list of states. For the final states, when the conversation reaches any of these states it will terminate.
<variables>: list of variables of this conversation class. It is not necessary to declare variables in advance, they can be created dynamically, when and if needed. This declaration is useful especially to document the purpose and use of variables in a conversation class. Remember that variable names start with `?' or `??'.
<recovery rules>: list of unique names of the recovery rules used in the conversation.
<recovery rules control fn>: name of pluggable interpreter of recovery rules. Defaulted by various system configurations.
<intent check>: the predicate that will be applied to the value of the :intent slot of an incoming message to determine if this class can handle the incoming message. Can be function name, lambda expression or something else (depending on what the host language allows).

Conversation Rules

The COOL syntax for defining conversation rules:

(def-conversation-rule <name>
  :name <name>
  :comment <comment>
  :current-state <state>
  :received-test <received-test>
  :received <received>
  :received-many <received-many>
  :received-queue-test <received-queue-test>
  :waits-for-test <waits-for-test>
  :such-that <such-that>
  :next-state <next-state>
  :transmit <KQML message>
  :wait-for <wait-for>
  :do-before <do-before>
  :do-after <do-after>
  :do <do>
  :interactive-execution-fn <interactive-execution-fn>
  :incomplete <T or nil>
)

Explanation of the non-terminals:

<name>: is the unique global name of the rule.
<comment>: is any string used to document the rule.
<state>: is a state name.
<received-test>: is a predicate of one argument, the received message. Used to perform procedural checks on the received message.
<received>: is a message pattern against which the actual message will be checked. The use of pattern-matching enables the user to specify declaratively the expected structure of a message in order to apply a rule.
<received-many>: list of patterns against corresponding received messages will be matched. This enables us to match several messages in a rule.
<received-queue-test>: predicate of one argument, the queue or messages for the conversation. Enables checking the entire queue before applying the the rule.
<waits-for-test>: predicate of one argument, the list of terminated conversations this conversation is waiting for. This can be used only if the current conversation is waiting for other conversations to terminate, enabling the conversation to be resumed as soon as the test condition is satisfied.
<such-that>: predicate of any number of arguments applied on a list of bindings produced by matching the patterns in :received or :received-many. A number of standard variables bound by the system are available.
<next-state>: state name, the next state if the rule is applied.
<KQML message>: a KQML message to be transmitted as an effect of rule execution. Anywhere in the KQML message, values of the form (<expr>) are replaced by the value of <expr>. Inside <expr>, free variables are first replaced by their values. This gives a way of performing arbitrary computations to determine any components of the message to be sent.
<wait-for>: list of conversations this conversation is waiting for to terminate. The conversation is put on wait as a consequence of executing the rule.
<do-before>: executable actions to be carried out before transmitting the <KQML message>
<do-after>: executable actions to be carried out after transmitting the <KQML message>
<do>: executable actions to be carried out at an unspecified moment in relation to when the <KQML message> is transmitted
<interactive-execution-fn>: a user written function that has application-specific GUI-s guiding the execution of the action part of the rule.

 The semantics of the conversation rule definition above is as follows:

Ifcurrent state of the conversation is :current-state

		and:received-test is satisfied by the last message

		and last received message matches :received

		and there exists a set of messages in the queue matching

		 		:received-many (order matters)

		and the message queue satisfies :received-queue-test

		and :wait-for-test predicate satisfied by the list of

		 		conversations this conversation is waiting for

		and :such-that predicate satisfied

Then

		go to :next-state

		and transmit the :transmit message

		and put the conversation on wait for the mentioned :wait-for

		 		conversations

		and do the :do-before actions before transmitting the message

		and do the :do-after actions after transmitting the message

		and do the :do actions anytime

		or if interactive-execution-fn exists, execute it

		 		(assume it will carry out all above actions)

The use of predicates and other executable functions in places like :such-that and :do clauses assumes that programmers are allowed to place as free variables any variables of the conversation. These will be replaced with their actual values before evaluating the forms they are in. Moreover, the following variables are always bound by the system and can be used as well: