Multiagent Architecture for D-Sifter

0 downloads 0 Views 3MB Size Report
In contrast the lat- ter one is using the Sifter approach as a basis and is worked out in more detail. ... reason a short foundation for information retrieval and filtering (section 1.1) and intelligent ...... The messages have the format of standard text.
Multiagent Architecture for D-Sifter A modern approach to flexible information filtering in dynamic environments

Ingo J. Timm TZI-Bericht Nr. 21, 2000

Multiagent Architecture for D-Sifter A modern approach to flexible information filtering in dynamic environments Technical Report Ingo J. Timm

October 2000

Preface This report summarizes the results of my stay at the Computer Science Department at the Indiana University-Purdue University Indianapolis (IUPUI) from August 1st , 1999 until February 15th , 2000. I like to thank Prof. Dr. M. Palakal (IUPUI, Indianapolis, U.S.A.) and my advisor Prof. Dr. O. Herzog (University of Bremen, Germany) for providing the opportunity of this research exchange during my PhD scholarship. My special thanks are going to all members of the project team at IUPUI, who gave me substantial support, both in private and professional aspects. Resuming my stay in Indianapolis I am very happy to state that I learned a lot about new topics in information filtering - which was not part of my previous research -, had a lot of interesting discussions and learned that it is sometimes not easy to discuss issues in a foreign language.

ii

Contents 1 Foundation 1.1 Information retrieval and filtering (SIFTER) . . . . . . . . . . . . . . . . . 1.2 Intelligent agents and multiagent systems 1.2.1 History . . . . . . . . . . . . . . . 1.2.2 Basic concepts . . . . . . . . . . . 1.2.3 Agent architecture . . . . . . . . 1.2.4 Multiagent architecture . . . . . . 1.2.5 Communication . . . . . . . . . . 1.3 Related work . . . . . . . . . . . . . . . 1.3.1 MIT Media Lab . . . . . . . . . . 1.3.2 University of Bremen - TZI . . . 1.3.3 CISC - IUPUI . . . . . . . . . . . 2 Multiagent information filtering 2.1 Motivation . . . . . . . . . . . . . . . . . 2.1.1 The filtering and retrieval process 2.1.2 Agent-oriented design: AWIC . . 2.2 Design . . . . . . . . . . . . . . . . . . . 2.2.1 Agent model . . . . . . . . . . . . 2.2.2 World model . . . . . . . . . . . 2.2.3 Interoperability model . . . . . . 2.2.4 Coordination model . . . . . . . . 2.3 Specification of domain knowledge . . . . 2.3.1 Hierarchical domains . . . . . . . 2.3.2 Domain in a market place . . . . iii

3 . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

3 8 9 10 13 14 17 21 22 22 27

. . . . . . . . . . .

28 29 29 31 32 32 37 39 39 41 41 43

iv 3 Multiagent D-Sifter 3.1 Introduction . . . . . . . . . . . . . . 3.2 Architecture . . . . . . . . . . . . . . 3.2.1 General Approach . . . . . . . 3.2.2 Communicator . . . . . . . . 3.2.3 Controller . . . . . . . . . . . 3.2.4 Executor . . . . . . . . . . . . 3.3 Design . . . . . . . . . . . . . . . . . 3.3.1 System overview . . . . . . . 3.3.2 Agents . . . . . . . . . . . . . 3.3.3 Agent interaction . . . . . . . 3.3.4 Agent control . . . . . . . . . 3.3.5 Market-based decision model . 4 Resume

CONTENTS

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

45 45 46 47 49 67 77 78 78 81 88 94 103 106

List of Figures 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16

Model of the filtering process . . . . . . . . . . . Agents mediating inter-enterprise communication Agent as a black-box . . . . . . . . . . . . . . . . Agent as an expert system . . . . . . . . . . . . Goal-based agents . . . . . . . . . . . . . . . . . Multiagent system . . . . . . . . . . . . . . . . . Shared memory . . . . . . . . . . . . . . . . . . . Message passing . . . . . . . . . . . . . . . . . . . Structure of communication . . . . . . . . . . . . Auction . . . . . . . . . . . . . . . . . . . . . . . Negotiation . . . . . . . . . . . . . . . . . . . . . Contract net protocol . . . . . . . . . . . . . . . Bilateral communication . . . . . . . . . . . . . . Hyperedge . . . . . . . . . . . . . . . . . . . . . . Distributed blackboard communication . . . . . . Complex communication hierarchy . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

6 11 13 14 15 16 17 18 19 20 20 21 23 24 25 26

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8

Components of the AWIC approach . . . . . . . . . Global view to system boundaries . . . . . . . . . . Domain - class agent relationship . . . . . . . . . . Overview: agents . . . . . . . . . . . . . . . . . . . Agent world with interopability relations . . . . . . Communication channels . . . . . . . . . . . . . . . Example: domain hierarchy computer science . . . Example: interdisciplinary domain Bio-Informatics

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

31 33 36 37 38 40 42 43

3.1 3.2 3.3

3-Level architecture for agents . . . . . . . . . . . . . . . . . . 47 Workflow for an incoming message . . . . . . . . . . . . . . . 50 The communicator layer . . . . . . . . . . . . . . . . . . . . . 51 v

vi

LIST OF FIGURES 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24

Abstract Elements of Service Class . . . . . . . . Message flow within the communicator . . . . . . Abstract Class Translator (has part) . . . . . . . Class Hierarchie . . . . . . . . . . . . . . . . . . Design of communicator . . . . . . . . . . . . . . Example of a simple ACL message . . . . . . . . Example: XML encoded ACL message . . . . . . Design abstract data type letter . . . . . . . . . . Example of a letter object in multiagent D-Sifter Components of the Controller . . . . . . . . . . . Main object of the controller . . . . . . . . . . . . inference . . . . . . . . . . . . . . . . . . . . . . Inheritance hierarchy of agent classes . . . . . . . Architecture of the Multiagent D-Sifter . . . . . . Definition for conversation figures . . . . . . . . . Conversation: Registration . . . . . . . . . . . . . Conversation: Unregistration . . . . . . . . . . . . Conversation: What domains are available . . . . Conversation: New Documents . . . . . . . . . . Overview: control in Multiagent D-Sifter . . . . . Cash flow within Multiagent D-Sifter . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

52 53 54 55 56 63 63 64 67 68 69 76 79 80 89 90 90 91 92 95 104

Introduction In recent years the amount of available information in almost any areas of life has risen enormously. Professionals are confronted with a world, in which information sources of any kind are connected and integrated in computer networks. The most famous one - the so-called Internet - enables people all over the world to share information about developments, trends, research etc. in the shape of documents. This great enhancement of intellectual potential and the new chances for distributing and sharing cognitive processes implies on the other hand a increasing need for organization and filtering of information provided by these new sources. Information filtering and information retrieval has been an actual subject of ongoing research in computer science and artificial intelligence for this reason in recent years. The exponential increase of relevant information accessible in the new information environment serves as a booster for this research. Currently one of the most promising research fields in computer science in order to support the automation of information filtering and retrieval are multiagent systems [Balabanovic, 1997], [Clack et al., 1997], [Moukas, 1996], [Knoblock and Ambite, 1997], [Malone et al., 1997]. Intelligent agents represent a modern approach in Artificial Intelligence and distributed software engineering dealing with software entities which can act autonomously, communicate with other agents, are goal-oriented (pro-active) and are using explicit knowledge [Weiss, 1999].

1

2

INTRODUCTION

They are often used for tasks, which can be hardly solved monolithically and are showing a natural distribution, such as information networks. In these domains agents gain great benefit as they are able to collaborate and solve problems in a distributed manner. Especially in the field of information logistics there is a huge unused potential of this technology [Knirsch and Timm, 1999]. Representing user interest agents are capable of organizing, controlling and managing information flows autonomously. The topic of this report is design of a multiagent architecture for information retrieval and filtering. Focusing on an enhancement of the existing non-distributed information filtering system Sifter [Mostafa et al., 1997] two concepts will be presented. The first approach stays on a high level of abstraction using an alternative filtering process. In contrast the latter one is using the Sifter approach as a basis and is worked out in more detail.

Chapter 1 Foundation The main task of this project is the integration of information retrieval and filtering on the one hand and multiagent systems on the other. For this reason a short foundation for information retrieval and filtering (section 1.1) and intelligent agents and multiagent systems (section 1.2) is given in this chapter. The project D-Sifter is based on results of the SIFTER-project obtained by the working group of Prof. Palakal before such that this section deals with a short summary only.

1.1

Information retrieval and filtering (SIFTER)

Information filtering and information retrieval is an essential technology to handle the growing demand or need for information basically connected with development of global economy using distributed production and worldwide networks. The richness and range of natural language based information need implies a large area of possible response to it. Artificial Intelligence especially within the field of Natural Language Processing has faced this challenge. Many approaches using sophisticated semantical representations have been developed but most of them are missing the goal of effectiveness and accuracy. The promise of higher efficiency by using high-level representations could not transposed to reality in most cases. The first generation of commercial information retrieval systems, evolved in the sixties onwards, were using simple descriptor sets, consisting of 3

4

CHAPTER 1. FOUNDATION

subject headings, indices and thesauri. In combination with the power of terminological relations the descriptor sets were used for partial matching of interesting documents and user profiles described in the same manner. Modern information retrieval theory and practice are responses to the retrieval situation that overcome the limitations of these first generation automated systems, and in addition take advantage of the much increased computing power that allows full-text searching. They use natural language of requests and document and offer open ways of partial matching. Modern approaches are statistically based in the sense of exploiting frequency data about the occurrences and co-occurrences of natural language terms. That is, they assume a correlation between term frequency and conceptual properties. This correlation is not necessarily treated in the most obvious way: thus since retrieval is a selective business aimed at identifying the normally few relevant documents amidst the mass of non-relevant ones, the more a search term occurs in the file, the less discriminating it is (cf. [Jones, 1999]). The SIFTER approach is following this modern direction of research: the representation is based on a thesaurus in combination with term and inverse document frequency measurements. The classification incorporates cluster learning and a vector classification stage. User profiles and their changes are adapted automatically. Generally, there are two different approaches of information selection to be presented to the user. The first one, information retrieval, is a user-driven process. Information retrieval systems are therefore designed to meet the need for rapid retrieval of information in relatively short-term usage. They have to react immediately on individual demands of diverse user groups. On the other side there are information filtering systems in order to support long-term information needs of a particular user or a group of users with similar needs. The SIFTER system aims to integrate both approaches within a unified framework. Doing so the primary objective of SIFTER (Smart Information Filtering Technology for Electronic Resources) is to perform a mapping from a space of documents to a space of user relevance values. User intervention within the operation of the system must be minimized. Faced with changes in documents or user information needs, the system must adjust quickly with

1.1. INFORMATION RETRIEVAL AND FILTERING

(SIFTER)

5

little or no degradation in performance. The underlying problem is formally described as follows: Learning information retrieval and filtering can be understood as the construction of a map from a space of documents to the space of real-valued user relevance factors. f :D→R

(1.1)

Being aware that this construction has to cope with changing of user behavior and interest this has to be seen as a time dependent process. Formally the whole process may be modeled by a map from Cartesian product of the document space and the real-time into the space of user relevance factors. ft : D × R+ → R

(1.2)

Sifter is using a two level approach for the construction of this map. The task on the higher level is to partition the document space into a finite number of classes. f1 : D → {C1 , C2 , ..., Cm }

(1.3)

The user relevance is determined by the lower level mapping, which matches the finite set of these classes to the individual user relevance space. f2 : {C1 , C2 , ..., Cm } → R

(1.4)

The product of the maps f1 (equation 1.3) and f2 (equation 1.4) should lead to the same results as the map f (equation 1.1). Using this two level approach the following architecture was developed for SIFTER (see figure 1.1). The model consists three components, mainly. The first component (Document Acquisition & Management) is the front-end to the information sources available. Documents are acquired and stored by this component. User interaction is managed by the Presentation & Access Management (PAM) module. The most important component in the system is the Filter module, which can be seen as six functional units. Documents are processed by the main units: Representation, Classification and Profile Management. Each of them is using a service unit. Functionalities of these units are described in the following.

6

CHAPTER 1. FOUNDATION

Figure 1.1: Model of the filtering process Representation is the first task in the filtering process. It is one step before the equation f1 as it translates the documents in a computer interpretable form, only. The representation is based on the vector-space model (cf. [Salton, 1989]). In this model a document is represented by a vector, which is representing the frequencies of the terms provided by the thesaurus. To estimate the particular degree of importance the frequencies are computed by the product of term frequency and inverse document frequency. The document frequency is calculated off-line for each term in the thesaurus using a sufficiently representative collection of documents. Formally, the representation of a document is a weight vector Wi where Wik determines the relevance of term k in document i: Wik = Tik × log(

N ) nk

(1.5)

where Tik is the number of occurrences of term Tk in document i; Ik = log( nNk ) is the inverse document frequency of term Tk in the document base; N is the total number of documents in the document base; and nk is the number of documents in the base that contain the given term Tk . Classification as the second step in the Sifter filtering model incorporates the map f1 (equation 1.3). Furthermore it includes the off-line step of creating the classes. Using an unsupervised cluster learning algorithm, it

1.1. INFORMATION RETRIEVAL AND FILTERING

(SIFTER)

7

generates an initial cluster hypothesis [C 1 , C 2 , ..., C k ] using a representative sample of document vectors [S 1 , S 2 , ..., S N ]. The representation of the clusters is realized by its central document Z i , also named centroid. Incoming document vectors V i are classified to a class C k if, following a distance measure, Z k is the nearest centroid of V i . The measure for computing the distance between two document vectors is determined by the cosine similarity measure (cf. [Salton, 1989]). Given two non-null document vectors X = [X1 , ..., Xt ]T and Y = [y1 , ..., yt ]T , such a similarity measure represents the cosine of the angle between them and is calculated as Pt xi yi q P i=1 P (1.6) t t 2 2 ( i=1 xi )( i=1 yi ) The distance is then calculated as 1 minus similarity.

Profile management is the last step in the filtering process. It deals with the user interest. So it should realize the map f2 (equation 1.4). Therefore, the profile learning is using a simplified model of the user based on the relevance feedback given by the user. In this framework di determines the underlying (unknown) expected user preference for the class Ci . It is represented in the computational model as a product of the estimated relevance probability vector dˆi as an estimation of di and an action probability vector p = [pi ] representing the probability of the class C i being selected by the filter as the most relevant class. Both elements of the estimation of di are updated automatically. For further information on the learning algorithm, please, refer to [Mostafa et al., 1997]. The adaptation of the learning algorithm is not capable of recognizing real interest shifts of the user. In consequence a user interest shift detection module is included in the Sifter architecture. This system continuously checks the given feedback with former relevance feedback and decides if the feedback is within the range of statistical (random) variation.

For further information refer to [Mostafa et al., 1997].

8

1.2

CHAPTER 1. FOUNDATION

Intelligent agents and multiagent systems

The definition of (intelligent) agents is not indisputable. Pattie Maes (1997) - one of the research pioneers on agents - delivers a wide definition of software agents: Agents are software entities that assist people and act on their behalf [Maes, 1997]. For intelligent agents we propose a secondary definition as follows: Agents are situated in an environment, act autonomously, and are able to sense and to react to changes [Knirsch and Timm, 1999]. In recent years the interest in agent technology - and agent-related topics has risen enormously. Research groups all over the world spend considerable amount of time and effort into the research and development of agent technology. Providing a research field where results are visible and some kind of ”fancy” like autonomous hardware robots or competitions around ”The Robot World Cup Initiative” (RoboCup) there is not only a huge engagement of public entities as well as private companies but there is even an immense public interest on agents. So agent technology seems to be the most popular and promising research field in artificial intelligence. This section - restricted to intelligent software agents - will give an introduction to intelligent agents, multiagent systems and their communication perspectives. Beginning with different views on agents and multiagent systems communication problems and standardization issues will be discussed. Aiming to apply agent technology to the domain of information filtering criteria are presented, which must be satisfied by a domain for an adequate application of agent technology. Agent technology from the theoretical view known for its simplicity, flexibility, partial autonomous behavior, and capability of adaptation should be the first architectural choice in industrial software engineering, but there is still a gap between research and application concerns. The last part of the section addresses recent research topics at the Center for Computing Technologies (TZI) in Bremen, the MIT MediaLab, Boston, and the AI-Group at IUPUI, Indianapolis.

1.2. INTELLIGENT AGENTS AND MULTIAGENT SYSTEMS

1.2.1

9

History

In recent years the interest in agent technology, and other agent-related topics, has risen enormously [Jennings and Wooldridge, 1998]. This is mainly a result of the spreading of global network agents that can act independently, and the expectation that very complex tasks can be solved by agents concurrently. Research groups around the world spend considerable amounts of time and effort to explore and develop new agent technologies applied to different problems. Currently one of the most promising research fields in computer science in order to support the automation of flexible process chains are multiagent systems [Swaminathan et al., 1993]. An intelligent agent is a knowledge-based system that perceives its environment; reasons to interpret perception, draw inferences solve problems, and determine actions; and acts upon that environment to realize a set of goals or tasks for which it was designed. The agent interacts with a human or some other agents via some kind of agent-communication language and may not blindly obey commands, but may have the ability to modify requests, ask clarification questions, or even refuse to satisfy certain requests [Tecuci, 1998]. Artificial intelligence approaches appear to suit well for the development of intelligent agent systems [Ferber, 1999]. For the long-term success of intelligent agents and multiagent systems it is absolutely necessary to transfer research results into commercial applications. A very promising field of application is information filtering -because of its inherent complexity that cannot simply be overcome by conventional approaches-, especially handling information in the world wide web. Two main topics can be identified. First, AI researchers create intelligent agents to develop, refine and evaluate various concepts, methods, and techniques. Second, multiagent systems are used for modeling, managing, controlling and simulating information flows on demand of single persons, within companies or networks of persons or institutions. Recent research issues deal with at least one of the following aspects: • Theoretical and methodological foundations of multiagent systems

10

CHAPTER 1. FOUNDATION • Identification, modeling, simulation, and formal representation of realworld business scenarios • Further improvements of agent technology in the context of well-defined problems of the information networks • Business- and market-related impacts of agent technologies • Mutual influences of evolving business standards, e.g., Jini and XML, and their fruitful merging with existing agent technology standards

Information Management (information at your fingertip) has always been a hot topic both in academia and in industry [Wooldridge, 1999]. Especially the amazing success of companies like Microsoft has brought computer science in the mid-point of every days discussion. By this it became a promising field of future application for the development of multiagent systems and intelligent agents have become the most promising software technologies for this domain during the last decade. Their application potential is almost unlimited leading to the use of ”intelligent objects” in software engineering tasks. The engineering aspects of this technology have not been realized yet, nor have they been satisfyingly considered. Therefore, only a small number of concepts, methodologies and large-scale scenarios for adequate applications of multiagent systems in the industry are available up to now [Parunak, 1999]. This section aims to sketch concepts, scenarios, and basic ideas related to agent technology, and to identify possibilities for application within the domain of information management especially in information retrieval and filtering as they are general goals of the new German Priority Research Program on ”Intelligent Agents and Realistic Commercial Application Scenarios” funded by the DFG (2000-2006).

1.2.2

Basic concepts

Intelligent agents represent a modern approach in Artificial Intelligence and distributed software engineering dealing with software entities which can act autonomously, communicate with other agents, are goal-oriented (pro-active) and are using explicit knowledge (Weiß, 1999). They are often used for tasks, which can be hardly solved monolithically and are showing a natural distribution. In these domains agents gain great benefit as they are

1.2. INTELLIGENT AGENTS AND MULTIAGENT SYSTEMS

11

able to collaborate and solve problems in a distributed manner. Especially in the field of logistics there is a huge unused potential of this technology [Knirsch and Timm, 1999]. Representing companies in demand networks agents are capable of organizing, controlling and managing information flows autonomously (cf. figure 1.2). Even consideration of company secrets can be integrated easily by special filtering processes. Furthermore, agents are not bound to static organizational structures and can choose their communication counterparts dynamically during runtime of the system.

Figure 1.2: Agents mediating inter-enterprise communication A widely accepted definition of Intelligent Agents refers to the three necessary attributes proposed by one of the leading research groups on agents in Europe ([Wooldridge and Jennings, 1995]): reactivity, pro-activeness and social ability. A different definition given by Foner is pointing out the dynamic aspects of agents [Foner, 1993]: ... autonomous objects with the capacity to learn, memorize and communicate. There are two different views on agents: one is stressing the social aspect, i.e. the collaboration of different entities. The other is focused on cognitive aspects. The beginning of the cognitive tradition can be found in the book of Marvin Minsky ”The Society of Mind”: Marvin Minsky introduced in his book ”The Society of Mind” the realization of higher cognitive aspects through agent societies [Minsky, 1985]. I’ll call ”Society of Mind” this scheme in which each mind is made of many smaller processes. These we’ll call agents. Each mental

12

CHAPTER 1. FOUNDATION agent by itself can only do some simple thing that needs no mind or thought at all. Yet when we join these agents in societies- in certain very special ways- this leads to true intelligence.

This approach is based on a strong use of metaphoric language and has been criticised for this aspect being an obstacle on the way of formalization. More formalized approaches evolved from system theory, actor theory and game or decision theory. As early as 1975 John Gall discussed hierarchic systems as the basic concept [Gall, 1975]. 1. Everything is a system. 2. Everything is part of a larger system. 3. The universe is infinitely systematizable, both upward (larger systems) and downward (smaller systems) 4. All systems are infinitely complex (The illusion of simplicity comes from focusing attention on one or a few variables) The actor theory is a mathematical framework for formal modeling of systems with active components and introduces an agent-related term -the actor- as follows [Agha and Hewitt, 1987]: Actor: A computational agent which has a mail adress and a behavior. Actors communicate by message-passing and carry out their actions concurrently. A very useful theory describing independent negotiation parties is the game theory by that it seems to be an adequate methodology for modeling and formalizing agent systems. A representative esteem may be found in [Holler and Illing, 1990]1 : Nowadays methods from game theory are used intensively in all fields of economics and social sciences. Game theory provides formal instruments for analysis of conflicts and cooperation. A often discussed issue is the differentiation between objects and agents. Therefore, [Mueller, 1998] presented characteristic essentials for both entities as presented in Table 1.1. 1

This description has been translated from German original.

1.2. INTELLIGENT AGENTS AND MULTIAGENT SYSTEMS Agents Agents have an architecture Agents have ”mental” states Agents are goal-directed Agents are plan-based Agents have dialogs

13

Objects Objects have not Objects have attributes Objects are message-triggered Objects are ”life-cycle bounded” Objects have send/receive behaviour

Table 1.1: Agents versus objects

1.2.3

Agent architecture

In the previous sections we discussed different approaches to the understanding of agents. For practical applications or theoretical research a specific architecture has to be developed. Until now there is no generally accepted standard architecture [Mueller, 1996]. On the other hand there are basic principles for the construction of agents.

Figure 1.3: Agent as a black-box In a first step any system can be described by its input/output relations (black-box principle). Following this principle an agent would be a mapping from the set of inputs or sensor information to output or effector actions (cf. Figure 1.3). This definition ensures reactive behavior. Early Artificial Intelligence approaches defined agents as encapsulated expert systems situated in an environment. Consequently a knowledge base and an inference engine have to be introduced (cf. Figure 1.4). This concept can be extended to a learning system as mentioned in [Tecuci, 1998].

14

CHAPTER 1. FOUNDATION

Modern AI approach try to incorporate pro-active and autonomous behavior. Doing so internal planning is needed and this leads to architectures as presented in [Russell and Norvig, 1994] for goal-based agents (cf. Figure 1.5). This architecture integrates the necessary attributes for Intelligent Agents. Its internal state considers sensor information, forecast and goals.

Figure 1.4: Agent as an expert system Deliberative Agents and their architectures are considered on the edge of cognitive science and AI. The goal is to simulate the human decision process aiming to construct artificial intelligent behavior. Bratman introduced a formal architecture framework called BDI [Bratman, 1987]. The formalization is based on modal logic. On the conceptual level the architecture uses three different mental categories: Believes, Desires, Intentions. Desires are representing agent interests on the highest level of description and they may be presented using semi-formal languages. Intentions are derived and specialized from desires on the base of actual beliefs about the agent itself and the environment including other agents. Some extensions to this work use an additional concept which represents short-term goals (”goal”). This control structure enables agents to rational actions. The BDI framework contains three different strategies for goal commitment: ”blind commitment” (until goal is reached), ”single-minded commitment” (as long as the goal is believed to be possible), and ”open-minded commitment” (cancel goal if it is no longer desired).

1.2.4

Multiagent architecture

The reasons for the application of multiagent system can be found in distributed problem-solving or adequate modeling of the application domain

1.2. INTELLIGENT AGENTS AND MULTIAGENT SYSTEMS

15

Figure 1.5: Goal-based agents [Garijo and Boman, 1999]. The overall objective of the application is to reach an emergent behavior of the system, i.e. global benefit is gained by individual optimization. A multiagent system consists of a society of agents and an environment. The common goal is reached by individual goal-oriented behavior of each agent. The participating agents are collaborating using some kind of agent communication language. The society of agents is flexible, i.e. new agents can join the society, agents are adaptive, and agents can be removed. For an efficient and accepted application we should determine if MAS are adequate means for modeling organizations and temporary cooperation relations. Therefore it seems to be adequate to determine demands which must be met by the domain. In this context H. J. Mueller proposes three requirements to be satisfied by the domain to ensure that a MAS can fruitfully be applied [Mueller, 1997]. • Natural Distributivity When mapping a distributed domain to a model, it is essential to keep up the distributivity, or the distributivity lays within the task structure. On the other hand the distributed structure should be an inherent

16

CHAPTER 1. FOUNDATION property of the domain and not only an artificial design. • Dynamic Environment This demand does not only address to changing data of the environment but also structural changes of the whole systems, e. g. machines which are added or removed to the shop floor, partners, who are giving up the cooperation or are joining it. • Flexible Interaction The processes or objects which should be complemented with the help of a MAS are in need of complex interactions, e. g. they have to negotiate or exchange complex information. This usually requires the usage of well-defined semantics for the exchanged information pieces.

Figure 1.6: Multiagent system The main focus within multiagent systems lays on the communicative behavior of the agents and their interaction with the environment (cf. Fig. 1.6) [Conen and Neumann, 1998], [Cohen, 1997]. One representative approach to a multiagent architecture is the MEKKA architecture introduced by Lux 1995 [Lux, 1995]. The MEKKA agent architecture considers an agent as a three part software architecture. The first part (communicator) enables communications between agents and has knowledge about the existence of other agents. The sensors, attractors and communication functionality are part of the communicator. The second component - the head - ”agentifies” the existing software system to be enabled within the agent architecture. It has four important

1.2. INTELLIGENT AGENTS AND MULTIAGENT SYSTEMS

17

features: goal activation, planning, scheduling and execution. So the head provides the features which are demanded by an agent as goal oriented behavior, independent planning and scheduling of its actions etc. The head could be replaced by any other agent control architecture, e.g. BDI-based control, however. The third and last component of the MEKKA architecture is called the body. The underlying system can be found in the body, i.e. databases, business information systems. The main drawback of the MEKKA approach is the missing of semantical foundations for the architecture, e.g. representation of reactive behavior.

1.2.5

Communication

There are two principal approaches to multiagent communication, shared memory and message passing. The first one has been introduced in 1962 by Newell [Newell, 1962]. He invented the blackboard metaphor, which is symbolized in Figure 1.7 and may be described by the following original text: Metaphorically we can think of a set of workers, all looking at the same blackboard: each is able to read everything that is on it, and to judge when he has something worthwhile to add to it. This conception is just that of Selfridges Pandemoneums’ a set of demons, each independently looking at the total situation and shrieking in proportion to what they see that fits their nature.

Figure 1.7: Shared memory

18

CHAPTER 1. FOUNDATION

Blackboard architectures have been widely used in the area of distributed problem solving. An advantage as well as a restriction of this approach is the fact that agents do not have to know from the existence or the address of other agents. The main drawback is that all agents have to use the same language and representation of the problem domain. The blackboard method has to face common problems of concurrent manipulations and the priority design.

Figure 1.8: Message passing Being aware that communication is the intentional exchange of information the message exchange approach seems to be more flexible and adequate [Russell and Norvig, 1994]. It is based on the production and perception of signs with mutual unique semantics for each communicative pair or channel (cf. Fig. 1.8). These complex structured systems of signs are arranged in so called agent communication languages [Pitt and Mamdani, 1999]. The main aspects of message passing systems are: • Precondition: sender and receiver are in need of the same semantics (unique, redundant) • Possible languages: first order logic • Messages are send from the sender to the receiver • Messages are commonly based on speech-acts • Series of messages produce a dialog • Messages may change the believes of the receiver or cause actions The following example of a simple message exchange may illustrate this approach and its main procedures (Table 1.2). A general and conceptual description of communication via message passing (agent communication protocol) has to integrate mutual knowledge

1.2. INTELLIGENT AGENTS AND MULTIAGENT SYSTEMS Speaker Intention Generation Synthesis Hearer Perception Analysis Disambiguation Incorporation

19

S wants H to believe P (S believes P ) S chooses the words W (← they express P ) S utters the words W (addressing them to H) H H H H

perceives W 0 (W 0 = W ideally!) infers that W 0 has possible meanings P1 , P2 , Pn infers that S intended to convey Pi (ideally Pi = P ) decides to believe Pi (or reject if inconsistent?!) Table 1.2: Message exchange

about its topics (domain), the general process of the dialog, and its current state [Carron et al., 1999]. Thus, the structure of communication protocols may be divided into a domain dependent (content, problem, topic) and a domain independent part consisting of process knowledge (methods of communication, address of partners, dialog structure) (cf. Fig. 1.9). Common protocols are based on the speech-act theory for the design

Figure 1.9: Structure of communication of the process (dialog). Knowledge sharing efforts in the framework of DARPA standardisation created context description protocols for knowledge interchange in expert systems. The main efforts were KIF ([Genesereth and Fikes, 1992]) as an knowledge representation and KQML ([Finin et al., 1997], [Finin et al., 1995]) as a knowledge exchange protocol. These developments have been widely used for multiagent systems and had great impact on the evolution of a standard agent communication language. The result, the FIPA agent communication language (FIPA/ACL 2.0) seems to be a promising base for further standardization [FIPA, 1998], [FIPA, 1999a], [FIPA, 1997], [FIPA, 1999b]. Examples for communication

20

CHAPTER 1. FOUNDATION

structures are provided by figures 1.11 and 1.10

Figure 1.10: Auction An early but very efficient approach to communication behavior in multiagent systems is the usage of the Contract-Net Protocol. Invented by Smith 1988, it consists of a simple dialog structure, which ensures a termination within a predefined number of steps [Smith, 1988]. Each contract-net integrates one contractor (a), offering a task, and a arbitrary number of contractees (b), willing to solve the task. The net uses one iteration of message sequence task announcement (a, broadcast), task evaluation with task bid as a result (b), bid evaluation procedure resulting in task award (a) and finally contract establishment (b). The agent architecture recommended for this protocol can be found in Figure 1.12.

Figure 1.11: Negotiation At the end of this section a concluding comparison of the communication concepts may be useful. Advantages and disadvantages of both communication concepts (shared memory, message passing) introduced above

1.3. RELATED WORK

21

may be stated as follows: shared memory approach is superior, if great numbers of agents communicate using standardized language and unified representations of the domain problems. The main benefit of this approach is the incremental generation of the solution providing ”anytime” behavior at no additional cost. It is adequate especially if agent activation is event driven. But there is a strong need for efficient management and control of priorities.

Figure 1.12: Contract net protocol

On the other hand message passing is superior if heterogeneous problem representations or agent communication languages occur in the multiagent system. It enables distributed problem-solving in disconnected subgroups of agents.

1.3

Related work

The development of multiagent architecture for D-Sifter is closely related to ongoing research especially in three places, the MIT Media Lab (Software Agents), the University of Bremen, Center for Computing Technologies TZI (AI research group), and IUPUI, Department for Computer and Information Science CISC (AI group). In this section we will shortly introduce these approaches.

22

CHAPTER 1. FOUNDATION

1.3.1

MIT Media Lab

The Media Lab at the MIT has a special interest group on multiagent systems. This group is headed by one of the most important pioneers in agent research. The group started the project AMALTHAEA in 1996. The project objective is to develop a multiagent system for information filtering. They have two type of agents, one for filtering and one for discovery tasks. These two types of agents are forming two agent societies. The user receives results and gives feedback via a Java HTML interface. The Java interface communicates with the filtering agents using a credit system. The filtering agents are grouped and so describing clusters of interest. After receiving a task from the Java interface the agents try to retrieve information from the retrieval agents also using a credit system for communication. Information retrieval is using external distributed information sources, e.g. database keyword extractor. Their results, found documents, are delivered to the information filtering agents, which are classifying the documents. Documents relevant for the user are sent to the user interface. The community of all agents is organized in a closed economy. The communication protocols within this approach are based on a market paradigm. Further information can be found at: http://lcs.www.media.mit.edu/projects/amalthaea/

1.3.2

University of Bremen - TZI

The Intelligent Systems group of the Center for Computing Technologies (TZI) has quite a few projects with the technological focus on multiagent systems. We will present three different projects: distributed classification and diagnosis, distributed blackboard architecture, complex communication objects. Distributed classification and diagnosis On a closed meeting in May 1999 a concept for a multiagent system solving distributed classification and diagnosis tasks has been developed. The assumption in this approach is that there are many different problem-solving methods available and the solution of a classification or diagnosis task depends on the adequate choice of these methods. On the other hand there

1.3. RELATED WORK

23

is information - knowledge - about the domain acquired and represented. This knowledge should be refined within the classification processes, as well as by user feedback and as by learning of new domain concepts and sub concepts. In this approach there are two types of agents identified. The generic agents are dealing with real data outside of the multiagent system, e.g. images, video or audio streams, documents or databases. These agents are interpreting incoming data and are deriving some kind of low-level concepts of this information. Any agent is representing a problem solving method (PSM). The definition, description of capabilities etc. of PSMs is one main focus in the intelligent systems group. The other type of agents is using concepts to derive new concepts. The main difference between both types of agents is that only the generic agent is working on incoming data. If an agent is missing a proved concept to propose his new concept he can hire another agent to prove the missing concept. The approach uses market-based communication without explicit role assignment: agents can offer and buy concepts.

Figure 1.13: Bilateral communication One main difference to other approaches lays in the manner of collaboration. In this case the solution is built by cooperative support of hypotheses. The multiagent system has a learning competence in the market-based approach. It is known that the choice of PSM is not independent of the domain. Agents involved in concrete problem solving will gain more financial

24

CHAPTER 1. FOUNDATION

power. So they are able to act earlier or to hire other agents for proving their concepts. This behavior should lead to run-time optimization of the system. Another advantage of this approach can be found in the representation of domain ontologies. There is no need for a complex general ontology accepted by all agents, but each agent may have a different specialized view of the world yielding its ”own” ontology. Adequate partial ontologies for communication purposes may be defined by collaborating agents by simple intersection of appropriate parts of their individual ontologies.

Distributed blackboard architecture An interesting approach to agent communication is the attempt to merge the basic concepts of message passing and blackboard architecture forming a hybrid communication structure. The communication channels used in message passing are substituted by a bilateral shared memory (blackboard) and extended to a arbitrary number of participants.

Figure 1.14: Hyperedge Each blackboard is representing a communication between agents with a certain common goal. Additionally, there is no general management system for the blackboards left, but each blackboard instantiates its own management system by negotiation of its initiating agents. This approach

1.3. RELATED WORK

25

leads to a transition from passive to active communication in consequence. The basic idea of a distributed, hybrid blackboard message-passing communication can be found in the restriction of message-passing communication to a bilateral one (see Figure 1.13). The restriction is not technically reasoned but in common approaches concerning message-passing communication only a bilateral one is considered. The underlying assumption suggests that a multilateral communication can be simulated by a sequence of bilateral ones. The problem is, that in a dynamic environment with low-bandwidth communication there are time-delays or losses in communication dialogues and in consequence also in the sequence of bilateral communication. E.g. the effect concerning a trading situation can be severe for one counterpart if a decision is based on the first positive answer. In this case an agent receiving a message earlier has an unnatural advantage.

Figure 1.15: Distributed blackboard communication The agent system is represented as a hypergraph, i.e. a bimodal graph. Agents are symbolized as nodes and edges as communication channels. The second kind of nodes stands for communication objects. The communication nodes in combination with the adjacency edges are forming a hyperedge (see Figure 1.14). So the structure of the communication - who can communicate with whom - is given by a subgraph and can be modified by rules of graphtransformation. The communication object is the most relevant aspect in

26

CHAPTER 1. FOUNDATION

this approach. A simple idea of this communication object is that it is representing a market place. This place is used for negotiation about a single product. In a more general consideration the product could be any kind of topic. For the negotiation the object consists of two parts: a finite automata and a blackboard. The finite automaton is supervising and controlling the negotiation process (management system). It is part of the communication protocol. The blackboard enables the agents not only to bargain but also to solve problems etc. So each market place can be individualized for the current topic and the needs of the involved agents (see Figure 1.15).

Complex communication objects The complex communication object approach differs from the previous one. It uses the multilateral communication enabled by a hypergraph representation too. But it does not use a blackboard concept extending the communication channel. The basis of this approach is, that any communication language can be derived from a more general language. Further on these languages can be arranged in a binary tree structure (taxonomy). Comparable to the communication language the dialog protocols can also be represented as taxonomy.

Figure 1.16: Complex communication hierarchy

1.3. RELATED WORK

27

All agents know about the top element of both taxonomies. So all agents have the same generic communication protocol. Communication protocols are defined as pair of both hierarchic types (communication language, dialog protocol). A complex communication object is an object with all information needed for the semantically and syntactical interpretation. E.g. if two agents want to communicate without using the same language they can teach each other a new common communication protocol by exchange of appropriate messages (in predefined structure). A communication object can be exchanged by itself or by partial graph (selected group of son nodes). So the communication object stored in the hyperedge of a concrete communication is a subset of the communication taxonomy.

1.3.3

CISC - IUPUI

At the Department of Computer and Information Science at IUPUI there is a lot of preliminary work done for information filtering and distributed information filtering. Especially the programming language dependent and independent interfaces for object interaction are carefully explored. A special topic of the research interests of Dr. Raje is at the agent architecture debate from high interest. He works on a Unified Meta-object Model (UMM), which can be seen as a more general concept of agents. In this approach he introduces three different aspects of an object: the computational, cooperative and auxiliary aspect. A further very interesting aspect in his work is the definition of a headhunter objects as counterparts to mediator objects. For further information please contact Dr. Raje2 .

2

Rajeev Raje, PhD, Assistant Professor at the Department of Computer and Information Science, Indiana University-Purdue University (IUPUI), Indianapolis, Indiana, USA. Email: [email protected]

Chapter 2 Multiagent information filtering - a first approach The topic of this report is design of a multiagent architecture for information retrieval and filtering. As discussed in the introduction, there are two approaches to multiagent information filtering. The first one, which is discussed within this chapter, tries to make use of the power and flexibility of the multiagent system communication but has to define new information filtering methods in consequence. The process of information filtering is exported into the communication causing difficulties estimating the efficiency and accuracy of the overall system’s behavior. The second approach keeps the information filtering process as tight as possible to SIFTER benefitting from all respective research but has to restrict the flexibility of defining the multiagent communication doing so. It will be presented in the next chapter.

The modeling granularity of the here presented approach only includes the selection of agents, their interaction behavior and control structures within agents, but does not include object-design of the agents nor of the agent environment.

28

2.1. MOTIVATION

2.1

29

Motivation

Considering the application of multiagent systems in the domain of information retrieval and filtering there are three main questions to be answered: • How is the process of filtering to be implemented? • What is an agent? • Where should agents collaborate? • How should agents communicate? Answering these questions the justification for using a multiagent approach should be fulfilled. Following H.-J. Mueller the three criteria a)natural distributivity, b) flexible interaction, and c)dynamic environment are essential. Dealing with these problems we will follow the strategy to use a well defined methodology (AWIC) to synthesize the multiagent system and try to incorporate a appropriate filtering process. Both aspects will be covered in the following subsections.

2.1.1

The filtering and retrieval process

The main difference to the existing single- and multiagent Sifter can be found in the capability of agents. As the existing D-Sifter is using agents each capable of the complete filtering process, this new approach divides the filtering tasks among different agents and exports the filtering process into the communication protocols. In the existing D-Sifter information filtering consists of: • Acquisition of new documents • Representation • Classification • Filtering according to user preference A closer look into the first task shows that it is mostly domain independent. But some aspects are highly domain related causing need to know which information sources to use. The representation step includes the use of

30

CHAPTER 2. MULTIAGENT INFORMATION FILTERING

the thesaurus and a classification algorithm. Considering the classification algorithm it could be domain independent. The thesauri representing domain knowledge are obviously domain dependent. In this step the domain has to be specified. Classes are generated or filled using examples and domain information. New documents are classified by distance calculation (see 1.1). The filtering step works on the basis of the user profile, which is not necessarily domain dependent. But it is applied on the results of the classification process and in consequence also in need of domain knowledge. The other approach of using D-Sifter is for information retrieval. In this case the user places a query. This should start the following process: • Filtering available documents • Acquisition for new documents • Representing new documents • Classifying new documents • Filtering new documents As it is easily seen the difference in the intuitive process is not significant. The difference does not lay in the structure but in the realization of this task. Here the dependency between each step is higher. Thus, the coordination effort must be greater as the user wants the relevant information in shorter time as in the information filtering process. This means that the acquisition step must be initialized according to the user request. This process structure leads to four main tasks: • Filtering • Classification • Representation • Acquisition

2.1. MOTIVATION

31

In this structure the interfaces to the system are given in user-driven filtering and information sources driven acquisition. The classification and representation steps are, foreseen of maintaining thesaurus or classification algorithms, independent from the outside of the system. The strategy of dividing these operational tasks into different types of agents and communication protocols has to follow the general methodology of the agent system construction and will be described later in detail.

2.1.2

Agent-oriented design: AWIC

A general approach to agent-oriented software engineering is introduced by [Mueller, 1997]. He proposes an AWIC design process (illustrated in Figure 2.1) consisting of the following steps: A Agents: Main pro-active elements in the system W World: Environment, where the agents should act in I Interoperability: Interaction of agents and environment C Coordination: Interaction between agents

Figure 2.1: Components of the AWIC approach This design methodology is an iterative one. Furthermore, the methodology takes a new issue into account: the role of an environment. The here presented design is oriented along the AWIC design process. Following this methodology four different models will be created. The first

32

CHAPTER 2. MULTIAGENT INFORMATION FILTERING

one, the agent model, contains information on active entities in the problem domain, specification of their tasks, world knowledge, their perception abilities, the physical actions they are capable of, and their basic planning abilities. For implementation purposes it is recommended to choose agent architectures for the active elements at the construction of this model. In the next step, the world model is generated. The main elements of the world model are the representation of the (physical) environment of the agents, definition of world laws for minimization of synchronization between agents, and the definition of preconditions for the decision, whether an action an agent wants to perform in the world is possible or not. At this step, a decision for the general coordination and communication model should be reached (e.g. blackboard or message passing). The interoperability model is describing the (physical) actions of the agents, which will be reflected in the world. In a simulated world the agent may send an action request to the world and the world would decide whether the action can be performed. In the positive case it would change its world state, in the negative case it would reject the action request. The last model to be generated is the coordination model. This model specifies the message types and protocols between the agent. It is based on an adequate formalism to implement the communication features. In most cases the coordination model is extending the planning abilities of the agents towards joint planning, joint activities, and plan coordination mechanisms.

2.2

Design

This section is addressed to the design of the agent system on an abstract layer. The modeling depths only includes the selection of agents, their interaction behavior and control structures within agents, but does not include object-design of the agents nor of the agent environment.

2.2.1

Agent model

In designing multiagent systems one of the first and most important tasks is finding adequate agents. This is similar to the problem of finding classes in object-oriented design. Good clues for finding agents -if they are not given physically or structurally (enterprises)- are the search for different tasks,

2.2. DESIGN

33

which can be solved in a quasi-autonomous manner. For re-use purposes of agents it is important to identify as many domain independent agents as possible. The domain dependent agents have to be adapted for each domain the system should be applied to. In the following there is one approach presented providing great domain independency. These leads to an extended agent structure not only oriented along the previously described processes but also considering maintenance issues. Figure 2.2 shows an external view to the system and shows two types of user interaction: User and Administrator agent. The boundaries of the system are the user interactions (user, administrator) and the integration of external information sources (wrapper). Additionally, a user simulation agent can be used to evaluate the system. The user can affect each part of the system using the administrator agent, which instructs and uses the monitor and maintenance agents. The classes are represented by class agents and domains by domain agents. Service agents provide elementary algorithms (classification) to the system.

Figure 2.2: Global view to system boundaries

34

CHAPTER 2. MULTIAGENT INFORMATION FILTERING

Wrapper agent Wrapper agents are serving as an interface between external information sources and the system. In this role agents are not only connecting to different databases or web-pages but also to different media like audio or video streams. The general capability of one single wrapper agent is to understand one information source, i.e. there is one wrapper agent for each information source integrated into the system. Wrapper agents have to understand the output of an information source and are capable of transforming this output in an internal representation consisting of title, abstract and document reference only. The document reference can be used by the user to refer to the original document. Consequently, documents are not directly saved within the system.

Service agent There are two main reasons for the usage of service agents: efficiency and diversity. Cloning of service agents can lead to an easy distribution of the classification tasks, e.g. on different computers. The filtering approach of D-Sifter uses different steps of classification. The first step deals with the unsupervised clustering of the thesaurus and the second with the distance calculation according a set of representative documents. Service agents may be specialized to certain methods in order to increase the efficiency, such that some may be working on unsupervised clustering and some on distance calculations. This approach enables a more general design, however. A possible solution of the classification step could be a knowledge-based agent using content-based, deliberative algorithms for classification , for example. The design recommends generate at least one service agent per algorithm. The domain and the user profile agents are using the service agents to process the available documents. These agents should hide the inner structure of classification or representation algorithms that no other agent is need of knowledge about algorithm details. A classification agent should represent one classification algorithm and they should be provided with collaboration abilities, so that new classification algorithms can evolve from the cooperation of the generic classification algorithms.

2.2. DESIGN

35

Monitor agent The monitor agents are one of the most important utilities for the evaluation of system adaptation and behavior. They are tracking the user feedback in context of investment (cf. market-based communication), for example. The generation of specific monitor agents is possible using administrator agent. They are also responsible for visualization of user adaptation. Maintenance agent The maintenance agents are the only agents, which are able to manipulate other agents. In contrast to the principle of autonomy within agent systems, the maintenance agent can dictate new facts during communication. Using this agent, e.g., the administrator agent may add new domain or class agents with predefined structures. Administrator agent The administrator agent is the user interface for the administrator of the overall system. It enables him to change (maintenance agents) and supervise (monitor agents) the system by interacting with the corresponding agents. There must be at least one administrator agent for the system for initialization. If there are more administrator agents, they are ordered in a strict hierarchy clarifying priority rules. Domain agent For the representation of a domain there are two concepts. The first concept uses active communication for the representation of a domain, i.e. the domain only exists within communication objects. The second approach is to use hierarchic agents to represent a domain. Both approaches will be described later on. Using the hierarchic approach, each domain agents represents a unique domain by its thesaurus and the knowledge, which domain agents also belong to this domain. Further on a domain agent knows all class agents of its domain. They can supervise the classification, representation, filtering, retrieval processes including the user feedback given to a class. In order to optimize the filtering and retrieval process a domain agent can create new class agents using service agents, it can remove class agents from the system, or it can

36

CHAPTER 2. MULTIAGENT INFORMATION FILTERING

modify class agents. Note: in the special case of one domain and a D-Sifter behavior, the domain agent would initiate and control the unsupervised learning step creating the class agents using the service and maintenance agents. Class agent The class agents are representing the rules defining the respective document class. The manual creation of class agents is done via maintenance agents or by an administrator user. In the standard application of the system a class agent is created as follows. The domain agent instructs service agent to use e.g. unsupervised clustering on a representative sample. This results in a number of suggested classes with their respective definition or classification matrix.

Figure 2.3: Domain - class agent relationship In contrast to the classical understanding of agents, the persistence of the class agent depends on the supervision and evaluation of the domain agent. Domain agents are acting comparable to mediators, balancing user feedback and resource usage. The domain agent has the ability to manipulate class definitions to increase accuracy and efficiency. The relation between domain agent and class agent can be found in Fig. 2.3. User agent Each user agent is the interface to a specific human user. They maintain and keep the user profile for the system, i.e. they process feedback adapting to user interest by learning. The main task is to communicate with the other agents, i.e. translate a user query into messages and calculate a specific amount to invest for a query or to decide whether an offered information (document) is to be accepted.

2.2. DESIGN

37

User simulation agent The user simulation agent is needed for the evaluation of the system’s behavior and the adaptation capabilities of the information retrieval and filtering process to specific and standardized queries. Each user simulation agent is representing one and only one simulated user. Conclusion The multiagent system consists of seven agents within the boundaries of the filtering system. The agent concepts for administrator can be handled as a complex user interface and the user simulation agents are used for evaluation purposes only. So the considered part of further descriptions consist of the agents shown in Figure 2.4.

Figure 2.4: Overview: agents

2.2.2

World model

As has been stated above the world model represents the physical environment the agent will operate in (cf. Fig. 2.5). Therefore, an agent registration center, including all necessary information for inter-agent collaboration, is defined as central element of the world. Agents can register at this center after they have been created and they have to cancel their registration. Another important functionality of the world is the generation of user agents after the login of an user through the graphical user interface, which is, at the beginning of a user’s session, directly connected to the agent world. The

38

CHAPTER 2. MULTIAGENT INFORMATION FILTERING

generation of the user agent also includes the transfer of the graphical user interface address to the new user agent. After termination of the user’s session, the agent world is saving the user profile, storing this information to the account server, and removes the user agent from the system. Last but not least the documents have to be stored within the system. To keep the wrapper agents small and efficient, and to decrease communication effort within the system, only references to documents are handled from one agent to another. This procedure is in need of a separated document space, which is implemented by a document server. For scalability purposes this document server can be replaced by a network of document servers. The construction of the agent world needs rules (world laws, social laws)

Figure 2.5: Agent world with interopability relations ensuring that redundancy and inconsistency will not occur during runtime. In contrast to classical agent approaches the here used model of complex communication objects takes care of these issues on its own by introduction of the market place paradigm. The server within the agent world (document, account) are using standard technologies known from databases and distributed systems as world laws.

2.2. DESIGN

2.2.3

39

Interoperability model

The interopability relations are describing the interaction of the agents with the agent world. The agent world is generating the user agents only. The other agents are created by the administrator and the domain agent. The agents are interacting with the agent world in different ways. They are using the agent registration center for communication purposes, which provides addresses, names, and capabilities of the other contributing agents. The graphical user interface, connected to users and administrative users, interacts in an agent like way with the agent world. It uses the agent world for communication with the user simulation user, maintenance and monitor agents. Analogous to the graphical user interface the administrator agent uses the agent world for communication purposes. It instructs other agents by special pre-defined methods for direct manipulation. The account center is connected to the user agents and maintenance agents. There is one special interaction within the agent system. The wrapper agents are connected to external document sources, which are explicitly not part of the agent world. This reflects the open approach of the information filtering system. The design of the interoperability may be constructed graphically within the AWIC approach, such that all further details can be found in Figure 2.5.

2.2.4

Coordination model

The AWIC approach uses the coordination model of KADS mainly. This model unifies communication and coordination in the sense of inter-agent communication structures and examples. The communication can be found on three different levels. So the agent system is in need of at least three different communication protocols. The differences can be found in the complexity of the exchanged concepts mostly. The agent considered as a simple multiagent system needs a very rudimentary communication for its coordination. This coordination can be considered as a command structure, in which only few negotiation steps are necessary. The second level of coordination is needed for standard filtering without time restriction. In this case a market-based communication protocol should be sufficient which is capable of handling domain concepts. The last and top-level communication is needed for user queries which can not be answered easily. If a user query does not match an existing document in its original classification the agents should be capable of negotiating for

40

CHAPTER 2. MULTIAGENT INFORMATION FILTERING

finding an appropriate document for the user with -hopefully- high relevance. Here it could be imagined that the agents are discussing a new and perhaps only temporarily existing classification of a document. On the other hand the agents have to coordinate their behavior, so that they do not waste time with the acquisition of new but completely irrelevant documents.

Figure 2.6: Communication channels

The AWIC methodology does not only consider the communication protocols but also possible communication channels and relations as the KADS approach does. The communication infrastructure and hierarchy can be found within Figure 2.6. Directed edges symbolize an instruction relation, which is not based on agent communication protocols but on direct manipulation. Edges within the structure graph symbolize possible communication channels between agents (nodes). Multilateral communication seems to be important for document classification or user query processing, but is not included within this early step of modeling.

2.3. SPECIFICATION OF DOMAIN KNOWLEDGE

2.3

41

Specification of domain knowledge

The AWIC methodology does not include the concrete instantiation of the multiagent system to the problem domain. The adaptation of the system to different domains is essential for keeping in touch with changing user relevances, however. Thus, a specific way to adapt to domains has to be added. This section proposes two fundamentally different domain representations within the multiagent D-Sifter. These representation methods are alternative choices. The basis for the consideration of domain knowledge are the following introductionary issues: The wrapper agents are responsible for the acquisition of new documents from various types of information sources. They are constructed as follows: An abstract agent is created for each type of information source, e.g. specific database, web pages, e-mails, etc. If a new information source is connected to the system a new wrapper agent will be instantiated on the base of the respective information source accompanying abstract agent. The instantiated agent can acquire new documents as well continuously as on demand. The problem with demand driven document acquisition is that these agents are in principle domain independent and do not have knowledge about specific thesaurus concepts to interpret queries. The next step within the filtering process is in need of domain knowledge and will be introduced and considered in the next subsections alternatively.

2.3.1

Hierarchical domains

The approach of hierarchical domains uses the explicit definition of domain agents, incorporating the knowledge about the domains. To extend this approach and to integrate multiple domains we recommend to use hierarchical structures between the domains and transfer this structure to the domain agent subsystem directly. Being aware that the wrapper agent does not contain domain knowledge, the step of representing the document within the system is only possible by a cooperation between domain and wrapper agents. Both agents interact on representing the documents found and translating them into the system’s internal representation using service agents. A domain is defined technically here as a set of concepts. In contrast to a

42

CHAPTER 2. MULTIAGENT INFORMATION FILTERING

single domain Sifter system this approach has to deal with multiple domains presenting a complex hierarchical structure. We assume that the domains may be arranged within a tree following there semantical structure, there is one top level domain (root), and the leaves are consisting of single concepts only.

Figure 2.7: Example: domain hierarchy computer science For the coordination of the classification process, it is presumed to provide an organizational structure to the system, which reflects this tree hierarchy of domains. So a lot of domains can be assessed or used by leading domain agents within the organizational tree structure induced by the domain tree. E.g., the specific domain agent of computer science is subsuming the field of artificial intelligence and software engineering (cf. Fig. 2.7). Of course these assumptions will be violated if complex domain structures e.g. interdisciplinary fields are in question. There may be contrary opinions

2.3. SPECIFICATION OF DOMAIN KNOWLEDGE

43

between different users leading to conflicts. This however is only true for constant and user independent, general definitions of such trees. Dynamic realization of organizational structure by communication laws involving user relevance and user choice will overcome such problems (cf. Fig. 2.8).

Figure 2.8: Example: interdisciplinary domain Bio-Informatics For construction of sub-domains the user should follow the principles for re-use, defining a sub-domain as general as possible increasing the ability of reuse but also as specific as needed to reduce interaction efforts. In this approach the re-use of pieces of knowledge is considered to be more important than the interaction costs between domain agents. This increases the efficiency of the system as the domain agents are temporarily organized in tree structures according to specific domains. Within these trees the transaction costs between the agents are very low, as the taxonomy enables the agents to use condensed ”instruction”-like protocols instead of complex communication protocols for negotiations. This hierarchy can be used top-down for meeting a specific user request or bottom-up as it is used in the information filtering process.

2.3.2

Domain in a market place

The ”domain in a market place” is proposing an alternative approach to domain knowledge representation. In contrast to the prior concept the domain agents are substituted by dynamic complex communication objects (see section 1.3.2), i.e. the representation of the domain is incorporated by agent interaction.

44

CHAPTER 2. MULTIAGENT INFORMATION FILTERING

The basic ideas for the information acquisition, user profile and classification agents are very similar to the above described. The main difference lays in the representation of domain knowledge. Considering multiagent information filtering and retrieval one main issue is the level of adaptation of the system to a specific domain. In the previous approach this adaptation is not significant as any domain can be added through integration of further domain agents. This alternative approach uses the distributed blackboard concept (compare 1.3.2). In this case the domain specific concepts are stored in the distributed blackboards (market places). Each market place can be considered as a single domain. The persistence of a communication objects is the same as in the approach introduced in section 1.3.2. This means domains without connections, neither to user nor to wrapper agents, are removed from the system. This increases the performance as well as the direct mutual access of all involved agents contributing. Agents working on a domain are directly connected to the domain market place. There could be a second type of edges realizing a dynamical structure between market places comparable to domain agents in the domain hierarchy approach of the previous section. One problem using market-based approaches is that it is very difficult to implement some kind of social reliability. In the field of shared knowledge within multiagent systems there are some approaches not using the market-based metaphor but negotiation. Shoham has initiated a research field in the agent community with introducing his social laws for multiagent systems. He uses them esp. for coordination of physical robots. The social laws enable the robots to initiate traffic rules etc. My recent idea in this field is to introduce a stock-market for marketbased multiagent systems. The stock-market provides any agent with a social value of a single agent. This social value will be dependent from his quality and reliability. The advantage of this approach compared to the social law approach is that the representation of the social reliability follows the marketparadigm and it does not need completely different communication protocols.

Chapter 3 Multiagent D-Sifter As discussed in the introduction of this report there are two different approaches to multiagent information filtering. The first one has been introduced in chapter 2. The second one, which will be discussed in this chapter, keeps the information filtering process as tight as possible to Sifter benefitting from all respective research. It has to restrict the flexibility of defining the multiagent communication doing so, however. After a short introduction the general approach is outlined. Presenting a flexible three layer architecture for a single agent, the main focus of this chapter is the detailed description of the communication and controlling features. Execution and registration processes constitute the last part of this chapter.

3.1

Introduction

D-Sifter combines two different user request methods: information filtering and information retrieval. They can be distinguished by the principles underlying the process of information presentation. Information retrieval is comparable to the pull-principle in economy; i.e. the user requests information about a specific topic. The alternative approach is to search for documents available according to the user’s interested. This is comparable to the push-principle in economy. Following this comparison it seems natural to construct a multiagent system for this purpose and to transfer ideas from economical reasoning to this subject.

45

46

CHAPTER 3. MULTIAGENT D-SIFTER

This motivation for a multiagent architecture leads to two main aspects for the system to be developed: On the one hand there is the need of a pro-active behavior providing new documents to the user and on the other hand the system should act in a reactive manner meeting a user-specified query. A general criterion for the system is that it should follow an anytime-behavior that means results can be represented at any time and the system is optimizing the results until the optimal solution is found or the user cancels the activity. This chapter is divided into two main sections, dealing with the general single agent architecture of each agent and the multiagent architecture (design). Starting with the single agent architecture in the next section, we have to face the requirements of the following five types of agents discussed in the design section: • user agent: interface to user, maintains and manages user profile on actual state, • classifier agent: providing classification methods to the system, • document acquisition and management (dam) agent: organizing, keeping, acquiring and assigning (classifying) documents, • representer agent: representing documents using special protocols, and • domain agent: incorporating specialized domain knowledge.

3.2

Single-Agent Architecture

In this report the emphasis on the single-agent architecture does not indicate, that there is an attempt to realize the whole D-Sifter solution within one single agent, but reflects the fact, that the whole multiagent system is constructed using a general unified single agent architecture. These are two different levels of abstraction and views as in the multiagent architecture there is a focus on the assignment of tasks, responsibilities, and on the definition of collaboration between them. The single-agent architecture deals more with the definition of different layers (communication, control, execution) and their general representation. It depends on the heterogeneity of the agent system, i.e. how different agents should be designed, whether

3.2. ARCHITECTURE

47

the single-agent architecture is a good entry-point for discussion on the architectural design of the system. In our case there should be as many common functionalities as possible, so that most of the agents are very similar. Only the user agents require a special design.

3.2.1

General Approach

The basic approach to an adequate architecture within this domain should strictly separate internal and external aspects due to security issues. We propose a three-layer agent architecture integrating a communicator layer for generic communication actions, a controller layer for the agent’s internal controlling and an executer layer for generic actions (see Figure 3.1). This architecture is integrating the deliberative decision algorithm BDI [Bratman, 1987] and the main characteristics of the MEKKA architecture (cf. Lux, 1995)[Lux, 1995].

Figure 3.1: 3-Level architecture for agents The realization of multiagent D-Sifter should use Java and in consequence the three-layer architecture is implemented using the interface-concept. This leads to explicit export interfaces as described in the following:

48

CHAPTER 3. MULTIAGENT D-SIFTER • communicator: receiveMessage(String xmlMsg): boolean This method is used by other object as an exported method which is published in the RMI registration center. The syntax is very easy the xmlMsg is a String consisting of a XML statement which is passed over to the translator and stored in the internal Letter object. The return value of this method shows the calling object if the message was received without an error. • controller: newMessage(Letter msg): boolean This method is the receiving method for new messages called by the communicator if a new message has arrived. The message is passed from the communicator to the controller as a parameter. The return value of this method is the error value. • controller: sendMessage(): Vector(Letter) This method is called in the main loop of the communicator. It returns a Vector of Letter objects. If the vector is empty, there is no message to send, otherwise the objects will be send starting with the first message. There is no possibility for the controller to stop once queued messages in this vector. • executor: doAction(Object objMethod): boolean The interface between controller and executor level is implemented in the executor class. The doAction method receives method name and parameter as attributes which should be executed. If values should be changed in the executor class a method must be called using doAction to do so. There is no direct way of changing attributes. • executor: getInfo As mentioned before there is no direct attribute interaction between executor and controller. Therefore, we introduce a method to get the content of an attribute. The method getInfo is called by the controller to check the value of a variable in the executor class.

The single-agent architecture serves as the superclass for all agent classes. The agent classes can be discriminated into the five above mentioned agent types: user, domain, classifier, representer, and document acquisition and management. So the single-agent architecture is implementing all important features which are common among all agent classes.

3.2. ARCHITECTURE

49

The multiagent collaboration is realized using direct message passing through a network, in contrast to the last chapter, where a complex agent world is introduced. To enable agent direct collaboration the instantiation of some kind of yellow page service is needed. In analogy to the platform concept proposed by FIPA, this approach uses a directory facilitator called agent registry. In earlier versions this yellow page service was called agent world.

3.2.2

Communicator

In the context of information filtering we restrict to information agents. Thus, the communicator represents the only interface to the external environment or multiagent system. This does not include resources, which are supervised by the agent. The agent communicator should be able to establish flexible communication channels to other agents autonomously. Being aware of possibly heterogeneous agent communication languages and representations we propagate a very flexible approach to agent communication. In this framework, we are using different speech-act based inter-agent communication languages (e.g. FIPA/ACL2, KQML) explicitly. Therefore we implement generic types of communication acts within the communicator, which can be translated into different inter-agent communication languages by partitioning and transforming the messages. Thus, within the first level, the so called communicator level, is providing the rudimentary communication skills to the agents. These skills include the registration at a registration center, sending messages to another registered agent, receiving messages from other agents, and the bidirectional translation between the sending, processing, and representation of messages. In the mutliagent D-Sifter approach we restrict to Java RMI, i.e. the agent registration center is substituted by the Java RMI registration. Messages are exchanged by remote method invocation between communicator objects of different objects respective agents. As FIPA/ACL2.0 is used as the main communication protocol and XML statements are used for the transfer of information from one agent to another (discussed later in this section), the communicator must be capable of translating XML statements into the internal representation, i.e. object centered message layout. A sample message passing of incoming messages is

50

CHAPTER 3. MULTIAGENT D-SIFTER

illustrated in figure 3.2. An intuitive approach to enable this message flow within the communicator is the logical discrimination into three parts: connection, envelope (letter), and translator (cf. Figure 3.3).

Figure 3.2: Workflow for an incoming message The first component ’connection’ is responsible for the ’lowest-level’ part of the communication, which is concerned in this approach, i.e. it uses interconnection protocols as JavaRMI, CORBA, DCOM etc. rather than network protocols, like TCP/IP. The idea is that a service class is instantiated for each connection type. For each service there will be a class which uses the abstract class service. Thus, for connecting to other agents, all necessary functions and methods are defined in the abstract class and these are overridden in the specialized classes. The general service class consists of two parts (cf. Figure 3.4). As network details and special address information can vary between different services we suggest to keep track of the data within each service object. Using JAVA RMI as a client-server solution there is only one-way com-

3.2. ARCHITECTURE

51

munication or synchronous bi-directional communication. Normal agent communication is bi-directional asynchronous as there is no limitation to the processing time of an agent’s control. To provide bi-directional asynchronous communication we propose to use a two part messaging system. On the one hand an agent must offer an object to receive messages as other agents use this object to send messages. On the other hand the agent can use other agent’s exported objects to send messages to them. The passive part - receiving messages - must be a function which runs concurrently and the active part can be expressed by a collection of addresses of the other agent’s exported objects.

Figure 3.3: The communicator layer The server services provide other agents with the possibility to log on and communicate with an agent via client service. A very simple example is the agent registration center. It - also realized as an agent - initializes in our case a RMI server service which can be used by any other agent to send and receive messages. If the transfer or response times are not satisfyingly, an agent can decide to launch its own service and invite agents it is interested in. The object service can react in two main ways: it can send messages and receive messages. The messages have the format of standard text. The ’envelope’ ensures the universal application of the agents even in heterogeneous environments. It is transforming incoming and outgoing messages into XML-statements. Thus, they can be delivered by any service, which can transmit text strings. It also parses incoming XML statements

52

CHAPTER 3. MULTIAGENT D-SIFTER

and handle them to the ’translator’ module only if its correct syntactically. The envelope contains information like used agent communication language, sender, etc. The letter object is an abstract data type realizing the ’envelope’ features (cf. 3.11)

Figure 3.4: Abstract Elements of Service Class The controller layer initiates a communicative act by sending a unified message to the ’translator’ module of the communicator layer. The formalization of the unified message is following the internal knowledge representation of the agent. This module translates the unified message into the designated inter-agent communication language (e.g. KQML). The translated message is transferred to the ’envelope’ module. On the other hand incoming messages are transferred from the ’envelope’ to the translator, which is decrypting the inter-agent message into the internal unified message format. The interaction of Envelope and Translator will be explained in more detail, using the message flows (cf. Figure 3.2) of incoming and outgoing messages as an example. There are two ways, messages have to be considered within this architecture: messages generated by the controller or messages sent by another agent. Both directions are using the contributing components visualized in Figure 3.5. The edges within this figure are symbolizing a message, resp.

3.2. ARCHITECTURE

53

data, flow relationship. If the message is sent by another agent it will enter the agent through a service as CORBA or JavaRMI. The text-string including an XML statement will be submitted to the Envelope. The Envelope will extract the information and identify the accompanying agent communication language, transforming the statement into a term of this language. Then the message in form of a language term is submitted to the Interpretor which handles it to the correct translator for this language. In the next step the term will be interpreted and pre-processed for the knowledge-base of the system. Afterwards it is handled to the controller for further processing.

Figure 3.5: Message flow within the communicator The alternative direction of a message is that the controller formulated a message in the interchange format. This is sent to the Interpreter which encrypts this message using an agent communication language. Which is not pretty clear at the moment. It could be the one the sending agent prefers or it is one from which the sender knows that the receiver is able to understand it. In the here discussed case it is not important as there will be only one language implemented. The encrypted term is handed over to the Envelope which transforms the internal representation of an agent communication term (e.g. abstract data type) into a XML statement which is passed to the connector. The connector looks up the service for the receiver and submits it to the corresponding service unit. After that the message should be sent.

54

CHAPTER 3. MULTIAGENT D-SIFTER

Following this description the latter two objects are introduced. The envelope secures the universal application of the agents even in heterogenous environments. The main functionalities are very similar to the functionalities of the agent communication language objects. So there is a common super-object: Translator. A translator object consists of four elements (cf. Figure 3.6), Decode, Encode, Parser, and ToUni. Any object which has be handled by a translator is parsed if the syntax is correct. Only after a correct parsing the term is further considered. If a term is decoded it is passed over to the next process step. The object at that step must be able to read values from the language object. So there should be some unified representation, which is generated by the part toUni. The XML translation and the agent language translation are not the

Figure 3.6: Abstract Class Translator (has part) same. At this step of consideration of this single-agent architecture, the XML notification does not include expected dialogues or parts of protocols. KQML or ACL can have contents which imply dialogues or partial protocols. So there is a difference between the semantical and syntactical conversation and the necessary preprocessing for the controller. Therefore there is a super-class for agent communication languages included which is a sub-class of translator (Language, cf. Figure 3.7). The language translation results in a object centered language, so that it can be asserted into the knowledge-base within the controller unit directly. A small class hierarchy for the main classes can be found in Figure 3.7. The design of the communicator has been worked out in great detail during my stay at IUPUI. The following Figure 3.8 shows the communicator

3.2. ARCHITECTURE

55

in more detail. The interface between the communicator and the controller is strongly restricted to two methods: newMessage, sendMessage. These two methods are exported methods from the controller class. The first method gets the received message object as a parameter and the second method returns either an empty message or a message object which should be send to another agents.

Figure 3.7: Class Hierarchie The communicator has only two tasks and two interactions with other objects/agents. It can receive messages or sent messages. Therefore it can call a remote method to send the message or a remote object can invoke a receiving function in the communicator. The exchange of messages is clearly restricted to the exchange of text strings. For this purpose it is necessary to transform outgoing messages from an abstract data type to an ASCII complaint string. As the controller is operating on message objects (letter, discussed below) there must be a translation from XML to letter-objects taking different agent communication languages into account. We propose to build a XML-letter object translator for each agent communication language. So there are two directions in which this translator will be used. In the first direction it has to translate an incoming message from XML to letter-object. In this case there could be multiple translator (e.g. XML-KQML-letter,

56

CHAPTER 3. MULTIAGENT D-SIFTER

XML-FIPA/ACL-letter). To chose the correct translator each translator has a parse method to decide if it’s a valid statement for this language. In the second case we have an outgoing message sent from the controller in the letter-object format. This has to be translated into a XML statement using a specific translator. The choice of the translator is very simple. As long as the controller hasn’t specified a translator the default one is used.

Figure 3.8: Design of communicator The specification of a translator by the controller is based on the knowledge of the controller about another agent. Consequently to the above mentioned aspects of a translator object there are three main methods for them: parse, decode, encode defined in natural language as follows: • parse(x: string):boolean The communicator to check if a message is in correct XML-format and the specified method structure is valid for the agent communication language represented by the translator-object uses parse. In case it is a valid statement this method returns true, otherwise it will return false.

3.2. ARCHITECTURE

57

• decode(x:letter):string The communicator to translate an outgoing message from the letterobject to the XML-statement uses decode. • encode(x:string):letter Encoding an incoming message from the XML-statement into the letter-object this method is used. Mythos Communication The communication - the most important method of collaboration - is a very difficult construct as the metaphors are in many cases too natural. A general approach to different types of agent communication is to divide the approaches in two main classes: speech-act based and game-theory based. Unfortunately the speech-act is normally realized in logic-based implementation has very similar problems with them in theorem proving. The worst of it is unsatisfying performance. On the other hand is the gametheory based or market-based communication for some problems to flat for real efficient distributed problem solving. To overcome these problems we propose a mixed approach: A game-theory based communication using a speech-act based cover. As the FIPA tries to improve the standardization in agent-design we are using the FIPA ACL2.0 as a first candidate for implementation. For the exchange of messages between the agents on a programming level we use envelopes in the form of XML. The advantage of XML is that it is a new and in future broadly accepted exchange format for data and information. As an alternative we could use a self-defined envelope or we could exchange objects (as abstract data types) which implement a message. But the problem occurs when the at the beginning implemented RMI connection between the agents is replaced by another approach. It is not clear which object-types this approach is supporting, so the most flexible approach is to send simple ASCII string with clear defined semantics - and the usage of XML enables us with exactly this flexibility. Back to the phenomenon communication. In computer science respective artificial intelligence communication is commonly defined as the collaboration between two or more entities. A more useful definition is that a communication act between two or more entities can be defined as a dialog. Speech acts and dialogs will be presented in the next sections following FIPA/ACL

58

CHAPTER 3. MULTIAGENT D-SIFTER

2.0 as an example. Speech Acts in ACL Dialogs consist of single speech acts. Speech acts can be discriminated using the sender’s intention about the receiver’s reaction. In ACL we know the following speech acts, normally defined as performatives: 1. accept-proposal The action of accepting a previously submitted proposal to perform an action. 2. agree The action of agreeing to perform some action, possibly in the future. 3. cancel The action of cancelling some previously requested action which has temporal extent (i.e. is not instantaneous). 4. cfp The action of calling for proposals to perform a given action. 5. confirm The sender informs the receiver that a given proposition is true, where the receiver is known to be uncertain about the proposition. 6. disconfirm The sender informs the receiver that a given proposition is false, where the receiver is known to believe, or believe it likely that, the proposition is true. 7. failure The action of telling another agent that an action was attempted but the attempt failed. 8. inform The sender informs the receiver that a given proposition is true. 9. inform-if (macro-act) a macro action for the agent of the action to inform the recipient whether or not a proposition is true.

3.2. ARCHITECTURE

59

10. inform-ref (macro-act) A macro action for sender to inform receiver the object which corresponds to a definite descriptor (e.g. a name). 11. not-understood The sender of the act (e.g. i) informs the receiver (e.g. j) that it perceived that j performed some action, but that i did not understand what j just did. A particular common case is that i tells j that i did not understand the message that j has just sent to i. 12. propagate The sender wants the receiver to treat embedded message as sent to oneself and to search agents in its knowledge by a condition and forward the received whole propagate message to them. This is aimed for delivering brokerage-requesting messages (instantaneous requests by above proxy message, or persistent requests by request-when/request-whenever message embedding proxy message) through federated brokerage agents. 13. proxy The sender wants the receiver to select target agents that satisfy a given condition and to forward an embedded message to them. 14. propose The action of submitting a proposal to perform a certain action, given certain preconditions. 15. query-if The action of asking another agent whether or not a given proposition is true. 16. query-ref The action of asking another agent for the object referred to by an expression. 17. refuse The action of refusing to perform a given action, and explaining the reason for the refusal. 18. reject-proposal The action of rejecting a proposal to perform some action during a negotiation.

60

CHAPTER 3. MULTIAGENT D-SIFTER

19. request The sender requests the receiver to perform some action. One important class of uses of the request act is to request the receiver to perform another communicative act. 20. request-when the sender wants the receiver to perform some action when some given proposition becomes true. 21. request-whenever The sender wants the receiver to perform some action as soon as some proposition becomes true and thereafter each time the proposition becomes true again. 22. request-whomever The sender wants an action performed by some agent other than itself. The receiving agent should either perform the action or pass it on to some other agent. 23. subscribe The act of requesting of persistent intention to notify the sender of the value of a reference, and to notify again whenever the object identified by the reference changes. Dialogs using ACL Based on these speech acts, we can build communication protocols. A dialog can be modeled as an deterministic finite automata. For an easier implementation at the beginning we reduce the finite automata to trees there the root is the starting point of a dialog and leaves are the possible end states. As mentioned before a message consists of required information and a standardized format (as long as only one agent communication language is concerned, KQML and ACL are different in a few elements). An ACL message consists of the following contents: • sender Denotes the identity of the sender of the message, i.e. the name of the agent of the communicative act.

3.2. ARCHITECTURE

61

• receiver Denotes the identity of the intended recipient of the message. Note that the recipient may be a single agent name, or a tuple of agent names. This corresponds to the action of multicasting the message. Pragmatically, the semantics of this multicast is that the message is sent to each agent named in the tuple, and that the sender intends each of them to be recipient of the CA encoded in the message. For example, if an agent performs an inform act with a tuple of three agents as receiver, it denotes that the sender intends each of these agents to come to believe the content of the message. • content Denotes the content of the message; equivalently denotes the object of the action. • reply-with Introduces an expression which will be used by the agent responding to this message to identify the original message. Can be used to follow a conversation thread in a situation where multiple dialogues occur simultaneously. • in-reply-to Denotes an expression that references an earlier action to which this message is a reply. • envelope Denotes an expression that provides useful information about the message as seen by the message transport service. The content of this parameter is not defined in the specification, but may include time sent, time received, route, etc. The structure of the envelope is a list of keyword value pairs, each of which denotes some aspect of the message service. • language Denotes the encoding scheme of the content of the action. • ontology Denotes the ontology which is used to give a meaning to the symbols in the content expression.

62

CHAPTER 3. MULTIAGENT D-SIFTER • reply-by Denotes a time and/or date expression which indicates a guideline on the latest time by which the sending agent would like a reply. • protocol Introduces an identifier which denotes the protocol which the sending agent is employing. The protocol serves to give additional context for the interpretation of the message. • originator This parameter indicates the ultimate sender of brokerage request messages. This parameter must be relayed through brokerage agents (e.g. DFs or matchmaker agents) and delivered to the ultimate recipient agent. In the brokered/recruited request message (i.e. embedded in proxy message), this indicates the original requesting agent. On the other hand, in the replying message, this indicates the source of the answer (i.e. the replying agent). With this parameter, the ultimate recipient agent can know the ultimate sender agent of the received message and can treat such messages as having more trustworthiness. • reply-to In requesting messages, this parameter indicates that replying messages are to be sent to its value’s agent name instead of the sender of the received requesting message. This is used for recruiting within the proxied request (not only for recruiting requests, this can be used in the requesting messages in general). • protocol(+) Introduces an identifier which denotes the protocol which the sending agent is employing. The protocol serves to give additional context for the interpretation of the message. This indicates the nesting structure of protocols. The left most name is the most nesting sub-protocol (i.e. current sub-protocol). • conversation-id (+) Introduces an expression which is used to identify an ongoing sequence of communicative acts which together form a conversation. A conversation may be used by an agent to manage its communication strate-

3.2. ARCHITECTURE

63

gies and activities. In addition the conversation may provide additional context for the interpretation of the meaning of a message. Each conversation-id in the list corresponds to the sub-protocol in the protocol parameter. The left most is the one in the current sub protocol. • conversation-id Introduces an expression which is used to identify an ongoing sequence of communicative acts which together form a conversation. A conversation may be used by an agent to manage its communication strategies and activities. In addition the conversation may provide additional context for the interpretation of the meaning of a message.

(inform :sender i :receiver j :content "weather(today, raining)" :language Prolog ) Figure 3.9: Example of a simple ACL message An example for a FIPA ACL message (cf. Fig. 3.9)and its translation into XML (cf. Fig. 3.10) is provided by the corresponding figures. weather(today, raining) Figure 3.10: Example: XML encoded ACL message

Message-Structure for D-Sifter Communication in the multiagent D-Sifter bases on the FIPA/ACL2.0 messages, i.e. the constructs mentioned in the last sections as speech-act types

64

CHAPTER 3. MULTIAGENT D-SIFTER

(performatives) and the contents of a message are used following the same semantics. For syntactical reasons based on the Java implementation some names are changed. There is one extension to the receiver content as men-

Figure 3.11: Design abstract data type letter tioned below. The following list is the content list of the D-Sifter implementation. The design of an abstract data type for messages can be found in figure 3.11. The envelope element from the FIPA method is removed from the message object and integrated into a single abstract data type. The reason for the separation of message and envelope in the letter object can be found in probable future developments of new agent communication languages or the use of a KQML statement instead of FIPA/ACL2.0 statement for which the message semantics must be changed, but the relevant parameters for sending

3.2. ARCHITECTURE

65

and receiving of the message will keep the same. The adapted letter object within Multiagent D-Sifter is consisting of the following concepts: • sender Agent name of sender. • receiver This concept is extended as FIPA does not know the here used concept of agent classes. Sending a message with an agent class name as receiver means sending a broadcast message between all agents of this class. As broadcasting is sent to all agents, all agents of different classes will ignore this message. • content Denotes the content of the message; equivalently denotes the object of the action. • replyWith Each message gets an ID in the field in-reply-to. This is used by all responses to another message. • inReplyTo This is an unique identity consisting of the agents name and its internal message counter. • envelope – sent Sending date of the message. To compensate asynchronous communication. – source Agent address which can be used to directly address to the source agent. – destination Agent address which can be used to directly address to the destination agent and in fact is used as long as this is not a broadcasting message. Considering broadcasting here can only be found the name of the destination agent class.

66

CHAPTER 3. MULTIAGENT D-SIFTER • language Denotes the encoding scheme of the content of the action. • ontology In the case of D-Sifter the ontology is constant as all agents are using the same ontology (’Information Retrieval and Filtering’). • replyBy Denotes a time and date expression which indicates a guideline on the latest time by which the sending agent would like a reply. • protocol Introduces an identifier which denotes the protocol which the sending agent is employing. The protocol serves to give additional context for the interpretation of the message. The available are well-defined and can be found in one of the following sections. • originator At the moment it is not clear if this field is needed to keep track of the requesting domain agent when new documents are retrieved, represented, and classified. • replyTo In some protocols it is necessary that other agents are instructed to respond, e.g. if a domain agent instructs a dam agent to retrieve documents these documents are passed to the representer and not to the domain. • protocol(+) not used. • conversation-id (+) not used. • conversation-id The conversation identity is the same expression as the inReplyTo identity if this is the first message of the conversation. Otherwise the number is kept from previous messages. The conversation identity is unique for any conversation in the system.

3.2. ARCHITECTURE

67

• type The message type is newly introduced for this design as it is necessary to describe which agent communication language the message is encoded in. raining Figure 3.12: Example of a letter object in multiagent D-Sifter Figure 3.12 shows an example for a message in multiagent D-Sifter (XML).

3.2.3

Controller

The controller layer determines the behavior, strategy, and state of the agent. That means an agent behaves in the way the functions and procedures in the controller decide. The agent can only learn from experience acknowledged in the controller. The architecture presented here is based on the deliberative

68

CHAPTER 3. MULTIAGENT D-SIFTER

agent architecture BDI. The architecture will be extended to an architecture enabling an agent to decide its behavior on the basis of conflict resolution. This approach, the conflict-based agent control, is part of my PhD thesis. In this section, we are presenting an intuitive approach to an agent control motivated by BDI and realized with the calculation of priorities through utility functions. The knowledge representation of an agent is based on object concepts.

Figure 3.13: Components of the Controller The management and control of the agent’s action and behavior is subject to innumerable researches. The here proposed structure is influenced by market-based communication protocols, BDI and the KADS methodology for knowledge engineering. The main knowledge-base (cf. 3.13) is the set of beliefs. The beliefs have assumptions on the probability or usability of desires and intentions. Desires are the more abstract goals like an criteria for optimal solution which cannot

3.2. ARCHITECTURE

69

be reached in the current state of the agent. Intentions must be realistic and reachable under the current situation. The agent has committed to the intentions, i.e. it is trying to fulfill the intentions. The intentions are corresponding to goals. Goals is an extended concept of BDI architectures which is used in this approach as it is an intersection to tasks in KADS. We use the exported functions as ”inferences” (misunderstandable word!). An element of the powerset of ”inferences” combined with a pre- and postcondition leads to a goal. The goals are matched to intentions. So the planning of an agent involves choosing the right intention in dependency to the most popular desire at the state of consideration of the recent knowledge.

Figure 3.14: Main object of the controller A first approach will leave the complex control structure out of consideration and will start with an easy relational knowledge representation for the beliefs, utility functions for the intentions and desires are left out. Figure 3.14 shows exported methods of the controller, which are used by the communicator. The inheritance relation is very simple, the controller is a direct subclass of the class object. Starting with a rudimentary control algorithm the agent gets an explicit knowledge representation with explicit algorithms on this knowledge. The first implementation will consider the controller as an object-centered knowledge base with simple reasoning and update methods on this knowledge. Future implementations should integrate a more powerful knowledge-base representing temporal knowledge and should integrate updating algorithms

70

CHAPTER 3. MULTIAGENT D-SIFTER

as truth-maintenance-systems. For a better understanding, the first two subsections will introduce a formal model to BDI and the decision algorithm of BDI. The next subsection is dealing with the knowledge representation followed by a subsection for the decision algorithm on this basis. There are some comments on learning and adaptation within this framework.

Formalizing BDI The general shape of formalization may be explained by the following basic definitions.

Definition 1 A single belief is symbolized as a term, the set of any possible beliefs is defined as B, and the set of current beliefs as B. The agent state at the time t (St ) is determined by the 3-tuple (Bt , Dt , It ) of current beliefs, desires, and intentions, which are defined in the following definitions 1, 5, and 6. For a better understanding we start introducing the concepts bottom-up. On the action level of the system we differentiate two general concepts, communicative actions (communicator) and executive actions (executer). Definition 2 A is the set of all generic actions. The sets of generic communicative and generic executive actions are defined as Ac ⊆ A and Ae ⊆ A, so that (Ac ∩ Ae = ∅) ↔ (Ac ∪ Ae = A) is true. The agent has a set of predefined generic communicative action types (Ac ) as well as a set of generic executive action types (Ae ). The instances of these generic action types are activated either by the communicator or the executer (see Definition 2). For the next level of abstraction we unify communicative and executive behavior. Executor action sequences and communicator action sequences are integrated in the dialogue 3-tuple (Sequence, B diag , select) (Definition 3). The dialogue concept consists of a set of available generic actions, a set of current beliefs in the framework of this dialogue, which is a subset of the current beliefs of an agent, and a mapping from both sets to one action, which implements a dynamic belief

3.2. ARCHITECTURE

71

network for action selection.

Definition 3 The 3-tuple (Seq, B diag , select) is a dialogue with Seq ⊆ A, B diag ⊆ B, and the mapping select, defined: select : A × B → A, select(Seq, B diag ) 7→ α∗ with α∗ ∈ Seq. The current available dialogues of an agent are symbolized with Di as a subset of all dialogues Di ⊆ DI. A dialogue has a subset of the current beliefs of the agent. They are containing necessary information about the opponent, the state of the dialogue, and support for the selection of the agent’s next action. If there is content knowledge necessary, e.g. content of a speech-act or parameters for method invocation, it is supported by the next level of abstraction, the conversations (see Definition 4). The conversation concept slightly comparable to the concept of partial plans. It consists of pre- and post-conditions, a subset of the current beliefs of an agent, a set of dialogues, and a select-mapping for choosing the next dialogue to activate. The subset of beliefs can be rather complex and is representing the knowledge, which is necessary within and between the dialogues. The above introduced concepts, action, dialogue, and conversation are represented by classes, which are activated by instantiation. In the case of a conversation a subset of current beliefs of the agent and in the case of a dialogue a subset of the beliefs of the activating conversation is created for them.

Definition 4 C is the set of all possible conversations. C ⊆ C symbolizes the set of conversations, which are implemented in an agent. A conversation c ∈ C is defined as the 5-tuple (Con, P re, P ost, B con , select) with Con ⊆ C, P re ⊂ B, P ost ⊆ B, B con ⊆ B and the mapping select. The mapping select matches the possible dialogues Con and the believes of the conversation B con to a dialogue, which is designated for their activation: select : C × B → D; select(Con, B con ) 7→ δ ∗ with δ ∗ ∈ Con. On the basis of these concepts we define an auxiliary concept Aim, which is used by the following definitions. Aim is a subset of the set of beliefs B.

72

CHAPTER 3. MULTIAGENT D-SIFTER

It is used for the post condition desired by the hosting concept. The agent’s goals are specified as desires (see Definition 5). They consist of the set Aim and a set of alternative conversation for pursuing, i.e. achieving, Aim. Furthermore, it contains a mapping for the determination of the preferred conversation as well as the currently chosen preferred conversation.

Definition 5 Let D be the set of any possible desire an agent can have and D ⊆ D the current set of desires the agent has. The 4-tuple (Aim, Alt, c, pref erred) is a desire with Aim ⊆ B, Alt ⊆ C, c ∈ C and the mapping pref erred : B × C → C; pref erred(Aim, Alt) 7→ γ ∗ with γ ∗ ∈ Alt. In the BDI as well as our approach intentions are defined as committed desires. For the activation of a desire it is necessary to choose one conversation from the set of alternatives as a basis for achievement of the goal. After this selection it is not possible to change the conversation unless by in-activation and later activation of the desire again. So the definition of desires is reduced to a set of Aim, the selected conversation, and extended by a status mapping, determining the current process of Aim satisfaction (see Definition 6). Definition 6 The 3-tupel (Aim, con, status) is defined as an intention with Aim ⊆ B as a set of beliefs, con ∈ C as the activated conversation and the mapping status : B × C → [0..1]; status(Aim, con) 7→ x with x ∈ [0..1] determining the completion of the Aim. The BDI algorithm The BDI approach consists of four actions, which are arranged in a loop and continuously executed. P symbolizes the set of perception for the agent, p ∈ P is defined as a single perception; the actions are presented in a semiformal manner and explained in natural language. 1. belief − revision : B × P → B belief − revision(Bt , p) 7→ Bt+1

3.2. ARCHITECTURE

73

The belief revision is responsible for updating the knowledge-base, i.e. the beliefs, of an agent due to the current perception. It initiates a new state of the system by the generation of a new belief set (Bt+1 ). 2. options : B × I → D 0 options(Bt+1 , It ) 7→ Dt+1 The second step of the BDI algorithm creates the options for the next action. Some approaches to BDI explicitly define a new set at this stage, the set of goals. This is necessary if the set of desires is allowed to be inconsistent. In this case the set of goals is a consistent subset of the set of desires. We define the set D0 as a consistent subset of D. The contents of the set of goals are depending on the current state (Bt+1 ) and the set of intentions from the last step (I). 3. f ilter : B × D × I → I 0 f ilter(Bt+1 , Dt+1 , It ) 7→ It+1 The filter mapping creates a new set of intentions for this state (It+1 ). It is the most important step within the BDI algorithm as it determines the next course of action. The selection of a new intention is called ”commitment to the intention”. But the filter step is not only activating intentions but also retracting intentions which are not appropriate any more or cannot be achieved under the current conditions. 4. execute − action : I → A execute − action(It+1 ) 7→ α, with α ∈ A The last step in the BDI algorithm is initiating the previously selected action according to the current set of intentions (It+1 ). The major drawback of this algorithm in the field of information retrieval with changing domains can be found in the assumption of a consistent set of desires. Modeling complex organizations of domains often leads to definition of goals, which are inconsistent. The creation of consistent subsets (goal) for action selection is not satisfying for such environments, as they have to realize multi-criteria optimization, which are based on competing goals. The construction of a general conflict-based agent control is part my PhD thesis. Knowledge representation in multiagent D-Sifter For the rapid prototype implementation of a first multiagent D-Sifter there is need of a simple, efficient, and adaptable approach in the knowledge-

74

CHAPTER 3. MULTIAGENT D-SIFTER

representation. There are four important steps in the controller workflow: 1. Update Knowledge-Base 2. Evaluate Resulting Goals 3. Planning Actions 4. Select Action → Execute These steps are executed in a loop. These procedure automatically leads to eight issues: 1. Representation of knowledge 2. Updating the knowledge-base 3. Inferencing goals from knowledge-base 4. Evaluating goals 5. Goal decomposition into actions 6. Planning actions 7. Selection of the ’most important’ action 8. Supervision of action Each agent’s knowledge representation bases on the object-centered knowledge representation, i.e. the information on other agents, own behavior, and interaction is stored in special objects. As this system is a non-adaptive system there are two main parts of knowledge which can be discriminated: dynamic knowledge and static knowledge. Very important for the evaluation algorithm is that each piece of knowledge is combined with a probability, symbolizing relevance or belief of this knowledge unit to the agent. This enables the agent to calculate priorities for actions more easily.

3.2. ARCHITECTURE

75

Dynamic knowledge The dynamic is changed by the agent on its own during runtime. This part of the knowledge-base is responsible for the current state of the agent. It is describing the agent’s knowledge of other agents, itself, current communication protocols (showing active conversations). On the other hand its also showing its abilities regarding to its actions and solution capabilities. The elements of the knowledge base, their abstract data type, and their content type can be found in the following items. • MySelf (Tuple): (Name,Class, Description, Address, Credits) • AgentClasses (List): (Name, Importance) • Protocols (List of Simplified Trees) • Actions (List): (Name, Preference) • Goals (List): (Name, Preference) • Preconditions (List): (Name) • Solution (List): (Precondition, Action, Goal, Preference) The dynamic knowledge is under consideration in each inference step of the controller. This may have the effect, that the contents are changed from one action selection to the next. Static knowledge The static part of the knowledge base contains knowledge, which is changed within every inference step of the control algorithm. Knowledge of the other agents seems to be static. But even this knowledge can be changed, e.g. an agent, which is leaving the system, can be erased from the agent list. A state is defined as a list of tuples. They are showing the preconditions and their relevance to the agent. The most important aspects of the static knowledge are the following: • Agents (List): (Name, Class, Description, Address, Used, Efficiency, Earned, Spent) • State (List): (Preconditions, Relevance)

76

CHAPTER 3. MULTIAGENT D-SIFTER • Solving (List): (Solution, Belief) • ActiveConv (List): (Protocols, Relevance) • (Utility (method): Evaluation method for determining the priority)

Agent control in multiagent D-Sifter Next to the knowledge there is also a processing algorithm to be implemented that is introduced in this section. The processing algorithm consists of five main actions: process messages, update goal list, update option list, evaluate options, and execute actions (cf. BDI algorithm). This algorithm is running in a loop. It is explained in more detail within this section. The execution cycle is represented in Figure 3.15.

Figure 3.15: inference 1. processMessages The processMessages method will check the inbox if any new messages have arrived. The messages will be processed in first-in first-out order. Some messages will need an immediate response unlike most messages which simply change the agent’s state and update its knowledge. This method is a elementary method which is part of the controller object. 2. updateGoalList After the messages are evaluated and the knowledge has been updated the agent looks for any goals which can be fulfilled on basis of his recent state. These goals are stored in a list. This method is based on the knowledge and in consequence situated in the knowledge object. 3. updateOptionList The list of goals leads to a list of possible actions, automatically. This list is called OptionList as not any possible action can be executed.

3.2. ARCHITECTURE

77

4. evaluateOptionList This is one of the main tasks within the agent control. The options or possible actions must be evaluated to find the most important task which can be executed afterwards. In the first implementation this includes a aggregation of the action and goal relevance. 5. executeAction The action with the highest priority is called in this method. The successful/unsuccessful execution updates the knowledge of the agent. Here ends one processing circle.

3.2.4

Executor

In contrast to the communicator layer this layer ensures the internal communication with accessible units of its underlying resources, e.g. document space, filtering algorithm, or thesaurus. The next interface, connecting the executor level to the controller level consists of explicit methods which can be used by the controller for action planning and execution. This level tries to reduce re-programming of Sifter significantly. In this part there are all functionalities implemented and defined. That means that the Executer is exporting all methods, which can be accessed from outside the classes. This will lead to all possible elementary actions, the controller can plan. So the difficulty can only be found in identifying the corresponding classes to the different types of agents. The whole concept bases on two different elementary actions: getInfo, doTask. These both actions are translated in method calling and variable manipulation. The methods and variables are defined through the public variables and methods of the package ’executor’. The ’executor’ should be build on basis of the existing Sifter versions. As the user profile is represented partially within the controller layer of the user agent the executor level of the user agent is not identical to the user profile within Sifter. We assume that the translation from other agents is easier (see next section).

78

3.3

CHAPTER 3. MULTIAGENT D-SIFTER

Design

Multiagent D-Sifter is trying to combine flexibility of multiagent systems, user adaptability, and filtering power of the Sifter system. In this section we are introducing the major communication and decision aspects of the multiagent system. Beginning with a short system’s overview, an introduction of the different agent types and a detailed description of the communication protocols of the different agents are presented. This section is closed with an introduction of market based decision models in respect to information filtering and retrieval. Information filtering and information retrieval is one of the most important tasks in environments where the amount of available information is steadily growing. There are different approaches to this topic reflecting the grade of user interaction. One major aspect of the Sifter development is to keep user interaction as low as possible. Thus, the multiagent system does not need a lot of different user interaction interfaces as in the agent architecture proposed in the last section.

3.3.1

System overview

The basis of this multiagent approach is the original Sifter system. The design of the multiagent system is motivated by the FIPA standardization efforts [FIPA, 1999c]. FIPA is proposing a reference architecture consisting of a directory facilitator, an agent management system, the agents, and an agent communication channel. This architecture should enable agent systems within one (physical) environment, e.g. one computer. The agent management system is supporting intra-agent communication within this environment. The agents communicating to agents of other platforms are using the agent communication channel. The directory facilitator is incorporating a yellow page service for the agent platform. Connected to other agent platforms it is sharing the agents’ address information. The approach proposed here is restricted to software agents, so that the implementation of different agent platforms is not a primary goal. Thus, the design of the system here is missing an agent management system. The agent communication channel is integrated into each agent. The system is in need of a yellow page service comparable to the directory facilitator,

3.3. DESIGN

79

however. Considering the tasks of a yellow page service within an agent system, it is obvious that there are just a few tasks to be solved: register, de-register, and request information about other agents. This entity is therefore comparable to a very simple agent, being able of three different communication protocols. In the approach presented here, the yellow page service is realized by an elementary agent: the agent world, also named agent registration center.

Figure 3.16: Inheritance hierarchy of agent classes The main agent system is consisting of five different agent types, introduced in the next subsections. For implementation details, we introduce the concept of agent skeleton. This class as a subclass of the class object is integrating the generic communication abilities with a simple decision mechanism for the agent’s behavior. But the skeleton is reduced to the two agent specific modules communicator and controller. The executor module is added in the class agent. The class agent registry is a subclass of agent skeleton and is also not implementing the executor level. Analogous to the

80

CHAPTER 3. MULTIAGENT D-SIFTER

agent registry we shall introduce a user registry entity, keeping track of all user relevant login information and properties. The class agent is integrating interfaces for the executor level, is a sub-class of agent skeleton, and the super-class for any other agent within the system. The main agents will be introduced in the next subsection. The inheritance hierarchy can be found in Figure 3.16. The logical view on the system does not contain the agent registration center as it is a part of the environment resp. network. The agent system is dealing with different agent types, which are fully connected via a network. This enables them to communicate with any other agent or agent type. The environment (agent world) is just providing the agents with necessary information for the building connections to other agents. In Figure 3.17 the general concept of agents without static hierarchical structures is symbolized.

Figure 3.17: Architecture of the Multiagent D-Sifter In the first step, the multiagent system will be implemented using Java and for inter-object collaboration JavaRMI. The discussion is not completed yet and it could be possible that the concept of object interaction will be exchanged in the future (e.g. with CORBA or Database and JDBC). As a result the architecture of each agent must be as flexible and modular as possible to make it easy to exchange different communication channels. Even a combination of different approaches looks promising. For the message exchange between agents there will be the new concept of hiding the agent communication language in a XML statement which can also represent semantical information independent from any programming language or agent communication language as mentioned in the last section.

3.3. DESIGN

3.3.2

81

Agents

The agents within the new architecture are identified following the different tasks of the prior Sifter versions. Thus, it seems to be promising to incorporate the following agent types: user, representer, domain, classifier, and data-acquisition & management (DAM) (cf. Figure 3.17). Another important agent in this design is the user registration center. This agent is the entry point from a web interface to the multiagent systems. Its objective is to authenticate an user and assign the user to his user agent or create an user agent (cf. agent factories in [FIPA, 1999c]). This section is restricted to the definition of the first five agent types, however. The other two agent types do not have to be realized from the scratch as concepts of them are existing. The agent registry is clearly defined within the FIPA standardization efforts and the user registry can be re-used from the classical Sifter approach.

User Agents User agents keep track of the user relevance vectors (estimated relevance and action probability vector) and influences the system in two ways. For the information retrieval, i.e. the keyword based retrieval of probably interesting documents the agent can initiate a retrieval process following special keywords/keyword combinations. On the other hand the user agent is providing feedback to documents depending on the user relevance. This feedback should change the behavior of the system in that way that agents which participate on high relevance document retrieval are used in a more frequent way. As we are dealing with multiple domains the user agent must be capable of handling various relevance vectors according to the domains in question. The user agent is the most complex entity in our distributed environment. Unlike the other agents, the computational part of the user agent cannot be exported into the executor. The user agent also implements an user interface. So the user can directly interact with the user agent but the other agents have to use agent communication. The user agents keep track of the relevance of domains and thesaurus’ and - of course - of the user profile (i.e. the d and the p Vector). The user agents aims at getting as many documents as possible with the highest value considering the users profile

82

CHAPTER 3. MULTIAGENT D-SIFTER

into the system. It can initiate information retrieval and evaluate sources, i.e. give feedback to the DAM agents. The standard interfaces for the user agent are receiving document handle from the domain agent, or documents from the DAM agent, receiving a list of domain agents for the user choice between interesting topics, receive thesaurus for the selection of search keywords, giving feedback to the domain agent according the users interest in documents. For the normal use of an user agent the following conversation situation will occur: • New User / Initialization If a new user agent was generated. The first interaction is between the user agent and the user registration center to receive the user agent’s address and establish direct communication between user and user agent. The second step is the call of the Setup User Profile and afterwards in an extended version of the Sifter prototype the user agent should communicate with other user agents to identify similar user profiles and preset the preferred domain agents. After this the user has to create a password with Login / Authentification and finally the user has to chose the domain(s) he wants to work with. • Login / Authentification The login/ authentification protocol is a collaboration between the user agent and the user registry center. The user has to chose his password or at first use create a new one. If the user tries to log-on as a returning user, the Website is communicating with the user registry center, this is checking on the password and id and asking all user agents if someone is assigned to that user. If there is no assigned user the initialization procedure is started. • Receive Document The user agent requests a specific document from a list of new documents. This request should be sent to the domain agent and handled over to the dam agent. As a result the dam agent sends the requested document or document handle to the user agent directly. • Setup User Profile The setup of the user profile is similar to recent development in DSifter. In this case the domain agent is asked to present classes. The

3.3. DESIGN

83

classes, i.e. centroids, are send from the domain agent to the user agent on request. Then they are presented to the user which evaluates them. • Select Domain The user agent broadcasts a message to any other agent and asks for information on domain agents in the system. These agents send their ’personal’ information to the requesting user agent. • Information Filtering In information filtering the user agent just sends some information about the highest prioritized classes, documents, or domain agents to the domain agent. The domain agents wants to satisfy the user agents requests and instructs the dam dam agent to provide documents fitting minimal similarities conditions. If the dam agent doesn’t have similar files its retrieving new documents. • Information Retrieval In the information retrieval phase the process gets a bit more complicated. The user agent receives the thesaurus of the field in which the user wants to start its retrieval. Then the user has to chose a couple of keywords and these keywords are handled back to the domain agent and afterwards to the dam agent. New documents are retrieved, represented, classified and visualized to the user. • User Feedback Processing user feedback is a very rudimentary functionality of the user agents. The role of the user agent is to determine the user profile and identify the domain agent which supported retrieving the document. This leads to the Give Feedback action. • Give Feedback This should support the overall system to optimize the document retrieval to user oriented behavior which adapts to changes in the users’ interest. The user agent sends positive feedback for a documents to domain agent. This is supporting its dam agent with the positive feedback and so the dam agent can increase the seek of documents in that source which has been interesting for multiple users.

84

CHAPTER 3. MULTIAGENT D-SIFTER

Domain Agents Domain Agents have a very central role in this approach. They are storing the inverse document frequency vector for the document bases they are using. Furthermore they are saving results of the classification (centroids) and managing the thesaurus. The domain agent has some kind of centralistic role in this design as it is controlling the retrieval of documents through keyword submission to the dam agents and keeping track of the classes and thesaurus’ of one domain. The domain agent has the most complex interfaces as its receiving document handles from the DAM agent, the representations vectors of documents and the inverse document frequency from the representer agents, centroids and assignment vectors from the classifier and keywords for retrieval from the user agent. On the other side the domain agents provides the thesaurus to the user and representer agent, it handles the inverse document frequency vector to the classifier as well as the classes in case of classification of a single document. It’s instructing the DAM agent by sending special keywords or special amount of credits, it’s providing feedback to the DAM agent considering the user agent’s feedback. The DAM agent also passes document handles to the representer, classifier, and the user agent. • Initialization A new domain is generated by the superuser or administrator. Essential connections of the new domain agent is at least one thesaurus. The agent may probably get preferences for DAM agents, but can also generate them by itself. The initialization process follows an announcement for all agents that a new agent is available and an request for all DAM agents. If no preferences are available the DAM agents get all the same priority and assessment and one of them is chosen by random. • Retrieve Documents There are two ways of document retrieval: active and passive. If a user agents asks for specific information the domain agents looks for the dam agents he got the best results for this user agent. The domain agents delivers the thesaurus to the user agent and the user agent returns some keywords to the domain agents. These are passed over to the dam agent. The dam agent should start a research, deliver the documents to the representer, the domain agent delivers the thesaurus

3.3. DESIGN

85

to the representer, the representer agent passes the representation to the classifier and the document is classified. Afterwards the domain agents gets the document handle, the class association and forwards this information to the user agent. In the passive way of retrieval the domain agents instructs first the DAM agent with the highest priority for a research and if he has a special credit value instructs other DAM agents. • Receive Document If a DAM agent is in the opinion that the domain agent may be interested in the documents as it bought a lot of other documents, it offers the domain agent documents. Depending on the actual standing of the domain agent it starts to represent and classify the documents following its thesaurus. • Select Domain The user agent broadcasts a message to any other agent and asks for information on domain agents in the system. Basing on this request the domain agents sends its identification, i.e. ’personal’ information to the requesting user agent. • Receives Feedback The user agent gives feedback to some of the retrieved documents. The feedback will be stored to the accompanying class. So the class value is increasing. The domain agent can use important keywords of an important class for a filtered retrieval. • Give Feedback The domain agent gives feedback to the DAM agent which delivered the document the user was satisfied with. • Classify new data source If a new data source is classified the domain agent receives the inverted document frequency vector, the document representation vector and receives in the second step from the classifier agent the centroids. • New Document If the agent receives a single document the document is represented by sending the handler and the thesaurus to a available rep-

86

CHAPTER 3. MULTIAGENT D-SIFTER resenter. Afterwards its classified using the existing inverse document frequency vector.

Document Acquisition and Management Agents Following the importance and complexity of the agents, document acquisition and management agent are the third agent-group. Each of these agents has two sub-agents. The communication with the agent system is realized by the management agent (component). This is instructing two sub-agents, the wrapper, and the document storage agent. The latter one is responsible for storing documents so that they are available in the agent system. The wrapper agent is almost identical with the wrapper agent for E-Sifter. The DAM agent consists of two computational aspects: the document set and the wrapper. The document set simply stores all document or document handles the wrapper agent acquires. The wrapper agents automatically retrieves new documents from the document source. For these tasks the DAM agent receives feedback from the domain agent, provides the domain agent with document handles, passes on base of document handles documents to the representer or the user agent. • Initialization A new DAM agent initializes its wrapper and fills the document set. The document set can be prepared by the user oder superuser. The search is unfocused and has a low priority at the beginning. • Retrieve Documents If the domain agent asks for documents and it must provide three information: How old should they be?, Are there any keywords for the documents?, and Is it an urgent matter? These information are mutually for the further retrieval process. Normally the DAM agents receives a few keywords and delivers document handles after a specified time. In either case the DAM agent passes a set of document handles to the domain agent. • Send Document The user or representer agent asks for the document handle of a specific document. This is passed to them immediately.

3.3. DESIGN

87

• Nothing to Do If the DAM agent has nothing to do it will automatically search for new documents in the web. For this purpose it stores old queries and the queries with the best results considering feedback will be used as default. Representer Agents These agents consist of problem solving methods independent from domain or user. They have access to all necessary information for their special job and provide the inverse frequency vector in combination with evaluated vectors for the documents. The representer agent is a simple agent. It’s only providing an algorithm for other agents. The usage is that the domain agents sends a set of document handles to the representer agent, which has to ask for the documents at the DAM agents. Furthermore it receives a thesaurus for this document set and evaluates the document set. The result is an inverse document frequency vector and a document representation vector. These are handed to the domain agent. Classifier Agents Classifier agents are problem-solving methods in the meaning of algorithms which can be used generally and independent of domain or user. They are instructed with all necessary information and provide the inverse frequency vector in combination with evaluated vectors for the centroids (classifier). Similar to the representer agent the classifier agent is from a very simple kind. It’s only collaborating with the domain agent. There are two possible usages: first the domain agent provides the classifier agent with a set of document representation vectors, an inverse document representation vector and asks for the generation of classes, the centroids and the document-toclass-assignment vector. In the second case the classifier agent receives the centroids, the inverse document vector and is simply assigning a document representation vector to a specific class.

88

CHAPTER 3. MULTIAGENT D-SIFTER

Remark: representer and classifier agents Classifier and representer agents are problem solving methods in the meaning of algorithms which can be used generally and independent of domain or user. They are instructed with all necessary information and provide the inverse frequency vector in combination with evaluated vectors for the documents (representer) or the centroids (classifier).

3.3.3

Agent interaction

The identification of communication dialogs and conversation behavior between agents seems to be very similar to finding a minimum set of interfaces between objects. We are presenting standard communication behavior of the different agent behavior. The standard approach for modeling communication protocols is to use finite automata. Some problems occurs with a finite automata model of communication protocols: they can contain cycles and lead to an unpredictable and a possible unstable behavior of the overall system. To address these problems we decided to use tree structures to model communication protocols. The advantage lays in the a priori known maximum length of communication protocols. The root is symbolizing the starting point of the protocol. Speech acts are represented by the edges. The leaves are marking stop-points of the communication. For the definition of the communication protocols each agent is analyzed in respect to its communicative behavior. Communication protocols for these behaviors can be derived directly and must be shared by any participating agent. Within this subsection there are two types of communication protocols introduced: general interactions, used by any agent, and specialized communication protocols listed according to the initiating agent. The figures are interpreted using the definition in figure 3.18. General interactions These interactions are the conversation performed by any agent or at least group of agent classes. As these interactions are not class based they are more technical dialogs for login on the system, log out, or general requests.

3.3. DESIGN

89

Figure 3.18: Definition for conversation figures • Registration An agent initiating this dialog is logging on at the system and sends its name address, class, and natural language description to the other agents, so that it can be addressed. The agent does not wait for any responds, as it’s a general information consisting of only one speech act. Any Agent: Registration (cf. figure 3.19) An agent coming into the system sends its identification, address, class, name, and a description string to any other agent. This is a single speech-act conversation as no answer is required. • Unregistration The agent announces that it is canceling participation. It is destroyed after this message, probably. Any Agent: Unregistration (cf. figure 3.20) Any agent which is removed from the system sends a message to all

90

CHAPTER 3. MULTIAGENT D-SIFTER

Figure 3.19: Conversation: Registration other agents that it’s no longer available. The content is also the agent description. This is a single speech-act conversation as no answer is required.

Figure 3.20: Conversation: Unregistration

User agent interaction In consequence of the tasks identified in the last section there are five main communication sequences initialized by the user agent. They are defined as follows: • User - Domain: What domains are available? (cf. figure 3.21) The user agent tries to identify all available domain agents. The answer to this request is a simple inform. (One major question could be: Why do we need this communication concept when our agents are storing all information about other agents? Because user agents are created instantly by the system and new user agents haven’t received any broadcasting messages from all different domain agents). • User - Domain: New documents? (cf. figure 3.22) The user agent tries to receive new documents from the domain agent (only document handler!). The user agent requests documents, the domain agent may ask something considering this request, e.g. How young should they be. The user agent would answer this request and if the domain agent knows what to show, it will provide documents. The selection of the

3.3. DESIGN

91

Figure 3.21: Conversation: What domains are available documents is part of the domain agent knowledge (first the newest documents from the class of the highest priority). This could also be a question from the domain agent, which is more important: new or relevant documents. If the domain agent has no information to provide it can instruct a DAM agent and let new documents be represented and classified which it can then provide to the user agent. • User - Domain: Research The user wants to retrieve documents to specific keywords considering a domain. This is the active part of the user agent. The user agent requests the thesaurus from the domain agent and provides the user with all available keywords. The user selects a few of them, assigns weights to them and the user agent requests a research on these keywords to the specified domain agent. The domain agent passes these keywords to the DAM agent which instructs its wrapper part to find documents. The user agent may cancel this research based on a time-limit or a change of the user’s good will. • User - Domain: Feedback For the adaptive behavior of the multiagent system the feedback is one of the most important aspects. Feedback is provided from the user to certain documents. It can be positive or negative. In the D-Sifter approach are the same categories used as in the Sifter approach. The user agent converts the user’s feedback to credits and assigns these to a domain agent via this message. Here the user user agent provides the document handle and the feedback as a tuple so that the feedback can be properly computed by the domain agent. This conversation is

92

CHAPTER 3. MULTIAGENT D-SIFTER

Figure 3.22: Conversation: New Documents a simple inform - confirm construct. • User - Domain: Show Document Also a very simple conversation is the user’s request for a specific document. The request is attributed with the document handle. The domain agent forwards this request to the specific DAM agent which directly communicates with the user agent to pass over the document. Domain agent interaction The domain agent is using the communication protocols to keep the documents within a domain up-to-date. Further on they are enabling the domain

3.3. DESIGN

93

agent to perform a user query. The domain agent incorporates four main communication protocols: • Domain - DAM: Document Retrieval The domain agent instruct the DAM agent for a research. Therefore it has three different kinds of research: keyword research with high priority (user research), keyword research with low priority (own research based on the most important keywords in the classes with the best overall user feedback), or unfocused research (without providing keywords). The last type is used for researches done at a time where the domain agent cannot decide which classes are important as it hasn’t received feedback. The first two types are pretty similar. The conversation is for all three classes equal. The domain agents requests the research, the DAM agent provides document handles, and informs the domain agent which representer received the document. • Domain - Representer: Represent Documents The domain agents sends the thesaurus to the representer agents and waits for the inverse document frequency vector and the vector for the documents. If there is already an inverse document frequency vector in the domain agent then the new one is ignored. • Domain - Classifier: New Classification If the domain agent has never received a classification scheme for the document source from where it received new documents then the domain agent instructs the classification agent to classify the documents. The classification agent received the vectors of the document representation from the representer agent in before and the domain agent passes the inverse document frequency to the classifier agent1 . Now it is using its classification algorithm to generate the classes and passes centroids of the classes, and the assignment vector of the documents to the classes to the domain agent. • Domain - Classifier: Classify Document This conversation is also a very simple one. The classifier agent received 1

Why are we passing the inverse document frequency vector from the domain to the classifier agent and not from the representer to the classifier? Because the representer doesn’t care about an existing classification or representation. Any representation made by the representer agent is the same. The documents are sent to the classifier agent to reduce the communicative efforts of the domain agent.

94

CHAPTER 3. MULTIAGENT D-SIFTER a document set from the representer agent. The domain agents informs the classifier agent about a wanted classification and sends the centroids as well as the inverse document frequency vector to the classifier agent. The result from the classifier agent is the assignment of the documents to the centroids. This is send to the domain agent.

DAM agent interaction The DAM agent as an interface to external information sources is not acting to pro-actively within the system. Therefore, we can identify only one communication protocol, exclusively initiated by the DAM agent.: • DAM - Representer: Not Represented Document Set The first part of this conversation is a broadcast to all available representer agents which should return their actual workload. The second part is a conversation between only two agents. This part of the conversation between DAM and representer agent is just a confirmed information from the DAM agent. The DAM agent transfers the documents, or the document handle (for URL-documents) and the name of the requesting domain agent to the representer agents. Representer agent interaction The representer agent is responsible for the classification and representation of new documents. If a document is not classified during represention it is using classifier agents pro-actively. The following conversation is establishing this connection to classifier agents: • Representer - Classifier: Not Classified Documents In this conversation the representer agents broadcasts for classifier agents and passes the represented document vectors to one selected classifier agent. Therefore it passes the domain agent’s name to the agent which is in charge of these documents. It is as the last conversation a combination of a broadcast and a point-to-point communication.

3.3.4

Agent control

The controller can be the distributed bottleneck of the whole agent system. It is very important that the controller has not a complex structure and

3.3. DESIGN

95

it have to incorporate efficient processing algorithms. On the other hand, the controller determines the capabilities of the overall system. So if the structure is chosen too simple there are strong restrictions to the flexibility and the quality of the system’s behavior and results. We have chosen an object-centered knowledge representation with manually integrated processing algorithms. This is not the most flexible approach, but should satisfy the performance criteria as well as being flexible enough for future extensions. The main coordination algorithms are based on market mechanisms. These mechanisms does not need high processing power or complex representations, however.

Figure 3.23: Overview: control in Multiagent D-Sifter The design of the controller is divided in four major parts:

96

CHAPTER 3. MULTIAGENT D-SIFTER • Functional description of knowledge-processing algorithm This description should help to identify necessary data types and methods on these data types for the overall control behavior of agents. The description should include semi-formal definitions of the functions. • Design of abstract data types The knowledge base is in need of special data types for the object-centered representation. The data types are introduced here, methods on these data types are defined semi-formally. • Design of knowledgeBase class On the basis of the abstract data types of the previous section the knowledge base is introduced here. One important part can be found in the definitions of the methods. • Design of controller class The controller class realizes the processing algorithm and is based on the knowledge base mainly. Nevertheless there are some important issues missing in the previous sections that make this semi formal description necessary.

The main aspects of each agent types control behavior is pictured in Fig. 3.23. Each agent type contains three text boxes. The first box lists distinctive knowledge pieces. Primary responsibilities are printed in the second text box. The interactions to other agents are content of the third text box. Functional description knowledge-processing algorithm As mentioned in the last section the algorithm consists of five steps. These steps are representing the most important tasks. Each of the step is a highly complicated method. processMessages ProcessMessages uses the Inbox, which is storing all incoming messages until they are processed, and the KnowledgeBase. The algorithm is used for all messages in the Inbox. The messages are processed in sequential order; for each new message the following procedure is executed: 1. Is the receiver of the message my class or me? • If no, ignore message and go to next message.

3.3. DESIGN

97

• If yes, go on with processing ... 2. Does this conversation exists in my knowledge-base? • If no: Generate new conversation Update state of conversation according to this message • If yes: Update state of conversation according to this message 3. Analyze Content: Follows immediate action? • If no, update knowledge. • If yes: generateOptions evaluateOptions executeAction 4. Do I know the sender? • If no: send info request • If yes: proceed. 5. Delete message, proceed with next message updateGoalList The goals, consisting of name and preference functions, are updated each reasoning steps. It takes into account that the preference in a specific goal is strongly associated with the recent state of an agent. The result are new preference values for each goal. Later implementations - for better performances - should use non-monotonic reasoning for maintaining the goal’s preferences. But this would outburst the prototype design. updateOptionList Each ongoing conversation has a state. Possible transitions to the next states are indicating possible actions. Each goal can be achieved by following actions defined in the set of actions. Possible actions are: send message, new conversation, compute (work with the computational part of the agent/ use the executor module). The option list is the list of all possible actions considering the state of the agent.

98

CHAPTER 3. MULTIAGENT D-SIFTER

evaluateOptions For choosing an appropriate action its mutual to evaluate them. In a first approach the actions can be assessed which leads to a number for each action. The number indicates the preference of the agent in this action. The action with the highest number is the most desired one. executeAction The action with the best evaluation will be executed. Execution consists of different steps: a) the action must be configured, b) the execution is run (message send, method called), c) the success of the action is traced (message was received, method calling lead to no errors, i.e. return value indicates ok). Depending on the success of the chosen action the knowledge of the agent is updated. One iteration of the reasoning process is done. Design of abstract data types Most of the abstract data types are mentioned in the last section introducing the needed knowledge elements for the knowledge base. The main elements are AgentClass, AgentInfo, ComTree, and ComNode. They are listed with the essential attributes and methods. AgentClass • Attribute: String Name Name/Identifier of Agentclass, e.g. Domain, Representer. • Attribute: int Importance Modifier for the relevance claculation. • Vector Agents Vector of agents, meaning: knowledge about other agents is stored in the specific agentClass object. E.g. all domain agents are stored in the AgentClass domain. • Method: relevance():real The relevance is calculated following this equation: P Relevance = #agents (f racagenti #agents) ∗ Importance i=0

3.3. DESIGN

99

AgentInfo • Attribute: String Class The name of the class the agent belongs to. • Attribute: String Name The name of the agent. • Attribute: String Description The natural language description which can be shown to human user or system supervisor. It can also be used in protocols. • Attribute: String Address The address of the agent in - considering the RMI prototype - RMI convention. • Attribute: int Credits The amount of credits, the agent gained. • Attribute: int NegCredits The amount of credits, the agent haven’t earned due to negative results. • Attribute: boolean Used This flag shows prior cooperation with the agent. • Attribute: int Efficiency This variable - prior called modifier - is an experience factor which can be set by human supervisor or by the agent. It can be changed during runtime to reflect negative or positive experience. The default value is inherited from the agent class. • Method: relevance(): real – if not used then Relevance = 1 – if used then Relevance is defined as   Credits − N egCredits ∗ Ef f iciency ∗ Sign(Credits − N egCredits) if relevance = 0 then replace relevance with 1 (as 1 is neutral element for multiplication purposes).

100

CHAPTER 3. MULTIAGENT D-SIFTER

ComTree • Attribute: int ID The ID of a conversation state is within the conversation unique. A unique ID of the state throughout the system is gained by the combination of conversation name and ID. • Attribute: String Name Name of the communication protocol (conversation) • Attribute: Vector Sons (type: ComNode) List/Set of sub-nodes. The ComTree element is the root of a tree, the rest is realized in a recursive way; each node can have sub-nodes (sons). The direct sub-nodes are representing the states which are reachable from the current node. • Attribute: boolean Leaf This flag is set, if the node is an end state, i.e. the conversation is finished with this state. There are no son-nodes available then. This would be an empty conversation. • Method: getOptions The getOptions method works on base of the son nodes and receives the possible actions. • Method: evaluateOptions This method calls the evaluateOption method and returns the method which application is most likely in this setting. ComNode • Attribute: int ID The ID of a conversation state is within the conversation unique. A unique ID of the state throughout the system is gained by the combination of conversation name and ID. • Attribute: String Name Name of the node, equal to the name of the performative for reaching this node. • Attribute: Action transition This action shows indicates the action which has to be taken to reach this state.

3.3. DESIGN

101

• Attribute: Vector Sons List/Set of sub-nodes. The ComTree element is the root of a tree, the rest is realized in a recursive way; each node can have sub-nodes (sons). The direct sub-nodes are representing the states which are reachable from the current node. • Attribute: boolean Leaf This flag is set, if the node is an end state, i.e. the conversation is finished with this state. There are no son-nodes available then. Design of knowledgeBase class The KnowledgeBase class is the main class of the controller. The knowledge base represents the agent’s view on the other agent, itself, and the environment. The explicit existence of a knowledge base is one of the main difference to the common object-oriented programming approach. The knowledge base is filled with information the agent receives at initialization and this knowledge is updated by the agent itself. As we use object-centered knowledge description and a basic approach the agent is not capable of extending data types in the knowledge-base nor gain knowledge on its own. The agents are restricted to updating their knowledge base. Control behavior of an agent is only adapted and not newly induced. As introduced in the last section, there are two types of knowledge to be represented: static and dynamic. The knowledge representation is using abstract data types, which can be generated from the following description: Dynamic knowledge • MySelf (Tuple): (Name, Class, Description, Address, Credits) • AgentClasses (List): (Name, Importance) • Protocols (List of Simplified Trees) • Actions (List): (Name, Preference) • Goals (List): (Name, Preference) • Preconditions (List): (Name)

102

CHAPTER 3. MULTIAGENT D-SIFTER

• Solution (List): (Precondition, Action, Goal, Preference) Static knowledge • Agents (List): (Name, Class, Description, Address, Used, Efficiency, Earned, Spent) • State (List): (Preconditions, Relevance) • Solving (List): (Solution, Belief) • ActiveConv (List): (Protocols, Relevance) • (Utility (method): Evaluation method for determining the priority) Design of controller class The controller class is resulting from the abstract data types introduced in the two subsections above. The contents of the data base are proposing all needed attributes. The agent control is incorporated by methods for the evaluation of knowledge (messages) and a main method running the inference within a loop. The inference steps are as follows; the methods have to be defined according to these descriptions: 1. processMessages The processMessages method will check the inbox if any new messages have arrived. The messages will be processed in first-in first-out order. Some messages will need an immediate response unlike most messages which simply change the agent’s state and update its knowledge. This method is a elementary method which is part of the controller object. 2. updateGoalList After the messages are evaluated and the knowledge has been updated the agent looks for any goals which can be fulfilled on basis of his recent state. These goals are stored in a list. This method is based on the knowledge and in consequence situated in the knowledge object. 3. updateOptionList The list of goals leads to a list of possible actions, automatically. This list is called OptionList as not any possible action can be executed.

3.3. DESIGN

103

4. evaluateOptionList This is one of the main tasks within the agent control. The options or possible actions must be evaluated to find the most important task which can be executed afterwards. In the first implementation this includes a aggregation of the action and goal relevance. 5. executeAction The action with the highest priority is called in this method. The successful/unsuccessful execution updates the knowledge of the agent. Here ends one processing circle.

3.3.5

Market-based decision model

The previous section about agent control introduced the necessary knowledge representation and inference methods for agent control. This section deals with the coordination between agents. The basis of the coordination behavior is an approach motivated by market mechanisms. Thus, the single agent has the goal to maximize its yield. The realization of such a goal is pretty easy as utility functions known from game theory can be used. The implementation of these functions are probably efficient. Different possible actions weighed using utility functions can be ordered and the action with the best benefit will be selected. The following paragraphs will propose strategies of the different agent types. Figure 3.24 is symbolizing the monetary flow within the agent system, showing the strong influence of the user agents as well as the domain agents. The agent world is representing not only a directory facilitator but also a scheduling unit. This unit is providing processor time to the other agents within one physical environment. User agent strategy The user agent is mainly responsible for coordinating information retrieval and for propagating user relevances to the system. Furthermore, it is presenting new documents to the user. Considering the cash flow in the multiagent system the user agent is the most important entity. The goal of the user agent is to optimize the user feedback. The user feedback is transferred internally to credits. These credits are given to the domain agent, which

104

CHAPTER 3. MULTIAGENT D-SIFTER

Figure 3.24: Cash flow within Multiagent D-Sifter provided the document to the user agent. For an information retrieval user agents instructs one or more domain agents by providing them credits. Domain agent strategy In the cash flow the domain agent is the most important entity. Domain agents have the objective to maximize the payoff. Domain agents are paying classifier agents for classification services, DAM agents for documents and classifier agents for classification services. For information filtering a domain agent has to pay DAM agents to filter new documents represent and classify them. Afterwards it can offer the user agent to buy the document for the user. The domain agents will prefer DAM agents which were useful in before. This behavior leads to an adaptation of the overall system to the user’s needs and -hopefully- to an optimization of the efficiency. The other direction of information gathering is the information retrieval. In this case the user agent pays the domain agent even as long as no documents were retrieved. In idle state the domain agent can use some of its credits to instruct DAM agents for specific retrieval tasks. These tasks are based on expected relevant keywords to ’regular’ user agents. To keep the overall performance of the system high it is necessary to keep control of individual CPU usage. Therefore,

3.3. DESIGN

105

agents like domain agent have to pay for CPU usage. DAM agent strategy The DAM agent has the goal to sell as many documents as possible and to retrieve documents continuously. The DAM agent has to pay for CPU usage during retrieval jobs. The construction of the agent world should take into account that if no processes are running on a system the CPU usage is cheap and if it is pretty busy the usage is very expensive. Thus, DAM agents are using the computer as long as it is not used by other applications for intensive retrieval. The DAM agent can receive credits directly from the user agent. As it is storing the documents it received, the user agent has to pay credits for the visualization of a document of the DAM document space. Representer agent strategy The representer agent is a passive agent just receiving credits from the domain agent for representation of documents. It has to pay credits to the agent world for the CPU usage it will cause. Classifier agent strategy Analogous to the representer agent, the classifier agent is also receiving credits for a service provided. The classifier agent is receiving its cash from the domain agent.

Chapter 4 Resume This report is presenting two concepts for multiagent information filtering and retrieval on the basis of the Sifter concept. The first approach is focused on runtime flexibility of the system. Complete domains and inter domain relationships are in question and can be adapted. It has been developed using the AWIC methodology for agent engineering. The AWIC methodology proved to be helpful during the early steps of conceptualization, but it is difficult to generate a concrete model respectively a concrete agent architecture. The second approach is elaborated in more detail. A new agent architecture has been developed which will be extended within my PhD thesis. This agent architecture combines the approaches of the MEKKA interacting agent architecture and the control behavior focused model BDI. The realization of this architecture using market mechanisms is likely to meet the goal of efficacy. In the framework of Sifter-based information retrieval and filtering it also seems to be sufficient with respect to expressive power and inference. This second approach allows to re-use wide parts of the Sifter implementation with only small modifications. As my stay ended before the system could be implemented experience with the practical realization is missing. Refinements due to practical application problems could not be integrated for the same reason. Nevertheless, the latter approach is worth to be implemented. The expected benefits of the multiagent D-Sifter can be found in the high 106

107 flexibility and easy extensibility. The market-based protocols are enabling the multiagent system to adapt on user requirements. The system is optimizing itself during runtime. The management and achievement of new documents is implemented by a credit point system. But this approach is based on the assumption that an information source, providing relevant documents once, is more likely to provide relevant documents later on too. The encoding of domains within agents enables the user to add new domains to the D-Sifter system during runtime without resetting the system. The flexibility of the system ensures even greater changing such that new applications may be adapted dynamically, e.g. the system may be extended to manage its work balancing on computers.

Bibliography [Agha and Hewitt, 1987] Agha, G. and Hewitt, C. (1987). Concurrent Programming Using Actors, Object-Oriented Concurrent Programming. The MIT Press. [Balabanovic, 1997] Balabanovic, M. (1997). An adaptive web page recommendation service. In Proceedings of the First International Conference on Autonomous Agents (AA ’97), CA. Marina del Rey. [Bradshaw, 1997] Bradshaw, J. M., editor (1997). Software Agents. AAAI Press / The MIT Press, Menlo Park, California, USA. [Bratman, 1987] Bratman, M. E. (1987). Intentions, Plans and Practical Reason. Harvard University Press, Cambridge, Massachusetts. [Carron et al., 1999] Carron, T., Proton, H., and Boissier, O. (1999). A temporal agent communication language for dynamic multi-agent systems. In [Garijo and Boman, 1999], pages 115–127. [Clack et al., 1997] Clack, C., Farringdon, J., Lidwell, P., and Yu, T. (1997). Autonomous document classification for business. In Proceedings of the First International Conference on Autonomous Agents (AA ’97), CA. Marina del Rey. [Cohen, 1997] Cohen, P. R. (1997). Communicative actions for artificial agents. In [Bradshaw, 1997], pages 419–436. [Conen and Neumann, 1998] Conen, W. and Neumann, G. (1998). Coordination Technology for Collaborative Applications. Number 1364 in Lecture Notes in Artificial Intelligence. Springer, Berling. 108

BIBLIOGRAPHY

109

[Ferber, 1999] Ferber, J. (1999). Multi-agent systems - an introduction to distributed artificial intelligence. Addison-Wesley, Harlow, UK. Ecologic Systems - Agentensysteme - interessante Einf¨ uhrung. [Finin et al., 1995] Finin, T., J-Weber, Wiederhold, G., Genesereth, M., Fritzson, R., MacKay, D., McGuire, J., Pelavin, R., Shapiro, S., and Beck, C. (1995). Specification of the KQML Agent-Communication Language. Technical report, The DARPA Knowledge Sharing Initiative External Interfaces Working Group. [Finin et al., 1997] Finin, T., Labrou, Y., and Mayfield, J. (1997). Kqml as an agent communication language. In [Bradshaw, 1997], pages 291–316. [FIPA, 1997] FIPA (1997). Fipa agent communication language. Foundtion for Intelligent Physical Agents: http://www.fipa.org. FIPA Spec 2 - 1997. [FIPA, 1998] FIPA (1998). Fipa 97 developer’s guide. Foundtion for Intelligent Physical Agents: http://www.fipa.org. FIPA Spec 13 - 1998. [FIPA, 1999a] FIPA (1999a). Fipa agent communication language. Foundtion for Intelligent Physical Agents: http://www.fipa.org. FIPA Spec 2 1999. [FIPA, 1999b] FIPA (1999b). Fipa agent message transport. Foundtion for Intelligent Physical Agents: http://www.fipa.org. FIPA Spec 16 - 1999. [FIPA, 1999c] FIPA (1999c). Fipa developer’s guide. Foundtion for Intelligent Physical Agents: http://www.fipa.org. FIPA Spec 13 - 1999. [Foner, 1993] Foner, L. N. (1993). What’s an agent, anyway? - a sociological case study. MIT Media Lab. [Gall, 1975] Gall, J. (1975). Systemantics: How Systems Work and Especially How They Fail. Quadrangle. [Garijo and Boman, 1999] Garijo, F. J. and Boman, M., editors (1999). Multi-Agent System Engineering - 9th European Workshop on Modelling Autonomous Agents in a Multi-Agent Worlds, MAAMAW’99 in Valencia, Spain, volume 1647 of Lecture Notes in Artificial Intelligence. Springer.

110

BIBLIOGRAPHY

[Genesereth and Fikes, 1992] Genesereth, M. R. and Fikes, R. E. (1992). Knowledge Interchange Format Version 3.0 - Reference Manual. Technical Report 94305, CS Department, Stanford University, Stanford, California. [Holler and Illing, 1990] Holler, M. J. and Illing, G. (1990). Einfuehrung in die Spieltheorie. Springer, Berlin. [Jennings and Wooldridge, 1998] Jennings, N. R. and Wooldridge, M. J. (1998). Agent Technology. Foundations, Applications, and Markets . Springer, Berlin. [Jones, 1999] Jones, K. S. (1999). Information retrieval and artificial intelligence. Artificial Intelligence, 114:257–281. [Knirsch and Timm, 1999] Knirsch, P. and Timm, I. J. (1999). Adaptive multiagent systems applied on temporal logsitics networks. pages 213– 218, Padova Italy. ISL-99, Florence, Italy, SGE Ditoriali. [Knoblock and Ambite, 1997] Knoblock, C. A. and Ambite, J.-L. (1997). Agents for information gathering. In [Bradshaw, 1997], pages 347–374. [Lux, 1995] Lux, A. (1995). Kooperationen Mensch-Maschine Arbeit Ein Modellierungsansatz und dessen Umsetzung im Rahmen des Systems MEKKA. PhD thesis, Technische Fakultaet der Universitaet des Saarlandes, Saarbruecken. [Maes, 1997] Maes, P. (1997). Agents that reduce work and information overload. In [Bradshaw, 1997], pages 145–164. [Malone et al., 1997] Malone, T. W., Grant, K. R., and Lai, K.-Y. (1997). Agents for information sharing and coordination: A history and some reflections. In [Bradshaw, 1997], pages 109–144. [Minsky, 1985] Minsky, M. (1985). The Society of Mind. Simon & Schuster, New York. [Mostafa et al., 1997] Mostafa, J., Mukhopadhyay, S., Lam, W., and Palakal, M. (1997). A multilevel approach to intelligent information filtering: Model, system, and evaluation. ACM Transaction on Information Systems, 15(4):368–399.

BIBLIOGRAPHY

111

[Moukas, 1996] Moukas, A. G. (1996). Amalthaea: Information discovery and filtering using a multiagent evolving ecosystem. In Proceedings of the Conference on Practical Application of Intelligent Agents and Multi-Agent Technology, London. [Mueller, 1997] Mueller, H.-J. (1997). Towards agent systems engineering. Data & Knowledge Engineering, 23(3):217–245. [Mueller, 1998] Mueller, H.-J. (1998). Thinking in agents. Invited Talk at the 22nd Annual German Conference on Artificial Intelligence KI-98: Advances in Artificial Intelligence. [Mueller, 1996] Mueller, J. P. (1996). The design of intelligent agents: a layered approach, volume 1177 of Lecture notes in artificial intelligence. Springer, Berlin, second printing edition. Guter Ueberblick verschiedener Agentenarchitekturen, INTERRAP Ansatz. [Newell, 1962] Newell, A. (1962). Some problems of the basic organization in problem-solving programs. In Proceedings of the second conference on Self Organizing systems. Spartan Books. [Parunak, 1999] Parunak, H. V. D. (1999). Industrial and practical applications of dai. In [Weiss, 1999], pages 377–424. [Pitt and Mamdani, 1999] Pitt, J. and Mamdani, A. (1999). Designing agent communication languages for multi-agent systems. In [Garijo and Boman, 1999], pages 102–114. [Russell and Norvig, 1994] Russell, S. J. and Norvig, P. (1994). Artificial Intelligence: A Modern Approach. Prentice Hall. [Salton, 1989] Salton, G. (1989). Automatic Text Processing: The Transformation, Analsysis, and Retrieval of Information by Computer. AddisonWesley, Reading, MA, USA. [Smith, 1988] Smith, R. G. (1988). The contract net protocol: High-level communication and control in a distributed problem solver. In Bond, A. H. and Gasser, L., editors, Readings in Distributed Artificial Intelligence. Morgan Kaufmann, San Mateo.

112

BIBLIOGRAPHY

[Swaminathan et al., 1993] Swaminathan, J., Sadeh, N., and Smith, S. (1993). A knowledge-based multi-agent simulation testbed to support supply chain design and management decisions. In Proceedings IJCAI93 Workshop on Knowledge-Based Production Planning, Scheduling and Control. [Tecuci, 1998] Tecuci, G. (1998). Building Intelligent Agents - An Apprenticeship Multistrategy Learning Thory, Methodology, Tool and Case Studies. Academic Press, San Diego, California, USA. [Weiss, 1999] Weiss, G., editor (1999). Multiagent Systems - A Modern Approach to Distributed Artificial Intelligence. The MIT Press, Cambridge, Massachusetts. [Wooldridge, 1999] Wooldridge, M. (1999). [Weiss, 1999], pages 27–78.

Intelligent agents.

In

[Wooldridge and Jennings, 1995] Wooldridge, M. and Jennings, N. R. (1995). Intelligent agents: Theory and practice. The Knowledge Engineering Review, 10(2):115–152.