agentdays.pdf

8/13/2019 agentdays.pdf

1/15

S C H E D A E I N F O R M A T I C A E

XXXXXXXXX VOLUME nn Year

Validating UPML Concepts in a Multi-Agent Architecture

Calin Sandru and Viorel Negru1

1 Department of Computer Science, West University of Timisoara, Bd. V. Parvan, 4,

Timisoara, 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 Unified

Problem-Solving Method Development Language (UPML), and proposes a

multi-agent architecture to support this approach. The paper first models an

applicative program, solving non-linear equation systems, using UPML con-

cepts 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 rea-

soning, knowledge based systems, non-linear equation systems.

1. Introduction

Many research efforts in Artificial Intelligence study how to model knowledge basedsystems (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 earlyidentified as being useful in describing a KBS [4].

The next step was to conceptually model KBSs by identifying various levels ofabstractions in their descriptions together with the relevant classes of informationused when representing knowledge in order to solve problems [20, 8].

As a contribution of the conceptual approach, KADS proposes a model of ex-pertise [24] and focus on finding ways to reuse knowledge. In this context, thelanguage 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 (Unified Problem-solving Modelling Lan-guage) [6] provide a coherent conceptual view on the problem solving process by


2/15

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 abovementioned components of expertise. The ontologies provides basic terms and re-lations for describing application domain, inference and tasks. In general, manydifferent ontologies are used in order to model a complex application. If, for exam-ple, the application domain and the inference procedures are not described in theterms of the same ontology, then some components are needed in order to adaptontological terms in such a way that the inference procedure may be applied on thespecific application domain.

UPML uses ontological bridges in order to solve the possible ontological differ-ences between various components of the expertise. When developing a new applica-tion the effort shifts from implementing new inference procedures to their reusabilityfrom existing libraries and to provide appropriate bridges in order to be able to effec-

tively apply the procedures in order to satisfy tasks in a specific application domain.Although not developed in a multi-agent context, in our view, the UPML ap-

proach could be adapted to a multi-agent environment by providing mechanisms inorder to:

view the inference procedures as agent capabilities and tasks as requests forexecuting 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 TaskOriented Problem Solver) which we applied to solve non-linear equation systems inan application called NESS (Non-linear Equation Systems Solver)[15].

An expert system for solving non-linear equation systems was developed atCarnegie-Mellon (Talukdar, 1983) [13]. The expert system supervise the applica-tion of three different numerical programs for solve some non-linear algebraicallyequation systems which cannot be solved with only one method. The choice is madein 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 tospecify 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 de-scription of the NESS solver in the UPML language. Consequently, in the section 3.,the NESS elements are expressed in terms of ontologies, domain knowledge, tasksand problem solving methods. The UPML adapters link all NESS components andrefine them as needed.

The section 4. describes the generic multi-agent architecture (MATOPS) capableto execute the problem solving methods described in the section 3. The MATOPS


3/15

3

environment provides elements to cope with different aspects of the UPML language

in a distributed solving context.In the section 5. we show how the generic architecture above is instantiated inorder to solve the NESS problems. Finally some related work and conclusion aredescribed.

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 toautomatically choose the most adequate numerical methods or to combine two ormore numerical methods for solving non-linear equations systems.

The methods for solving non-linear systems of equations have some certain intrin-sic characteristics (which do not generally depend on the particular system whichhas to be solved); such characteristics are crucial elements of the general solvingstrategy. There have also been developed special methods for certain classes ofproblems, having in view to use some particularities of the problems and to getenhanced performances by these means.

The characteristics of solving non-linear problems are the convergence rate, thecomputing effort per one iteration, the possibilities to exploit the sparsity and nu-merical stability.

Solving non-linear problems also involve a series of collateral extremely importantproblems; for example, choosing the initial iteration, error evaluation, possibility ofparallelization, the problem of finding 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 accountseveral external aspects: the form of the system, knowledge about a good iteration,structural characteristics (the quality of the Jacobian, condition number), etc. Otherelements who influence the solving process are: the precision, the memory space, theconvergence 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 first prototype NESS [16] was implemented in CLIPS 6.0 [5] expert systemshell. The graphics interface was developed in WxWindows. The task-orientedmodel was based on task structure which allows to make explicit reasoning andcontrol knowledge at different levels of abstraction [4, 16].

Tasks are organized on several levels according to the problem degree of ab-straction or the problem complexity. A high level task is more supple (modelling,


4/15

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 languageof subproblems) and it is a first approximation of the reasoning.

The (partial) tree of tasks is shown in figure 1.

System feature

determination

Compute

features

User

informations

Symbolic

transformation

Problem

formalise

DiagnosisModify

hypothesis

Instantiate

methodmethodSolving

construction

Problem

analyse

Problem

define

NESS

Rework reasoning

Figure 1.: A partial tasks tree of NESS solver

To solve a non-linear system of equations, we used a model which simulates ahuman experts reasoning. The model is similar to the solving paradigmsGenerate,Test, and Debug. In our case we used a meta-reasoning level which suppose thefollowing stages: construction, instantiation and diagnosis.

Constructionthe reasoning means finding a chaining of tasks and their associatedmethods, which - at the level of elementary tasks - is nothing else than a sequenceof calls to calculus routines or inference mechanisms (classification, inductive ordeductive rule-based mechanisms, etc). As result of this stage a graph of elementarymethods is obtained.

Instantiationmeans the realization of the formerly obtained tasks chaining (moreexactly: the execution of a path in the graph of elementary methods).

Diagnosis refers to the analysis of the intermediary and final results. It alsomeans - in the case of failure - establishing the causes of the failure (by use of causalknowledge) and reworking the reasoning.

NESS is able to determine the properties of the system of equations, based onthe problems description, and to propose candidate numerical methods based onthe characteristics of about thirty (which variants) implemented numerical methods.

The symbolic transformations refer to: the reducing of the terms of equations,


5/15

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 anon-linear part).If a method fails, the system (NESS) reworks the reasoning with (some) modified

parameters (discretization step, number of iterations, precision), a modified initialiteration or another numerical method (or combination of numerical methods). Forexample, if the conjugated gradient method fails, NESS can try to solve the problemwith the Steffensen method using the last iteration of conjugated gradient methodas initial iteration.

Concerning the numerical solving methods, the application implemented someclassical ones with high solving performances (Classic Newton, Discretized Newton,Secant, Steffensen, Parallel Lines, etc.) and some more recently designed (Broyden,Friedman, Conjugated Gradient, Successive Over-relaxation, Alternating DirectionsIteration, etc.), as well as special methods, generally useful for solving equations

with differences resulted from continuous problems discretization (for example, theequations with differences 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 formalismfor modelling the reasoning. A significant part of the NESS components (tasks,problem solving methods and ontologies) is presented in the figure 2.

At the upper part of the figure one can see the three main ontologies used fordefining the terminology for the application components. The NonlinearEquati-onSystems ontology, for example, defines terms used for the task SolvingNESandthe application domain. It defines terms like EquationsSystem, SystemPropertyand V ariableInstantiation or functions like eval allowing for the evaluation of aEquationsSystemon a V ariableInstantiation.

The NESSproblem solving method (PSM), in the middle of the figure 2, is themain application method intended to realize the task ApproximativelySolvingNES.This task is a refining of the task SolvingNES because it allows for an arbitraryprecision in the resulting solutions and thats why it imports terms defined in theontology called Approximation.

There is a relation in the figure 2 which deserves special attention. It concerns

the link between the Iterating task and the ChoosingIterationMethod task. TheIterating task is figured to be realized by the iterativeSolving method. In factthere are many iteration methods to be used in order to iterate on a function. Thesolution is to refine the iterativeSolvingmethod in order to obtain specific methodslike classicNewton, steffensenor conjugatedGradient.

There are many iteration methods in the mathematical literature, each hav-ing particular characteristics and each being appropriate for problems with specificproperties. Therefore, choosing a solving method for NESS problems is a non-trivialtask.


6/15

6

- bridge TD

000000000000000000000000000000000000000000111111111111111111111111111111111111111111

ApproximativelySolvingNES

- bridge TM

000000000000000000000000000000111111111111111111111111111111

SolvingNES

0 0 0 0 0 01 1 1 1 1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 01 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

000000000111111111

000000000000000000000000000000000000000011111111111111111111111111111111111111110000000000000000000000000000000000000000000011111111111111111111111111111111111111111111

00000000000000000000000000000000000000001111111111111111111111111111111111111111000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111 000000000000000000000000000000

000

000

000000000

111111111111111111111111111111

111

111

111111111

Approximation IterativeSolving

NESS

IteratingReadNES

GenerateNewIterations Stop

- task - PSM -domain - ontology

- choosing PSM task- refining

- ontology import - precondition task

Choos

ingIterationMethod

NonlinearEquationSystems

classicNewton ...

DOMAIN

ADI-KellogiterativeSolving

SolvingNonlinearEquationSystems

Figure 2.: NESS expertise components

Generally, the UPML language assumes that the method selection for a partic-ular task is based on the method competencies (preconditions and subtasks) andsome other method characteristics like the costs of applying the method, methodcommunication style, or statistical observations related to the methods execution [1].

As previously said, the NESS expert is performing a complex task in order tochoose methods and the traditional selection is not powerful enough. This is thereason why the ChoosingIterationMethod is called, before applying the traditionalrules, in order to select the best iteration method for the task. Indeed, adding sucha task implies creating bridges between the meta-ontology of the UPML language

and the domain ontologies.We call method choosing tasks the tasks like ChoosingIterationMethod. The

methods choosing tasks perform reasoning based on the domain knowledge andthis is precisely the main aspect differentiating them from the traditional UPMLbrokering algorithm. Indeed, the evaluation of a methods preconditions, consideredin UPML, could provide a mean to use domain knowledge in the process of PSMselection for a task, but this kind of evaluations are far from being as complex asreasoning effected into an expert system, for example. This is exactly the last typeof reasoning we promote by introducing dedicated tasks for choosing between PSMs.


7/15

7

4. Multi-agent Architecture

The main interest of this research is to define a multi-agent architecture to runagents acting in terms of tasks and problem solving methods. The starting pointis the UPML architecture. In the introductory section we identified three aspectswhich could make us view UPML as a base for a multi-agent system. We will discusseach of them in turn.

As a preliminary observation, the formal examples below are written in the Zlanguage [2]. This language is expressive enough to describe most of the details of acomputing system together with the possible operations, in a unified and consistentmanner. It usesschemasand schemainclusionin order to provide descriptions atdifferent 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 first aspect concerns viewing the inference procedures as agent capabilitiesand tasks as requests for executing capabilities. The descriptions in the previoussection revealed a hierarchy of solving components modelling the NESS solving pro-cess. If we look at the problem solving methods there are simple computing routineslike iterative solving methods but also complex inferences like the one choosing theiterative method to be used, task performed by a mathematical expert.

In the first case, there is a huge number of iterative solving methods which islikely to be implemented by different developers and accessible in dedicated envi-ronments like Computer Algebra Systems or libraries. It is indeed possible to viewrelated 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 toassign a dedicated agent for executing such a task. It is thus reasonable to view theproblem solving methods of the UPML model as being considered capabilities of aset of agents. The paper [23] argues that in this case tasks may become descriptionsto 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 toidentify inference actions performed by the agents. FIPA uses a similar notioncalled 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 theUPML operational description of a PSM and executes it. If we assign PSMs onagents, as argued above, a more real situation is one when the agent implements somePSM and this PSM should be accessible to other agents. In this case, the operationaldetails of the PSM are of no interest for calling agents. The only information neededin order to correctly access a PSM implemented by an agent is the PSMs competencedescription.

The language UPML provides support for describing input and output data,preconditions, postconditions and the accessed subtasks of a PSM. Many CDLs use


8/15

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 requestedtask. The result of a procedure execution is an error code (Success | Fail) and aset of output values:

AssignedCapability

name: Attributeroles: Rolespreconditions: P1 Formulapostconditions: P1 Formulasubtasks: P Taskcontrol: P rogramagent: MATOPSAgentexecuteOperationalProcedure: P rogram RequestedTaskResult seqActualRole

The third aspect is related to the facilitation of the agent capabilities. Thisis 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 triedto ontologically map input and output roles from the required task description and

PSM description. This is based on the existence of bridge adapters between theontologies describing terms in tasks and PSMs. Additionally, PSMs preconditionsare evaluated and the availability of the PSMs subtasks is checked as well as thepossibility to evaluate operational description terms and relations. The ontologicalbridges 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 thecase of NESS. In this case an expert system reasoning over the application domainknowledge is supposed to perform better by applying some selection rules over theproblem and methods properties. We pointed out above the need for method choosingtasks. These tasks focus on processing the application domain knowledge. We cansee 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 onto-

logical bridges and method choosing tasks. It is called BridgeLibrarianand offersservices to the Facilitator agent for capability retrieval and to ordinary agents inorder for these to be able to map tasks roles to capabilities input or output.

Retrieving capabilities are subject of the Facilitatoragent activities. For exam-ple, the following schema describes the facilitator retrieving appropriate capabilities(PSMs) for a specified task:


9/15

9

MATOPSFacilitator

MATOPSAgentagentsCapabilities: PAssignedCapabilitycapabilityRetrieval: AssignedCapabilityretrievalFunction: Task PAssignedCapabilityexecuteMethodChoosingTask: Task PAssignedCapability

capabilityRetrieval.agent.id= idcapabilityRetrieval.control = retrievalFunction task: Task

if( choosingTask: TaskbridgeLibrarian.hasChoosingTask(task,choosingTask)) then

Let (rawMethods== executeMethodChoosingTask(choosingTask)retrievalFunctiontask= {capability: AssignedCapability

capability rawMethodscapability agentsCapabilities(bridgeLibrarian.hasBridge capability task)}

else

retrievalFunctiontask= {capability: AssignedCapability|capability agentsCapabilities(bridgeLibrarian.hasBridge capability task)}

The agent is performing itself a method capabilityRetrieval in order to satisfya requested task with the goal of retrieving capabilities for a given task. The oper-ational procedure of this capability is described by the retrievalFunctionfunction.

PSM

...

TASK LAYER TASK LAYER

MATOPS AGENT INTERFACE AGENT

FACILITATOR

EXTERNAL SYSTEM

BRIDGE LIBRARIAN

CAPABILITY

... ...

CAPABILITY

Figure 3.: MATOPS architectural structure

Essentially, this function first tries to find method choosing taskspublished bysome agents having the goal to find PSMs for the task being facilitated. If no suchtask exists, the task capabilities are selected based on the existing bridges betweenthe requested task and the published capabilities. In the case a method choosingtask exists, it is performed and its results are filtered like in the previous case inorder to be sure that all the needed ontological mappings are available.


10/15

10

The figure 3 is showing several agent types and their relationship in the proposed

multi-agent system calledMATOPS(Multi-Agent Task Oriented Problem Solver).An ordinary MATOPS agent executes a set of capabilities. It publishes thecapabilities with the facilitator and interacts with the facilitator and the bridgelibrarian in order to execute a requested capability or to execute the subtasks of thecapabilities.

The category of interface agents, also presented in the figure 3, are exhibitingfunctions similar to an ordinary MATOPS agent but they have the role of inter-acting with an external system by translating the data format between MATOPSagents and external agents. They are of particular usage in the frame of the NESSapplication as illustrated in the next section.

5. Agents Operation on NESS

This section is dedicated to the way the multi-agent framework MATOPS could beused 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 mono-lithic systems like Computer Algebra Systems or to use solving methods situatedin libraries of mathematical methods, a multi-agent architectural model has someadvantages:

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 foradding solving procedures by including different solving environments into thesame application.

As illustrated above, various components of the NESS application may beimplemented using different technologies: the iterative solving methods maybe ordinary programs written in some particular language while the proceduredeciding which iterative method to use may be an expert system written insome expert system shell. Heterogeneity is better supported in multi-agentsystems than in mono-agent systems.

While modelling the NESS application using the UPML model, there are var-ious components of expertise which can be placed at the level of particular

agents. The language UPML uses bridges to link the components togetherand we showed how the facilitator and the bridge librarian agents may use andmanage the bridging information in order to select agent capabilities to solveparticular tasks.

When creating a multi-agent model for NESS, the first thing to do is to iden-tify the inference procedures to be used as agent capabilities. Some of them werepresented in the section 3. The second step is to identify the agents performing theinference procedures.


11/15

11

The figure 4 shows the essential MATOPS agents composing the NESS applica-

tion. The facilitator and the bridge librarian are omitted from the figure since theirrole was already described.

USER INTERFACE

readNES

NESS

printResults

NESS EXPERT

findSystemProperties

choosingIterationMethod

generateInitialIterations

NEWTON SOLVER

classicNewton

newtonIteration

INTERFACE TO

MATHEMATICA

multiplyMatrices

invertMatrix

MATHEMATICA

invert_matrix

multiply_matrices

Figure 4.: MATOPS agents used in NESS application

We identified the User Interface agent whose capabilities are related to userinteractions while reading problems and presenting solutions or algorithm evolution.This agent starts the solving process by issuing a request to theFacilitatoragent inorder to find the agent performing a capability to solve the task ApproximativelySol -vingNES.

The facilitator response indicates the locally available NESS method whichis then called. The NESS capability asks for executing its precondition taskReadNESand then to perform the iteration process. The Iterating task could berealized by many methods executed by solving agents like NewtonSolver,Steffen-senSolverand so on. There are as many solver agents as many distinct algorithmscould 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 theNESS Expertagent by the capability choosingIterationMethod.This task is called by the F acilitatoragent because The Iterating task was foundto have it as a method chooser task. The expert agent is the most pro-active one inthe system because, for example, it may decide when to abandon a solving methodand when to start a new solving method based on its evaluation about the solvingprocess state. In practice this is done by having each solvers performing a task ofthe NESSexpertagent at each execution cycle.

The figure 4 also presents a category of external agents, in this case a Mathematicasolver whose solving algorithms can be used depending on the problem properties.


12/15

12

In order to effectively use the capabilities of this component, the multi-agent system

is supposed to contain an interface agent for Mathematica which manage all theexternal 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 BridgeLibrarian agents in theMATOPSarchitecture are performing a similar role with the FIPADirectoryFacili-tator agent respectively the FIPA Ontology Agent. However, these agents are notnecessarily FIPA compliant since they are specialized to manage interactions in termsof the UPML concepts.

Related to the description of the MATOPS facilitator is the work on the IBROWproject [1]. For simplicity reasons, in our definition of the facilitator retrieval func-tion, we assume as being enough to check with the bridge librarian if there areontological mappings between task and methods. The work cited above analysis inmore details the process of ontological bridging and also some other issues like thepossibilities to configure or adapt problem solving methods for/to the desired tasks.

The proposed facilitator above is potentially similar with the IBROW brokerbecause it can use the results of this research, but it also copes with the new proposedfeature ofmethod choosing tasks. In this context, theBridgeLibrarianagent is usedto mainly provide two kind of information to the facilitator: the ontology mappingsand the assertions stating a task as being a choosing method taskfor another task.

Like in the RETSINA [21] framework, the overall MATOPS facilitation processis structured into a sequence of steps. But besides the filtering steps based on theontological characteristics of PSMs and their competencies, the MATOPS brokeringprocess is adding a filtering step based on choosing methods tasks and another step inorder to sort the PSMs based on their properties compared with the actual problemto 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 In-formation Mediator)[12]. In this multi-agent system, the facilitator is also managinga common problem solving library described in UPML. In our context, this approachis not suitable because any agent may posses particular descriptions of problem solv-ing methods and tasks to perform. This architecture does not cope with ontologicalbridges since it is assumed that all tasks and PSMs are described in a common on-tology. In particular, the NESS application proves that complex applications are notusually described using a common set of terms and acceptions. MATOPS considersa special agent, the bridge librarian, to cope with this kind of issues.


13/15


14/15

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 unified problem-solving method developmentlanguage upml. Knowledge and Information Systems, 5(1):83131, 2003.

[7] M. dInverno, D. Kinny, M. Luck, and M. Wooldridge. A formal specification ofdmars. In Rao Sings and Wooldridge, editors, Lecture Notes in AI,IntelligentAgents IV: Proceedings of the Fourth International Workshop on Agent Theo-ries, Architectures and Languages, volume 1365, pages 155176. Springer Ver-lag, 1998.

[8] D. Fensel, J. Angele, and R. Studer. The knowledge acquisition and representa-tion 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. Specification of the kqml agent-communication language. Technical report, The DARPA Knowledge SharingInitiative External Interfaces Working Group, 1993.

[10] FIPA. Fipa agent management specification.http://www.fipa.org/repository/bysubject.html, 2002.

[11] J.H. Gennari, M.A. Musen, R.W. Fergerson, W.E. Grosso, M. Crubezy,H. Eriksson, N.F. Noy, and S.W. Tu. The evolution of protege: An envi-ronment for knowledge-based systems development. Technical Report SMI-2002-0943, Stanford Medical Informatics, Stanford University, 2002.

[12] M. Gomez, C. Abasolo, and E. Plaza. Domain-independent ontologies for coop-erative information agents. In Springer-Verlag, editor,Proc. Fifth InternationalWorkshop Cooperative Information Agents CIA-2001. Lecture Notes in Artifi-cial Intelligence, LNAI 2128, pages 118129, 2001.

[13] J. S. Kowalik, editor. Coupling symbolic and numeric computing in expertsystems. Elsevier Science Pbs., 1986.

[14] Michael Luck and Mark dInverno. A conceptual framework for agent definitionand development. The Computer Journal, 44(1):120, 2001.

[15] St. Maruster, V. Negru, D. Petcu, and C. Sandru. Intelligent front-end for solv-ing differential and non-linear equations, revised and extended version. Journalof Mathematical Sciences, Plenum Pbs. Corp., 108(6):11391151, 2002.


15/15

15

[16] V. Negru, St. Maruster, and C. Sandru. Intelligent system for non-linear simul-

taneous equation solving. Technical Report Report Series, No. 98-19, RISC-Linz, December 1998.

[17] C. Sandru, V. Negru, and D. Pop. A multi-agent approach to a sales opti-mization application. In Proceedings of the 14th International Conference onControl Systems and Computer Science, Bucharest, Romania, 2003.

[18] G. Schreiber, H. Akkermans, A. Anjewierden, R. de Hoog, N. Shadbolt, W. Vande Velde, and B. Wielinga. Knowledge Engineering and Management. TheCommonKADS Methodology. The MIT Press, 1999.

[19] J. F. Sowa. Representing knowledge soup in language and logic. Conference onLogic 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 matchmakingamong 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 Reasonabout Capabilities for Intelligent Agent Cooperation. PhD thesis, University ofEdinburgh, 1999.

[24] B.J. Wielinga, A. Schreiber, and J.A. Breuker. Kads: A modelling approach toknowledge engineering. Knowledge Aquisition, 4(1), 1992.

agentdays.pdf

Documents