ontological basis for open distributed multi-agent system - CiteSeerX

ONTOLOGICAL BASIS FOR OPEN DISTRIBUTED MULTI-AGENT SYSTEM V.A. Abramov*, N.B. Szirbik*, J.B.M. Goossenaerts*; T. Marwala†, P. De Wilde†; L. Correia‡, P. Mariano‡, R. Ribeiro‡ * Information & Technology Department, Faculty of Technology Management, Eindhoven University of Technology; Eindhoven, The Netherlands; † Electrical and Electronic Engineering Department, Imperial College; London, England; ‡ Department of Informatics, Faculty of Science and Technology, Universidade Nova de Lisboa; Lisbon, Portugal; [email protected], [email protected], [email protected]; [email protected], [email protected]; [email protected], [email protected], [email protected] Abstract Some methodological aspects of developing multi-agent systems are considered in this work. In particular, influence of analysis and design methodologies on the interoperability properties of multi-agent systems is investigated from the perspective of ontology-based meaning transfer. A combined approach to developing better multi-agent systems is proposed and importance of interdisciplinary integration of research efforts for creation of interoperable systems is emphasized.

1 Introduction In this paper, we want to discuss some methodological aspects of developing multi-agent systems (MAS). Generally, these systems are the software infrastructures inhabited by a number of purposeful autonomous software entities. These entities are usually called agents since their act on behalf and solve relatively high-level tasks of their (mostly human) principals.1 MAS as the majority of other software systems are developed for practical purposes and they are considered an effective solution for the problems that involve: distribution of data, control, expertise or resources; a society of autonomous cooperating components as a natural component of the infrastructure; and/or a set of legacy software systems that need to interact with each other at a high level (Jennings and Wooldridge, 1998). As a rule, MAS are rather complex distributed software systems that may reveal some degree of cooperative intelligence. This set of features makes such systems extremely difficult from the standpoint of development. Therefore, attention should be given to the methods and tools as well as methodologies that are used within development of such systems. 1

We will use the terms agent, MAS and agent-based system in the above intuitive sense leaving the reader free to discover their numerous semantic nuances in (Franklin and Graesser, 1997; Jennings et al., 1998).

Whenever a need for MAS is detected, an approach to agent-based system development has to be chosen. Many existing approaches to information system development have already been tried out for the tasks of agent-oriented system’s design and implementation. However, up to the moment none of these approaches has become standard or even prevalent. Consequently, each MAS research or development project relies on an ad hoc chosen set of techniques, methods, languages, tools, etc. While this way of developing MAS (sometimes) works for small and self-contained applications, it creates many problems whenever such applications attempt to interoperate with each other. The interoperability problem is especially important for systems that have to co-operate within globally distributed open information architectures such as emerging e-commerce infrastructures (for example, see the projects like ebXML, BMEcat, Rosetta2, etc.). Not attempting to offer the ultimate solution in this work, we determine the location of the problem (section 2), explore its roots and offer some ideas that could facilitate the creation of better approaches to MAS development (section 3). Then we discuss the other existing solutions, compare the situation in agent research to similar problems in related fields, and draw some conclusions (section 4). 2

These projects can be reached at www.ebxml.org, www.bmecat.org and www.rosetta.nl correspondingly.

2 MAS life cycle and agent-oriented methodologies We intend to discuss the role of methodologies in agent system development; therefore it is important to start from the general description of the development process. In this way, the exact location of discussed problems should become clear.

2.1 MAS lifecycle To investigate the problem mentioned in the introduction – interoperability of agent-based systems – we have to consider the life cycle of MAS. As MAS is a kind of software system, initial part of its life cycle generally consist of the following stages: • • • •

Analysis (resulting in a set of models); Design (resulting in design specifications) Implementation (resulting in a system) Testing

These stages are iterative in a sense that MAS developers often return from the later stages to the preceding ones and even to initial one in order to correct mistakes in analysis, design, and/or implementation. The whole development is a difficult and expensive process. Therefore, it should be done in such a way as to minimize the need to return from the further stages of system life cycle: • • •

Operation Maintenance Utilization

These stages are sequential; only the maintenance stage can alternate with the operation stage. In normal situation, there is no return to expensive stages of system development. Nevertheless, the problem of establishing interoperation links between several MAS made by different developers often turns out to be a problem requiring return to redesign. In fact, different developers cannot produce readily interoperable systems or systems that can be easily made interoperable without redesign (Singh, 1998). We believe that methodologies of analysis and design used at the initial stages of development make contribution to this problem.

2.2 Methodologies of analysis and design In the field of agent systems, researchers have developed several methodologies to support the development of MAS at the analysis and design stages. The majority of these methodologies are coming from three distinct areas: object-oriented software development, knowledge engineering and knowledge-based systems development, and formal software specifications (Iglesias et al., 1998). The traditional methodologies from

these areas have been augmented and transformed into new methodologies that use agent as a key abstraction. Examples of such agent-oriented methodologies are the Agent-Oriented Analysis and Design methodology (Burmeister, 1996), the MAS-CommonKADS methodology (Iglesias et al., 1997), the formal framework of agent specification based on Z (d’Inverno et al., 1997), etc. Let us consider the function of methodologies within the process of system development and their role in resulting design of agent system. An analysis and design methodology can be considered as a sum of two functional parts: 1) A set of abstract concepts (meta-concepts): these are offered to a developer in a form of meta-terms as a basis for decomposition a conceptualization about agent system; 2) A set of rules, recommendations, and examples: these are to detail the properties of the above meta-terms, to clarify the underlying meta-concepts and to provide a developer with informal guidelines that lead the decomposition process. For example, the MAS-CommonKADS methodology suggests to analyze and describe an agent system in such (meta-) terms as: • • •

• • •

Agent model – to detail the characteristics of agents (reasoning capabilities, skills, services, etc.); Task model – to specify the tasks assigned to agents; Expertise model – to explain what kinds of knowledge are used by agents during solving the tasks (e.g., domain, task, inference, problem solving knowledge); Coordination model – to specify interactions among agents, conversations and protocols used; Organization model – to describe the organizational environment where MAS will operate as well as organization of agent society itself; Communication model – to specify interactions between agents and people.

Here the agent, task, expertise, coordination, organization and communication models (along with their internal structure) constitute the first part of the methodology. Its function is to serve as a meta-language used by a developer to describe an agent system. More specifically, this meta-language is used to provide a structure to the detailed description of the agent system. The meta-terms establish a representation framework for the detailed system description. Components of the detailed description can be considered as particular instantiations of the methodology’s meta-concepts. The methodology also provides a developer with guidelines regarding mapping a conceptualization onto the basis of meta-concepts of the methodology. For

example, the MAS-CommonKADS methodology offers several techniques to identify the elements of agent model. These techniques are based on syntactic analysis of the problem statement, analysis of actors of the conceptualization, application of heuristics, etc. Such techniques are informal and intended for use by human developers. The process of mapping conceptualization onto the basis of meta-concepts is subjective and often looks more like a creative work rather than a technological process. Whole process of representing conceptualization in the framework of a particular methodology is difficult to comprehend and repeat. Therefore, it is impossible to guarantee that two MAS will be able (or can be easily made) to work together even if the same methodology was used. Different methodologies have diverse sets of meta-terms and guidelines that complicates the situation even more. For example, Burmeister (1996) suggests a methodology with the following decomposition: • • •

Agent model – to describe agents including their plans, goals, beliefs, etc.; Organizational model – to describe roles of agents and static relationships among them; Cooperation model – to describe cooperation among agents.

How to relate these models to the above models of the MAS-CommonKADS methodology? Is it possible to establish one-to-one links between them? Is it possible to make that automatically? – Such questions are common when the interoperation between different agent systems is considered. The questions are especially difficult to answer if such methodologies as the above examples are used. There are other methodologies that can be applied for agent system development. These rely on formal approaches to system description that gives hope for successful interoperation. However, such approaches have other problems. For example, the formal framework of agent specification based on Z does not provide rich structuring facilities for the system description as the methodologies considered earlier. The only thing available is a representation language that is expressive enough to describe whatever structure is considered appropriate. Now we will consider the role of a methodology in the process of interoperation among several MAS. Primary means of communication within a MAS is exchange of messages among agents. Agent communication languages (such as KQML (Finin et al., 1997), ARCOL (Breiter and Sadek, 1996), FIPA (FIPA, 1999), etc.) are used to formulate these messages. Ideally, an ACL should provide a way for heterogeneous agents and agent systems to communicate without knowledge of the internal structure of each other. In reality however, that is not the case. No agent communication language so far is completely independent of the internal structure of agent and agent system (Singh, 1998). If

the same developer creates the whole system then agents have no problem with interpretation of messages circulating in the system. However, the situation is completely different if parts of the MAS are created by different developers or the agents of one MAS have to interpret messages from agents of another MAS. Contrary to intentions of ACL designers, an agent (or an agent system) has to know the construction of another agent (system) in order to interpret its messages in correct way. Therefore, description of an agent as a part of MAS as well as description of an agent system become important for successful interoperation. Agent-oriented analysis and design methodologies play role of a framework for these descriptions. They determine structure of the descriptions, basic meta-level concepts and relations among them used to represent a developer’s conceptualization behind an agent system. If a description of an agent system is available then it can be used as a foundation for interpretation of messages. In the field of knowledge representation, the descriptions of (a part of) a system that are shared by many parties to enable knowledge exchange have become known as ontologies. In case of interoperating MAS, a system description (or a part of it) plays role of ontology. Therefore, it is useful to consider the process of MAS development from the perspective of ontology development and then to consider the process of establishing interoperability between agent systems from the perspective of using an ontology for knowledge exchange). Before doing that, we need to draw in some concepts from the field of knowledge representation.

2.3 Conceptualizations and ontologies First, we have to explain such terms as conceptualization and ontology, and to detail their meaning in our case. These terms are widely used in many research works and two interpretations have been generally recognized. The former is the definition of Gruber (1995): “Conceptualization: the objects, concepts, and other entities that are assumed to exist in some area of interest and the relationships that hold among them. An ontology is an explicit specification of a conceptualization.” Also, it is said in this context: “an agent commits to an ontology if its observable actions are consistent with the definitions in the ontology.” Another, more precise definition is given in (Guarino and Giaretta, 1995): “An ontology is an explicit, partial account of a conceptualization.” This definition underlines the incomplete character of ontologies – they do not provide exhaustive descriptions of conceptualizations. Also, a mathematic definition of ontology is given by Guarino (1998a). We will not go here into mathematical details about use of this definition (interested reader can find some ideas in Abramov, 1998). What is

important here is that we consider a representation of a developer’s conceptualization about a MAS as ontology. It is obvious that the properties of such ontology highly depend on a representation means used. In general, to represent ontologies one can use (with different degree of success) knowledge representation languages, programming languages, diagram languages, logical formalisms, etc. In particular, agent-oriented methodologies suggest using such means as the OMT (Kinny et al., 1996), UML notations, CRC cards (Burmeister, 1996), IDEF diagrams (Kendall, 1996), in-house notations, etc. As mentioned earlier, a methodology has two constituents: a set of meta-terms (abstract concepts) and a set of guidelines that specify their meaning and lead the representation process. The former part provides a developer with the syntax, while the latter – with the semantics of the methodology’s meta-language. The syntax can easily be put in use and become a part of particular ontology representation. For example, meta-term agent model can be instantiated and linked to such terms as agent class A, agent class B, etc. However, the semantics of such representations are not always well defined since the meanings of the abstract concepts usually are not formally specified within the methodology. The only thing that helps to understand their meaning is the informal guidelines. That makes use of a methodology easy but at the same time not precise. The main cause leading to such a situation is that methodologies are oriented not on specialists (researchers) in ontology representation (or generally, in knowledge representation) but on ordinary developers of agent systems. We detail this and some other properties of methodologies in the following section.

3 Agent-oriented methodologies and MAS interoperability In this section, we investigate the influence of agent-oriented methodologies on interoperability properties of MAS. There are several stages in the life cycle that contribute to interoperability of agent systems. These are the initial stages of the life cycles where results of problem analysis and conceptual design are represented and embodied into a system implementation. Also, it is the integration stage (which can belong to the operation or maintenance stages) where integration procedures are carried out over existing systems in order to ensure the semantic compatibility of their mutual communications. In the following subsections, we will consider role of methodologies at these stages.

3.1 Some general characteristics of methodologies Let us consider the process of representing some conceptualization using a methodology that includes the set T of meta-terms and the set G of informal guidelines explaining the meaning of the meta-terms. Generally,

the set meta-terms can be used to represent the set O(T) of various ontologies, i.e., agent system designs (see the figure 1; the square is a set of all possible ontologies).

O(T+G)

O(T)

O(T+mO) C

Figure 1: Typical relations between classes of ontologies and conceptualizations However, a developer of a system usually has in mind some substantially smaller set C of conceptualizations (class of conceptual designs) corresponding to this system or a class of such systems. Using the meta-terms of the methodology along with the informal guidelines allows narrowing the above set O(T) of ontologies toward the set of conceptualizations. The set O(T+G) corresponds to the ontologies resulting from a typical use of the methodology by a developer. In general, there is no guarantee that O(T) or O(T+G) covers C; a developer has to check that himself. Also, there is no way to check if a particular representation belongs to the O(T+G), i.e., if the representation has been made in the framework of this methodology (note the fuzzy borders of the O(T+G) set in the figure). On the other hand, there is a possibility to use another kind of representation means that consist of the set T of meta-terms along with the set mO (meta-ontological) of formal descriptions of these meta-terms’ meaning. That corresponds to a methodology with formally specified abstract concepts. Examples of such kind of formal specifications are the Frame Ontology (Gruber, 1993), the ontology of meta-level primitives (Guarino et al., 1994; Guarino and Welty, 2000). In this case, the resulting set of ontologies (O(T+mO) in the above figure) can be made closer to the intended set of conceptualizations (i.e, agent system designs can be specified more precisely). Along with the more precise representation, this approach provides a way to check if a particular ontology is a member of O(T+mO) set (e.g., if an agent of a MAS is veracious by design or not). However, such an approach is available only for specialists familiar with formal specification, mathematical logic and other advanced methods. More specifically, such approaches are developed and used mostly within the research community where it is realistic to expect such qualifications.

c. C

(I)

c. C

(II)

(II)

(I) O(T) o. O(T+G)

o. O(T+mO)

Figure 2: Representing a conceptualization using a traditional agent-oriented methodology

3.2 Representing conceptualizations Let consider detailed processes of constructing ontologies using two approaches outlined above. We will take one situation where an ontology (representation of a developer’s conceptualization about a MAS) is built by a general developer using a methodology with informal meta-concepts (we will call it traditional), and second situation where an ontology is created by a researcher using a methodology with formal specifications of meta-concepts. Whenever a developer has a conceptual image of a required agent system and intends to represent this conceptualization in some material way, he selects an appropriate methodology.3 The developer has in mind some specific conceptualization c (see figure 2; there and later on, an upper box contains conceptualizations, lower one contains ontologies; dashed arrows denote manual operations, solid arrows denote automated ones). Let us assume that he is choosing a methodology to use and is checking the candidate methodology M, which consists of the set T of meta-terms and the set G of guidelines. To avoid expensive re-representations (if the methodology will turn out to be inappropriate), he makes an estimation of the methodology. That can be done mentally by creating a projection C of the set of ontologies O(T+G) expressed in terms of the methodology’s meta-concepts onto space of a developer’s conceptualizations (see stage I in figure 2) and comparing this projection with c. If class of conceptualizations that can be expressed within the selected methodology (as this developer sees it) includes c then the positive conclusion may be made regarding use of the methodology. Making such a decision, the developer subjectively (because it is impossible to check formally) asserts that elements of C including c have the properties (informally) described by the methodology. The only thing that can, in principle, be verified is that the stage II (see figure 2) of the representation process will 3

It is implicit in the worst case.

Figure 3: Representing a conceptualization using an agent-oriented methodology with formal meta-concepts produce an ontology o which is represented using the terms of T (i.e., o belongs to O(T)). Now, let take the second situation: a researcher is using an advanced methodology M (with formally specified meta-concepts) consisting of the set T of meta-terms T and set mO of the terms’ formal specifications. In this case, the situation is similar (see figure 3). However, there is also a difference because the resulting ontology o can be formally verified with respect to the methodology (i.e., that o belongs to O(T+mO)).

3.3 Establishing interoperation In this subsection we will consider the scenarios that may be used to establish interoperation between two or more MAS made by different developers. There are several situations in MAS life cycle where the task of arranging an interoperation can arise. These are the situations involving operation of two or more MAS created by different developers (commercial companies or research community): 1) using the same methodology with informally (or formally) specified meta-terms; 2) using different methodologies with informally (or formally) specified meta-terms. Generally, to establish an interoperation between two or more systems one has to make certain that format and content of the messages (which are sent by individual agents to other agents across the system boundaries) are equally interpreted within both systems. That is a problem since no ACL so far is completely independent of the structure of agent and MAS and, therefore, interpretation of messages by agents depends on the underlying assumptions (e.g., agent benevolence, veracity, etc.) introduced by analysis and design methodologies used. From the practical point of view, there can be many solutions of this problem. We will discuss them in the section 4. Below we are elaborating the details of one of them.

If the problem is the incompatibility due to difference in messages that circulate within and across agent system boundaries then it is reasonable to expect that some conversion tools (or some more general integration tools) may be developed to dynamically change format and content of the messages. Such conversion tools would take into account particular properties of both sender and receiver agent systems. The properties that should be considered while developing such a tool include particular designs of agent systems including features brought in by methodologies used at the analysis and design stages of their life cycle. In order to enable the conversion of messages, a developer of a conversion tool should establish mappings between: 1) elements of methodologies (meta-concepts) used and 2) elements of system descriptions that incorporate analysis and design models and play role of ontologies.4 Developing such conversion tools is an approach that may be useful for solving practical interoperability problems. However, it is necessary to estimate the feasibility of using this approach in different situations. 3.3.1 Single methodology case Let us assume that there are two MAS created by different developers using the same agent-oriented methodology M. The systems are different because they are created for different purposes: their developers’ conceptualizations are different. Consequently, systems’ descriptions are different, and their parts that would play role of ontologies (to enable message conversion) are also different: o1≠o2. Also, there may be a difference caused by subjective character of methodology application: first system is created in the framework of T+G’ methodology, second system – in the framework of T+G” (here G’ and G” denote subjective interpretation of methodology’s guidelines by different developers). Therefore, to enable building a conversion tool, it is necessary (as an initial part of such a development) to pass through the following sequence of steps: 1) Establish a mapping between two interpretations of the methodology: T+G’ ↔ T+G” (see figure 4, step III); 2) Transform the ontology o1 from original representation (T+G’) into the framework of T+G” using the above mapping (figure 4, step IV); 3) Compare the transformed ontology o1” with the ontology o2 (figure 4, step V).5

O(T+G’) (III)

o. 1” .o 2

o1 . (IV)

(V) Figure 4: Establishing interoperation: case of single methodology with informal meta-concepts difficult. It is based mostly on intuitive understanding of the methodology’s meta-concepts. Their names (meta-terms) are the same in both cases but interpretation may differ. The documentation supplied with the systems plays the crucial role for creating a mapping between two sets of the meta-concepts. The consequent transformation of the ontology o1 is made by hand using the established informal mapping. Comparison of two ontologies is also done by hand. In general, development of a conversion tool in these settings requires a lot of subjective hand- and mind work. However, it is not very complicated and available to a general developer. Moreover, the resulting tool can be quite simple. Now, let us consider the same situation but with another kind of methodology used: T+mO (see figure 5). In this case, the same three steps are required but some of them can be taken automatically. A mapping between methodologies (figure 5, step III) is trivial since there should be no difference in interpretation of formally specified meta-terms. Therefore, a developer of a conversion tool can directly obtain (step IV) the ontology o1 from the other system (of course, if the ontology has been represented explicitly and made available). Comparison of the ontologies o1 and o2 is the same as in the previous case. It can be done by hand or with support of automatic tools depending on particular means used for ontology representation.6 Thus in case of single methodology with formal meta-terms, the work necessary to build a conversion

O(T+mO)

O(T+mO) (III) o1

o1 .

.

.o 2

(IV)

It is clear that the manual work is required to take all the above steps. The first step – finding out differences in methodology interpretations – is probably the most

(V) Figure 5: Establishing interoperation: case of single methodology with formal meta-concepts

4

That may be not sufficient for such a conversion, but we believe these steps are necessary. 5 Having this comparison done, further steps of the developer should ensure the proper message conversion. However, we will not go into these details since we want only to consider role of methodologies within this development process.

O(T+G”)

6

Agent-oriented methodologies usually do not restrict a developer to specific representation languages, but they provide these representations with a specific structure.

O(T1+G1’)

O(T2+G2”)

O(T1+mO1)

(III)

O(T2+mO2)

(III) o. 1” .o 2

o1 .

O(T1)

(IV)

O(T2)

o1 .

T1+mO1 ↕ T2+mO2 (IV)

(V)

o. 1* .o 2

(V)

Figure 6: Establishing interoperation: case of multiple methodologies with informal meta-concepts

Figure 7: Establishing interoperation: case of multiple methodologies with formal meta-concepts

tools is straightforward, it is more automated and potentially more precise. Now let us consider the case of multiple methodologies.

is a rather complicated problem that requires good knowledge in many areas of mathematics and computer science that are available mostly within the research community. Therefore it is difficult to expect that general developers will create such tools. It is also rather problematic to manually convert the ontology o1 from the representation framework of T1+mO1 into o1* represented in terms of T2+mO2 since that requires almost the same high level of qualifications. The same can be said about further comparison of two ontologies: o1* and o2. On the other hand, such problems will hardly emerge outside of the research community since general developers do not use such kind of methodologies in the first place.

3.3.2 Multiple methodologies case In this case, there are two MAS created by different developers using different traditional (with informal meta-concepts) methodologies M1 and M2. The systems are not created for the same purpose, therefore o1≠o2 (as in the case of single methodology). Individual biases of developers’ uses of the methodologies are also present: the agent systems are created in the framework of T1+G1’ and T2+G2” methodologies correspondingly (see figure 6). The steps that should be taken to enable developing a conversion tool are about the same as in the previous case. The difference lies in the nature of mapping between methodologies, which should be established. Now, it is necessary to establish a mapping between two completely different sets of meta-terms that have only informal specifications: T1+G1’ ↔ T2+G2” (see figure 6, step III). This work is made manually using only intuitive understanding of the meta-concepts of both methodologies. This kind of work can be considered as rather difficult for a general developer, since it requires mastering two different methodologies. The documentation supplied with the MAS as well as descriptions of methodologies themselves are highly important at this step. Transformation of the ontology o1 is then also made manually using the established mapping (figure 6, step IV). It is an error-prone process because of the informal nature of the methodologies’ meta-concepts, subjective character of their use and informal character of mapping. This fact complicates further comparison of two ontologies (step V). If the methodologies with formally specified meta-terms have been used to develop agent systems then the steps necessary to enable a conversion may become easier. Indeed, formal character of methodologies’ meta-terms allows building tools to translate the representation of ontologies between two frameworks: T1+mO1 ↔ T2+mO2 (figure 7, steps III, IV). Similar approach has been developed in the knowledge representation domain (Gruber, 1993). Building such a tool

3.4 A combined approach Thus, it is evident that different types of developers can establish interoperation between agent systems in various ways that have rather diverse properties. In two tables below we summarize the positive and negative properties and consequences of using different agent-oriented methodologies at initial stages of system development as well as in the process of establishing interoperation between agent systems. It is easy to see (subsections 3.2, 3.3) that using traditional methodologies (with informal specification of the meta-terms) is not very difficult at the stages of initial system development. These methodologies can be used by a general developer. However, the inherent properties of such methodologies cause problems as soon as the necessity to interoperate with other systems arises. Main reason for that is subjective character of methodology application both at the initial development stages and at the time of arranging an interoperation. That problem exists even in the case of single ontology used by different developers. Table 1: Use of methodologies at initial stages of agent system development

I II

Using T+G simple inaccurate simple inaccurate

Using T+mO complicated more accurate complicated more accurate

Here, I – comparison of set of ontologies and class of conceptualizations (step I in figures 2,3); II – characterizing a conceptualization with an ontology (step II in figures 2,3). Table 2: Use of methodologies at the stages of establishing interoperation between agent systems

III

IV

V

III

IV

V

Single methodology case informal meta-terms formal meta-terms simple; trivial not precise; precise manually automatically simple; trivial not precise; precise manually automatically complicated by depends only on informal character ontologies; of steps I, II; manually manually Multiple methodologies case informal meta-terms formal meta-terms difficult; very complicated; not precise; precise; manually manually difficult; simple; not precise; precise; manually automatically complicated by depends only on informal character ontologies; of steps I, II; manually manually

Here, III – establishing a mapping between sets of ontologies corresponding to use of two methodologies (step III in figures 4-7); IV – converting an ontology between representation frameworks of two methodologies (step IV in figures 4-7); V – comparing a converted ontology with an ontology of another agent system (step V in figures 4-7). Methodologies with formally specified meta-terms (advanced methodologies) have better properties from the standpoint of interoperability of the resulting agent systems. Transformation of ontologies between representation frameworks of different methodologies can be made automatically and precisely. The problem with such methodologies is that at the initial stages of system development they can be used only by developers with high qualifications (researchers). We believe that a combined use of both formal and informal specifications of methodology meta-terms can alleviate the above problems. The essence of a combined approach is that a methodology should have its meta-terms specified using both formal descriptions and informal guidelines. Such a methodology should be created as a single represen-

tation framework (let designate it T+G+mO) to ensure that the formal descriptions and informal guidelines characterize the same meta-concepts. In this case, the set O(T+G+mO) of ontologies that can be represented within the framework will be close both to O(T+G) and O(T+mO) (see figure 8). That property would guarantee that the classes of ontologies created by a general developer and by an advanced developer (researcher) will coincide. In this way it would become possible to divide the processes of agent system development and establishing interoperability into phases where the most precise and simple methods are applied (by different specialists). In these settings, making comparison between the set of ontologies and class of conceptualizations designer would use the T+G part of the representation framework (see figure 8, step I), as it is easier to understand. That would make choice of a methodology more efficient, since unsuitable methodologies would be rejected at early stages without digging into formal details. Characterizing a conceptualization with an ontology would also be made using the T+G part of the framework (figure 8, step II). If necessary, formal specifications can then be used to verify the resulting ontology. Establishing a mapping between two methodologies’ representation frameworks is a difficult task, but within this approach it have to be done only once. That can be done by specialists with high qualifications. A tool to transform ontologies between two frameworks would be created: T1+mO1 ↔ T2+mO2 (figure 8, step III). Such tool automatically transforms ontologies (figure 8, step IV) eliminating difficult handwork and otherwise inevitable mistakes. Finally, the comparison of the transformed ontology and ontology of the local system can be made in the framework of T2+G2. That is simper and can be performed by a general developer. Alternatively, there is always a possibility to use other part of the framework: T2+mO2. Again, comparative analysis of two ontologies more depends on their particular content and representation means used.

c. (I)

(II)

C

O(T1+mO1)

o1 .

O(T1+G1)

(III) T1+mO1 ↕ T2+mO2 (IV)

O(T2+mO2)

o. 1* .o 2

O(T2+G2)

Figure 8: A combined approach

(V)

4 Discussion and conclusion Development of MAS that have to operate within globally distributed open information architectures is problematic by many reasons. Such development is inherently decentralized. It is impossible to force developers to work in the same way in order to make their MAS interoperable. Agent systems are developed for different purposes that may be difficult to foresee in advance. These systems have to be open to be able to interoperate with other systems without returning to the design stage. One of the problems that hinder creating really open distributed multi-agent systems is the problem of establishing common interpretation for information messages exchanged by agents. This problem is general for distributed information systems but in case of agent systems it has some peculiarities. Agents communicate using some ACL. Many ACL have been created, but no ACL is independent of internal structure of agent (and MAS). That implies interoperability problems even agent systems use the same ACL. For example, KQML had been considered as a de facto standard for ACL. However, the semantics of KQML is not formal, thus there is no way to help a developer to correctly use KQML except by informal guidelines and commonsense knowledge. The process of ACL development and standardization is continuing (see FIPA project), but there is no guarantee that the abovementioned problem of dependence will be solved. As an alternative solution, reconsideration of the basic principles of ACL is proposed in (Singh, 1998). The idea there is to change the perspective of agent communication from private to public. In this way it may be possible to separate communication and internal structure of agent and MAS. Till then, an agent (system) has to take into account the internal structure of another system’s agent (and/or entire system). The structure of MAS depends on purpose of MAS, particular developer, methodology used. Their influence on the MAS internal structure has to be accounted for and, if possible, compensated for successful interoperation. Many methods can be applied to compensate various incompatibilities. For example in (Steels, 1997) the compensation of difference in agents’ applied lexicons is discussed. In our work, the influence of methodology on MAS interoperability properties is considered. A typical methodology of agent-oriented analysis and design suggests molding a conceptual view of a developer into specific set of models describing the agent system. Moreover, these models have to describe entire system leaving no space for their consequent transformation, expansion and integration with other systems. To some degree, that is due to the structure of MAS life cycle, since there are no integration-related stages in it. On the other hand, the methodologies themselves introduce no concept of integration.

The consequence of using such methodologies within the MAS life cycle is that the resulting systems are neither immediately interoperable nor can easily be made interoperable (by some automated means or manually). It is easy to see that even the same traditional agent-oriented methodology used by different people influences the resulting systems in different ways. Compensating this difference is not easy. Therefore standardization of a traditional agent-oriented methodology will not help since using the same informal methodology does not necessarily promote the interoperability. Another way is to use only methodologies with formally specified meta-concepts. That would help to resolve some problems. However, such approaches are difficult and expensive. Also, they are not easily scalable (Fisher et al., 1997). Besides, there are only few methodologies that utilize formally specified meta-concepts. Important reason for that seems to be the fragmentation of research among many fields. For example, in this work we have considered a combined approach to agent system development and integration. It could work and make the interoperability problem easier to solve. In practice, however, that requires joint efforts of specialists from different research fields such as agent systems, formal methods, knowledge representation, formal ontology, etc. Another example of about the same problem is the situation in the area of object-oriented software development. At some stage of its evolution, there were several informal methodologies of object-oriented analysis and design that came mostly from the practitioners (for example see Booch, 1991; Rumbaugh et al., 1991), etc.). Later, UML (Rational, 1997) has been created by the same practitioners to become a standard methodology and language. At the same time, important results from the area of formal ontology (e.g., Guarino, 1998b) have not been applied here in any way because they came from a different field. Consequently, UML remains a traditional object-oriented methodology (with informally specified meta-terms), while it could be supplemented with powerful formal facilities. That would give additional quality to the resulting designs and products. But that has not been done and the main reason seems to be the fragmentation of research and development among many fields. In agent research, the situation looks very similar. There are many traditional methodologies but there is no standard yet. There are some formal approaches that come mainly from other fields. Some standard methodology may appear as an attempt to avoid incompatibility problems (like interoperability of different MAS). However, it will not help (as shown above) if the formal specifications will be left overboard. Moreover, these methodologies are developed and used within a scientific community that has no close integration with a general developer community.

In our opinion, use of the combined approach described in this paper would bring benefits both to general developers and researchers in the field. The former group would receive a more efficient methodology that improves the system development process and raises the quality of its results. Also, developers’ efforts to establish interoperability among different systems would be greatly alleviated with automated tools. The latter group would receive a more intense introduction and a larger proving ground for the research results. The combined approach is a way to solve interoperability problem. It allows relieving this problem for particular instances of agent system. However, as the number of MAS will grow the problem will become more serious. Plain use of the combined approach would lead to developing a translation tool for each pair of interoperating agent systems. That implies grow of number of tools according to O(N2) law (N is number of pairs). If there were a standard methodology (a combined one) then it would be possible to create just O(N) translation tools that made translation through a standard meta-language. Such a solution has already been demonstrated to be effective in a related field (see Gruber, 1993). As it is detailed above, efficient use of automatic ontology conversion tools is possible only for agent-oriented methodologies with formally specified meta-terms. That agrees with the fact that Gruber’s approach also requires formal specifications of the methodologies’ meta-terms. In our opinion, a standard (combined) methodology will emerge to provide a reference point for other methodologies in a logically centralized way. A set of the meta-concepts of such a methodology will be specified by using both formal and informal means. The formal part will be to a large extent based on ideas of Formal Ontology (Guarino, 1998b). This part will play a role of meta-ontology for representing shared descriptions of agent systems. Presently, we are working on elements of this meta-ontological basis for open distributed MAS. Thus in this paper, some methodological aspects of developing multi-agent systems have been considered. In particular, influence of analysis and design methodology on the interoperability properties of resulting agent system has been investigated from the perspective of ontology-based meaning transfer. A combined approach to developing better multi-agent systems has been proposed. It is based on joint use of informal and formal specifications of methodology’s meta-terms. Some existing approaches to solve agent systems’ interoperability problem have been discussed and compared to approaches used in related fields.

Acknowledgements This work has been carried in the framework of the research project No. IST-1999-10304 supported by Commission of the European Communities, European Union.

References V.A. Abramov. Co-ordination of knowledge representation systems for knowledge sharing tasks. Proceedings of Zolotov's mathematical school, Institute for Automation and Control Processes, Far Eastern Branch of Russian Academy of Sciences, Part 1: 12-21, IACP FEBRAS, Vladivostok, Russian Federation, August 28 – September 3, 1998. (in Russian) G. Booch. Object-Oriented Design with Applications. Benjamin/Cummings, Redwood City, CA, 1991. P. Breiter and M.D. Sadek. A Rational Agent as a Kernel of a Cooperative Dialogue System: Implementing a Logical Theory of Interaction. Proceedings of ECAI-96 Workshop Agent Theories, Architectures, and Languages, 261–276, Springer-Verlag, Berlin, 1996. B. Burmeister. Models and methodology for agent-oriented analysis and design. Working notes of the KI’96 Workshop on Agent-Oriented Programming and Distributed Systems, K. Fischer (Ed.), 1996. T. Finin, Y. Labrou, and J. Mayfield. KQML as an agent communication language. Software Agents, J.M. Bradshaw (Ed.), AAAI Press, 1997. FIPA. Foundation for Intelligent Physical Agents. FIPA’99. http://www.fipa.org. 1999. M. Fisher, J. Müller, M. Schroeder, G. Staniford, and G. Wagner. Methodological foundations for agent-based systems. Proceedings of the UK Special Interest Group on Foundations of Multi-Agent Systems (FOMAS), Knowledge Engineering Review, 3(12), 1997. S. Franklin and A. Graesser. Is it an agent, or just a program? Intelligent Agents III (LNAI Volume 1193), J.P. Müller, M. Wooldridge, and N.R. Jennings (eds.), 21-36. Springer-Verlag, Berlin, 1997. T.R. Gruber. A translation approach to portable ontology specifications. Knowledge Acquisition, 5:199-220, 1993. T.R. Gruber. Toward Principles for the Design of Ontologies Used for Knowledge Sharing. International Journal of Human and Computer Studies, 43(5/6):907-928, 1995. N. Guarino. The Ontological Level. Philosophy and the Cognitive Science. R. Casati, B. Smith and

Hölder-Pichler-

Agents in a Multi-Agent World MAAMAW’96. Springer Verlag, Heidelberg, Germany, 1996.

N. Guarino and P. Giaretta. Ontologies and Knowledge Bases: Towards a Terminological Clarification. Towards Very Large Knowledge Bases: Knowledge Building and Knowledge Sharing 1995, N. Mars (Ed.), 25-32, Amsterdam, IOS Press, 1995.

Rational. Unified Modelling Language (UML) version 1.0. Rational Software Corporation, 1997.

G. White (eds.), 443-456, Tempsky, Vienna, 1994.

N. Guarino. Formal Ontology and Information Systems. Proceedings of the International Conference on Formal Ontology in Information Systems (FOIS’98), N. Guarino (Ed.), Trento, Italy, June 6-8, 1998, Amsterdam, IOS Press, 1998a. N. Guarino. Some Ontological Principles for Designing Upper Level Lexical Resources. Proceedings of First International Conference on Language Resources and Evaluation, 527-534. Granada, Spain, ELRA - European Language Resources Association, 1998b. N. Guarino and C. Welty. Ontological Analysis of Taxonomic Relationships. Proceedings of ER-2000: The International Conference on Conceptual Modeling, A. Laender and V. Storey (eds.), October, 2000. C.A. Iglesias, M. Garijo, J.C. González, and J.R. Velasco. Analysis and design of multiagent systems using MAS-CommonKADS. AAAI’97 Workshop on Agent Theories, Architectures and Languages, Providence, RI, July 1997. C.A. Iglesias, M. Garijo, and J.C. González. A Survey of Agent-Oriented Methodologies. Proceedings of the Workshop on Agent Theories, Architectures and Languages, Paris, France, July 1998. M. d’Inverno, M. Fisher, A. Lomuscio, M. Luck, M. de Rijke, M. Ryan, and M. Wooldridge. Formalisms for multi-agent systems. The knowledge Engineering Review, 3(12), 1997. N.R. Jennings, K. Sycara, and M.J. Wooldridge. A Roadmap of Agent Research and Development. International Journal of Autonomous Agents and Multi-Agent Systems, 1:7-38, 1998. N.R. Jennings and M.J. Wooldridge. Applications of Intelligent Agents. Agent Technology: Foundations, Applications and Markets, N.R. Jennings and M.J. Wooldridge (eds.), 3-28, 1998. D. Kinny, M. Georgeff, and A. Rao. A methodology and modelling technique for systems of BDI agents. Agents Breaking Away: Proceedings of the Seventh European Workshop on Modelling Autonomous

J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and V. Lorensen. Object-Oriented Modelling and Design. Prentice-Hall, 1991. M.P. Singh. Agent Communication Languages: Rethinking the Principles. IEEE Computer, 12:40-47, December 1998. L. Steels. Language Learning and Language Contact. Proceedings of the workshop on Empirical Approaches to Language Aquisition, W. Daelemans (Ed.), Prague, 1997.