Application proposal: Agents in an open distributed information system

Paul Kearney
Research Manager, Distributed Intelligent Systems
paul.kearney@sharp.co.uk
Sharp Laboratories of Europe Ltd.
Oxford Science Park
Oxford OX4 4GA

Caveat

This is a personal position statement and the views expressed herein do not necessarily reflect those of Sharp Laboratories of Europe Ltd. or of Sharp Corporation.

Summary of proposal

The proposal is that FIPA should define the syntax and semantics of an inter-agent message language to be used to implement an an extra layer of "" control to augment existing and projected multimedia content delivery services working over public networks. The language would be used to exchange information on the availability of services and content, negotiate over terms and conditions, etc., then when agreement is reached, authorise delivery. The requirement is general across all classes of distributed information system. However, for the sake of concreteness I concentrate on Internet applications using HTTP.

Application overview

The field of open distributed information systems (I use a broad definition of information which includes entertainment and communication) is an extremely important application area for agent technology. Greater intelligence and autonomy is required in

client software, where the agent acts on behalf of the user of the information,
in server software, where the agent acts on behalf of the "" of the information
in software managing the services which link the two (including communication services, broking services and services consolidating and converting information).

Note that the distinctions among the above is somewhat artificial. For example the same software may act in the role of client one minute and server the next.

Already we are seeing agent products on the market (at least the vendors claim they are agent-based). These tend to be:

client-based, i.e. they add functionality to the client software, and make use of client interface to content delivery services
server-based, i.e. they add functionality to the server / broker software, and make use of server interface to content delivery services
hybrid, i.e. they have both client-based and server-based components communicating via a special-purpose protocol, frequently layered on top of the client-server protocol of the delivery service.

There are many advantages to having distinct client- and server-based components which cooperate with each other (as in the hybrid approach). However, for agents to achieve their full potential, the cooperation needs to be multi-way (not just 1-to-1), and the agent-agent communication needs to be open to allow interoperability and free competition. There are also limits to what can be achieved by using the delivery service protocol for agent-agent communication.

My view is that agents will be used to provide an extra layer of "" control to augment existing and projected multimedia content delivery services working over public networks. The agents will exchange information on the availability of services and content, negotiate over terms and conditions, etc., then when agreement is reached, authorise delivery. Examples of delivery services include:

Internet/HTTP (World-Wide Web)
interactive digital broadcast, VOD, etc.
telephony-related services

In the following discussion I concentrate on Internet/HTTP, because it is (probably) the most rapidly emerging requirement and for reasons of concreteness. I also assume that agents are static and inter-agent communication is by message-passing. Analogous issues do also arise in the case of mobile agents, however. Perhaps FIPA should aim to support both in an integrated fashion.

Application to World-Wide Web

The World-Wide Web client-server protocol is the HyperText Transfer Protocol or HTTP. A client sends a server a request in which the object of the request is specified by a URL (uniform resource locator). The object of the request is usually a file, which the server transmits back to the client. However, it is also posible for the request to be processed by a script or by an agent which generates document on the fly. Note that HTTP provides for a series of parameters and values to be passed as part of the URL. This is how communication with search engines work, for example -- the search terms are passed as parameters within the URL, and the search engine generates (typically) an HTML document containing references to known documents. Search queries are normally initiated by the user, who also views the response and decides on further action him/herself. However it is also possible for a client-side agent to initiate the search and to analyse the response and take appropriate action itself. Thus HTTP itself can be (and is) used for agent-agent communication / cooperation.

However, there are a number of problems with this approach including:

expressiveness is severely limited
semantics are defined only for a specific application (e.g. a specific search engine)
the connection-oriented HTTP is not well suited to passing many small messages -- one probably wants to perform agent-agent negotiation to identify with a high degree of confidence the sought information and agree terms before opening up the expensive connection to preform the document transfer.

There is, therefore, a strong case for an agent-agent message language to augment HTTP.

The message language will not only allow improved versions of existing classes of WWW service, however. It will also enable a wide variety of novel intermediate ("") services, support cooperation within user groups, and facilitate commercial transactions. There is also the possibility of negotiation between information agents and agents within the Internet infrasctructure concerning quality of service parameters, charges, etc.

Standardisation items

Interface to message delivery service

It is not appropriate for FIPA to consider the mechanisms for delivering inter-agent messages. However, FIPA should define desired characteristics and an API covering sending and receipt of messages.

Characteristics to be considered include:

connectionless, store-and-forward, address by user/agent name
security & authentication
guaranteed delivery?

Syntax and semantics

The various levels of language requiring definition include:

Outer layer / speech act level (cf KQML) -- relatively easy to specify syntax, but must be clear on semantics of speech acts, etc.
grammar level (cf KIF) -- several candidate styles (e.g. 1st order logic). It may be necessary to keep the grammar simple (at least initially) or to have graduated levels of capability.
domain ontology -- a vocabulary which grounds the language in the real world. It must describe document content, servers and the services they supply, user and client characteristics, terms and conditions (cost, quality of service ...), agents and their capabilities, etc. It needs to be expandable, which means agents must be able to compare versions (so the ontology must be able to describe itself to some extent. Even in this restricted application area it may be necessary to define sub-ontologies (for example, all agents understand a basic ontology, plus zero or more sub-ontologies)
negotiation protocols -- a number of dialog structures (perhaps expressed in terms of state machines) describing message-exchange sequences reaching definite conclusions. Example "" include:
- agreeing terms and conditions for supply of a service (e.g. transfer of a document)
- agreeing a level of language complexity and a common set of sub-ontologies so that a meaningful dialog can take place.
- an incrementally refined search for a service satisfying the client agent's requirements (e.g. search for the best document containing specific information)

My view is that we should aim to define a simple, practical, but extandable language rather than a complex one which aims to solve all problems in one go.

Related issues

Related issues to be born in mind include:

standardisation of interfaces between agents and standard client and server software (e.g. web browsers, web servers, databases)
payment for commercial transactions
mobile agents / executable messages