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
The World Wide Mind is a project which will provide an architecure to enable AI researchers make their work available online. AI researchers develop applications which simulate environments (worlds) and thought processes (minds). The minds decide upon actions that bodies should take in the worlds. Until this point, any researcher who wished to create a new mind would also have to create a new world to test the mind. It is the intention of the WWM project to provide an easy to use architecture which would enable researchers to make their creations (minds and worlds) available online so that other researchers could use them in their experiments. The developer of a mind would no longer need to create a world, but could instead make use of a world already made available online by another researcher. The advantages of this are many. Apart from the obvious advantage of code reuse, we could foresee a situation where a small number of worlds become benchmarking testbeds that can be used to measure the effectiveness of one mind against another. Also, several minds could be grouped together to create a large mind, so for a researcher to create a new mind, they may only need to construct an interface which chooses which mind to consult in certain circumstances.
The minds and worlds that are put online will be referred to as WWM servers. They each provide a public interface which we will refer to as their service. This will define the operations that they can perform, and the data that they can return. There will exist a core set of operations that all servers must provide. There will also exist a set of configurable operations, which will vary from server to server. This paper outlines how these servers will communicate with eachother. We outline how we designed a protocol that is sufficiently complex to embody all the requirements for communication in the WWM, while at the same time keeping it sufficiently simple so that anyone who wishes to make a server available online can do so without having to learn a great deal about new technologies.
This architecture is identical in form to the emerging web service architecture. In this paper we look at the technologies being currently used for web services, including XML, XML Schema, RDF, SOAP, UDDI and WSDL, and highlight the useful features in each. We then present our own architecute which makes use of some of the useful features, but none of the technologies. We argue that the complexity of each of the technologies rules against their adoption in our architecture.
Keywords: WWM, Web Services, AIML, SOAP, XML, AI.
Researchers in all areas of AI produce programs which simulate minds, whether they are creating artificial life or autonomous agents. Researchers who create articifial minds need an environment in which to test them. Typically the construction of these environments, or artificial worlds requires a large amount of effort, and is ultimately only used by the researcher who built them. Similarly, minds created by researchers are only used for the experiments at hand, and following the writing up of the experiments, the minds are no longer used.
The World Wide Mind (WWM) [humphrys, 2001] project aims to make this AI research available online. When a researcher constructs a mind or world they integrate it with the WWM architecture. This means that other researchers can construct a mind to run in the artificial world has been put online, or can use the new mind as a part of a greater Society of Mind [minsky, 1986]. To do this the WWM architecture must be made sufficiently simple to allow any AI researcher put their work online with a minimum of effort.
In the WWM, worlds and minds are considered WWM servers. WWM servers present a public interface, showing the methods and operations that they make available to clients, for example, a world server should have a method which allows a client get the current state of the world. Parts of this public interface belong to the core protocol designed for the WWM, and parts are configurable by the server. The public interface defines the service the server provides.
This architecture is identical in form to the emerging web service architecture [Jones, 2001]. In this paper we examine web services, and several of the technologies that are at the core of this architecture. We examine the useful aspects of each of these, identifying the usefullness of several of these features for our own architecture. However we argue that while each of these technologies has an obvious use for web services, their complexity does not lend themselves easily to our requirements. We require a lightweight protocol that can be easily understood by anyone who wishes to create a WWM server. There should not be a steep learning curve, as there is with the majority of the technologies we identify.
We then present the protocol which we have developed for the WWM. The Artificial Intelligence Markup Language (AIML) defines the set of queries that must be supported by WWM servers. Inbuilt into AIML is an introspection or discovery mechanism for identifying the set of operations that form the service for that server. We discuss the, not yet implemented, possibility of incorportating aspects of the Semantic Web[berners-lee, 2000][www.semanticweb.org] into our architecture, where servers can publish the typs of data they use for defining, say, the state of the world they represent, so that other servers can correctly interpret this data.
We begin however, with a high level look at the World Wide Mind architecture.
|
|
| Figure 1: Simple WWM Architecture | Figure 2: Society of Mind in WWM |
The World Wide Mind is comprised of the following components
The servers provide an interface allowing clients inquire about their current state, and order them to take actions. The client is the main driving force behind the architecture, analogous to the web browser in the World Wide Web architecture. The protocol is the set of messages that can be sent between the client and the servers, and the means for finding out the data required for each opertation.
 |
| Figure 3: WWM Client |
It will then initiate a run. When a run is started the server provides a service to the client. It can be requested to provide, for example, the current state of the world, or given a particular state, it can be asked to select an action appropriate for the world (this is the function of the mind server).
Figure 1 above shows a section of a run. The client queries the world server to get its current state. The server then returns some textual representation of the state, in the example above this is the simple string "(1,2)". The client will receive the response to this, and then supply the state of the world to the mind. The mind will attempt to understand the world's representation of the state, and from this it will attempt to decide upon an action that should be taken in the world. This action, in the case above represented by the text string "GO NORTH!!", is returned to the client, who then informs the world server to take this action.
Note, it is up to the two servers to attempt to understand the representations of state and action. This is not controlled in any shape or form by the protocol, as of yet. You will, however find a brief duscussion below of how this could be changed.
The run continues in this fashion, with the client requesting the state from the world server, the mind server deciding upon an action to take in the world, and the world server being instructed to take this action. It is up to the server to distinguish between separate clients. The protocol incorportates a runid to identify the client, however it does not specify how the world server should implement multiple instances of a world to run concurrently. We do however, provide advice on a number of different ways this could be implemented on a server, depending on the level of technical expertise [w2mind.org].
It is also possible to use the service provided by a server while not involved in a run. The protocol incorporates queries that allow a client query a server to suggest an action given a particular state, without reference to any particular run.
At no point do world and mind servers talk directly to eachother, all interaction takes place through the client. This is done because the client is to have full control over the run. The mind and world servers need not be aware of eachother's existance.
However, it is possible for world servers to talk to world server, and mind servers to talk to mind servers. Figure 2 above shows an instance of a Society of Mind. In this case, the client talks to a MindM server. A MindM server is one which asks other Mind servers to select an action. Its job is to decide who to ask. Thus, the protocol has to reflect that all interaction with servers does not happen through clients. For a fuller discussion of the various types of servers see [humphrys, 2001].
The examples given above are relatively simplisitic, and reflet the simplest interaction between the different components in the WWM. Large Societies of Mind will include many servers, distributed throughout the world. Any protocol which supports the examples above would have to be scalable to be able to handle these larger instances. This sohuld not present a problem.
Our primary concern in developing this protocol was as follows. Success of the WWM project in dependent upon interest in the AI community in it. We need AI researchers to see that this is a good idea. We also need them to see that is will not require a knowledge of a new domain (computer networks) for them to make their worlds and minds available as WWM Servers. For that reason we chose the simplest option in every case. However, we were careful not to compromise the strength and robustness of our protocol to such an extent that it would soon become unworkable. A lot of the protocols below are extremely useful and sound pieces of work. However they all belong to the class of unforgiving protocols that have recently emerged from the w3c and others. They lack the forgiving nature of standards such as HTML. Imperfect HTML (missing end tags, missing sections) could well account for a spectacularly large amount of the HTML available on the Web. This imperfection gives Joe Public the confidence that he too can build a web page, or site, without having to learn a new language fully, or have an enormous amount of technical knowledge. This is what contributed in no small part to the success of the web. Our endeavor here is along the same lines as the www. We are attempting to construct a protocol that will not scare potential users away due to unnecessary complexity.
In order to implement a protcol to support the WWM architecture we required the the following:
These are very similar to the requirements for developing a web service. A web service is a web site intended for use by computer programs rather than by human beings. The currently most popular way of implementing a web service is through the use of the following protocols and standards
Web services are also concerned with things such as security which are of little concern to us.
The Hypertext Transfer Protocol (HTTP) [w3.org a] is the application layer protocol used on the WWW. It defines a simple set of request response messages for retreiving different types of data over the web. Typically this type of data would be text. Status codes contained in a HTTP response indicate how successful the requested operation was, ranging from complete success, to partial success to failure because of client or server faults. The HTTP extension framework [w3.org b] allows for extension of HTTP in a co-ordinated fashion. It incorportaes information about how the extension should be used, and who it is intended for. This is possibly a useful feature for our own protocol, given that servers can define extensions that apply to themselves alone. However, we decided to incorporate this extensibility into the protocol we developed, rather than using the HTTP capability to do so. HTTP, as we will see, is instead simply used as our transport mechanism, for delivering our messages.
The Common Gateway Interface (CGI) is a standard way for a web server to pass a users HTTP request including parameters to an application program and receive data back to forward to the client. It allows HTTP clients interface with programs. Using CGI, or any of its close relations, incluing Java Servlets, ASP, JSP, is the simplest way of creating an elaborate networked program. The application program simply reads from Standard Input (or even better, retreives data through use of an API) and writes to Standard Output. All transmission of data across the network is handled by the web server and client, and the underlying protocols, including HTTP. It is a straightforward alternative to socket programming.
The Extensible Markup Language (XML) [w3.org c] is at the core of what appears to be something of a revolution on the Internet. Developed by the W3C, as a subset of the Standard Generalised Markup Language (SGML) [w3.org d] which allows for the definition of customised tags to define data. An XML document consists of a single element with many child elements, and appears to have a form similar to the language of the WWW, HTML. However XML has a number of features which make it significantly different to HTML. Firstly, all XML documents must be well formed. This means that any start tag must be accompanied by an end tag, with the exception of standalone tags, which must be terminated with a forward slash '/'. Start and end tags must be spelled identically (obviously) and in the same case. XML documents may optionally be valid. In order to be valid an XML document must abide by a set of rules outlined in a Document Type Definition, or XML Schema [w3.org e]. A DTD or Schema will give the structure for a document, indicating that element X must have attribute Y and child element Z. Failure to abide by these rules will result in an XML document being rejected.
This feature is obviously useful, in that it ensures integrity of data, and should not pose a problem when application programs are exchanging data, since application programs should not generate incorrect XML, if they do then they are in error. This idea is discussed in [nelson, 2002] where the author decides that the feature in a browser which informes a user of an error in an XML document, means that users should not be generating incorrect XML. However, validation software has long existed for HTML [w3.org f], yet this has not led the the proliferation of correct HTML on the web. The reason for this is that browsers are willing to tolerate incorrect HTML. We have decided that the messages in our protocol should be correct, but in the case of their being generated with slight imperfections then parsers should be willing to tolerate this, and attempt to extract the correct information regardless. The reason for this, as stated earlier, is that we do not wish to impose strong restrictions on researchers who wish to join the WWM, who may never have had experience with XML, never mind computer networks.
Had we decided to use XML we would have been able to make use of the may parsers that are available for free, e.g. Xerces from Apache [xml.apache.org]. We would also have been able to make use to the myriad of documentation and sample code to encourage WWM users to learn the language. We would have created an XML namespace to distinguish our language from others, and published a DTD or Schema which users would have to abide by. In doing these and other things, we would have ensured that all messages distributed between WWM clients and servers would have been correct. However, the overhead of becoming familiar with what these things mean would server as a barrier to entry to many who may otherwise have had an interest in our project.
XML has grown rapidly since its inception. While the core remains the same, the 'extras' that have been added on such as query languages[w3.org g], ammended query languages [tatarinov, 2001] for but one example mean that the options to consider when creating an XML application are many. Compressed and binary forms of XML have also been developed, in a move away from simple text based markup. Examples of this include the WAP protocol for mobile communications. WML (Wireless Markup Language) documents are converted to binary format by the WAP gateway prior to being delivered to the mobile device. Use of compression to speed up remote procedure calls using XML is one of t he subjects of [sundaresan, 2001]. This paper discusses how the use of a proxy compression server can reduce the overheads associated with an XML-RPC (incidently, XML-RPC is the predecessor of SOAP, to be discussed below) by a factor of 2.25.
There has also been movement in the opposite direction. Common XML [laurent, 2000] is a stripped down version of XML that identifies the most useful parts of XML for certain applications. Similarly, MinML [Wilson, 2000] subsetted XML leaving out everything but elements and text, in order to create a language suitable for embedded systems. Our idea would appear to be along the same lines as this. We want the benefits of XML in that is it a powerful means for expression and representation of data. However we do not want the hassle of handling many of its features.
The Simple Object Access Protocol (SOAP) [w3.org h] provides a mechanism for sending requests to objects located at various points throughout the Internet. It is similar in concept to CORBA, DCOM and Java RMI, but has the advantage over each of these that it runs over currently existing protocols. SOAP defines three things.
SOAP messages are XML documents. The format for a SOAP messages consists of the Envelope, the Header and the Body. The envelope contains namespace declarations and additional attributes. The header contains entries to specify authentication and other high level information. The body contains the information required for the message.
The encoding rules provide a platform independent definition for primitive types such as integer, string etc. It also provides a way to encode an object, an array, sections of an array and other complex data types.
The binding framework ties the SOAP message to an underlying protocol. This protocol is typically HTTP, but can be any application layer request response protocol, such as SMTP, the e-mail protocol.
Developing our protocol as an applicaion of SOAP initially seemed like a very attractive possibility. Firstly, it appears to have unified a lot of the distributed object systems, by providing an interlingua the can all interface with. This, it has to be said is also true of CORBA. Secondly, it operates (mostly) over the WWW, meaning anyone with web space can develop an application with SOAP clients. Thirdly, it provides encoding rules for all data types. This would prove very useful for our protocol, as we will see, when we are exchanging types data. Forthly, it is at the centre of web services, having already been embraced by Microsoft with the .NET initiative, as well as several other implementations of web services. It appears to have assumed the position of the standard means for invoking a web service.
However, basing our protocol on SOAP was decided against for a number of reasons. Firstly, it is based on XML which we have already argued against. Secondly, anyone who wanted to create an application which would interpret SOAP messages would need to first get an API to parse these requests. This introduces a number of problems. We do not know who is going to be developing WWM Servers, and as a consequence, we know nothing about the environment they will be using. Therefore we cannot insist on their installing some software, since we do not know if that software is available for their platform. This may not be a consideration in mainstream computing, where APIs can be produced for the main languages and platforms, and the remaining (small) minority can be left to wait. In AI it is possible that a researcher who carries a lot of weight in his field has created a mind in LISP, a language for which it is unlikely that we will ever see an API for SOAP. Such a researcher would have no interest in learning Java or any mainstream language, simply so he can participate in the WWM project. Therefore, he would immediately be excluded from participating. Were he to try to parse SOAP messages himself he would quickly learn that SOAP messages are quite complex, and generating a SOAP response from first principles would also prove difficult.
We have borrowed a number of good ideas from SOAP, but our protocol will not be an application of SOAP.
The Web Services Definition Language (WSDL) [w3.org i]is an XML format for defining what web services look like. For example [w3.org i] provides an example of what a web service for providing a Stock Quote would look like. It defines the messages that can be sent to the service and the types of response that they can expect, among other things. This language is used in conjunction with UDDI to locate appropriate web services.
One of the requirements for our protocol is a type of discovery mechanism. We do not require a way for locating a server, since we assume this is done by the user, prior to starting the client. We do, however, require some way for the client application to talk to the server to find out the types of parameters and arguments it expects. We will build something that looks like WSDL into our protocol, but we will not use the protocol itself.
Universal Description, Discovery and Integration (UDDI) [uddi.org]provides a type of yellow pages for web services. Aimed primarily at business services, it provides an interface whereby a client can send a request to locate a certain type of service. The definition of this service may be stored in the UDDI registry using WSDL. Other forms of describing services include the Web Services Inspection Language from IBM [brittenham, 2001].
UDDI certainly has its usefullness in the business web, but we see little use for it in the WWM as of yet.
The protocol and architecture we've developed for the WWM uses the following technologies:
These three components fit together as shown in Figure 4.
 |
| Figure 4: Communication in the WWM |
A client has been developed and is available at [w2mind.org]. WWM servers are built and put online by AI researchers, without having to install any software. They only have to abide by the protocol which we describe in the remainder of this section and elsewhere [w2mind.org].
AIML is less strict than XML. In fact it is quite similar to HTML, in that messages are never rejected because of missing end tags. The language is totally case insensitive. If badly structured messages are received then it is the responsibility of the parsing application to attempt to extract the required information from the message. If it cannot do this then the message is rejected and an error response is sent to the client. If a request is received without the full set of parameters that are expected then the application can attempt to use default values. If it is successful, then the response will indicate that the request was a success despite the fact that the full information was not supplied. Otherwise, and error response is issued to the client or calling server.
An AIML parser which obeys these rules has been developed in Java and is available at [w2mind.org]. It is intended to make parsers available in various other languages in the future. However, AIML has been developed with the aim of being as simple as possible, so server authors should be able to parse AIML requests through straightforward string searching and pattern matching techniques.
Our aim here is to give an overview of the design of AIML. The full protocol is available at [w2mind.org].
All AIML messages have a sinlge element with various child elements. The root element MUST be called 'aiml'. The root element MUST have an attribute called 'version' indicating the version of AIML being used. Future developments of AIML will be supersets of current versions. The child element of an AIML message will ALWAYS be one of the following
A request (Figure 5) is a message from a client (note that a server can also be a client to another server, for example in a Society of Mind model, Fig 2) instructing the server to perform some operation. An information message (Figure 6) requests some information from the server. This is an idempotent operation. Such messages can be piggybacked on other messages, so that as well as, say, taking an action in a world, a server can return information about the current state of the world. A response (Figure 7) is a message sent from a server to the client. It will ALWAYS indicate either success or failure of the requested operation. Any return values will be piggybacked on the success or error response.
| <aiml
version=1.1> <request type="NewRun"> </request> </aiml> |
<aiml
version=1.1> <information type="GetStructure"> </information> </aiml> |
<aiml
version=1.1> <response type="Success" runid="1234"> <param name="id" value="0001"/> <param name="alttext" value="Structure Incl"/> <piggyback type="GetStructure"> <param name="display" value="TRUE"/> </piggyback> </response> </aiml> |
| Figure 5: Request | Figure 6: Information | Figure 7: Response |
All AIML messages can carry parameters. These are name value pairs. For example, a success response will always carry an 'id' parameter, indicating the status code.
The discovery mechanism of the WWM is handled by the GetStructure information type request. A GetStructure request sent to a WWM server is an instruction to supply the following
| aiml
version=1.1> <response type="Success" runid="1234"> <param name="id" value="0001"/> <param name="alttext" value="Structure Included"/> <piggyback type="GetStructure"> <param name="diaplay" value="TRUE"/> <arguments request="NewRun"> <argument name="size" type="integer" default="100"/> </arguments> </piggyback> </response> </aiml> |
<aiml
version=1.1> <request type="NewRun"> <argument name="size" value="50"/> </request> </aiml> |
| Figure 8: AIML GetStructure Response | Figure 9: AIML Arguments |
We identified above the possibility of using compression in order to cut down on the delay time for a call to a service. This however is highly infeasible due to the complexity involved, or at the very least the requirement to install software on the web servers used by AI researchers. We looked instead at the possibility of carrying two requests together in one HTTP packet. In order to do this we found it necessary to distinguish between types of requests, and therefore we created the <information> tag discussed above. We decided that it should be possible to carry an information request alongside any other type of request. To do this we created the 'piggyback' tag.
A piggyback tag in a request or an information message indicates to the server that following completion of the main request, it should get the information required by the (one or many) piggybacked information requests, and piggyback this on the response.
All data carried in a response is piggybacked on a Success or Error response.
For example, imagine a NewRun request that also included the information request to get the display URL for the current run. Figure 10 shows how the request would carry the extra information request. Figure 11 shows how the Success response carries the resulting data. If the NewRun request required any data in the response following its own execution, this too would be piggybacked on the Success response.
| <aiml
version=1.1> <request type="NewRun"> <argument name="size" value="50"/> <piggyback type="GetDisplayURL"/> </request> </aiml> |
<aiml version="1.1"> <response runid="1234" type="Success"> <param name="id" value="0001"/> <param name="alttext" value="Action Completed"/> <piggyback type="GetDisplayURL"> <param name="url" value="http://displayurl/"/> </piggyback> </response> </aiml> |
| Figure 10: Piggybacked Request | Figure 11: Piggybacked Response |
All responses indicate either success or failure. There are a number of status codes used to indicate the level of success or failure, analogous to the status codes in HTTP. These will always be carried in the 'id' parameter in the response. There is a possibility to include an 'alttext' parameter in a response to indicate in natural language the level of success. These codes are available in the protocol specification at [w2mind.org].
World servers contain a state. Mind servers take this state and select an action based on the state. In doing so they may consult other mind servers. The state and action are represented as text strings. The format of this text string is not controlled by the protocol, and may take any form, as decided upon by the server. For example, a world server may decide that it represents its state as a pair of co-ordinates, as is the case in Figure 1. This would be appropriate for grid like worlds where the body or creature navigates its way through the grid in search of food. For an example of such a world see [humphrys, 1997]. Alternatively it could represent its state using an elaborate set of tags. Similarly the mind can represent its action in any form. In Figure the action is provided as a text string indicating that the creature should "GO NORTH!!". It is the responsibility of the server to understand what the text string means. We do this in anticipation of mind servers being developed specifically for certain world servers. It is not possible for us to specify a set of tags to capture all different types of knowledge, and all representations of same, so we do not attempt to do so (although in the next section, you will see some possibilities for doing so in the future). It is expected that with the proliferation of WWM servers, certain standards will develop for the specification of this data. However for the moment the client will simply pass anything contained between 'data' tags between servers without examining it or changing it. Figure 12 shows the result of a GetState request to a world server. The data is extracted and passed in a GetAction request to a mind server, as shown in Figure 13.
| <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) </data> </piggyback> </response> </aiml> |
<aiml version="1.1"> <request type="GetAction" runid="1234"> <data name="x"> (1,2) </data> </request> </aiml> |
| Figure 12: GetState response | Figure 13: GetAction request |
The full protocol is available in the protocol specification at [w2mind.org]. We have outlined the major decisions we made in designing the protocol, in order to provide access to the WWM servers through web services. The protocol is very lightweight, messages are small and non-complex. They should be easily generated, parsed and delivered by programmers without the requirement to uinderstand XML or network programming.
Although it is not our intention to define in any shape or form what the text between the 'data' tags in AIML messages should look like we could possibly foresee one of the following situations arising in the future.
Symbolic data is easily represented an could fall into the first category above without much difficulty. Sub-symbolic data will need something like the semantic seb to emerge before it can be controlled by a protocol.
When creating a WWM service an AI Researcher is required to do the following
We have defined a system for creating web services, by people who have little or no interest in computer networks or the Internet. We have attempted to use the simplest available option in every case, in order to avoid people being put of by the perception of complexity. Any AI researcher should be able to generate AIML requests and responses, and parse the same, since the language does not contain any of the complexity of languages such as XML. The language and protocol outlined in this paper and elsewhere [w2mind.org] uses notions from core web service components, such as the idea of defining a service using a language such as WSDL. Our definition does not go beyond the definition of arguments expected by a method call, yet we still need to consider definition of types, as done by SOAP.
The complexity of the web service technologies is quite obviously necessary to cover all possible areas they are used, especially e-commerce. However, our attempt to interest programmers whose field is not at all linked to e-commerce or Internet technologies forbids us from using these technologies. Ours are lightweight web services.
| [berners-lee, 2000] | Berners-Lee, Tim; Semantic Web Presentation, XML 2000 [online]; available at http://www.w3.org/2000/Talks/1206-xml2k-tbl/slide1-0.html |
| [berners-lee, 2001] | Berners-Lee, Tim; Hendler, James; Lassila, Ora; The Semantic Web; Scientific American, May 2001 Issue; also online; available at http://www.sciam.com/2001/0501issue/0501berners-lee.html |
| [brittenham, 2001] | Brittenham, Peter; An overview of the Web Services Inspection Language [online]; available at http://www-106.ibm.com/developerworks/webservices/library/ws-wsilover/ |
| [ginsberg, 2001] | Ginsberg, Matthew L., Knowledge Interchange Format: The KIF of Death, AI Magazine, Vol.5, No.63, 1991. |
| [hendler, 2001] | Hendler, James; Agents and the Semantic Web, IEEE Intelligent Systems 2001. |
| [humphrys, 1997] | Humphrys, Mark; Action Selection methods using Reinforcement Learning, PhD thesis, University of Cambridge, Computer Laboratory (Technical Report no.426), www.compapp.dcu.ie/~humphrys/PhD |
| [humphrys, 2001] | Humphrys, Mark;The World-Wide Mind: Draft proposal, Dublin City University, School of Computer Applications, technical report CA-0301, also onlive; available at http://www.compapp.dcu.ie/~humphrys/WWM/ |
| [jones, 2001] | Jones, Kevin F; Web Services Overview And How They Fit Into Your Future [online]; available at http://www.webservices.org/article.php?sid=444 |
| [laurent, 2000] | Laurent, Simon; Common XML [online], available at http://www.simonstl.com/articles/cxmlspec.txt |
| [minsky, 1986] | Minsky, Marvin; The Society of Mind |
| [nelson, 2002] | Nelson, Mark; XML Schema Validation in the Misrosoft Universe; Windows Developers Journal, January 2002 |
| [oconnor, 2001] | O'Connor, Dave; Humphrys, Mark; Walshe, Ray; First Implementation of the World-Wide Mind [online]; available at http://wwm.compapp.dcu.ie/wwm/documentation/first_implementation.html |
| [sundaresan, 2001] | Sundaresen, Neel; Moussa, Reshad; Algorithms and Programming Models for Efficient Representation of XML for Internet Applications; WWW2001 |
| [tatarinov, 2001] | Tatarinov, Igor; Ives, Zachary; Halevy, Alon; Weld, Daniel; Updating XML; University of Washington; SIGMOD Conference 2001 |
| [uddi.org] | UDDI Web Site [online]; available at http://uddi.org |
| [w2mind.org] | World Wide Mind Web Site [online]; available at http://w2mind.org |
| [w3.org a] | Hypertext Transfer Protocol Overview [online]; available at http://www.w3.org/Protocols/ |
| [w3.org b] | HTTP Extension Framework [online]; available at http://www.w3.org/Protocols/HTTP/ietf-http-ext/ |
| [w3.org c] | The Extensible Markup Language [online]; available at http://www.w3.org/XML/ |
| [w3.org d] | The Standard Generalised Markup Language [online]; available at http://www.w3.org/MarkUp/SGML/ |
| [w3.org e] | XML Schema [online]; available at http://www.w3.org/XML/Schema |
| [w3.org f] | HTML Validation Service [online]; available at http://validator.w3.org |
| [w3.org g] | XQuery 1.0: An XML Query Language [online]; available at http://www.w3.org/TR/xquery/ |
| [w3.org h] | Simple Object Access Protocol (SOAP) 1.1 [online]; available at http://www.w3.org/TR/SOAP/ |
| [w3.org i] | Web Services Description Language (WSDL) 1.1 [online]; available at http://www.w3.org/TR/wsdl |
| [w3.org j] | Resource Description Framework [online]; available at http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ |
| [Wilson, 2000] | Wilson, John; MinML [online], available at http://www.wilson.co.uk/xml/minml.htm |
| [www.semanticweb.org] | The Semantic Web Site [online]; available at http://www.semanticweb.org/ |
| [xml.apache.org] | Apache XML Project [online]; available at http://xml.apache.org/ |