MICK: A KQML Inter-Agent Communication Framework in ... - CiteSeerX

MICK: A KQML Inter-Agent Communication Framework in a Digital Library Adolfo Barceinas1, J. Alfredo Sánchez1 and John Schnase2 1 Laboratoty of Interactive and Cooperative Technologies, UDLA-P 2 Center for Botanical Informatics, MBG {adolfo,alfredo,jschnase}@cbi.mobot.org, phone: (22) 29 26 66, fax: (22) 29 24 31 Abstract: This paper describes a solution to the problem of communication among components of a highly distributed digital library. Specifically, we refer to the architecture of the Floristic Digital Library (FDL), which is oriented to user services, including agent services. In this context, the paper focuses on communication between an Agent Director (an interface for users to control their agents) and the set of agents and between the Agent Director and an Active Library Server. In order to enable communication among those components, an inter-communication framework was designed. This framework includes an agent communication language (KQML), a communication protocol defined in terms of the language, a vocabulary, message routers, and a facilitator that defines an architecture by assisted coordination. A prototype for this framework was implemented in Java, using JATLite as the KQML implementation. Message routers were created for agents, the Agent Director and Active Library Services. A facilitator was also implemented to mediate communication and a new version of the Agent Director was created to test communication services offered by the framework. Additionally, the message router for agents was converted into a CORBA object using ILU as the CORBA implementation, and an API was created for agents implemented in C or Java to access message router services. Keywords: Agent communication, digtal libraries, FDL, KQML,CORBA,MICK.

1. Introduction Digital Libraries emerge as an ambitious discipline attempting to organize the vast data repository and the diverse means that information technology currently offers. As an information system, digital libraries are among the most complex and advanced ones since they frequently include collaborative support, hypertext, information filtering, copyright management, multimedia information systems, reference services, among others. In this effort, the Human-Computer Interaction methods used to handle information are particularly important to effectively assist users in searching, organizing, using and learning about the vast data repository contained in digital libraries [Fox et al. 1995; Fox and Marchionini 1998]. In this context, user interfaces based on agents have been proposed as a means to simplify user-system dialogs, automate tasks, handle complex information and use resources efficiently. In addition to their application in user interfaces, agents are also being used in a variety of fields such as telecommunications, network administration, electronic mail and information retrieval. Agents are proposed to address the problems of increasingly distributed, complex and dynamic applications. They are becoming an area of development where a great number of different disciplines such as HumanComputer Interaction, Software Engineering, Networking, Sociology and Artificial Intelligence come together.

Although the term agent has become very popular in the software industry, there seems to be no agreement on a definition for it. Despite this lack of consensus, some properties are usually associated with the concept of agent: autonomy, sociability, cooperation, reactiveness, proactiveness (with a goaloriented behavior and with initiative), temporal continuity (processes running continuously) and adaptability (to the environment as well as to the user) [Chauhan 1998]. The work presented here addresses the property of sociability associated with agents. Specifically, this paper describes a communication framework named MICK that supports communication among agent services and the components of a digital library, using the popular agent communication language called KQML (Knowledge Query Manipulation Language). The digital library is referred to as FDL, or the Floristic Digital Library, as it comprises a vast repository of botanical information. In order to situate the agent services developed for the FDL, the taxonomy proposed by Sánchez and Leggettt [1997] is briefly described here. This taxonomy considers three types of agents: programming agents, network agents, and user agents. Programming agents are abstractions created for the sake of programmers, allowing them to conceptualize, design and implement complex systems where computer process modeling is emphasized. Network agents are autonomous entities that travel through the network, install themselves in some node, and use its resources on behalf of the node who sent them. Finally, user agents are abstractions that help final users to interact with applications. User agents can be subdivided into information agents, task agents and synthetic agents. Information agents help users to deal with complex and dynamic information spaces. Task

agents run concurrently with the user application, observe user activities and give the option to automate some tasks. Synthetic agents create environments where animated characters are introduced in the interface. This classification is summarized in Figure 1. The rest of the paper is organized as follows. Section 2 presents the general problem area, Section 3 describes the particular problem area, Section 4 depicts the conceptual proposed solution, Section 5 presents the prototype that implements the proposed solution and Section 6 describes the ongoing and future work for MICK.

Figure 1. Agent Taxonomy (adapted from Sánchez [1997]) 2. The general problem of communication in multi-agent systems The ability to interact, that is, to interchange information and knowledge that can be mutually understood is evidently important and desirable for agents. Some authors, like Genesereth and Ketchpel [1994], even state that an entity cannot be called an agent if it does not communicate correctly in an agent communication language. This interaction can be modeled based on two different paradigms. The first one establishes that competence emerges from a great number of relatively simple agents integrated by some intelligent architecture. The second paradigm is based on the idea that competence arises from agents that process a lot of useful knowledge, where the

architecture is not so important [Guha and Lenat 1994]. As with interaction among people, interaction among agents needs more than a common language to reach an effective communication. In general three components are required: the ability to interchange knowledge, a common language and mutual understanding of the knowledge being interchanged. Issues relating to these requirements are presented next. 2.1 Multi-agent system architectures The ability of agents to interchange messages depends a great deal on having an architecture to organize agents. Two general architectures for organizing agents have been explored: (1) direct communication and (2) assisted coordination. Direct Communication An organization of agents by direct communication is characterized by agents that handle their own coordination, which has the advantage of not depending on any other programs or middleware to communicate and the disadvantage of increasing the level of complexity when implementing each agent. Within this form of organization, two architectures exist. One is known as contract network and the other as shared specification. In contract network architectures, agents distribute requests to different agents whenever they need some service. The agents that receive these requests evaluate them and send offers that are used by the agent requesting the service to decide which agent to establish a contract with. This architecture is evidently expensive because of the amount of messages required. When shared specification is used instead, agents do not send service requests when they need a service, but they provide information to other agents about their capabilities and necessities in advance, so when the need arises,

this information is used by agents to coordinate their activities. The number of messages exchanged is considerably smaller than those in a contract network, which makes shared specification a more efficient architecture. Assisted Coordination Another form of organizing agents is by assisted coordination, and a very popular example of which is the architecture known as federated system , where agents instead of communicating directly with each other, they do it through a facilitator [Genesereth and Ketchpel 1994]. This facilitator offers services such as finding the identity of other agents, finding agents capable of performing a specific task, sending a message to an agent, and splitting complex requests into sub-problems. Facilitators also get the answers for each subproblem and combine them together to produce an answer for the original request. Their work may involve translating among different agent vocabularies. A graphical representation of this architecture is shown in Figure 2.

Figure 2. Federated System (adapted from Genesereth and Ketchpel [1994]) 2.2 Agent Communication Languages Using a common communication language eases the development of interoperable software because it allows programmers to separate implementation from interface; that is, as long as a group of programs adhere to some communication language, they can inter-operate regardless of the language used to implement their functionality. In order to design this

language, there are two well-known alternatives: procedural and declarative. A procedural method is based on the idea that communication can better be modeled as the interchange of directives. In this way, not only commands can be transmitted, but also entire programs. Usually, procedural execution is efficient and direct. The main disadvantages when using this method are the requirement of information about the message receiver (which is not always available), and the unidirectional nature of procedures, when most of the time it is convenient for agents to share information. On the other hand, the declarative method establishes that communication can best be modeled using declarative sentences. To be useful, this method requires the language to be expressive enough to communicate different types of information including procedures, to be compact and not having the need to extend the vocabulary too often in order to maintain communication. A good example of this kind of language is ACL (Agent Communication Language) [Genesereth and Ketchpel 1994]. 2.3 ACL This language was created by ARPA to make inter-operation among autonomous and distributed agents possible. ACL has three components: a vocabulary, a content language called KIF (Knowledge Interchange Format) and a communication language called KQML. An ACL message is then a KQML message containing a communication directive and a semantic content in KIF, expressed in terms of the vocabulary. The ACL vocabulary is a set of words related to common application areas. Every word has a description that is used by people to understand its meaning and a formal annotation (written in KIF) that is used by programs. The vocabulary is open, meaning that new words can be added.

KIF is a prefix version of the first order predicate calculus with extensions to increase its expressiveness. Its basic semantic (without rules or definitions) is similar to first-order logic and the extensions handle non-standard operators. An important feature of KIF is its ability to code knowledge about knowledge. KQML provides the linguistic layer to make communication efficient by considering the context of messages. It was conceived as a message format and as a protocol that enables identification, connection and information exchange among programs. According to Finin et al. [1995], three important characteristics of KQML are the following: 1. KQML messages are opaque to the content that they transport, which implies that KQML messages not only communicate sentences in some language, but also an attitude or intention about the content. 2. Primitives are called performatives and indicate the valid actions or operations. 3. An environment in which agents communicate with KQML can be enriched with a special kind of agents called facilitators. 2.4 Common Object Request Broker Architecture (CORBA) Although KQML is presented as a solution to the problem of inter-agent communication, standard lower level infrastructures are needed to achieve real coordination and interoperation among applications. Keeping this in mind and considering the objectives of simplifying the development of distributed applications and providing flexible bases for higher level services, CORBA has been created. CORBA is a specification for a standard object-oriented architecture for applications. It is the result of the OMG (Object Management Group) consortium, which groups more than 650 companies. Its mission is to define interfaces for inter-operable software using the

object-oriented technology. The importance of CORBA lies in the fact that it uses the concept of object as the unifying metaphor to get interoperable applications regardless of their programming language and platform. A CORBA object interface must be defined in a declarative language called IDL (Interface Definition Language). This interface is independent of any programming language and operating system and includes constants, type declarations, exceptions, attributes and operations. From an IDL interface, language specific client stubs and server skeletons are generated by an IDL compiler. CORBA, as well as DCOM (Distributed Component Object Model) from Microsoft, are proposed as solutions to the agent communication problem. However, Mayfield et al. [1995] consider them as an agent technology within the category of coordination protocols and states that these technologies will be useful for agent development, but that they do not give complete answers to the agent communication problem because agents are not only set of data structures and methods. Mayfield considers that these protocols and standards can be the underlying layers to build agent languages. Another relationship between agents and CORBA is noted when software interoperation method based on agents is compared with object-oriented programming. Like objects, an agent provides an interface based on messages which are independent of its internal data structures and algorithms. The difference between these two forms of achieving interoperability lies in the meaning of messages, which can vary from one object to another, while in agent-based interoperability a common language with semantics is used, regardless of the agent [Genesereth et al. 1994]. Another difference is noted by FIPA [1997] when stating that agents communicate in a higher level of discourse, that is, communication contents are meaningful sentences about the environment

and knowledge of the agent, while in CORBA, interactions appear as method invocations among strongly encapsulated computational entities. 3.0 The problem of communication in the FDL As stated before, MICK addresses the issue of enabling communication among user agents and components of the FDL. The current architecture of the FDL is an evolution of the architecture presented in [Sánchez and Leggett 1997]. In this architecture four elements need to communicate with each other: the Active Library Services (ALiS), the User Agent Manager (UAM), the User Agent Director (UAD), and the set of user agents (see Figure 3).

Figure 3. FDL Architecture Elements (adapted from Cabrera [1997] and from Sánchez and Leggett [1997]). ALiS is the component that handles the agent abstractions and directly interacts with the DBMS underlying the FDL. The UAM is an interface through which digital library managers (librarians) can control agent classes, agent instances, users and predefined actions used by agents and library services. The UAD is the interface which end users of the digital library can summon any of their agents to see results or current progress of the assigned task, see relevant information related to their agents, and suspend, resume or terminate their activities. Through this interface, end users can also select

classes of agents to create new user agent instances. ALiS receives and executes requests from the UAD or UAM. This means that ALiS must be able to receive and interpret messages coming from these two components and respond adequately.The UAM needs to communicate with ALiS to notify about any change requested by the manager.The UAD component needs to establish communication with ALiS to request information about agent instances and agent classes and to notify about changes in agent instances. It also needs to communicate with agent instances to request changes in their status. The group of user agents refers to instances of agent classes that end users create and have been personalized and assigned specific tasks. They must be able to receive messages coming from the UAD, requesting changes in their status. Not only do they need to respond to these messages but they also need to start a dialog by sending a message to the UAD when their status is changed through their own interfaces. Without direct communication channels among these elements, communication is possible, for example, by means of a common message repository. This is highly inefficient, as in order to keep consistency the common message repository must be accessed very frequently. 4. MICK: A KQML Inter-Agent Communication Framework The solution proposed to the particular problem stated in the previous section is a communication framework named MICK. It is intended to avoid adding complexity to existing elements as well as facilitating the integration of new ones. Five MICK elements define an architecture by assisted coordination and are the following: a facilitator, a message router, an agent communication language, a shared vocabulary and a protocol (see Figure 4).

4.1 Facilitator This is a central element that defines the framework as an architecture by assisted coordination. It takes care of accepting connections, receiving register requests and keeping addresses of those elements registered. Its main function is that of a communication mediator. It prevents elements from keeping several connections and also from maintaining a list of other elements' addresses.

Figure 4. MICK elements and FDL components participating in communication Solid arrows represent channels through which messages are exchanged and dotted arrows denote function calls. 4.2 Message Router Every digital library element wishing to communicate with others using KQML requires an associated message router. This router takes care of registering the element with the facilitator, receiving messages and calling the proper functions of the element the router is associated with. The router also constructs messages, and sends them to the facilitator, which in turn forwards them to the intended element. All routers in MICK have the same structure but differ from each other in the vocabulary and the number of messages that they can handle. For example, the router for user agents can only handle messages requesting changes of state,

while the router for the UAD handles messages containing information about agent classes and agent instances in addition to messages relating to changes of state in agent instances. Two important features of these routers are the following: (1) they are independent processes and for this reason, sending and receiving messages is asynchronous, and (2) elements using these routers only require to know how to get them, what router operations are available to send messages, and implement the functions the router will call when receiving a message. 4.3 Language The language used to communicate the elements of the digital library is KQML (described in section 2.3). From all standard performatives in KQML, only a small subset is used. They are the following: 1) tell.- the message content is true in sender's environment. 2) achieve.- the sender requests the receiver to make the message content true in its environment (receivers's environment). 3) ask-about.- the sender wants all sentences that match the message content. 4) reply.- the sender believes that the message content is an appropriate answer to a previous request or question. 5) forward.- the sender wants the receiver to send the message content to another receiver. 6) sorry.- the sender has received a message to which it is not able to give a more meaningful answer. 4.4 Vocabulary A set of words were defined as MICK's vocabulary to be used in content messages. These words along with the performative are recognized by message routers to give meaning to the whole message. The words are the following: status, summon, active, suspended, terminated, added,

dropped, AgentInstance, AgentClass, User and Action. 4.5 Protocol Based on the performatives and the vocabulary presented before, a communication protocol was defined to structure communication between the UAD and user agents, between UAD and ALiS and between UAM and ALiS (see tables 1-3). All messages in the protocol are composed of a performative and a set of parameters starting with a colon. For the purpose of this paper all parameters except the content parameter are omitted. UAD

user agent

KQML Message achieve : content(status = suspended) achieve : content(status = active) achieve : content(status = terminated) achieve : content(summon)

Reply tell : content (status = suspended) tell : content (status = active) tell : content (status = terminated) None

Table 1. Communication protocol between UAD and user agents. The communication protocol between UAD and user agents contains messages referring to changes of status in agents and a message to summon agents. UAD

ALiS

KQML Message ask-about : content (AgentClass) ask-about : content (AgentInstance) achieve : content (AgentInstance = added) achieve : content (AgentInstance = suspended) achieve : content (AgentInstance = active) achieve

Reply reply : content (AgentClass) reply : content (AgentInstance) tell : content (AgentInstance = added) tell : content(AgentInstance = suspended) tell : content(AgentInstance = active) tell

: content (AgentInstance = terminated)

: content (AgentInstance = terminated)

Table 2. Communication protocol between UAD and ALiS The communication protocol between UAD and ALiS has messages referring to information about agent instances and agent classes. It also contains messages about changes of status and addition of new agents. UAM

ALiS

KQML Message achieve : content(Action = added) achieve : content(Action = dropped) ask-about : content Action achieve : content(User = added) achieve : content(User = dropped) ask-about : content (User) achieve : content(AgentClass = added) achieve : content(AgentClass = dropped) ask-about : content(AgentClass) ask-about : content (AgentInstance)

Reply tell : content(Action = added) tell : content(Action = dropped) reply : content Action tell : content(User = added) tell : content(User = dropped) reply : content (User) tell : content(AgentClass = added) tell : content(AgentClass = dropped) reply : content(AgentClass) reply : content (AgentInstance)

Table 3. Communication protocol between UAM and ALiS The communication protocol between UAM and ALiS refers to actions, users, agent classes and agent instances. 5. Working Prototype Three of the components of the FDL mentioned in section 2 (ALiS, UAD and UAM) were implemented by Cabrera [1995] as part of the FDL architecture using the CGI interface. From this work, the need of addressing the communication issue in a more efficient way came up. As a result of this need, MICK

elements and a new version of the UAD were implemented as part of a prototype using Java. Additionally, the agent router was transformed into a CORBA object and an Application Program Interface to access this router was created. This API now allows agents implemented in other languages besides Java (currently only C) to use the communication services offered by the message router. The following subsections present descriptions of the development tools, the implemented MICK elements, the new version of the UAD and the API. 5.1 Development Tools The working prototype was developed using Java Agent Template, Lite (JATLite) as the KQML implementation and Inter-Language Unification (ILU) as the CORBA implementation. JATLite was used to implement the facilitator, the ALiS router, the UAD router and the agent router. ILU was used to transform the agent router into a CORBA object. A brief description of these tools is given next. JATLite This is a set of Java packages created at Stanford University which eases the creation of agents and provides basic communication tools and models based on TCP/IP. JATLite helps in the development of agents that exchange KQML messages [Jeon 1997]. This tool is composed of five layers from which the developer can choose the most appropriate to start building the system. Each upper layer impose new restrictions to the agent applications. The five layers are the following: the abstract layer, the base layer, the KQML layer, the router layer and the protocol layer. ILU This CORBA implementation was created by Xerox Parc and can be used to build multilingual object-oriented libraries ("class

libraries") with well-specified languageindependent interfaces. It is described as a multi-language object interface system which provides interfaces that hide implementation distinctions between different languages, between different address spaces, and between operating system types. It allows programmers to define object interfaces in either IDL or ILU's Interface Specification Language (ISL). The version used for the prototype of MICK is ILU alpha 12, which supports the programming languages C++, ANSI C, Python, Java, and Common Lisp. Contributed support is also available for Modula-3, Guile Scheme, and Perl 5. 5.2 Implementation of MICK elements The elements of MICK implemented for this version include a facilitator, a message router for ALiS, a message router for the UAD and a message router for agents. As mentioned before, Java and JATLite were used for their implementation. The KQML layer of JATLite was used as the starting layer.

advance by the facilitator and the UAD message router. The implementation of the UAD’s message router establishes connections with ALiS and the facilitator and accepts connections from agent message routers. It is able to exchange messages with agent message routers concerning changes of agent status and also with ALiS concerning requests about agent instances and agent classes. The agent message router implementation registers the agent with the facilitator and enables agents to receive messages from UAD requesting a change in their status and messages summoning them. It also allows agents to send messages informing about a status change. For the case of an agent implemented as an applet, its message router will only be able to connect to a local facilitator (a facilitator running on the host where applet code comes from) due to security restrictions.

The facilitator for this prototype accepts connections from the UAD and from user agents. It also establishes a connection with ALiS in order to send undelivered messages in some cases. Since its main function is being a mediator in the communication process, the facilitator only receives messages requesting to forward the message content without examining it. Only when unable to deliver a message, the facilitator analyzes the message content to determine if the message should be redirected to ALiS. Message routers willing to use facilitator's services must know its address (host and port). The message router for ALiS is implemented for handling messages coming from UAD requesting information about agent classes and agent instances, requesting addition of new agents and requesting change of status for user agent instances. Its address must be known in

Figure 5. User agent director interface 5.3 Implementation of a new UAD version A new version of the UAD was implemented to test and show the communication capabilities of MICK. It was created as an applet showing a

single window divided in two parts (see Figure 5). The upper part shows user agent instances and their status as well as the available operations for them (summon, view information, resume, suspend, terminate, and terminate all). The lower part shows a list of available agent classes from which users can select one to create and start a new instance. When the user requests the creation of a new agent instance, an agent name and a description must be entered as well as the specific execution parameters for the agent class. This information is sent by the UAD message router to ALiS which can either start the execution of the new agent on the server side or send, as part of the reply, the location of the agent code (URL) so the UAD can start the agent on the client side. Once started, the message router of the new agent instance sends an initial message to UAD to indicate that it is ready to receive and send messages. When this message is received, the UAD makes the addition of the new agent instance visible to the user. 5.4 API for agents With the purpose of facilitating the addition of communication capabilities to agents created in different languages, an API was implemented. To achieve this, the agent message router had to be modified, an interface for agents had to be defined and language-specific functions to access the mediator object were implemented. Since the agent message router created originally as part of MICK was only useful for Java agents, it was transformed into a CORBA object using ILU. Its functionality did not change, it was only adapted to fit a new and simpler interface. To create the interface, a metaphor of a mediator helping someone to communicate with others in a different language (KQML in this case) was used. The interface written in ISL (native ILU interface specification language) is the following: TYPE Mediator = OBJECT

METHODS introduceMe(), tell(whom: String, what: String), sayBye() END; Through this interface an agent can ask the mediator to introduce it to other elements as the first step in establishing a dialog, then ask the mediator to tell some FDL element something and ,when leaving, ask the mediator to let the rest know that it will no longer be accessible for communication. Once having implemented the agent message router as a CORBA object another interface had to be defined for agents since the message router also requires to call agent operations. This interface also gives the message router a common view of all agents, regardless of the language in which they are implemented. The interface defined for agents is the following: TYPE KQMLAgent = OBJECT METHODS suspend(), terminate(), activate(), summon() END; Now, agents in any language wanting to interact with the message router for agents have to implement this interface according to the rules established by ILU, which vary from one language to another. Finally, to simplify the process of getting the agent message router, assistants for agents in Java and C were created. The Java assistant is an object with only one operation available, the one to get a mediator object. The C assistant is a library consisting of a function to get a mediator. 6. Ongoing and Future Work The work presented here provides a solution to the current need of communication among user

agents and components of a digital library using a variety of models and tools such as KQML and CORBA integrated in a framework named MICK. Although initial tests are encouraging, much work is needed to deploy MICK in a fully operational environment. Moreover, extensions to this work are possible and necessary. One of the most important extensions is integrating the UAM to the communication framework, which was postponed due to time constraints. This can be done by creating a message router similar to those for ALiS and UAD, but with a different vocabulary. However, for this router to work with UAM, the current version of UAM would have to be modified and use ILU again as the tool to make message router and UAM work together. Another option would be to build a new version of UAM in Java considering the communication facilities offered by MICK. Tests were done using only one facilitator and it is very likely that as the number of users increases, the workload of message transfer will have to be distributed among several facilitators and they will have to be structured as a federated system. This will also be necessary whenever the UAD communicates with applet agents coming from different hosts, because of security restrictions imposed by web browsers. The creation of the API for user agents simplified the use of message router for agents and make MICK services accessible for agents in languages other than Java, but it also introduced considerable overhead and some problems. The main problem introduced is the loss of connections when several agents concurrently exchange messages with the UAD. This problem can be solved and the overhead reduced having a better understanding of ILU which can lead to find the best possible use of this tool for this particular problem. It could also be necessary to extend the API by creating more language-specific assistants like those

created for agents in C or Java to help agent developers to add communication capabilities to their agents if they are implemented in other languages. A lot of work can be done to support interaction among user agents that utilize user information to refine the way they perform their assigned task. Specifically, collaboration among user agents addresses two common problems observed in this kind of agents: (1) Since these agents learn when watching the user, a lot of examples are required before they can really be useful and their predictions about the user behavior can be accurate, and (2) an agent is limited to learn only from its user. If the acquired experience by agents is shared, the time required for an agent to reach an acceptable level of usefulness would be lower and the agent could take advantage of the knowledge acquired by other user in situations where there is no antecedent [Lashkari et al.1994]. This would imply extending the current protocol and add features to the facilitator. For example, the facilitator would have to find message receivers not only by name but also by topics of interest and capabilities. Acknowledgments Part of this work is funded by grants from the Andrew Mellon Foundation and the National Science Foundation (DEB-9505383 and DEB9626806) References Cabrera, J. 1997. Integración de servicios y agentes de usuarios en la recuperación de información en una biblioteca digital. B.Sc. Thesis. Computer Systems Engineering Department. Universidad de las AméricasPuebla. Chauhan, D. 1998. JAFMAS, a Java-based agent framework for multiagent systems development and implementation. Ph.D.

Dissertation. Computer Science and Electric Engineering Department. Cincinnati University (Also available at: http://www.ececs.uc.edu/~abaker/JAFMAS). Finin, T., Labrou, Y., and Mayfield, J. 1995. KQML as an agent communication language. Technical Report. Computer Science Department. Maryland Baltimore County University. Baltimore, MD (Also available at: http://www.cs.umbc.edu/kqml/papers/). FIPA. 1997. Agent communication language. FIPA 97 Specification 1.0, 2. Foundation for Intelligent Physical Agents. Geneva, Switzerland (Also available at: http://drogo.cselt.stet.it/fipa/spec/fipa97/fipa97. htm). Fox, E., Akscyn, R., Furuta, R., and Leggett, J. 1995. Digital libraries. Communications of the ACM 38, 4, 23-28. Fox, E., and Marchionini, G. 1998. Toward a worldwide digital library. Communications of the ACM 41, 4, 29-32. Genesereth, M. R., and Ketchpel, S. P. 1994. Software agents. Communications of the ACM 37, 7, 48-53 (Also available at: http://logic.stanford.edu/sharing/papers/agents.p s). Genesereth, M. R., Singh, N. P., and Syed, M. A. 1994. A distributed and anonymous knowledge sharing approach to software interoperation. Technical Report. Computer Science Department. Stanford University.

Menlo Park, CA (Also available at: http://logic.stanford.edu/sharing/knowledge.html ). Guha, R.V., and Lenat, D. B. 1994. Enabling agents to work together. Communications of the ACM 37, 7, 127-142. Jeon, H.1997. JATLite overview. http://java.stanford.edu/java_agent/html/JATLit eOverview.htm. Stanford University. Lashkari, Y., Metral, M., and Maes, P. 1994. Collaborative interface agents. Proceedings of AAAI 1994 (Also available at: http://agents.www.media.mit.edu/groups/agents/ papers/aaai-ymp/aaai.html). Mayfield, J., Labrou, Y. and Finin, T. 1995. Evaluation of KQML as an agent communication language. Technical Report. Computer Science and Electric Engineering Department. Maryland Baltimore County University. Baltimore MD 21228-5398 (Also available at: http://www.cs.umbc.edu/kqml/papers/). Sánchez, J.A. and Leggett, J.J. 1997. Agent services for users of digital libraries. Journal of Networks and Computer Applications 21, 1. Sánchez, J. A. 1997. A taxonomy of agents. Technical Report. ICT-97-1. Laboratory of Interactive and Cooperative Technologies. Universidad de las Américas-Puebla, Cholula, Pue. 72820 (Also available at: http://ict.udlap.mx/pubs).

Adolfo Barceinas Education BS 1998 Computer Systems Engineering University of the Américas-Puebla Research Interests Inter-process communication, digital libraries, agents, CORBA. Experience Member of the Laboratory of Interactive and Cooperative Technologies (ICT) at UDLA-P.

J. Alfredo Sánchez Education PhD Computer Science Texas A&M University MS Computer Science Texas A&M University BS Computer Systems Engineering University of the Américas-Puebla Research Interests Human-Computer Interaction, Digital Libraries, Computer-Supported Cooperative Work, and Database Systems. Experience Professor and researcher at the Department of Computer Systems Engineering of the University of the Americas (UDLA); director of the Laboratory of Interactive and Cooperative Technologies (ICT); associate researcher at the Center for Botanical Informatics (CBI) of the Missouri Botanical Garden.

John L. Schnase Education PhD 1992 Computer Science BS 1986 Computer Science MS 1984 Biology/Chemestry BS 1981 Biology/Chemestry

Texas A&M University Angelo State University Angelo State University Angelo State University

Research Interests Hypermedia, multimedia, database, and operating systems; digital libraries; the human/computer interface; computer-supported collaborative work; large-scale scientific collaborations; computing environments of the future. Experience Director, Center for Botanical Informatics, Missouri Botanical Garden, September 1; Senior Research Associate, Department of Computer Science, Washington University.