Ciarán O'Leary
coleary@maths.kst.dit.ie
http://comp.dit.ie/coleary
Dublin City University
School of Computer Applications
Glasnevin
Dublin 9
Dublin Institute of Technology
School of Computing
Kevin St.
Dublin 8
Ireland
World Wide Mind Research Group
Dublin City University
http://w2mind.org
info@w2mind.org
This paper will present the Artificial Intelligence Markup Language (AIML), the language, or protocol used for communication by the various servers and clients operating within the World Wide Mind (WWM). The WWM is an architecture which enables AI researchers make their work publicly available, in order that their work can by used by others. The WWM architecture consists of various minds and worlds, each hosted on a server on the world wide web. Interaction with the servers takes place over HTTP, where simple CGI requests can be sent and interpreted. It is not the intention of this paper to discuss the architecture of the WWM, rather, this paper provides a full discussion of the format of those messages, or requests sent to the servers over HTTP. The full protocol contains in excess of 30 requests which can be sent to the public interface of a world or mind server, each one instructing the server to perform some operation, or provide some information.
Keywords: Artificial Intelligence, AIML, WWM, XML
Web servers can host programs as well as information. These programs receive input from web clients over the Hypertext Transfer Protocol(HTTP), through the Common Gateway Interface (CGI). The World Wide Mind architecture builds on top of this architecture. AI researchers build World and Mind servers. These servers are programs. They are made publicly available by being placed on web servers, thus allowing interaction with them over HTTP and through CGI. Interaction with these WWM servers comes from clients. Clients instruct these servers to decide upon actions (if the server is a mind) or take actions (if it is a world). In order to do this clients need to find out information from the servers, for example, the client will need to know what parameters a server needs before it can be asked to start a run, and the client will also need a means to find out what the current state of a world server is.
The full architecture of the WWM therefore consists of three entities, clients, mind servers and world servers. There are several different types of each of these entities, as outlined briefly below, and in more detail in [1].
Minds run independently of worlds and vice versa. They need not be aware of eachother, it is the responsibility of the client to supply them with the information they require, information that the client gets from querying other servers. A sample run in the WWM would take the following form. A client application queries a world server for its current state. This state can then be provided to a mind server, which will interpret it and then decide upon an action which should be performed in the world. The client will be informed of this action. The client will then instruct the world to take the action suggested by the mind, thus providing a new state in the world. This new state would be provided to the mind server, which would decide upon the next action to be taken in the world, and so on.
This paper will not discuss the WWM as a concept, this has been done in [1] and [2]. It will however outline in full the protocol used by the various entities in the WWM to communicate with eachother in order to get the information they require, and instruct servers to perform the operations they require. This protocol is the Artifical Intelligence Markup Language (AIML).
The paper will proceed as follows. Section 2 introduces the AIML. Section 3 discusses the general format for an AIML request and response, and the different classes of requests and responses in the AIML. This builds on the previous implementation of AIML as outlined in [3]. Section 4 discusses the general requests and responses that can be sent to any server, and the significance of each of these requests. Section 5 discusses world servers and the requests they require. These requests are implementations of the concepts outlined in [1]. Section 6 introduces the different types of mind servers, and the requests required for each of these. We then conclude with a discusion of the AIML and WWM.
Although it is not our intention to discuss the WWM in details, through the definition of the AIML we are defining the operation of the WWM architecture. The protocol is not easily distinguihable from the overall concept, in much the same way as HTTP and the World Wide Web can not be discussed independently of eachother.
AIML is a request reply protocol. A single request receives a single response. It is up to the clients or servers to maintain state, such as the current state of the world, or the last action taken. This is not the function of the protocol. What we require is a set of messages that can be sent to servers. These messages are going to be parsed by the server, and must be interpreted precisely the same across the full set of servers. For example, as new run request must mean exactly the same to World Server 1 as it does to World Server 2.
A detailed description of AIML requests and responses is outlined here. This builds on the previous specification of AIML given in [3]. We call this current version of AIML, AIML version 1.1.
AIML messages take the form of tags identical to XML tags. Tags can exist in pairs, in which case an opening tag
<request>
must be accompanied at some further point with a closing tag
</request>
All tags and text that occurs in between the two tags are considered child tags.
Tags can also exist in the standalone form we are familiar with from XML.
<param/>
Standalone tags must end with a forward slash '/'. All opening and standalone tags can take any number of attributes, which consist of x=y pairs. All values on the right hand side of a pair must be enclosed within quotes, as shown below.
<param name="qtemp" value="10"/>
All AIML messages must begin with an AIML opening tag which includes an attribute called 'version', indicating the version of AIML to which the message complies. For all messages complying with this document the version will be '1.1'. The last line of an AIML message must contain an AIML closing tag.
<aiml version="1.1">
<request ...>
<param .../>
<argument .../>
</request>
</aiml>
Between the opening and closing tags the message will contain ONLY one of the following
Each of these message types will include the following attributes
The type attrbite provides information on which type of message is being sent, e.g. type=NewRun sent to a server indicates that the server should stare a new run. type=GetAction sent from a server indicates that this response is being sent as a response to a request of type type=GetAction.
The runid attribute provides the runid for this particular client with the server. This is used in a manner similar to a cookie in HTTP, to maintain state across multiple requests.
A request message is sent from a client to a server with optional parameters, data and arguments to indicate to the server that some operation should be executed.
An information message is sent to the server with no parameters or arguments, simply asking the server for some information, such as the current score, or the details of the server (name, dosplay url etc.). Such requests can be piggybacked on other requests to lower the number of requests being sent, see below.
A response message is sent following receipt of a request or information request to confirm that an action was taken or provide the desired information. If anything goes wrong an error message is send. The error codes are provided below.
The following are the only tags which are specified by AIML.
Additional tags may be defined by a server as part of their data. These need not be understood by the client, but must be understandable to the other servers which operate with it.
A param tag is a standalone tag which contains a name and a value. It is used for passing a parameter as part of a message. The parameters allowed with each message are specified as part of the protocol, as shown in the various sections below.
<param name="author" value="Ciaran O'Leary"/>
A date tag is a special type of parameter which contains a date. This requires its own tag since it can exist in multiple formats.
The 'string' format, shown below gives the date as a long string value. It must conform to this format so that the client can understand it.
<date name="lastmodified" format="string" value="Fri Jan 04 17:29:23 GMT 2002"/>
The 'short' format contains a dateval and a timeval.
<date name="datecreated" format="short" dateval="04/01/02" timeval="17:29:23"/>
Arguments are parameters whose format is defined by the server. The server can indicate to the client what arguments it needs to accompany its messages. The name and type of the arguments are not supplied as part of the protocol, since they vary from server to server. For example, a certain server may need to be supplied with an integer representing the size of the world it is to create, so it informs the client that it expects an argument called 'size', of type 'Integer' with a default value of '100'. The server informs the client of this in the response to the 'GetStructure' innformation request. The various arguments it expects are included as children to an <arguments> tag, each with its own <argument> tag. The client will then supply the required values within an <argument> tag with name, value pairs.
<arguments request="GetAction">
<argument name="size" type="integer" default="100"/>
</arguments>
<argument name="size" value="200"/>
The different 'type' values are necessary so that the client can know what to ask the user to enter. The 'default' attribute can be supplied with any type. The multiple attribute can also be supplied with any type. If there is a value associated with it, as below in the 'url' example then this is the number of tags of that type expected in a request. If there is no value associated with it, but it is not omitted, then any number of tags of that name can be supplied in a request.
The different types are as follows: (Examples are server to client)
A description tag can contain HTML or plain text, and is simply included to allow the client display information for the user. It has a 'type' attribute which can take the value 'text/plain' or 'text/html'. If it is HTML then it may include an extra attribute called imagedir, indicating the location of any images included in the HTML.
<description type="text/html" imagedir="http://host:port/imagedir">
<html><body>This is <b>some</b> Text <img src="img.jpg"></body></html>
</description>
The data tag has an attribute called 'name' which can take values a, ak, x, y, c. The data represents the state of the world (either desired or actual) if x, y, or c. It represents an action which could take place in the world if the name is a or ak.
The text between the opening and closing tags is not specified by the protocol, it can be anything. It is assumed that the server will understand it.
<data name="x">
(1,2,3,4)
</data>
All responses will be either Success or Error type messages. However when we require extra information this information is piggybacked on a success message. This means that it is included, in a specified format in a success message. It is possible to piggyback a
Information requests carry no parameters or arguments and are idempotent. When sending a get action request we may wish to also send a request for the current score. One way of doing this would be to send two independent requests. What we are proposing here is a way of wrapping the information request inside the main request, using a second <piggyback> tag.
Any information request can be piggybacked on any other type of request, information or otherwise. Responses are piggybacked on the main response in precisely the same way. Any number of information requests can be piggybacked on a request, but this facility should be used sensibly and not abused.
<aiml version="1.1">
<request runid="1234" type="TakeAction">
<data name="a">
6,8
</data>
<piggyback type="GetScore"/>
</request>
</aiml>
<aiml version="1.1">
<response runid="1234" type="Success">
<param name="id" value="0001"/>
<param name="alttext" value="Action Completed"/>
<piggyback type="TakeAction">
<data name="y">
(1,2,3,4)
</data>
</piggyback>
<piggyback type="GetScore">
<param name="score" value="10"/>
</piggyback>
</response>
</aiml>
Comment tags can be included but are not advised, as some servers may not check for them. The format for a comment is
<!--
Comment here
-->
Some servers may check for comment to aid with understanding.
General messages are the requests and response messages that can be sent to any type of server, world or mind. These include generic requests such as start run, end run, get information etc. Generic response types include success messages for correctly executed commands, and error messages with accompanying error codes.
The following are the general server messages included in AIML.
All request messages will be responsed to with wither a Success or an Error message, indicating that the operation took place correctly, in part or not at all. If the request needed some extra information returned with it then this information would be piggybacked on the success message. For example, the GetStructure request would be responded to with a success message if it was possible to get the information. The information itself that was requested would be stored between <piggyback> tags in the success response. If information was required that would not naturally be piggybacked on the response (for example, a TakeAction request simply returns a success message, but the client may wish to know the new state) then the request (the TakeAction request) should include a piggyback request, indicating that the result of a GetState request should be piggybacked on the response.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Run Started"/>
</response>
</aiml>
A success message indicates the the requested operation was performed successfully. It includes the runid of the current run, alongside the following parameters
The status codes for the success messages, first outlined in [3] are repeated in modified form here.
| Code | Description |
| 0001 0002 0003 0004 0005 0006 |
Operation performed successfully
Parameters missing, defaults used, operation performed Some parameters not understood. Ignored. Operation performed. Arguments missing, defaults used, operation performed Some arguments not understood. Ignored. Operation performed. Some piggybacked requests ignored |
<aiml version="1.1">
<response type="Error">
<param name="id" value="1001"/>
<param name="alttext" value="Server on Fire"/>
</response>
</aiml>
An error message indicates that the requested operation could not be performed. It includes the runid of the current run, except in the case where this would not be possible, for example for a NewRun request, or for any information requests taking place prior to the start of a run. The parameters included in this response are as follows.
| Code | Description |
| 1001 1002 2001 2002 3001 3002 3003 3004 3005 |
Server error
|
Further success and error codes may be provided below to account for possible states in world and mind servers. The codes given above are the definitive list however.
<aiml version="1.1">
<information type="GetDetails">
</information>
</aiml>
This information request asks the server to send back information regarding the server, such as who the author it, what title it has, when was it last modified, as provide a general description. This information is consistent accross runs, and as such does not require a runid. It does not even require that there is a current run, it is simply providing information about the server.
The response expected for this is shown below.
The following are the parameters expected back from this request
<aiml version="1.1">
<response type="Success">
<param name="id" value="0001"/>
<param name="alttext" value="Information Provided"/>
<piggyback type="GetDetails">
<param name="title" value="Ciaran O'Leary's Server">
<param name="author" value="Ciaran O'Leary"/>
<date name="datecreated" format="string" value="Fri Jan
04 17:29:23 GMT 2002"/>
<date name="lastmodified" format="string" value="Fri Jan 04 17:29:23 GMT 2002"/>
<description type="text/html" imagedir="http://host/d">
This is a <i>world</i> server. It uses algorithm 'alg' to produce a state 'y'.
</description>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<information type="GetStructure">
</information>
</aiml>
This information request gets the public interface of the server, in other words the information that the client will need to interact with the world. For example, it needs to know if the server has a display url associate with it, what type of server it is etc. It also needs to know what arguments it expects for each of its requests (see above for explanation of arguments).
Once again it is a general information request that can be sent to find out information about a server before a run has started, so that the client can find out about it. For example when a new run is beginning, the server may need to know what child servers it is to use (for example for an Action Selection Mind).
The following are the parameters expected from the response.
<aiml version="1.1">
<response type="Success">
<param name="id" value="0001"/>
<param name="alttext" value="Structure Provided"/>
<piggyback type="GetStructure">
<param name="display" value="true|false"/>
<param name="servertype" value="world|mind"/>
<param name="type"
value="simple|worldw|mindl|mindi|mindas"/>
<!-- if it is a worldw type world, then we can specify sub-worlds -->
<arguments request="NewRun">
<description type="text/html"
imagedir="http://host/im">
This request needs to know if the world is synchrononus. This means that....
</description>
<argument name=synchronous type=boolean default=true/>
<argument name=shared type=boolean default=false/>
<argument name=join type=string/>
<argument name=size type=string/>
<argument name=initialstate type=data/>
<argument name=subworld type=url multiple=2/>
<argument name=asalgorithm type=list values="alg1,alg2,alg3"/>
</arguments>
<arguments request="GetAction">
<argument name=qtemperature type=string/>
</arguments>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="NewRun">
<param name="client" value="http://host:port/process"/>
</request>
</aiml>
A new run request tells a server to begin a new run. The only parameter it expects is the client URL. In the majority of cases it will also expect several arguments, as specfiied in the response to the GetStructure information request.
The response to this will be either a success or error message. The success message will include the runid for this run, if a run has been started.
<aiml version="1.1">
<request type="NoOperation" runid="1234">
</request>
</aiml>
A 'ping' type operation to check that the server is still running. Once again will return a success message if successful.
<aiml version="1.1">
<information type="GetDisplayURL" runid="1234">
</information>
</aiml>
A simple information request to find out the display URL for the current run. The existance of such a URL is indicated in the response to the GetStructure information request. This request would typically be piggybacked on a NewRun request.
The response contains a single parameter indicating what the display url is.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Display URL Provided"/>
<piggyback type="GetDisplayURL">
<param name="url" value="http://host:port/process"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="Reset" runid="1234">
</request>
</aiml>
Reset the server, so that it 'forgets' what it has learned, or simply initialises back to its initial state. The response would be success for error.
<aiml version="1.1">
<request type="ResetScore" runid="1234">
</request>
</aiml>
Reset the score back to its default value. Once again the response will be success or error
<aiml version="1.1">
<information type="GetScore" runid="1234">
</information>
</aiml>
Information type request to get the score in the server. Would typically be piggybacked on a TakeAction request. The response given below returns the score in a single parameter.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Display URL Provided"/>
<piggyback type="GetScore">
<param name="score" value="100"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="EndRun" runid="1234">
</request>
</aiml>
End the current run. Will return a success or error response.
A world server is an implementation of an environment containing a body, for which a mind chooses an action. For a further discussion of this see [1]. The requests given below will ONLY be understood by world servers. WorldW servers are world servers which use sub worlds. These servers exhibit precisely the same interface as a standard world server. They may require an extra argument providing the URL of the other world, but this is supported through the GetStructure request above. Any other arguments they may require for other requests will also be specified through the GetStructure response.
The following are the two requests that MUST be supported by the interface to a world server
<aiml version="1.1">
<information type="GetState" runid="1234">
</information>
</aiml>
A GetState information request is an idempotent operation asking the server for its current state. It could be piggybacked on other requests such as TakeAction.
It returns a single parameter, the state of the world represented as a text string understandable by the world and mind but not specified by the protocol, contained between the opening and closing data tags. The name attribute is set to 'x' for this response unless the message is piggybacked on a TakeAction request(in which case it will be set to 'y', indicating that it represents a new state).
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="State Provided"/>
<piggyback type="GetState">
<data name="x">
(1,2,3,4)
<!--
This data represents x, the state of the
world
-->
</data>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="TakeAction" runid="1234">
<data name="a">
4
<!--
This data represents a, the action
suggested by the mind
-->
</data>
</request>
</aiml>
This request provides an action to a world server which must be performed in the world. The action is represented in a form understandable by the world and mind but not controlled by the protocol. It is stored between opening and closing <data> tags, with the name set to 'a' indicating that it represents an action.
The response to a TakeAction request is a Success message. The state of the world will often be piggybacked on this reponse if this was requested in the request. Note: This is a major departure from AIML v1.0, where the state was always returned as part of the TakeAction response.
There are several types of minds. A standard mind will accept requests to generate an action and return the result. However, the outline for the WWM indicates that we should be able to handle several different types of mind including those that can learn, those that can make action selection decisions between the selected actions of other minds etc. For a fuller discussion of this see [1]. The types of mind supported by AIML v1.1 are as follows:
MindM servers are mind servers which use sub minds. These servers exhibit precisely the same interface as a standard mind server. They may require an extra argument providing the URL of the other mind, but this is supported through the GetStructure request above. Any other arguments they may require for other requests will also be specified through the GetStructure response.
Below we outline the requests that MUST be understood by the interfaces to each of these types of mind, beginning with the requests that MUST be understood by ALL mins servers.
All minds must understand the following requests:
<aiml version="1.1">
<request type="GetAction" runid="1234">
<data name="x">
(1,2,3,4)
<!--
This data represents x, the
current state of the world
-->
</data>
</request>
</aiml>
Having got the state of the world from the world server, the client asks the mind server to get an action. The parameter passed is 'x' the state of the world, represented as a text string understandable by both the world and mind, but not controled by the protocol. The state is put between the opening and cloing <data> tags. The name attribute is set to 'x' indicating that it represents the state prior to an action.
The response contains the action 'a', once again stored between <data> tags, and 'q', the predicted score for this action, as opposed to the result of a GetScore request, which returns the actual score.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="State Provided"/>
<piggyback type="GetAction">
<data name="a">
4
<!--
This data represents a, the action
suggested by the mind
-->
</data>
<param name="q" value="10"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="TellState" runid="1234">
<data name="y">
(1,2,3,4)
<!--
This data represents y, the
state of the world resulting from the
execution of a.
-->
</data>
<param name="score" value="10"/>
</request>
</aiml>
Inform the mind of the state in the world as a result of the action it suggested, and the score that that action achieved.
The response is a standard success message, with extra optional piggybacked information indicating the score 'q' the mind attributes to the action and resulting state. The mind may use a different scoring system to the world.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Score calculated"/>
<piggyback type="TellAction">
<param name="q" value="10"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="ReadySuggestAction" runid="1234">
<data>
(1,2,3,4)
<!--
This data represents x, the
current state of the world
-->
</data>
</request>
</aiml>
Inquire of the mind server if it ready to suggest an action in the current state. The response will be success, or an error with status code 3005 (Cannot perform operation in current state).
Learning minds, in addition to understanding the general requests MUST also be able to understand the following requests:
<aiml version="1.1">
<information type="GetQTemperature" runid="1234">
</information>
</aiml>
Idempotent, information type request that could be piggybacked on other requests, simply asking for the current q temperature, the rate at which exploration varies with exploitation.
The response is a success with the qtemperature piggybacked.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Temperature Returned"/>
<piggyback type="GetQTemperature">
<param name="qtemp" value="99"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="SetQTemperature" runid="1234">
<param name="runlength" value="10"/>
<param name="qtemp" value="99"/>
</request>
</aiml>
This request takes two parameters, in order to set the qtemperature for the current run.
The response will be success, or an error with status code 3005 (Cannot perform operation in current state).
<aiml version="1.1">
<request type="ResetQTemperature" runid="1234">
<param name="runlength" value="10"/>
</request>
</aiml>
This request will reset the q-temperature to something sensible. It takes a single parameter.
The response will be success, or an error with status code 3005 (Cannot perform operation in current state).
All minds that are aware of the fact that they are not alone in the body, MUST also understand the following requests:
<aiml version="1.1">
<information type="GetMindStrength" runid="1234">
</information>
</aiml>
Idempotent, information type request that could be piggybacked on other requests, simply asking for the current mind strength, the strength this mind can use to compete with other minds in the same body.
The response is a success with the mind strength piggybacked.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Mind Strength Returned"/>
<piggyback type="GetMindStrength">
<param name="mindstrength" value="99"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="SetMindStrength" runid="1234">
<param name="mindstrength" value="10"/>
</request>
</aiml>
Set the strength of the mind to the value passed in. The response will be success, or an error with status code 3005 (Cannot perform operation in current state).
<aiml version="1.1">
<information type="GetWTemperature" runid="1234">
</information>
</aiml>
Idempotent, information type request that could be piggybacked on other requests, simply asking for the current w temperature.
The response is a success with the wtemperature piggybacked.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Temperature Returned"/>
<piggyback type="GetWTemperature">
<param name="wtemp" value="99"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="SetWTemperature" runid="1234">
<param name="runlength" value="10"/>
<param name="wtemp" value="99"/>
</request>
</aiml>
This request takes two parameters, in order to set the qtemperature for the current run.
The response will be success, or an error with status code 3005 (Cannot perform operation in current state).
<aiml version="1.1">
<request type="ResetWTemperature" runid="1234">
<param name="runlength" value="10"/>
</request>
</aiml>
This request will reset the w-temperature to something sensible. It takes a single parameter.
The response will be success, or an error with status code 3005 (Cannot perform operation in current state).
<aiml version="1.1">
<request type="SuggestAction" runid="1234">
<data name="x">
(1,2,3,4)
<!--
This represents x, the current state of the world
-->
</data>
<argument name="qtemp" value="10"/>
<argument name="wtemp" value="10"/>
</request>
</aiml>
Given a world state, suggest an action to be performed in this world. The state of the world is submitted as part of the request. The server may require other parameters, and these can be submitted as arguments, once the server informs the client that it expects these arguments. It can do this through the GetStructure response. In the example above the server expects two arguments, representing the qtemperature and wtemperature for this particular action. It would need to amend its GetStructure request to include the following
<arguments request="SuggestAction">
<argument name=qtemperature type=string/>
<argument name=wtemperature type=string/>
</arguments>
This type of server may also need to augment its GetStructure response to reflect the need for these values for its GetAction request.
The response given below includes the following parameters:
Only one of the first two parameters needs to be supplied.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Suggested Action Included"/>
<piggyback type="SuggestAction">
<data>
4
<!--
This represents a, the action
suggested by the mind
-->
</data>
<param name="mindserver" value="http://host:port/process"/>
<param name="q" value="10"/>
<param name="w" value="10"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="GetValuesForAction" runid="1234">
<data name="x">
(1,2,3,4)
<!--
This represents x, the current state of the world
-->
</data>
<data name="a">
4
<!--
This represents a, a suggested action for the world
-->
</data>
<argument name="qtemp" value="10"/>
<argument name="wtemp" value="10"/>
</request>
</aiml>
Given an initial state, and an action, return the q and w values measuring how good an action it is. The arguments would vary between servers and would need, once again, to be specified in the 'GetStructure' response, as is the case with the previous request. The parameters it takes are
The response includes the two values that were requested
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Values Calculated"/>
<piggyback type="GetValuesForAction">
<param name="q" value="10"/>
<param name="w" value="10"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="InformAboutWinner" runid="1234">
<param name="obeyed" value="true|false"/>
<param name="w" value="10"/>
<param name="winner" value="http://host:port/process"/>
<data name="ak">
4
<!--
This represents the winning action...
May not be understood
-->
</data>
<data name="y">
(5,6,7,8)
<!--
This represents the state that this winning
action led to
-->
</data>
<param name="score" value="10"/>
</request>
</aiml>
Inform the mind about who won the competition to be executed. The parameters passed are as follows:
obeyed: Boolean, states whether the action suggested by the mind was obeyed
All these parameters are optional, the client can inform the mind of as much or as little as it chooses.
NOTE: Client here can refer to another 'parent' mind which is calling this mind.
The response will include (optionally) the following parameters:
<aiml version="1.1">
<responsetype="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="INformed about winner, calculated values"/>
<piggyback type="InformAboutWinner">
<param name="q" value="10"/>
<param name="w" value="10"/>
</piggyback>
</response>
</aiml>
Feudal minds, minds that can be instructed to find a certain state, must also understand the following requests.
<aiml version="1.1">
<request type="GetValuesForAction" runid="1234">
<data name="x">
(1,2,3,4)
<!--
This represents x, the current state of the world
-->
</data>
<data name="c">
(5,6,7,8)
<!--
This represents c, the desired state for the world
-->
</data>
<data name="a">
4
<!--
This represents a, a suggested action for the world
-->
</data>
<argument name="qtemp" value="10"/>
<argument name="wtemp" value="10"/>
</request>
</aiml>
This request is the same as the GetValuesForAction request for a MindI. The only new parameter is the data(c), the desired state.
Given an initial state, an action, and a desired state return the q and w values measuring how good an action it is for reaching the state. The arguments would vary between servers and would need, once again, to be specified in the 'GetStructure' response, as is the case with the previous request. The parameters it takes are
The response includes the two values that were requested
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Values Calculated"/>
<piggyback type="GetValuesForAction">
<param name="q" value="10"/>
<param name="w" value="10"/>
</piggyback>
</response>
</aiml>
<aiml version="1.1">
<request type="GetToState" runid="1234">
<data name="x">
(1,2,3,4)
<!--
This is the current state of the world
-->
</data>
<data name="c">
(5,6,7,8)
<!--
This is the desired state of the world
-->
</data>
<argument name="qtemp" value="10"/>
<argument name="wtemp" value="10"/>
</request>
</aiml>
Given an initial state, x, and a desired state, c, choose an action to get to that state. Once again, additional argument may be needed by the server and are specified by the 'GetStructure' response. The parameters required are:
The response will provide an action OR a mind server to call, possibly accompanied by q and w.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Action Selected"/>
<piggyback type="GetToState">
<data>
4
<!--
This represents a, the action
suggested by the mind
-->
</data>
<param name="mindserver" value="http://host:port/process"/>
<param name="q" value="10"/>
<param name="w" value="10"/>
</piggyback>
</response>
</aiml>
Action Selection Minds make choices about which minds to obey given a conflict. Any such mind must be able to understand the following requests:
The NewRun request for an Action Selection mind may take a number of arguments, such as the algorithm to be used for action selection, or the URLs of the minds that are to compete. Once again, the requirement for these arguments would be informed to the client in the GetStructure response.
<aiml version="1.1">
<request type="AddMind" runid="1234">
<param name="mindurl" value="http://host:port/process"/>
</request>
</aiml>
Add a new mind, located at the URL provided, to the action selection algorithm. The response will be success, or an error with status code 3005 (Cannot perform operation in current state).
<aiml version="1.1">
<request type="RemoveMind" runid="1234">
<param name="mindurl" value="http://host:port/process"/>
</request>
</aiml>
Remove the mind, located at the URL provided, from the action selection algorithm. The response will be success, or an error with status code 3005 (Cannot perform operation in current state).
A sample run in the WWM could include a massive society of mind, incorporating many minds all communicating using the protocol outlined in this document. The number of requests and responses generated in such a society would quickly grow to too large a size to be included in this paper, but we do provide below a sample run involving a single, grid-like world and a mind. This is purely to illustrate the siumplest kind of run, we accept that the majority of runs would be a good deal more complex than this.
The sample run will include the following entities:
1. User informs client of URL of mind server it wishes to use.
2. Client generates request to find out general information about mind server, and sends it to the server.
<aiml version="1.1">
<information type="GetDetails">
</information>
</aiml>
3. Client receives the following response and prints details out to inform user of what mind server they have chosen.
<aiml version="1.1">
<response type="Success">
<param name="id" value="0001"/>
<param name="alttext" value="Information Provided"/>
<piggyback type="GetDetails">
<param name="title" value="Ciaran O'Leary's Mind Server">
<param name="author" value="Ciaran O'Leary"/>
<date name="datecreated" format="string" value="Fri Jan 04 17:29:23 GMT 2002"/>
<date name="lastmodified" format="string" value="Fri Jan 04 17:29:23 GMT 2002"/>
<description type="text/html" imagedir="http://comp.dit.ie/images">
A simple grid mind
server. <img src=descripmind.jpg>
</description>
</piggyback>
</response>
</aiml>
4. User confirms that this is the mind they want.
5. Server generates the following request
<aiml version="1.1">
<information type="GetStructure">
</information>
</aiml>
6. Client receives the following response.
<aiml version="1.1">
<response type="Success">
<param name="id" value="0001"/>
<param name="alttext" value="Structure Provided"/>
<piggyback type="GetStructure">
<param name="display" value="true"/>
<param name="servertype" value="mind"/>
<param name="type" value="simple"/>
</piggyback>
</response>
</aiml>
7. Client generated following NewRun request and piggybacks a request for the display URL on it.
<aiml version="1.1">
<request type="NewRun">
<param name="client" value="http://cs12.kst.dit.ie"/>
<piggyback type="GetDisplayURL"/>
</request>
</aiml>
8. Client receives the following response:
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Display URL Provided"/>
<piggyback type="GetDisplayURL">
<param name="url" value="http://comp.dit.ie/mind/display/1234"/>
</piggyback>
</response>
</aiml>
From this the client finds out the run id for the mind. It also finds out the display URL for the mind from the piggybacked response. A new run has started in the mind for the client.
9. User informs client of URL of world server it wishes to use.
10. Client generates request to find out general information about world server, and sends it to the server.
<aiml version="1.1">
<information type="GetDetails">
</information>
</aiml>
11. Client receives the following response and prints details out to inform user of what mind server they have chosen.
<aiml version="1.1">
<response type="Success">
<param name="id" value="0001"/>
<param name="alttext" value="Information Provided"/>
<piggyback type="GetDetails">
<param name="title" value="Ciaran O'Leary's World Server">
<param name="author" value="Ciaran O'Leary"/>
<date name="datecreated" format="string" value="Fri Jan 04 17:29:23 GMT 2002"/>
<date name="lastmodified" format="string" value="Fri Jan 04 17:29:23 GMT 2002"/>
<description type="text/html" imagedir="http://comp.dit.ie/images">
A simple grid world server. One predator, one nest, no food.
<img srg=descripworld.jpg>
</description>
</piggyback>
</response>
</aiml>
12. User confirms that this is the mind they want.
13. Server generates the following request
<aiml version="1.1">
<information type="GetStructure">
</information>
</aiml>
14. Client receives the following response and gets user to enter size argument for a NewRun.
<aiml version="1.1">
<response type="Success">
<param name="id" value="0001"/>
<param name="alttext" value="Structure Provided"/>
<piggyback type="GetStructure">
<param name="display" value="true"/>
<param name="servertype" value="mind"/>
<param name="type" value="simple"/>
<arguments request="NewRun">
<description type="text/html" imagedir="http://host/im">
Enter size of world in variable 'size' of type integer
</description>
<argument name="size" type="integer"/>
</arguments>
</piggyback>
</response>
</aiml>
15. Client generates following NewRun request and piggybacks a request for the display URL on it.
<aiml version="1.1">
<request type="NewRun">
<param name="client" value="http://cs12.kst.dit.ie"/>
<argument name="size" value="100"/>
<piggyback type="GetDisplayURL"/>
</request>
</aiml>
16. Client receives the following response:
<aiml version="1.1">
<response type="Success" runid="5678">
<param name="id" value="0001"/>
<param name="alttext" value="Display URL Provided"/>
<piggyback type="GetDisplayURL">
<param name="url" value="http://comp.dit.ie/world/display/5678"/>
</piggyback>
</response>
</aiml>
From this the client finds out the run id for the world. It also finds out the display URL for the world from the piggybacked response. A new run has started in the world for the client.
17. Client requests state from world with following request.
<aiml version="1.1">
<information type="GetState" runid="5678">
</information>
</aiml>
18. Client gets following response, giving state
<aiml version="1.1">
<response type="Success" runid="5678">
<param name="id" value="0001"/>
<param name="alttext" value="State Provided"/>
<piggyback type="GetState">
<data name="x">
(1,2,3,4)
</data>
</piggyback>
</response>
</aiml>
19. Client extracts state and provides it to the mind, asking it to provide an action.
<aiml version="1.1">
<request type="GetAction" runid="1234">
<data name="x">
(1,2,3,4)
</data>
</request>
</aiml>
20. Client gets action back from mind, in following form.
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="State Provided"/>
<piggyback type="GetAction">
<data name="a">
4
</data>
<param name="q" value="10"/>
</piggyback>
</response>
</aiml>
21. Client instructs world to take the action provided by the mind, and piggybacks a request to give the new state.
<aiml version="1.1">
<request type="TakeAction" runid="5678">
<data name="a">
4
</data>
<piggyback type="GetState"/>
</request>
</aiml>
22. Client gets state back from world following execution of the action (note data name = 'y')
<aiml version="1.1">
<response type="Success" runid="5678">
<param name="id" value="0001"/>
<param name="alttext" value="State Provided"/>
<piggyback type="GetState">
<data name="y">
(1,2,3,7)
</data>
</piggyback>
</response>
</aiml>
23. Client extracts state and sends it loops from step 20 to 22 continuously until run ends, either having executed the desired number of steps, or when the user stops the run explicitly.
24. Once the user decides the run should end then the client has to send a message to the two servers instructing them to end the run. The message to the mind server looks like the following
<aiml version="1.1">
<request type="EndRun" runid="1234">
</request>
</aiml>
The message to the world server looks like this
<aiml version="1.1">
<request type="EndRun" runid="5678">
</request>
</aiml>
25. The mind server should respond with
<aiml version="1.1">
<response type="Success" runid="1234">
<param name="id" value="0001"/>
<param name="alttext" value="Run Ended"/>
</response>
</aiml>
and the world server should respond with
<aiml version="1.1">
<response type="Success" runid="5678">
<param name="id" value="0001"/>
<param name="alttext" value="Run Ended"/>
</response>
</aiml>
AIML is going to be the language used to create protocol messages on the WWM. We have outlined in this paper the full set of messages that will be used in the protocol. We described the evolution of AIML, the design decisions made and the influence of technologies such as XML, SOAP and HTML in its design.
The sample run in section 7 describes how communication may take place in the WWM. However, it was not our aim to describe in full the operation of the WWM, our goal was simply to define the protocol that it would use.
This document should be used in conjunction with the documents in the references section.
[1] Humphrys, Mark, "The World Wide Mind: Draft Proposal", 2001, Dublin City University, School of Computer Applications, Technical Report no. CA-0301
[2] O'Connor, Dave and Humphrys, Mark, "The Implementation of a Distributed Hierarchical Mind on the Internet using the World-Wide-Mind", 2001, submitted to AAMAS-02
[3] O'Connor, Dave, "AIML - A Markup for Communication on the World Wide Mind", http://www.compapp.dcu.ie/wwm/documentation/aiml.html