SCHEDAE

XXXXXXXXX

INFORMATICAE
VOLUME nn Year

Validating UPML Concepts in a Multi-Agent Architecture

lin S Ca andru and Viorel Negru1

1

Department of Computer Science, West University of Timisoara, Bd. V. Parvan, 4, Timi soara, Romania, e-mail: {csandru,vnegru}@info.uvt.ro

Abstract. The task oriented reasoning represents a powerful design paradigm. This research starts from a representative research in the area, the Unied Problem-Solving Method Development Language (UPML), and proposes a multi-agent architecture to support this approach. The paper rst models an applicative program, solving non-linear equation systems, using UPML concepts and then instantiates the proposed generic multi-agent architecture in order to generate a multi-agent system to solve the proposed problem. Keywords: multi-agent systems, problem solving methods, task oriented reasoning, knowledge based systems, non-linear equation systems.

1.

Introduction

Many research eorts in Articial Intelligence study how to model knowledge based systems (KBS) such as to reuse their components in building other KBSs [4, 18, 19]. The notions of task and problem solving methods realizing a task were early identied as being useful in describing a KBS [4]. The next step was to conceptually model KBSs by identifying various levels of abstractions in their descriptions together with the relevant classes of information used when representing knowledge in order to solve problems [20, 8]. As a contribution of the conceptual approach, KADS proposes a model of expertise [24] and focus on nding ways to reuse knowledge. In this context, the language KARL [8] explicitly introduces the role of ontologies in problem solving, and PROTEGE II [11] provides tools for knowledge acquisition based on ontologies. More recently, the language UPML (Unied Problem-solving Modelling Language) [6] provide a coherent conceptual view on the problem solving process by

2 relating the components of the expertise (domain, inference and task knowledge) using adaptors. The central element in the UPML view are ontological descriptions of the above mentioned components of expertise. The ontologies provides basic terms and relations for describing application domain, inference and tasks. In general, many dierent ontologies are used in order to model a complex application. If, for example, the application domain and the inference procedures are not described in the terms of the same ontology, then some components are needed in order to adapt ontological terms in such a way that the inference procedure may be applied on the specic application domain. UPML uses ontological bridges in order to solve the possible ontological dierences between various components of the expertise. When developing a new application the eort shifts from implementing new inference procedures to their reusability from existing libraries and to provide appropriate bridges in order to be able to eectively apply the procedures in order to satisfy tasks in a specic application domain. Although not developed in a multi-agent context, in our view, the UPML approach could be adapted to a multi-agent environment by providing mechanisms in order to: view the inference procedures as agent capabilities and tasks as requests for executing capabilities; describe the agent capabilities in UPML; facilitate agent capabilities based on ontological bridges. In this regard, the starting point of this paper is the UPML architectural model which we intend to adapt to a multi-agent context. As a consequence of this research, we propose a general multi-agent framework called MATOPS (Multi-Agent Task Oriented Problem Solver) which we applied to solve non-linear equation systems in an application called NESS (Non-linear Equation Systems Solver)[15]. An expert system for solving non-linear equation systems was developed at Carnegie-Mellon (Talukdar, 1983) [13]. The expert system supervise the application of three dierent numerical programs for solve some non-linear algebraically equation systems which cannot be solved with only one method. The choice is made in function of the consequence concerning convergence. A general problem solving system, providing a remote interface, is NetSolve [3]. But this system is mostly concerned about how to provide a service and how to specify any general request apart from our intention of having a powerful nonlinear problem solver. NESS is rather intended to provide services for NetSolve engine. In order to better express how MATOPS is used to solve non-linear equation systems, we start with a description of the NESS application, followed by the description of the NESS solver in the UPML language. Consequently, in the section 3., the NESS elements are expressed in terms of ontologies, domain knowledge, tasks and problem solving methods. The UPML adapters link all NESS components and rene them as needed. The section 4. describes the generic multi-agent architecture (MATOPS) capable to execute the problem solving methods described in the section 3. The MATOPS

3 environment provides elements to cope with dierent aspects of the UPML language in a distributed solving context. In the section 5. we show how the generic architecture above is instantiated in order to solve the NESS problems. Finally some related work and conclusion are described.

2.

NESS solver

The goal of the NESS solver is to provide an intelligent framework being able to assist the user in solving non-linear equations systems. The system is be able to automatically choose the most adequate numerical methods or to combine two or more numerical methods for solving non-linear equations systems. The methods for solving non-linear systems of equations have some certain intrinsic characteristics (which do not generally depend on the particular system which has to be solved); such characteristics are crucial elements of the general solving strategy. There have also been developed special methods for certain classes of problems, having in view to use some particularities of the problems and to get enhanced performances by these means. The characteristics of solving non-linear problems are the convergence rate, the computing eort per one iteration, the possibilities to exploit the sparsity and numerical stability. Solving non-linear problems also involve a series of collateral extremely important problems; for example, choosing the initial iteration, error evaluation, possibility of parallelization, the problem of nding all solutions in a given domain, etc. Generally, there is not a unique recipe in solving the non-linear equations systems [15]. In order to choose a particular solving method, one should take into account several external aspects: the form of the system, knowledge about a good iteration, structural characteristics (the quality of the Jacobian, condition number), etc. Other elements who inuence the solving process are: the precision, the memory space, the convergence speed of the solving methods. NESS considers the following objectives: the acquisition and the formalization of the expert knowledge; the development of the methods base and of the corresponding routines library; the design of a task oriented formalism for modelling the reasoning. A rst prototype NESS [16] was implemented in CLIPS 6.0 [5] expert system shell. The graphics interface was developed in WxWindows. The task-oriented model was based on task structure which allows to make explicit reasoning and control knowledge at dierent levels of abstraction [4, 16]. Tasks are organized on several levels according to the problem degree of abstraction or the problem complexity. A high level task is more supple (modelling,

4 analyzing, identifying, classifying), while a low level task is more rigid (Jacobian calculus, reversing matrix, symbolical derivative). We used task-graphs (in particular: task-trees) to represent a reasoning scenario. A task-graph is a static model of solving the problem (usually described in a language of subproblems) and it is a rst approximation of the reasoning. The (partial) tree of tasks is shown in gure 1.

NESS Rework reasoning

Problem define

Problem analyse

Solving method construction

Instantiate method

Diagnosis

Modify hypothesis

Problem formalise

Symbolic transformation

System feature determination

Compute features

User informations

Figure 1.: A partial tasks tree of NESS solver To solve a non-linear system of equations, we used a model which simulates a human experts reasoning. The model is similar to the solving paradigms Generate, Test, and Debug . In our case we used a meta-reasoning level which suppose the following stages: construction, instantiation and diagnosis. Construction the reasoning means nding a chaining of tasks and their associated methods, which - at the level of elementary tasks - is nothing else than a sequence of calls to calculus routines or inference mechanisms (classication, inductive or deductive rule-based mechanisms, etc). As result of this stage a graph of elementary methods is obtained. Instantiation means the realization of the formerly obtained tasks chaining (more exactly: the execution of a path in the graph of elementary methods). Diagnosis refers to the analysis of the intermediary and nal results. It also means - in the case of failure - establishing the causes of the failure (by use of causal knowledge) and reworking the reasoning. NESS is able to determine the properties of the system of equations, based on the problems description, and to propose candidate numerical methods based on the characteristics of about thirty (which variants) implemented numerical methods. The symbolic transformations refer to: the reducing of the terms of equations,

5 the reducing of the number of equations, derivative computing and the explicitly diagonal form obtaining. Also it is possible to obtain the sum form (a linear and a non-linear part). If a method fails, the system (NESS) reworks the reasoning with (some) modied parameters (discretization step, number of iterations, precision), a modied initial iteration or another numerical method (or combination of numerical methods). For example, if the conjugated gradient method fails, NESS can try to solve the problem with the Steensen method using the last iteration of conjugated gradient method as initial iteration. Concerning the numerical solving methods, the application implemented some classical ones with high solving performances (Classic Newton, Discretized Newton, Secant, Steensen, Parallel Lines, etc.) and some more recently designed (Broyden, Friedman, Conjugated Gradient, Successive Over-relaxation, Alternating Directions Iteration, etc.), as well as special methods, generally useful for solving equations with dierences resulted from continuous problems discretization (for example, the equations with dierences corresponding to non-linear weak bi-locale problem).

3.

Modelling NESS in UPML

The language UPML is useful when solving the design of a task oriented formalism for modelling the reasoning. A signicant part of the NESS components (tasks, problem solving methods and ontologies) is presented in the gure 2. At the upper part of the gure one can see the three main ontologies used for dening the terminology for the application components. The N onlinearEquationSystems ontology, for example, denes terms used for the task SolvingN ES and the application domain. It denes terms like EquationsSystem, SystemP roperty and V ariableInstantiation or functions like eval allowing for the evaluation of a EquationsSystem on a V ariableInstantiation. The N ESS problem solving method (PSM), in the middle of the gure 2, is the main application method intended to realize the task ApproximativelySolvingN ES . This task is a rening of the task SolvingN ES because it allows for an arbitrary precision in the resulting solutions and thats why it imports terms dened in the ontology called Approximation. There is a relation in the gure 2 which deserves special attention. It concerns the link between the Iterating task and the ChoosingIterationM ethod task. The Iterating task is gured to be realized by the iterativeSolving method. In fact there are many iteration methods to be used in order to iterate on a function. The solution is to rene the iterativeSolving method in order to obtain specic methods like classicN ewton, stef f ensen or conjugatedGradient. There are many iteration methods in the mathematical literature, each having particular characteristics and each being appropriate for problems with specic properties. Therefore, choosing a solving method for NESS problems is a non-trivial task.

Approximation

NonlinearEquationSystems

IterativeSolving

11111111111111 00000000000000 ApproximativelySolvingNES 11111111111111 00000000000000 00000000000000 11111111111111 00000000000 11111111111 00000000000 11111111111 ReadNES 00000000000 11111111111 00000000000 11111111111
iterativeSolving

1111111111 0000000000 1111111111 0000000000 SolvingNES 111111111111111111111111111 000000000000000000000000000 SolvingNonlinear 0000000000 1111111111 111111111111111111111111111 000000000000000000000000000 EquationSystems 111111111111111111111111111 000000000000000000000000000 000000000000000000000000000 111111111111111111111111111 DOMAIN
NESS

0000000000 1111111111 0000000000 1111111111 Iterating 0000000000 1111111111 0000000000 1111111111

classicNewton ADI-Kellog

...

111111111111 1111111111 000000000000 0000000000 111111111111 1111111111 000000000000 0000000000 GenerateNewIterations Stop 111111111111 1111111111 000000000000 000000000000 0000000000 111111111111 0000000000 1111111111 000 111 - task - PSM 000 111 111111 -domain 000000 000 111
- refining - ontology import - choosing PSM task - bridge TD

111 000 000 111 000 111 000 111 000 111 000 111 000 111 000 111 000 111 000 111 000 111 000 111 000 111 000 111 000 111 - ontology
- bridge TM ChoosingIterationMethod

- precondition task

Figure 2.: NESS expertise components Generally, the UPML language assumes that the method selection for a particular task is based on the method competencies (preconditions and subtasks) and some other method characteristics like the costs of applying the method, method communication style, or statistical observations related to the methods execution [1]. As previously said, the NESS expert is performing a complex task in order to choose methods and the traditional selection is not powerful enough. This is the reason why the ChoosingIterationM ethod is called, before applying the traditional rules, in order to select the best iteration method for the task. Indeed, adding such a task implies creating bridges between the meta-ontology of the UPML language and the domain ontologies. We call method choosing tasks the tasks like ChoosingIterationM ethod. The methods choosing tasks perform reasoning based on the domain knowledge and this is precisely the main aspect dierentiating them from the traditional UPML brokering algorithm. Indeed, the evaluation of a methods preconditions, considered in UPML, could provide a mean to use domain knowledge in the process of PSM selection for a task, but this kind of evaluations are far from being as complex as reasoning eected into an expert system, for example. This is exactly the last type of reasoning we promote by introducing dedicated tasks for choosing between PSMs.

7 4. Multi-agent Architecture

The main interest of this research is to dene a multi-agent architecture to run agents acting in terms of tasks and problem solving methods. The starting point is the UPML architecture. In the introductory section we identied three aspects which could make us view UPML as a base for a multi-agent system. We will discuss each of them in turn. As a preliminary observation, the formal examples below are written in the Z language [2]. This language is expressive enough to describe most of the details of a computing system together with the possible operations, in a unied and consistent manner. It uses schemas and schemainclusion in order to provide descriptions at dierent abstraction levels. Another useful characteristic of the Z language is the ability to express terms from both conceptual and implementation points of view. It was also used to describe other multi-agent architectures, see [7, 14] for examples. The rst aspect concerns viewing the inference procedures as agent capabilities and tasks as requests for executing capabilities. The descriptions in the previous section revealed a hierarchy of solving components modelling the NESS solving process. If we look at the problem solving methods there are simple computing routines like iterative solving methods but also complex inferences like the one choosing the iterative method to be used, task performed by a mathematical expert. In the rst case, there is a huge number of iterative solving methods which is likely to be implemented by dierent developers and accessible in dedicated environments like Computer Algebra Systems or libraries. It is indeed possible to view related iterative solving methods as being executed by a dedicated component like a computing agent. In the second case, where complex inference tasks are needed, the complexity of the tasks and the technological requirements to perform the tasks makes feasible to assign a dedicated agent for executing such a task. It is thus reasonable to view the problem solving methods of the UPML model as being considered capabilities of a set of agents. The paper [23] argues that in this case tasks may become descriptions to be used in order to choose the capabilities to achieve a goal. The second aspect focus on using UPML as a capability description language (CDL). Agent architectures often use the term capability [9, 22, 21] in order to identify inference actions performed by the agents. FIPA uses a similar notion called service. UPML was primarily used to describe problem solving methods in a reusable methods library. In this view, some generic agent should be able to interpret the UPML operational description of a PSM and executes it. If we assign PSMs on agents, as argued above, a more real situation is one when the agent implements some PSM and this PSM should be accessible to other agents. In this case, the operational details of the PSM are of no interest for calling agents. The only information needed in order to correctly access a PSM implemented by an agent is the PSMs competence description. The language UPML provides support for describing input and output data, preconditions, postconditions and the accessed subtasks of a PSM. Many CDLs use

8 similar information as a capability description [22, 21]. Thus, UPML may be indeed used as a CDL if only the PSMs competence part is retained from a PSM description. A capability assigned to an agent is characterized by the elements of PSMs, the agent performing it and a function executing its operational procedure on a requested task. The result of a procedure execution is an error code (Success | F ail) and a set of output values: AssignedCapability name : Attribute roles : Roles preconditions : P1 F ormula postconditions : P1 F ormula subtasks : P T ask control : P rogram agent : M AT OP SAgent executeOperationalP rocedure : P rogram RequestedT ask Result seq ActualRole

The third aspect is related to the facilitation of the agent capabilities. This is about choosing the most appropriate agent capability to solve a required task. The problem is similar to retrieving PSM from a library in order to solve a task. UPML was used primarily in this latest situation and the performed reasoning tried to ontologically map input and output roles from the required task description and PSM description. This is based on the existence of bridge adapters between the ontologies describing terms in tasks and PSMs. Additionally, PSMs preconditions are evaluated and the availability of the PSMs subtasks is checked as well as the possibility to evaluate operational description terms and relations. The ontological bridges are again used in order to help verifying preconditions. Although rather complex, this process could be improved. It is not suitable, for example, to choose the most appropriate solving by iteration method in the case of NESS. In this case an expert system reasoning over the application domain knowledge is supposed to perform better by applying some selection rules over the problem and methods properties. We pointed out above the need for method choosing tasks. These tasks focus on processing the application domain knowledge. We can see now that both ontological bridges and method choosing tasks are involved in capability selection when a task is requested. A special agent type is introduced in the framework in order to manage ontological bridges and method choosing tasks. It is called Bridge Librarian and oers services to the F acilitator agent for capability retrieval and to ordinary agents in order for these to be able to map tasks roles to capabilities input or output. Retrieving capabilities are subject of the F acilitator agent activities. For example, the following schema describes the facilitator retrieving appropriate capabilities (PSMs) for a specied task:

9 M AT OP SF acilitator M AT OP SAgent agentsCapabilities : P AssignedCapability capabilityRetrieval : AssignedCapability retrievalF unction : T ask P AssignedCapability executeM ethodChoosingT ask : T ask P AssignedCapability capabilityRetrieval.agent.id = id capabilityRetrieval.control = retrievalF unction task : T ask if ( choosingT ask : T ask bridgeLibrarian.hasChoosingT ask (task, choosingT ask )) then Let (rawM ethods == executeM ethodChoosingT ask (choosingT ask ) retrievalF unction task = {capability : AssignedCapability capability rawM ethods capability agentsCapabilities (bridgeLibrarian.hasBridge capability task )} else retrievalF unction task = {capability : AssignedCapability | capability agentsCapabilities (bridgeLibrarian.hasBridge capability task )} The agent is performing itself a method capabilityRetrieval in order to satisfy a requested task with the goal of retrieving capabilities for a given task. The operational procedure of this capability is described by the retrievalF unction function.
MATOPS AGENT INTERFACE AGENT EXTERNAL SYSTEM

...
CAPABILITY

...
CAPABILITY

...

PSM

TASK LAYER

TASK LAYER

BRIDGE LIBRARIAN

FACILITATOR

Figure 3.: MATOPS architectural structure Essentially, this function rst tries to nd method choosing tasks published by some agents having the goal to nd PSMs for the task being facilitated. If no such task exists, the task capabilities are selected based on the existing bridges between the requested task and the published capabilities. In the case a method choosing task exists, it is performed and its results are ltered like in the previous case in order to be sure that all the needed ontological mappings are available.

10 The gure 3 is showing several agent types and their relationship in the proposed multi-agent system called M AT OP S (Multi-Agent Task Oriented Problem Solver). An ordinary MATOPS agent executes a set of capabilities. It publishes the capabilities with the facilitator and interacts with the facilitator and the bridge librarian in order to execute a requested capability or to execute the subtasks of the capabilities. The category of interface agents, also presented in the gure 3, are exhibiting functions similar to an ordinary MATOPS agent but they have the role of interacting with an external system by translating the data format between MATOPS agents and external agents. They are of particular usage in the frame of the NESS application as illustrated in the next section.

5.

Agents Operation on NESS

This section is dedicated to the way the multi-agent framework MATOPS could be used to solve a particular problem, in this case solving non-linear equation systems. While the traditional approaches to solve this kind of problems is to build monolithic systems like Computer Algebra Systems or to use solving methods situated in libraries of mathematical methods, a multi-agent architectural model has some advantages: Usually there are few solving methods implemented in a CAS and there is little or no support to use external solving routines. Multi-agent systems allows for adding solving procedures by including dierent solving environments into the same application. As illustrated above, various components of the NESS application may be implemented using dierent technologies: the iterative solving methods may be ordinary programs written in some particular language while the procedure deciding which iterative method to use may be an expert system written in some expert system shell. Heterogeneity is better supported in multi-agent systems than in mono-agent systems. While modelling the NESS application using the UPML model, there are various components of expertise which can be placed at the level of particular agents. The language UPML uses bridges to link the components together and we showed how the facilitator and the bridge librarian agents may use and manage the bridging information in order to select agent capabilities to solve particular tasks. When creating a multi-agent model for NESS, the rst thing to do is to identify the inference procedures to be used as agent capabilities. Some of them were presented in the section 3. The second step is to identify the agents performing the inference procedures.

11 The gure 4 shows the essential MATOPS agents composing the NESS application. The facilitator and the bridge librarian are omitted from the gure since their role was already described.

USER INTERFACE readNES

NESS EXPERT choosingIterationMethod

NESS

findSystemProperties

printResults

generateInitialIterations MATHEMATICA

NEWTON SOLVER classicNewton newtonIteration

INTERFACE TO MATHEMATICA multiplyMatrices invertMatrix

multiply_matrices invert_matrix

Figure 4.: MATOPS agents used in NESS application We identied the U ser Interf ace agent whose capabilities are related to user interactions while reading problems and presenting solutions or algorithm evolution. This agent starts the solving process by issuing a request to the F acilitator agent in order to nd the agent performing a capability to solve the task ApproximativelySolvingN ES . The facilitator response indicates the locally available N ESS method which is then called. The N ESS capability asks for executing its precondition task ReadN ES and then to perform the iteration process. The Iterating task could be realized by many methods executed by solving agents like N ewton Solver, Stef f ensen Solver and so on. There are as many solver agents as many distinct algorithms could exists. These agents are only computational and do not manifest initiative. Choosing between agents to perform iteration is an expert task and is performed at the level of the N ESS Expert agent by the capability choosingIterationM ethod. This task is called by the F acilitator agent because The Iterating task was found to have it as a method chooser task. The expert agent is the most pro-active one in the system because, for example, it may decide when to abandon a solving method and when to start a new solving method based on its evaluation about the solving process state. In practice this is done by having each solvers performing a task of the N ESSexpert agent at each execution cycle. The gure 4 also presents a category of external agents, in this case a M athematica solver whose solving algorithms can be used depending on the problem properties.

12 In order to eectively use the capabilities of this component, the multi-agent system is supposed to contain an interface agent for M athematica which manage all the external communication.

6.

Related Work

The overall multi-agent structure is somewhat similar with the FIPA architecture [10]. One may note that the F acilitator and the Bridge Librarian agents in the M AT OP S architecture are performing a similar role with the FIPA Directory F acilitator agent respectively the FIPA Ontology Agent. However, these agents are not necessarily FIPA compliant since they are specialized to manage interactions in terms of the UPML concepts. Related to the description of the MATOPS facilitator is the work on the IBROW project [1]. For simplicity reasons, in our denition of the facilitator retrieval function, we assume as being enough to check with the bridge librarian if there are ontological mappings between task and methods. The work cited above analysis in more details the process of ontological bridging and also some other issues like the possibilities to congure or adapt problem solving methods for/to the desired tasks. The proposed facilitator above is potentially similar with the IBROW broker because it can use the results of this research, but it also copes with the new proposed feature of method choosing tasks. In this context, the Bridge Librarian agent is used to mainly provide two kind of information to the facilitator: the ontology mappings and the assertions stating a task as being a choosing method task for another task. Like in the RETSINA [21] framework, the overall MATOPS facilitation process is structured into a sequence of steps. But besides the ltering steps based on the ontological characteristics of PSMs and their competencies, the MATOPS brokering process is adding a ltering step based on choosing methods tasks and another step in order to sort the PSMs based on their properties compared with the actual problem to solve. There is another research having the goal to build a UPML based multi-agent architecture to manage medical bibliography. The project is called WIM (Web Information Mediator)[12]. In this multi-agent system, the facilitator is also managing a common problem solving library described in UPML. In our context, this approach is not suitable because any agent may posses particular descriptions of problem solving methods and tasks to perform. This architecture does not cope with ontological bridges since it is assumed that all tasks and PSMs are described in a common ontology. In particular, the NESS application proves that complex applications are not usually described using a common set of terms and acceptions. MATOPS considers a special agent, the bridge librarian, to cope with this kind of issues.

13 7. Conclusion

The research described in this paper was mainly centered on proposing a multiagent architecture (MATOPS) intended to support the problem description and the problem solving process in terms of UPML concepts. It showed how the NESS application to solve non-linear equation systems could be modelled by using UPML terms and how MATOPS could be instantiated in order to solve it. There is also a special kind of task introduced and used to model some particular interactions, namely the process of choosing the right problem solving method for a specied task. We called these tasks method chooser tasks. As a future validation of this research we plan to instantiate the MATOPS architecture in order to solve another kind of mathematical problems like solving optimization problems or dierential equations systems [15]. Apart from the mathematical problems, we started to investigate the possibilities to apply a similar task model to a web oriented application [17]. In this case the main property of a task is represented by the pre and post-tasks, whose formalization is subject of future work.

Acknowledgment

This work was partially supported by the Romanian Government CNCSIS grant no. 564/2003, Austrian Government (BMBWK Ministry) grant no. GZ 45.427/1VI/B/7a/2002 and by WebQuote.com SRL, Timisoara, Romania.

8.

References

[1] V. Benjamins, E. Plaza, E. Motta, D. Fensel, R. Studer, B. Wielinga, G. Schreiber, Z. Zdrahal, and S. Decker. Ibrow3: An intelligent brokering service for knowledge-component reuse on the world-wide web, 1998. [2] J. Bowen. Formal Specication and Documentation using Z: A Case Study Approach. International Thomson Computer Press, International Thomson Publishing, 1996, Revised 2003. [3] H. Casanova and J. Dongarra. Netsolve: A network server for solving computational science problems. The International Journal of Supercomputer Applications and High Performan ce Computing, 11(3):212223, 1997.

14 [4] B. Chandrasekaran and T. R. Johnson. Generic tasks and task structures: History, critique and new directions. In J.-M. David, J.-P. Krivine, & R. Simmons (Ed.), Second Generation Expert Systems. Berlin: Springer-Verlag, pages 232272, 1993. [5] C. Culbert, G. Riley, and B. Donnell. CLIPS reference manual, Volume 1, 2, 3, 1993. [6] D.Fensel, E. Motta, V.R. Benjamins, M. Crubezy, S. Decker, M. Gaspari, R. Groenboom, W. Grosso, F. van Harmelen, M. Musen, E. Plaza, G. Schreiber, R. Studer, and B. Wielinga. The unied problem-solving method development language upml. Knowledge and Information Systems, 5(1):83131, 2003. [7] M. dInverno, D. Kinny, M. Luck, and M. Wooldridge. A formal specication of dmars. In Rao Sings and Wooldridge, editors, Lecture Notes in AI,Intelligent Agents IV: Proceedings of the Fourth International Workshop on Agent Theories, Architectures and Languages, volume 1365, pages 155176. Springer Verlag, 1998. [8] D. Fensel, J. Angele, and R. Studer. The knowledge acquisition and representation language karl. IEEE Transcactions on Knowledge and Data Engineering, 10(4):527550, 1998. [9] T. Finin, J. Weber, G. Wiederhold, M. Genesereth, R. Fritzson, D. McKay, J. McGuire, S. Shapiro, and C. Beck. Specication of the kqml agentcommunication language. Technical report, The DARPA Knowledge Sharing Initiative External Interfaces Working Group, 1993. [10] FIPA. Fipa agent management http://www.pa.org/repository/bysubject.html, 2002. specication.

[11] J.H. Gennari, M.A. Musen, R.W. Fergerson, W.E. Grosso, M. Crub ezy, H. Eriksson, N.F. Noy, and S.W. Tu. The evolution of protege: An environment for knowledge-based systems development. Technical Report SMI2002-0943, Stanford Medical Informatics, Stanford University, 2002. [12] M. Gomez, C. Abasolo, and E. Plaza. Domain-independent ontologies for cooperative information agents. In Springer-Verlag, editor, Proc. Fifth International Workshop Cooperative Information Agents CIA-2001. Lecture Notes in Articial Intelligence, LNAI 2128, pages 118129, 2001. [13] J. S. Kowalik, editor. Coupling symbolic and numeric computing in expert systems. Elsevier Science Pbs., 1986. [14] Michael Luck and Mark dInverno. A conceptual framework for agent denition and development. The Computer Journal, 44(1):120, 2001. [15] St. Maruster, V. Negru, D. Petcu, and C. Sandru. Intelligent front-end for solving dierential and non-linear equations, revised and extended version. Journal of Mathematical Sciences, Plenum Pbs. Corp., 108(6):11391151, 2002.

15 [16] V. Negru, St. Maruster, and C. Sandru. Intelligent system for non-linear simultaneous equation solving. Technical Report Report Series, No. 98-19, RISCLinz, December 1998. [17] C. Sandru, V. Negru, and D. Pop. A multi-agent approach to a sales optimization application. In Proceedings of the 14th International Conference on Control Systems and Computer Science, Bucharest, Romania, 2003. [18] G. Schreiber, H. Akkermans, A. Anjewierden, R. de Hoog, N. Shadbolt, W. Van de Velde, and B. Wielinga. Knowledge Engineering and Management. The CommonKADS Methodology. The MIT Press, 1999. [19] J. F. Sowa. Representing knowledge soup in language and logic. Conference on Logic and Knowledge, June 2002. [20] L. Steels. Components of expertise. AI Magazine, 11(2):2949, 1990. [21] K. Sycara, S. Wido, M. Klusch, and J. Lu. Larks: Dynamic matchmaking among heterogeneous software agents in cyberspace, 2002. [22] G. Wickler and A. Tate. Capability representations for brokering: A survey. Submitted to Knowledge Engineering Review, November 1999. [23] G.J. Wickler. Using Expressive and Flexible Action Representation to Reason about Capabilities for Intelligent Agent Cooperation. PhD thesis, University of Edinburgh, 1999. [24] B.J. Wielinga, A. Schreiber, and J.A. Breuker. Kads: A modelling approach to knowledge engineering. Knowledge Aquisition, 4(1), 1992.