OMAS—a flexible multi-agent environment for CSCWD

Future Generation Computer Systems 27 (2011) 78–87

Contents lists available at ScienceDirect

Future Generation Computer Systems journal homepage: www.elsevier.com/locate/fgcs

OMAS—a flexible multi-agent environment for CSCWD Jean-Paul A. Barthès UMR CNRS 6599 Heudiasyc, Université de Technologie de Compiègne, Compiègne, France

article

info

Article history: Received 6 November 2009 Received in revised form 6 March 2010 Accepted 7 May 2010 Available online 20 May 2010 Keywords: Computer supported cooperative work Multiagent systems

abstract CSCW requires efficient support to distributed teams. Several technologies seem to be good candidates for supporting CSCW among which groupware or agents. Groupware is efficient but rather inflexible, multiagent systems are more flexible but difficult to implement. OMAS (Open Multi-Agent System) is a multiagent platform derived from a number of previous research projects and teaching courses. With OMAS we tried to answer the problems of architecture, skill definition, protocol implementation, ontologies, dialog using natural language, and debugging, so as to simplify the work of an application designer. OMAS uses a ‘‘plug in’’ type approach offering a model of generic cognitive agent. Agents are of three types: service, personal assistants and transfer. They are organized as coteries, meaning that each agent sees all messages. Agents have separate ontologies and tasks models. Agents are multi-threaded and can execute several tasks concurrently. Personal assistants have prototype dialogs and vocal interface. OMAS has been designed for supporting CSCWD projects or applications. It can be downloaded from the Internet. © 2010 Elsevier B.V. All rights reserved.

1. Introduction Cooperative design requires strong cooperation, which is increasingly distributed and becomes multicultural. For example the design of an intervention after an incident in a power plant may require participants from several countries. Several technologies are good candidates to support the communication and organizational requirements needed to solve such problems, among which include groupware, web services or multi-agent systems. Groupware, exemplified by products developed on top of Lotus r offers excellent possibilities for handling documentation, Notes but is difficult to extend for supporting dynamic features, like live interaction, the use of legacy software, pro-activity, etc [1]. Web services, developed as an extension of object-oriented programming ported to the web environment are well qualified for supporting interaction. Although well adapted to building simple services on the Web, Web services require a lot of work for developing tools intended for cooperative work (see for example the Terregov project1 ). The multi-agent approach developed in the context of artificial intelligence provides interesting possibilities for building dynamic cooperative environments. Although the number of existing agent platforms is today rather impressive,2 few operational systems are reported in the literature (e.g. [2–5]). One of the reasons probably lies with the complexity of combining the needed features to fulfill the requirements of CSCW (Computer Supported Cooperative Work) environments.

E-mail address: [email protected]. 1 The Terregov project (European IP) aimed at developing a cooperative platform for helping civil servants do a better job in the domain of social care. It adopted a semantic web service approach. Results can be found at http://www.terregov.org. 2 See http://eprints.agentlink.org/view/type/software.html. 0167-739X/$ – see front matter © 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.future.2010.05.005

Several attempts however have been done to develop multiagent platforms so as to facilitate the building of applications. The best known effort can be attributed to the FIPA consortium3 that proposed to standardize a number of basic mechanisms, providing a minimal architecture upon which to build applications. The original target of the FIPA consortium was telecommunications. This lead to two open source platforms: JADE developed by TILAB4 and FIPA OS by Emorphia.5 Authors like Hao et al. however, noting the poor services offered by JADE, claimed that the architecture was too limited for building engineering applications easily. They offered adding a layer to improve its usability, which lead to the AADE platform [6,7]. However, although AADE provides additional functionalities, the basic approach remains the same, the overall system becoming more complex. Dimkovski and Deeb [8] qualify such approaches as formal-reductionist, missing the capacity of implementing real human-like intelligent functions based on interpretation of ontologies. We completely agree with their position and present a platform facilitating the development of systems positioned at the knowledge level as defined in their Functional Layered Intelligent model, but at the same time having the capability of including humans seamlessly. Thus, due to the lack of corresponding tools, the goal of this work has been to develop a multi-agent platform for building applications implying cognitive agents working at the knowledge level and relying on ontologies. The goal was to provide enough default features to let a non specialist build prototype applications

3 http://www.fipa.org. 4 http://jade.tilab.com. 5 http://sourceforge.net/projects/fipa-os.

J.-P.A. Barthès / Future Generation Computer Systems 27 (2011) 78–87

79

efficiently and easily. The paper presents first the requirements we considered; then describes the global architecture of the platform, then the three types of available agents; then platform features like multi-threading, skills, goals, message handling; then representations and ontologies. We then offer some information about debugging and interfacing with other platforms; then some information about personal assistants and the human interface. Finally we detail a small (programming) example that gives a programmer’s perspective; then conclude with future developments. 2. Requirements CSCW environments involve three different types of actors: (i) the end user; (ii) the developer of the application environment; and (iii) the developer of the basic supporting technology. The application developer must satisfy the user’s requirements, the technology developer must provide the application developer with the needed features in the tool box. In this paper, we focus on the developer of the basic technology, in this case multiagent platforms, trying to hide the complexity of communication operations and multi-threading and providing default mechanisms as one can find in typical artificial intelligence systems. Our approach is to consider multi-agent systems not as simple tools linking humans [9], but as an environment integrating both human and artificial agents working together [10]. For a developer of a multi-agent platform, requirements originate at two levels: (i) user’s requirements; and (ii) application designer’s requirements. 2.1. User Requirements Among the main users’ requirements we find:

• Distribution and flexibility, i.e. possibility of dynamic reconfiguration without interrupting the system.

• Agents providing services intelligently, e.g. agents volunteering relevant information, displaying proactive behavior.

• Integration of humans into the system, requiring easy interaction, e.g. the use of free spoken language.

• Integration of legacy systems. • Easy connection to new services (Internet, WS). • Capacity for the system to learn for later providing relevant information (knowledge management).

• Multilingual environments, e.g. providing translation services. • Privacy and protection. • Robustness against failures of components. 2.2. Application designer requirements Among the application designers’ requirements, we find:

• Simple architecture. • Easy programming. • Good debugging facilities. Note that a single point from this list can require quite some work (e.g., see [11] concerning failures and exceptions, or [12] for distributed programming). The role of the platform developer is to provide the essential mechanisms in a middleware so that the application developer can work easily to build an environment satisfying the user’s requirements.

Fig. 1. JADE architecture. The leftmost machine contains the agent manager (AMS) and the directory facilities (DF).

transport, defining agent skills, providing some standard interaction protocols. Using such libraries offers a good control about what the application designer intends to do, However, due to the low level of the modules, the approach requires a minimal amount of expertise in designing multi-agent architectures and necessitates a lot of work. At the other end of the spectrum, offers consist of providing models of agents and models of interactions and the corresponding middleware for building the application environment. For example, the FIPA group already mentioned proposes an architecture involving a special agent manager, white and yellow pages services, and a message transport mechanism. Such an architecture has been implemented for example in the JADE platform (Fig. 1). However in the JADE platform as in other similar approaches, some of the functionalities like Agent Management Services and Transportation Services (message handling) are gathered in a single machine, which makes the system more brittle. Replicating them adds more complexity. Furthermore, it compels each agent joining the system to declare its skills to the manager. Instead, we propose to organize the agents in a multilevel architecture based on the concept of ‘‘coterie’’. 3.1. Coteries The concept of coterie comes from applications in the domain of knowledge management. We wanted the agents to be organized in a coterie, i.e. a closely related group involved in global discussions. At the same time we wanted to let an agent be free to enter or to leave the group at any time. Thus, the decision was to define a platform not as a set of registered agents, but as a physical location, namely a network loop on a LAN. A coterie is then defined as a set of agents present on a LAN loop, sharing the same port address. One of the advantages of the decision is that we can deliver messages using UDP broadcast to all agents with a single message. The fact that each agent receives all messages amounts to say that agents are like a group of persons located in the same room, where each person overhears what the others say. This can be used by the agents to upgrade their internal representation of what is going on. In a coterie, all agents are independent. There is no repository of agent identities (white or yellow pages). Each agent is free to enter or to leave the coterie at any time. A consequence is that if a machine fails, no bookkeeping needs to be done on the other machines, which makes the system more robust.

3. Overall approach and platform architecture

3.2. Multi-level architecture

The first problem one encounters when trying to design a multiagent application is the choice of the overall architecture. Available architectures range from software module libraries to platforms using specific agent models. Most platforms consist of a library of modules providing basic services like defining an agent structure, handling message

Of course CSCW requires extensions beyond a local net loop. Thus, if we use the coterie approach several loops must be connected using gateways (Fig. 2). Our gateways are special agents called Transfer Agents (XA) detailed in Section 4.3. A message that occurs in a loop is automatically transferred to other loops by a transfer agent. As a test, we have deployed an OMAS platform,

80

J.-P.A. Barthès / Future Generation Computer Systems 27 (2011) 78–87

Fig. 3. Architecture of an OMAS service agent (SA) with personal assistant extensions. Fig. 2. The multi-agent architecture showing part of a coterie with Personal Assistants (PA), Service Agents (SA) and Transfer Agent (XA). DA, LA, OA, FA, JA are examples of Service Agents specific to the application (here a web search).

part of which is in Brazil, part of which is in France and part of which is in Japan. In addition, transfer agents can be programmed to interface with other types of platforms or to deal with Web services. Note that the coterie architecture is a physical grouping of agents, different from a software architecture like that of Ontozilla for example [13] in which groups are composed dynamically and an agent can belong to several groups. 4. Agents types and architecture In multi-agent applications agents have different roles, thus they require different structures. Defining the architecture of an agent and building it from fragments of software libraries is difficult. To simplify programming, OMAS provides ready-to-use generic models of agents comprising three types: service agents (SA), personal assistants (PA), and transfer agents (XA) (Fig. 2). The rationale for having three types of agents is that applications require services, human-machine interfaces and gateways. Each agent must be tailored to a particular application. However, contrary to a software library approach, an OMAS agent structure cannot be extended. The specialization is done through the definition of skills and goals. 4.1. Service agents Service agents are the basic type of agents. The structure of an OMAS SA is shown Fig. 3. SAs are composed of a Net interface, Skill repository, Self part containing self description and long term and short term memory, World model containing a description of the environment (most of the time other agents), Ontology and Control. User model and user interface are only present in personal assistants. 4.2. Personal assistants Since we want to create mixed environments with artificial and human agents, it is necessary to create human interfaces. Doing so from scratch is a very difficult task. To simplify the programmer’s task OMAS provides a default interface associated with personal assistants. Thus, Personal assistants are service agents in charge of letting humans be part of the environment. This is specially important for knowledge management applications, in which we want to exploit implicit knowledge directly. Details are given in Section 9.

4.3. Transfer agent Transfer agents are needed to communicate with distant local coteries or platforms with a different structure, e.g. FIPA compliant platforms. A transfer agent is a gateway implementing its own protocol, and translating communication and content languages. It may transfer all messages or select specific messages. A transfer agent receives all local messages (like any other agent) and can easily transfer them to distant parts of the coterie, or to other platforms. Conversely, whenever a message comes in from another platform, the transfer agent can broadcast it to the agents of the local coterie. The SPY agent. An example of transfer agent is the SPY agent. Each local coterie has a SPY agent as part of its IDE (Interactive Debugging Environment). The SPY agent receives all messages and displays them into a graphics window shown on the right part of Fig. 5. Although the SPY agent does not ‘‘transfer’’ data to another platform it uses the mechanism to maintain a display channel. 5. Features Our approach to supporting CSCWD led us to propose a platform in which agents are persistent, i.e. they are not created to perform a single task, multi-threaded, i.e. they can do several things at the same time. Protocols may be complex, given that legacy software must be taken into account as well as connections to other agent platforms. Furthermore, humans are part of the system rather than being outside the system, and the environment may be multilingual and multicultural. 5.1. Multi-threading A difficult point when developing an application is the problem of execution of a skill by an agent. Indeed, if the agent uses a single process (often the case with agents written in Java), then the skill has to be completed before another skill can be considered, which may lead to deadlocks. Alternatively, the programmer has to release the control explicitly within a skill to allow other skills to run, which makes programming more complicated. A much better solution is to use multi-threading. OMAS agents are multi-threaded (Fig. 4). A first thread takes care of incoming messages and either processes them directly (reactive behavior) or inserts them into an agenda. A second thread takes care of the agenda and for each task, creates two additional threads: one for processing the task, another one being a timer to kill the task after some predefined time. Personal assistants have a couple more threads to deal with the user through the user interface dialogs. Altogether, an agent may have a significant number of threads if it has several tasks to do at the same time. Tasks are thus processed in parallel in their own thread. Of

J.-P.A. Barthès / Future Generation Computer Systems 27 (2011) 78–87

81

Fig. 4. Muti-threading in OMAS agents showing a Personal Assistant with a scan process, an mbox process, task processes and a dialog process with the user.

Fig. 5. OMAS interactive development environment (Windows XP).

course, care must be exercised when accessing shared resources or synchronizing certain types of behaviors. Nevertheless, the programmer can then organize each skill as if it were the only one. The decision to add a timer to each task (execution of a skill) results from using long term agents. Indeed, we do not want to keep lingering processes in memory, waiting for some hypothetical event. The default maximal life time of a process is currently one hour. 5.2. Skill definition Skills are sometimes called ‘‘behaviours’’ and refer to what the agent must do. We think however that it is better to distinguish the skills of an agent (what it can do) from its goals (what it plans to do). 5.2.1. Skills OMAS distinguishes two types of agent skills: atomic skills and complex skills. Atomic skills execute without requiring any help from other agents, complex skills require results and cooperation from other agents. Skills are defined with a specific macro that can take a number of parameters (Table 1). Atomic skills have a static function, namely a function that will implement the skill. Complex skills have a static function and a dynamic function (actually a handler to receive the answers). All skills may have preconditions (a function in charge of checking if the skill can be fired), a time-limit option limiting its execution time and an acknowledge option to return an acknowledge message to

Table 1 Definition of a skill (AAA represents the agent, XXX the skill, fcn-XXX functions to be provided). (defskill :XXX :AAA :static-fcn static-XXX :dynamic-fcn dynamic-XXX :time-limit-fcn time-limit-XXX :timeout-handler timeout-handler-XXX :preconditions preconditions-XXX :select-best-answer-fcn select-best-answer-XXX :acknowledge-fcn acknowledge-XXX)

the sender if requested. Complex skills may have a timeout-handler to do something when answers from sub-contracts fail to return on time,6 and a select-best-answer function, used to select the answer on broadcast or Contract Net protocols. An important feature for the developer of an application is the possibility to handle time constraints directly at the level of the application rather than to let the underlying software do the work (e.g. automatic resend by a TCP protocol). Indeed, when sending a message, one may not know if there is any agent capable of answering it, or willing to answer it. If an OMAS agent does not want to answer a message, it simply does not answer it. Answering is not required since OMAS uses a connectionless protocol. This

6 We make a distinction between timeout and time limit. A timeout is the time a process is willing to wait before receiving an answer. A time-limit is the time allocated to a (sub-contracted) process to execute. Both are useful.

82

J.-P.A. Barthès / Future Generation Computer Systems 27 (2011) 78–87

Table 2 Sending a message using Contract-Net. (send-subtask agent :to :ALL :action :multiply :args (list nn (decf nn)) :delay delay :protocol :contract-net)

decision has the advantage of not overloading the network with useless messages. However, timeouts must be processed by the skills, which is the role of the timeout-handler option. We remark that, in general, the decision of what to do after a timeout occurs has to be taken at the application level anyway. 5.2.2. Goals OMAS implements goals separately from skills. Indeed, skills represent what the agent can do, goals what the agent intends to do.7 In this respect we depart from the attitude of mixing goals and skills as in the JADE approach that only provides the single mechanism of behaviours. Goals in OMAS can be oneshot, or cyclic. Goals are enabled by an enabling function that may block the triggering of the goal (somehow analogous to the precondition function for skills). A special mechanism of activation energy is planned: a goal can be activated when its energy becomes higher than a threshold level. However, the prototype applications developed up to now did not require this mechanism. 5.3. Handling messages and protocol implementation Handling messages may sometimes be a bothering problem, since the programmer has to wait for a message to come in, to filter it against the particular skill and to execute the targeted skill. OMAS simplifies the whole process: when a message reaches an agent, it wakes up the scan process that either processes the message in special cases, or puts it into the agenda. The mbox process then selects the message and distributes it to the right thread, calling the proper skill. Thus, selection and distribution of messages is done automatically by the middleware, simplifying the programmer’s work. Regarding protocols, OMAS implements several communication protocols: simple, broadcast and Contract Net. The OMAS agent communication language is simple and not very original, resembling KQML with the exception of a cancel-grant performative that allows granting contracts to a set of agents while at the same time cancelling the task for the other ones. This reduces racing conditions. The choice of the protocol is done at the message level. For example, using a contract-net protocol for distributing computations can be done is shown Table 2. 6. Representations and ontologies When designing applications involving cognitive agents it is necessary to include ontologies. Ontologies are used to understand the expressions of the content language, to build a knowledge base, or to interpret the utterances from the user. Thus, each agent may have its own ontology. An important question is the degree of integration of the ontology, the associated knowledge bases, or the associated reasoning mechanisms with the agent structure. OMAS uses a representation language called MOSS to express ontologies. MOSS8 is a framework for developing ontologies or knowledge bases. It has been made part of the OMAS platform and includes reasoning by means of a query system. MOSS ontologies can be multilingual and versioned. MOSS has a number of powerful features that cannot be developed in this article. We give a short summary of some of the MOSS features.

7 Note that this is different from the Desires and Intentions distinction of the BDI model. 8 See http://www.utc.fr/~barthes/MOSS/ for full documentation.

The MOSS formalism is based on two main points: properties are independent from concepts and defaults are the rule, like in semantic networks. In addition methods and demons can be defined and added to the ontology. Concepts are used to define ontologies, individuals constitute the knowledge base. 6.1. Properties We start with properties since they can exist independently from concepts and contribute to define objects that are not related to any concept. Properties are of two kinds: attributes9 and relations.10 Attributes and relations may have restrictions (cardinality, one-of, forall, exists, default, documentation). Attributes may define a possible index for accessing the objects having the property. Associated with properties are the traditional AI demons (ifadded, if-needed, if-removed) that are user-defined, as well as I/O demons (xi, format-value) for checking input and formatting output. Among the mentioned features, indexing is particularly useful, since it improves access efficiency greatly. When defined directly a property is translated into a generic property that may be used by any object, especially objects that are not attached to any concept. 6.2. Concepts and ideals Concepts are defined as objects with attributes, relations and some specific properties (name, super-, sub-concepts, documentation, . . . ). As stressed by Sun [14] it is important and handy to let programmers specify properties at the level of concepts. Thus, when a property is attached to a concept, a specific property is created as a sub-property of the corresponding generic property. If the generic property does not exist, it is automatically created. MOSS concepts do not have the role of specifier. They are simply an abstraction of the typical structure of an individual, meaning that individuals related to a concept may have properties not described in the concept itself (e.g. exceptional properties). Reasoning (through the query system) is done in term of typicality, not specification. Another important point is the decision to avoid creating subconcepts whenever it can be avoided. For example, we do not want to have a concept of Adult (i.e. a Person more than 18 years old) to avoid spreading actual individuals in a myriad of sub-concepts with multiple belonging. Thus, since we need the concept of Adult for reasoning, we create it as a non-instantiable concept (virtual concept), which translates internally into a rule to be applied at reasoning time. Defaults at the concept level are implemented through the notion of a special individual called ideal. It embodies a typical individual and has default values for properties. The ideal is not seen be the application programmer. 6.3. Methods MOSS has three kinds of methods: own-methods, that apply to a particular object; instance-methods, that apply to all individuals related to a given concept, unless shadowed by an own-method; and universal methods, that apply to all objects as a default method unless shadowed by instance- or own-methods. Methods are first class objects, i.e. individuals related to the concept of Method. 6.4. Individuals Individuals are objects that are determined by their properties. They may be related to a particular concept, to several concepts (multiple ‘‘belonging’’), or to no concept at all. An individual

9 Similar to OWL datatype properties. 10 Similar to OWL object properties.

J.-P.A. Barthès / Future Generation Computer Systems 27 (2011) 78–87 Table 3 Definition of a city. (defconcept (:en ‘‘town; city’’ :fr ‘‘ville; cité’’) (:att (:en ‘‘name’’ :fr ‘‘nom’’)(:unique)(:index)) (:att (:en ‘‘French department’’ :fr ‘‘département’’) (:to ‘‘département’’)(:unique)))

83

use this last formalism since the MOSS frame formalism integrates seamlessly. 7. Programming and debugging 7.1. Programming

Table 4 Example of content language using ontology concepts. ((:query (‘‘person’’ (‘‘has-first-name’’ :is ‘‘Dominique’’))) (:pattern (‘‘person’’ (‘‘name’’) (‘‘phone’’))

may play the role of a prototype for another individual, pending a classification. During their life individuals may be related to different concept, changing dynamically. 6.5. Multilingual features International cooperation compels us to define and use multilingual ontologies, which is implemented through multilingual names as shown Table 3. 6.6. Query language Reasoning in MOSS is done through the query language, which includes conjunction, disjunction, negation, and handles virtual concepts, versions and multi-lingual features. 6.7. Versions The concept of version corresponds to that of configuration. MOSS uses a configuration tree with sequential and parallel versions. Creating a new version must be done explicitly. MOSS can deal with all versions simultaneously (i.e. it has not the concept of roll-back, all versions are accessible through a with-version macro).

Programming OMAS requires plugging in functions to specify particular skills or goals. Most of the implemented features have default behavior, so that one can start running an application with minimal code. 7.2. Interactive debugging environment Developing MAS applications requires being able to visualize what happens when the application is running, which presents a serious problem when applications are asynchronous and multithreaded. OMAS like many other platforms offers a minimal development environment (Fig. 5) to visualize exchanges of messages, the state and content of agents, to trace execution of skills, to send messages directly so as to exercise the coterie. However, one has to admit that such a standard environment is limited for designing complex applications. 8. Interfacing with other systems Designing CSCW applications requires including legacy software or interacting with other systems. OMAS allows this to be done easily through the concept of the Transfer Agent. A transfer agent is also useful for connecting remote local coteries to make them part of the global coterie. Transferring messages can be done using any transport protocol but is usually implemented through TCP/IP. We have interfaced the OMAS platform with:

• JADE a platform written in Java in an application involving 6.8. Agent use of ontologies

English auctions.

• DASH, a platform for collecting GPS signals developed at CIT Agents use ontologies for several purposes: one is to organize their knowledge base and self representation; another one is for communicating with other agents or with humans. Local use. Local use is straightforward, allowing to define various representations of the agent itself (skills, owner, tasks, dialogs), or domain concepts and associated knowledge bases. Content language patterns. OMAS agents are defined in their own name space (Lisp package). They do not share ontologies physically. They have different ontologies, but must share a toplevel part of their ontology. The amount of sharing is application dependent. When agents send messages, using the OMAS content language, they can specify a query and a pattern using the ontology concepts. Table 4 shows part of the content language associated with a request for a telephone number of persons whose first name is Dominique. The answer is required to contain the name(s) and telephone number(s) of the solutions. Communication with humans. Communications with humans are handled by personal assistants (see Section 9). Ontologies are of course crucial in that case. Personal assistant ontologies include among others the concepts of task, dialog, dialog state. Individuals correspond to individual tasks. 6.9. Export Finally, simple (i.e. non versioned) ontologies using a restricted set of MOSS features can be translated into a mixture of OWL objects and JENA (or SPARQL) rules. However, OMAS does not

(Chiba Institute of Technology) in Japan.

• VIRTOOLS, a Virtual Reality environment in which avatars are represented by OMAS agents. An application called V3S simulates interventions in Seveso-type plants after a problem (Fig. 6). • PACPUS an onboard platform monitoring car sensors in realtime (10 µs). Using OMAS transfer agents it is also possible to call:

• Any type of Web Service, using WSDL syntax. • Translation services from the Web. • Mail services. 9. Human interface 9.1. Natural language interfaces The question of the human interface to an SMA is crucial. When applications become complex traditional approaches like ‘‘point and click’’ break down. Menus become difficult to use and to maintain. A better interface consists of using natural language. Unfortunately natural language understanding is out of reach of machines. However, most applications require only a limited understanding that amounts to selecting some action. Thus, a personal assistant (PA) may have a set of tasks that it knows how to solve. They can be represented as individual task objects, instantiated from the concept of task. When a human user requests her PA to do something, the PA selects a set of tasks, ranks them and

84

J.-P.A. Barthès / Future Generation Computer Systems 27 (2011) 78–87

Fig. 6. The V3S Seveso plant simulation application.

is to keep the PA relatively simple, with an ontology limited in size and complexity, and to leave the detailed technical problems to the more specialized staff agents. The Resulting OMAS architecture is shown Fig. 2. 9.3. Learning

Fig. 7. Example of a dialog with a PA (Enembreck [15]).

triggers the dialog associated with the more relevant one. Specific task dialogs can then be developed, included in a library of dialogs and used to gather enough information for executing the task. This is the approach used in OMAS. Fig. 7 gives an example of what can be done with an OMAS PA. Since we are convinced that CSCW applications cannot be conducted if the use of the PA is not facilitated by speech understanding, we added vocal interaction to improve the human/machine interface [16]. 9.2. Implementation In addition to the standard features of a service agent, personal assistants include a user model and a user interface. The user model contains a library of dialogs. The user interface executes the required dialogs (typed or vocal). A defassistant macro creates a PA and opens a default interface window (Fig. 8). Consequently, to define the user interface the application programmer has to design dialogs required for the application and to add them, together with an associated ontology. We found however that having a simple PA for interfacing a human user is not a good idea, since when the number of services increases, the complexity of the PA increases accordingly, and soon it becomes so complex that maintaining its code is very demanding. Therefore, we split the PA into several pieces, limiting the role of the PA to handling the model of user and dialogs with the user, and putting more specialized information into service agents defined to be the PA staff. This approach corresponds to the concept of digital butler proposed by Negroponte [17]. The main advantage

If we want our agents to be able to manage knowledge efficiently, they should have the possibility of learning. Thus, personal assistants have a mechanism that creates cases from the dialog with the user and organizes them in a case base. They are later used for answering questions or reusing solutions to problems [18]. 10. Discussion and example 10.1. OMAS vs. other platforms We did not spend too much time testing many other platforms in detail. However, we did some comparison with ZEUS [19] a few years ago, and with other French platforms using the benchmarks from the ASA group of the Agent College of AFIA (Association Française pour l’Intelligence Artificielle). In addition, in a course on multi-agent systems at UTC, projects are done using both OMAS and JADE. The ZEUS platform was tested in a UNIX environment and besides being very slow did not offer enough control during the sending and handling of messages. Anyway, it does not seem to be available any longer. The results from the benchmark of the French systems are reported in a paper that was published a few years ago [20]. Other platforms used Java, C++, C or even Prolog. OMAS was the only Lisp platform. ASA benchmarks tested the way of writing and solving test problems that included distributed factorial, English auction, distributed time tables, or workflow applications. Comparing with JADE, the (senior) computer science students taking the course entitled Multi-Agent Systems at UTC (Université de Technologie de Compiègne) indicate that they favor JADE because they are familiar with Java and Eclipse, but agree that OMAS is much faster and much more concise for complex applications, in particular involving the use of ontologies.

J.-P.A. Barthès / Future Generation Computer Systems 27 (2011) 78–87

85

Fig. 8. Default conversation window for a Personal Assistant (dialog occurs in the right hand part of the window, the left bins contain various types of messages).

The research side is different because we do not use other platforms for implementing our research prototypes. However, as mentioned in Section 8, we built hybrid OMAS-JADE, OMAS-DASH, and OMAS-PACPUS systems for feasibility tests. This did not pose any serious problem, since we could have cooperation between different agents living on different platforms. Compared with other platforms, OMAS is not intended to be a delivery platform. It is best used for prototyping complex applications since it is easy and fast to do so. 10.2. Example The following code illustrates the OMAS approach. We use examples found in the tutorials for the JADE platform so that interested readers can compare easily. For lack of space we cannot reproduce the Java code, but it can be found easily in the JADE documentation ([21,22] for ontologies). The first example consists of defining a BUYER agent that has to buy books from SELLER agents [21]. Defining agents. An OMAS agent is defined in its own file within its own name space. SELLER-1 is defined as follows: (defpackage :seller-1 (:use :moss :omas :cl)) (defagent :seller-1)

Once declared OMAS agents are active and reside on the local net loop. There is no need to register anywhere. However, after creation agents do not have any skills. Skills must be added (which can be done dynamically). Giving agents skills. Let us describe two different skills: the first one is for SELLER-1 to answer an inquiry about a specific book; the second one is more complex and corresponds to the buying strategy of the BUYER. The names of the skills are taken from the JADE tutorial. (defskill :offer-request :SELLER-1 :static-fcn static-offer-request) (defUn static-offer-request (agent message title) "service a request for a particular title. If there return its price, ~ otherwise does not bother answering." (declare (ignore message)) (let ((stock (assoc title (recall agent :books) :test #’string-equal))) (static-exit agent (if stock (cdr stock) :abort))))

The :offer-request skill is used to answer the question from the buyer about the availability of a particular book. It uses the agent memory (recall function). (defskill :request-performer :BUYER :static-fcn static-request-performer :dynamic-fcn dynamic-request-performer :select-best-answer-fcn select-best-answerrequest-performer) (defun static-request-performer (agent message title) "Tries to buy a book by broadcasting an offer, and taking the ~ cheapest answer." ;; ask about the prices of the book (send-subtask agent :to :all :action :offer-request :args (list title) ;:strategy :collect-answers :timeout 10 ; allow 10 seconds to answer ) ;; write title in the environment (env-set agent title :trying-to-buy) (static-exit agent :done)) (defun dynamic-request-performer (agent message data) "Whenever we get an answer here, we send a purchase order." (let ((title (env-get agent :trying-to-buy))) (cond ;; first time around ((null (env-get agent :purchasing)) ;; send purchase order whenever data is non nil (if data (progn (send-subtask agent :to (omas::from! message) :action :purchase-order :args (list title)) ;; set up marker in the environment (env-set agent t :purchasing)) ;; when no data then quit (dynamic-exit agent "book purchased"))) ;; second time around, answer to the purchasing order ((eql data :done) ;; record that we now own the book (remember agent (cons title (recall agent : my-books)) :my-books) ;; remove it from the list of books to buy (remember agent (remove title (recall agent :books-to-buy) : test #’equal)

86

J.-P.A. Barthès / Future Generation Computer Systems 27 (2011) 78–87

:books-to-buy) ;; should also decrease the amount of money... (not done) (dynamic-exit agent "book purchased")) ;; otherwise we have an error and give up (t (dynamic-exit agent :abort)))))

(defontology (:title "MUSIC shop ontology") (:version "1.0") (:language :en))

(defun select-best-answer-request-performer (agent environment answer-message-list) "keep the cheapest offer" (declare (ignore agent environment)) ;; order the collected answer messages by increasing prices ;; we do that only when there is more than one answer (when (cdr answer-message-list) (setq answer-message-list (sort answer-message-list #’<= :key #’omas ::content))) ;; select the message corresponding to the lowest price (omas::contents (car answer-message-list)) )

(defconcept "CD" (:is-a "Item") (:att "name") (:rel "tracks" (:to "Track")))

The skill here has three parts: the first part (static) initiates the buying process by sending a broadcast message to all other agents; the second part is more complex, if after waiting for 10 s the buyer has a best offer, it then sends a purchase order. Collecting the answers is done by OMAS automatically, the application programmer must however provide the application dependent function for selecting the best answer (select-best-answer-requestperformer). Note that there is not a single line for selecting messages or returning answers. The agent memory is used to store the data concerning books to buy. A special task storage area managed by the env-get and env-set functions allows to keep information specific to the particular task corresponding to the skill. Setting up a goal. The buyer agent has a cyclic goal (distinct from its skills) defined as follows: (defgoal buy-book :BUYER :type :cyclic :period 10 ; seconds :goal-enable-fcn enable-buy-book :script goal-buy-book) (defun goal-buy-book (agent) (list (make-instance ’omas::message :type : request :from (omas::key agent) :to (omas:: key agent) :action :request-performer :args (list (car (recall agent :books-to-buy))) ))) (defun enable-buy-book (agent script) "goal is enable each time there is something in the books-to-buy" (declare (ignore script)) (recall agent :books-to-buy) )

The goal is defined as a cyclic goal with a period of 10 s (for demonstration purposes). The script defines a message that the agent will send to itself. A specific function (enable-buy-book) enables the goal only when there are books to purchase in the agent memory. Ontologies. The ontology for purchasing books is fairly trivial. We thus take the ontology developed in the Jade Tutorial on ontologies [22] regarding music records, which MOSS expresses as follows:

(defconcept "Item" (:att "serial number"))

(defconcept "Track" (:att "title") (:att "duration")) (defconcept "Book" (:is-a "Item") (:att "title") (defconcept "Seller" (:rel "sell" (:to "Item"))) (defconcept "Buyer" (:rel "buy" (:to "item"))

Those few lines are enough to define an ontology strictly equivalent to the JADE one. From then on, agents can use it in queries or messages. It should be compared with the 25 pages of the JADE ontology tutorial. A multilingual ontology as shown Fig. 3 is not much more complex to define. The music-shop ontology is very simple. In engineering situations ontologies are more complex. The following example, taken from the V3S project models the concept of opening a gate, with pre- and post-conditions on the action expressed as default rules. (defconcept "mv-ouvrir-vanne" (:is-a "mv-vanne-action") (:att "rules" (:default (:if (?* "mv-vanne" ("statut" :is "ouvert")) :then (:return :success)) (:if (?* "mv-vanne" ("statut" :is "ferme")) (?* "mv-vanne" ("etat" :is-not "grippe")) :then (:set ?* "statut" "ouvert") (:return :success)) (:if (?* "mv-vanne" ("statut" :is "grippe")) :then (:return :failure)) )))

Conclusion. From the examples, it can be seen that there is no provision for handling messages, nor dealing with threads. This is hidden to the application programmer. When a message comes in, the function corresponding to the skill is called automatically. Afterwards, returning from the function creates (or not) an answer message. OMAS makes sure that messages are delivered to the right thread, which simplifies programming. The approach is a kind of plug in approach in which the application programmer provides the pieces overloading the system defaults, which is quite efficient when prototyping. 10.3. Projects The OMAS platform has been used for developing CSCWD projects, and is used currently for similar projects:

J.-P.A. Barthès / Future Generation Computer Systems 27 (2011) 78–87

• V3S is a project intended to design interventions in SEVESO plants (risky environments). The approach is to build a team mixing artificial and human agents represented by avatars in a virtual reality setting and playing different games according to different initial conditions and different agent profiles (including physical and psychological conditions). Each agent has its own representation of the world as filtered by its perception mechanism.

• TATIN is a beginning project centered on collaborative preliminary design, using multi-touch multi-user graphics table (and interactive boards). Each participant around the graphics table will be interfaced vocally to the system through personal assistants, and service agents will work in parallel to provide timely information.

• TWA (Trans-World Agents) consists of installing the OMAS platform across different countries (Brazil, France, Japan, Mexico) and study multicultural problems in cooperative design. The idea is to smooth cultural difference through personal agents, keeping interactions in the local language.

11. Conclusion and future developments We hope to have shown in this paper through the OMAS example that it is possible to develop multi-agent platforms answering most of the requirements of CSCWD. Applications can be distributed easily; applications can be developed in a very flexible manner; agents can use ontologies to represent knowledge as well as knowledge bases; humans can be included in the system through personal assistant agents in multilingual environments; other platforms, legacy systems can be connected. What is missing though is the capacity for an agent to learn easily, and privacy/protection mechanisms. However, we are not actually too concerned with the latter, since we are interested in developing essentially prototypes. A P2P approach makes the system robust, and providing default mechanisms can simplify programming. Debugging heavily multi-threaded distributed asynchronous multi-agent applications still remains a challenging task. A key point in such approaches is to integrate the representation mechanisms for developing ontologies and knowledge bases, skills and goals, and content language, within the environment of the agent platform. In the near future, we plan to install a sophisticated agent memory system that can build cases from the dialogs between a user and its personal assistant [18], allowing an agent to learn from past situations. Availability: OMAS is implemented in LISP11 using MCL 5.2 on Macintosh OS X 10.4, and using Franz ACL 8.1 on Windows XP. It may be downloaded for tests, including a full documentation.12

Acknowledgements Over the years, a number of Ph.D. students have helped in designing, developing and testing the OMAS platform. Among them: M. Vayssade, M. Ramos, W. Shen, E. Scalabrin, F. Enembreck, C. Tacla, E. Paraiso, K. Chen, L. Edward, O. Gonzales.

11 It is one of the very few platforms available in Lisp. 12 http://www.utc.fr/~barthes/OMAS.

87

References [1] C.A. Tacla, J.-P.A. Barthès, Agent-supported portals and knowledge management in complex R&D projects, Computers in Industry 48 (1) (2002) 3–16. [2] S.D.J. McArthur, E.M. Davidson, V.M. Catterson, A.L. Dimeas, N.D. Hatziargyriou, F. Ponci, T. Funabashi, Multi-agent systems for power engineering applications — Part I: concepts, approaches, and technical challenges, IEEE Transactions on Power Systems 22 (4) (2007) 1743–1752. [3] S.D.J. McArthur, E.M. Davidson, V.M. Catterson, A.L. Dimeas, N.D. Hatziargyriou, F. Ponci, T. Funabashi, Multi-agent systems for power engineering applications — Part ii: technologies, standards, and tools for building multiagent systems, IEEE Transactions on Power Systems 22 (4) (2007) 1753–1759. November. [4] S. Rahman, M. Pipattanasomporn, Y. Teklu, Intelligent Distributed Autonomous Power Systems, IDAPS, in: Proc. the IEEE PES Meeting in Tampa, Florida, 1–8, June 24–28, 2007. [5] W. Shen, D. Norrie, J.-P.A. Barthès, Multi-Agent Systems for Concurrent Intelligent Design and Manufacturing, Taylor & Francis, 2001. [6] Q. Hao, W. Shen, Z. Zhang, An autonomous agent development environment for engineering applications, Advanced Engineering Informatics 57 (1) (2005) 123–134. [7] Q. Hao, W. Shen, Z. Zhang, S.-W. Park, J.-K. Lee, Agent-based collaborative product design engineering: an industrial case study, Computers in Industry 19 (2006) 26–38. [8] M. Dimkovski, K. Deeb, Knowledge technology through functional layered intelligence, Future Generation Computer Systems 23 (2007) 295–303. [9] H. Liu, M. Tang, J.H. Frazer, Supporting dynamic management in a multi-agent collaborative design system, Advances in Engineering Software 35 (2004) 493–502. [10] J.-P.A. Barthès, MASH Environment for Corporate KM, Knowledge Management Workshop of IJCAI 2003, Acapulco, Mexico, 2003. [11] N. Shah, R. Iqbal, A. James, K. Iqbal, Exception representation and management in open multi-agent systems, Information Sciences 179 (2009) 2555–2561. [12] B. Stack, G. Hsiao, S.F. Jenks, A middleware architecture to facilitate distributed programming DAROC: data-activated replicated object communications, Future Generation Computing Systems 22 (2006) 88–101. [13] T.-J. Joung, F.Y. Chuang, OntoZilla: An ontology-based, semi-structured, and evolutionnary peer-to-peer network for information systems and services, Future Generation Computer Systems 25 (2009) 53–63. [14] X. Sun, OSLN: an object-oriented semantic link network language for complex object description and operation, Future Generation Computer Systems 26 (2010) 389–399. [15] F. Enembreck, J.-P.A. Barthès, C.A. Braulio, Dialog with a Personal Assistant, Advances in Artificial Intelligence, SBIA’04, São Luis, Brasil, vol. LNAI 3171, pp. 204–213, Springer, 2004. [16] E.C. Paraiso, J.-P.A. Barthès, An intelligent speech interface for personal assistants in R&D projects, Expert Systems with Applications 31 (2006) 673–683. [17] N. Negroponte, Being Digital Westminster, Alfred a Knopf Inc, Maryland, USA, 1995. [18] K. Chen, J.-P.A. Barthès, Giving an office assistant agent a memory mechanism, in : Proc. ICCI08, 2008. [19] L.C. Lee, D.T. Ndumu, H.S. Nwana, ZEUS: an advanced toolkit for engineering distributed multi-agent systems, in: Proceedings of the Practical Application of Intelligent Agents and Multi-Agent Systems, London, pp. 377–392, 1998. [20] J.-P.A. Barthès, P. Chevallier, R. Courdier, Z. Guessoum, O. Gutknecht, P. Mathieu, M. Ocello, in: R. Mandiau, E. Grislin-Le Strugeon, A. Péninou (Eds.), Comparaison des plates-formes SMA francaises à travers un toy problem, Lavoisier, Paris, 2002, 333–344 (in French). [21] G. Caire, JADE TUTORIAL: JADE programming for beginners, TILAB formerly CSELT, 2003. [22] G. Caire, JADE TUTORIAL: Application-defined content language and ontologies, TILAB formerly CSELT, 2002.

Jean-Paul A. Barthès obtained his Engineering degree from Ecole Centrale de Paris (France) and his Ph.D. from Stanford University (1973). Currently, he is a professor in the department of Computer Science at the University of Technology of Compiègne (UTC) in France. His main research interests are related to Distributed Artificial Intelligence and mixed societies of cognitive artificial and human agents. He is also the chairman of the IIIA Institute, a European program for helping large companies to cope with the problems of Knowledge Management.