JColibri: An Object-Oriented Framework for Building CBR Systems

JColibri: An Object-Oriented Framework for Building CBR Systems
Juan Jos´e Bello-Tom´ as, Pedro A. Gonz´ alez-Calero, and Bel´en D´ıaz-Agudo Dep. Sistemas Inform´ aticos y Programaci´ on Universidad Complutense de Madrid, Spain {juanjobt,pedro,belend}@sip.ucm.es

Abstract. We present an object-oriented framework in Java for building CBR systems that is an evolution of previous work on knowledge intensive CBR [8, 9]. JColibri is a software artifact that promotes software reuse for building CBR systems, integrating the application of well proven Software Engineering techniques with a knowledge level description that separates the problem solving method, that defines the reasoning process, from the domain model, that describes the domain knowledge. Framework instantiation is supported by a graphical interface that guides the configuration of a particular CBR system, alleviating the steep learning curve typical for these type of systems.

1

Introduction

Developing a CBR system is a complex task where many decisions have to be taken. The system designer has to choose how the cases will be represented, the case organization structure, which methods will solve the CBR tasks and which knowledge (besides the specific cases) will be used by these methods. This process would greatly benefit from the reuse of previously developed CBR systems. Software reuse is a goal that the Software Engineering community has pursued from its very beginning [16]. From this effort a number of technologies have appeared that directly or indirectly promotes software reuse: object-oriented frameworks, component technologies, design patterns, domain analysis, software architectures, software product lines, model driven architectures, to mention just a few. Most of these technologies have been applied in those software domains where mass production is required and where reuse is a must. Unfortunately AI systems have remained for too long in the prototype arena and, in general, AI researchers do not worry too much about software engineering concerns. The most significant and long term effort within the AI community to attain effective software reuse is the KADS methodology [21] and its descendants: CommonKADS[4] and UPML[10]. The KADS approach for building knowledge based systems proposes the reuse of abstract models consisting of reusable components, containing artificial problem solving methods, and ontologies of domain models.


Supported by the Spanish Committee of Science & Technology (TIC2002-01961)

P. Funk and P.A. Gonz´ alez Calero (Eds.): ECCBR 2004, LNAI 3155, pp. 32–46, 2004. c Springer-Verlag Berlin Heidelberg 2004


JColibri: An Object-Oriented Framework for Building CBR Systems

33

Nevertheless, the main emphasis in KADS is the definition of formal specification languages for the components, a formal approach to Software Engineering that departs from the mainstream results in this area. In this paper we present JColibri, a framework for developing CBR systems. JColibri is a software artifact that promotes software reuse for building CBR systems, and tries to integrate the best of both worlds: the application of well proven Software Engineering techniques with the KADS key idea of separating the problem solving method, that defines the reasoning process, from the domain model, that describes the domain knowledge. JColibri is an evolution of the COLIBRI architecture [8], that consisted of a library of problem solving methods (PSMs) for solving the tasks of a knowledge-intensive CBR system along with an ontology, CBROnto [9], with common CBR terminology. COLIBRI was prototyped in LISP using LOOM as knowledge representation technology. This prototype served as proof of concept but was far from being usable outside of our own research group. JColibri is a technological evolution of COLIBRI that incorporates in a distributed architecture a description logics (DLs) engine, GUI clients for assembling a CBR system from reusable components and an object-oriented framework in Java. The rest of this paper runs as follows. The next section describes the highlevel organization of JColibri around tasks, methods and CBR terms. Section 3 describes the framework design, and Section 4 describes the framework instantiation process. Section 5 reviews related work and, finally, Section 6 concludes.

2

Knowledge Level Description

A useful way of describing problem solving behavior is in terms of the tasks to be solved, the goals to be achieved, the methods that will accomplish those tasks, and the domain knowledge that those methods need. A description along these lines is referred to as a knowledge level description [17]. JColibri is built around a task/method ontology that guides the framework design, determines possible extensions and supports the framework instantiation process. Task and methods are described in terms of domain-independent CBR terminology which is mapped into the classes of the framework. 2.1

CBR Ontology

Every CBR system makes use of CBR terminology, the type of entities that the CBR processes manage. A CBR ontology elaborates and organizes the terminology found in, ideally, any CBR system to provide a domain independent basis for new CBR systems. On this way, CBROnto [9] elaborates an extensive ontology over CBR terminology, the idea beyond this ontology is to have a common language to define the elements that compose a CBR system and to be able to build generic CBR methods independent of the knowledge domain. In JColibri the CBR ontology is not represented as a separate resource in a knowledge representation formalism such as OWL or LOOM. The CBR concepts, such as Case, CaseBase, SimilarityFunction, GlobalSimilarityFunction, LocalSimilarityFunction, Query, Method, or Task, are mapped into abstract classes

34

Juan Jos´e Bello-Tom´ as, Pedro A. Gonz´ alez-Calero, and Bel´en D´ıaz-Agudo

or interfaces of the framework. The is-a relations in the ontology are mapped into inheritance relations between classes and the part-of relations are mapped into composition of classes. This way, the classes representing concepts in the CBR ontology serve two purposes: – they provide an abstract interface for the CBR methods and tasks that can be developed independently from the actual CBR building blocks (case structure, case base organization, similarity functions, etc.), and – they serve as hooks where new types of CBR building blocks can be added. The CBR ontology is already populated in the framework with a number of pre-packaged realizations of the CBR abstract entities that can be extended for particular applications. 2.2

Task/Method Ontology

Within a knowledge level description, problem solving methods (PSMs) capture and describe problem-solving behavior in an implementation and domainindependent manner. PSMs are used to accomplish tasks by applying domain knowledge. Although various authors have applied knowledge level analysis to CBR systems, the most relevant work is the CBR task structure developed in [1] influenced by the Components of Expertise Methodology [20]. At the highest level of generality, they describe the general CBR cycle in terms of four tasks: Retrieve the most similar case/s, Reuse its/their knowledge to solve the problem, Revise the proposed solution and Retain the experience. Each one of the four CBR tasks involves a number of more specific sub-tasks. There are methods to solve tasks either by decomposing a task in subtasks or by solving it directly. In our approach we use the notion of task structure proposed in [5]. The task structure identifies a number of alternative methods for a task, and each one of the methods sets up different subtasks in its turn. This kind of task-methodsubtask analysis is carried on to a level of detail where the tasks are primitive with respect to the available knowledge (i.e. there are resolution methods). Figure 1 depicts the task decomposition structure we use in our framework. Besides this task structure, our framework includes a library of PSMs to solve these tasks. It describes CBR PSMs by relating them within the CBR ontology concepts representing the tasks and domain characteristics. PSMs in our library are organized around the tasks they resolve. We also need representing the method knowledge requirements (preconditions), and the input and output “types”. These characteristics are described by using vocabulary (i.e. concepts) from the CBROnto ontology.

3

Framework Design

A framework is a reusable, “semi-complete” application that can be specialized to produce custom applications [14]. Application frameworks are targeted at a given application domain providing the design for a family of applications within that domain. The design of the JColibri framework comprises a hierarchy

JColibri: An Object-Oriented Framework for Building CBR Systems CBR_TASK

35

CBR_TASK Retrieve

Reuse Copy_Solution

ObtainCases

Adapt_Solution

AssessSim AssessLocalSim

Select_Strategy

AgregateSim

Select_Discrepancy Modify_Solution Apply_Transformation Local_Revision

Select Retain Retain_Case Retain_Knowledge

Revise

Retain_retrieval_knowlege

Evaluate

Retain_reuse_knowledge

Repair

Fig. 1. CBROnto Task Structure

of Java classes plus a number of XML files. The framework is organized around the following elements: Tasks and Methods. XML files describe the tasks supported by the framework along with the methods for solving those tasks. Case Base. Different connectors are defined to support several types of case persistency, from the file system to a data base. Additionally, a number of possible in-memory Case Base organization are supported. Cases. A number of interfaces and classes are included in the framework to provide an abstract representation of cases that support any type of actual case structure. Problem Solving Methods. The actual code that supports the methods included in the framework. 3.1

Tasks and Methods

Tasks are the key element of the system since they drive the CBR process execution and represent the method goals. Tasks are just identified by its name and description included in an XML file like this: CBR Task Main CBR task Retrieve Task CBR case retrieval ...

36

Juan Jos´e Bello-Tom´ as, Pedro A. Gonz´ alez-Calero, and Bel´en D´ıaz-Agudo

Fig. 2. Method declaration

Tasks can be added to the framework at any time, although including a new task is useless unless an associated method exists. Method descriptions follow the XML schema shown in Figure 2. This elaborated description includes the following elements: Name The fully qualified name of the class that implements the method. This class must implements the CBRMethod interface. Description A textual description of the method. ContextInputPrecondition A formal description of the applicability requirements for the method, including input requirements. Type JColibri manages two types of methods: execution (or resolution) and decomposition. Execution methods are those that directly solve the task, for which has been assigned to, while decomposition ones divide the task into other tasks. Parameters Method configuration parameters. These parameters are the variable hooks of the method implementation. For example, a retrieval method may be parameterized with the similarity function to apply. A parameter can be any object implementing CBRTerm, which is the root class for the CBROnto mapping. Competencies The list of tasks this method is able to solve.

JColibri: An Object-Oriented Framework for Building CBR Systems

37

Subtasks In decomposition methods this element provides the list of tasks that result from dividing the original task. ContextOutputPostcondition Output data information obtained from this method execution. The information will be used to check which method can take as input the output of this one. As example we show here the description of the CBRMethod that implements the CBR Task by decomposing it in the 4 Rs processes. Notice how this description is coupled with task descriptions through the Competence and SubTask elements, and with the classes of the framework through the Name element, i.e., tasks with those names must have been included in the XML tasks file and a class with that name must exist in the framework. cbrarm.method.CBRMethod Main CBR method that will divide the CBR process in the four typical tasks. Decomposition CBR Task Retrieve Task Reuse Task Revise Task Retain Task ...

Building a CBR system with this framework (i.e., instantiating the framework) is a configuration process where the system developer selects the tasks the system must fulfill and for every task assigns the method that will do the job. The execution of the resulting CBR system can be seen as a sequence of method applications where a method takes as input the output of the previous one. Obviously, not every method applicable for a given task can be applied once the method that solve the previous task has been fixed. For example, it makes no sense to apply a voting mechanism to obtain the result in the reuse process if the retrieval one returns just one case. Apart from input/output constraints, method applicability can be also determined by more general constraints such as the requirement of a particular organization for the Case Base or the availability of a given type of similarity

38

Juan Jos´e Bello-Tom´ as, Pedro A. Gonz´ alez-Calero, and Bel´en D´ıaz-Agudo

Fig. 3. Pre/Post condition specification

function defined on cases. These requirements are expressed as context conditions which specification language is shown in Figure 3. The element ContextInputPrecondition in a method description describes the requirements that the application of the method impose on the input context, while the element ContextOutputPostcondition describes how the context is affected by the execution of this method. 3.2

Case Base

CBR systems must access to the stored cases in an efficient way, a problem that becomes more relevant as the size of the Case Base grows. JColibri splits the problem of Case Base management in two separate although related concerns: persistency mechanism and in-memory organization. Persistency is built around connectors. A connector represents the first layer of JColibri on top of the physical storage. Connectors are objects that know how to access and retrieve cases from the medium and return those cases to the CBR system in a uniform way. The use of connectors give JColibri flexibility against the physical storage so the system designer can choose the most appropriate one for the system at hand. Currently, JColibri implements three different connectors: – File system connector to retrieve cases stored in XML files. – JDBC connector that makes possible the use of JColibri with most of the DBs available in the market. – RACER connector that allows the designer to use RACER [11], a Description Logics system, as source for cases. The obvious interface for a connector must include methods to read the Case Base into memory and update it back into persistent media. An interface such

JColibri: An Object-Oriented Framework for Building CBR Systems

39

that assumes that the whole Case Base can be read into memory for the CBR processes to work with it. However, in a real sized CBR application this approach may not be feasible. For that reason, connectors in JColibri implements a more sophisticated interface that allows to retrieve those cases that satisfy a query expressed in a subset of SQL. This way the designer can decide when and what part of the Case Base is loaded into memory. The second layer of Case Base management is the data structure used to organize the cases once loaded into memory. The organization of the case base (linear, k-d trees, etc.) may have a big influence on the CBR processes, so the framework leaves open the election of the data structure that is going to be used. The Case Base is placed on top of the connector layer which serves to populate its storage structure. In the same way connectors offer a common interface to the Case Base, the Case Base also implements a common interface for the CBR methods to access the cases. This way the organization and indexation chosen for the Case Base will not affect the implementation of the methods. The implementations of the CaseBase interface must provide at least the following functionality: construct or append a case base from persistent media through a query to a connector, make the case base persistent, learn a case, forget a case, and retrieve the K nearest neighbors to a given case. These methods are parameterized with, for example, the query to access the connector or the similarity function to apply for similarity assessment. Apart from the common interface, certain data structures may support additional operations on the Case Base that specific methods can exploit. For example, retrieval based on conceptual containment requires a hierarchy of is-a concepts on top of the cases. In that situation the given method will only be applicable if the supporting Case Base organization has been selected for the CBR system at hand. The two-layers organization of the Case Base is a powerful approach that allows a number of different strategies for accessing the cases. A degenerate situation is one where all the operations are carried out through the connector, so that the Case Base is just a proxy for an external media. One of the key aspects of the COLIBRI approach to knowledge-intensive CBR was the use of already available ontologies to serve as indexes for the cases: cases are instances within a conceptual hierarchy that support sophisticated retrieval, adaptation and learning processes. Description Logics systems, such as RACER [11], are one of the leading technologies for ontology processing and reasoning, providing automatic classification and consistency checking. In JColibri, we support ontology-based CBR as a degenerate configuration of the two-layers approach: an external DLs system, RACER, is responsible for maintaining and giving access to the cases, while the Case Base in the CBR process memory is actually empty. 3.3

Cases

JColibri represents a case in a very general way. As shown in figure 4, a case is just an individual that can have any number of relationships with other individuals (the attributes of the case). The framework is populated with a number of

40

Juan Jos´e Bello-Tom´ as, Pedro A. Gonz´ alez-Calero, and Bel´en D´ıaz-Agudo SimpleIndividual

parents[]

target

Individual

RacerIndividual

IndividualRelation 0..*

CBRCase attributes

CBRCaseRecord

CBRCaseRacer

attributes

0..*

IndividualRelationRacer

Fig. 4. CBR Case representation

predefined primitive data types that support the definition of any simple case. This abstract settlement, inspired on the Composite design pattern, allows for a uniform treatment of arbitrarily complex case structures as long as they conform to the Individual related through IndividualRelation to other Individual. Figure 4 also shows a particular implementation of the CBRCase interface, namely CBRCaseRacer. This representation for cases is the one used when Case Base management is delegated to RACER, described in previous section, where cases are maintained externally and CBR processes must access them through a proxy that connects with the RACER engine. 3.4

Problem Solving Methods

It is out of the scope of this paper detailing the specific methods included in the framework, also considering that any list of implemented methods would be out of date as the framework keeps on growing. We are porting the methods previously included in COLIBRI, which are fully described in [7], and which have been published elsewhere. Apart from methods oriented to knowledge-intensive CBR in the line of our previous work, we are also including a growing list of standard CBR methods, needed to make JColibri an interesting framework for a bigger portion of the CBR community. The key features of the framework infrastructure for methods along the main CBR tasks: Retrieve. Retrieval methods are organized around the tasks ObtainCases, AssessSim and Select. Since obtaining the cases is delegated to the Case Base, the methods in this category are mainly responsible for assessing similarity by parameterizing retrieval functionality. A number of similarity functions are provided both for local and aggregate similarity. Framework design imposes that similarity functions must be associated to specific individual types, the abstract constituents of cases. Similarity functions can be further parameterized through the context of a particular system configuration.

JColibri: An Object-Oriented Framework for Building CBR Systems

41

Reuse. It is well known how hard is to provide generic methods for CBR adaptation. JColibri provides an abstract design where slot-based and case-based adaptation methods can be hooked, along with a number of simple methods for adjusting primitive type values that populate this abstract design. The framework also provides the infrastructure to connect a CBR system with Jess1 , the Java version of CLIPS2 . This way, a CBR system designer may define adaptation rules using the CLIPS formalism, and forget about the gory details of connecting to the Jess engine. Revise. Revision is not supported by the framework. Retain. Learning as the process of updating the Case Base is delegated to the concrete implementation of the Case Base. Adding and deleting cases is parameterized with retain and forget criteria specific to the given application. Different types of parameters for the problem solving methods are organized around the classes which map the terms in CBROnto, whose interfaces must be conform to, when extending the framework.

4

Framework Instantiation: Building a CBR System

JColibri is designed to easily support the construction of CBR systems taking advantage of the task/method division paradigm described in previous sections. Building a CBR system is a configuration process where the system developer selects the tasks the system must fulfill and for every task assigns the method that will do the job. Different types of CBR systems can be built using JColibri, from retrieval only to full featured 4 Rs systems. Ideally, the system designer would find every task and method needed for the system at hand, so that she would program just the representation for cases. However, in a more realistic situation a number of new methods may be needed and, less probably, some new task. Since JColibri is designed as an extensible framework, new elements will smoothly integrate with the available infrastructure as long as they follow the framework design. One of the biggest problems with frameworks is learning how to use them. Since reusable systems are inherently more sophisticated, framework design tends to be more complex than the design of just one shoot system. A system developer needs to know the framework design to a certain extent, at least to determine what classes must be instantiated in order to obtain a given functionality. A deeper knowledge of the framework is needed when extending it. In order to alleviate framework instantiation effort, JColibri features a semiautomatic configuration tool that guides the instantiation process through a graphical interface. This interface is dynamically built to reflect the actual contents of the task/method ontology, relying on the XML files describing task and method constraints and profiting from reflection facilities implemented in Java. 1 2

http://herzberg.ca.sandia.gov/jess/ http://www.ghg.net/clips/CLIPS.html

42

Juan Jos´e Bello-Tom´ as, Pedro A. Gonz´ alez-Calero, and Bel´en D´ıaz-Agudo

Fig. 5. JColibri configuration interface

Figure 5 shows the JColibri configuration interface. To the left is shown the task panel with the task tree. This tree shows the decomposition relations between tasks. To the right appears the task configuration panel where available methods for the given task in the given situation are provided. The configuration of a CBR system using this interface consists of the following processes: – Defining the case structure, the source for cases and the case base organization. – While the system is not complete, select one of the tasks without a method assigned, select and configure a method for that task. At startup the task tree has only one element, CBRTask, which is solved by a decomposition method that results in additional tasks. Task/method constraints are being tracked during the configuration process so that only applicable methods in the given context are offered to the system designer. – Once the system is configured, the configuration code is generated so that a running CBR system is available. The configuration tool also provides a default interface for running the configured CBR system although in a real settlement an application specific interface should be developed. The snapshot in Figure 5 corresponds to the configuration of a retrieval only system for the well known travel domain. In this example we are using RACER

JColibri: An Object-Oriented Framework for Building CBR Systems

43

Fig. 6. Racer case definition

as case container, and the small ontology shown in Figure 6 defines the structure of the cases. Using this ontology we have a set of cases that are constructed with instances of the different concepts. Cases are retrieved through the RACER connector that returns instances of the cbr case concept. Once the Case Base and the structure of the cases have been set, the task/method configuration has to be built. In this simple example, the resulting configuration would be: – CBRTask solved by CBRMethod that decomposes it in Retrieve, Reuse, Revise and Retain. For a retrieval only system we just associate a method with RetrieveTask, leaving the other tasks unsolved. • RetrieveTask solved by RetrieveComputationalMethod that decomposes retrieval in the following tasks: ∗ ObtainCasesTask solved by ObtainCaseBaseMethod that returns the whole Case Base. ∗ ComputeSimilarityTask solved by NumericSimComputationMethod that computes similarity between the query and the cases obtained by the previous task. ∗ SelectBestTask solved by SelectBestCaseMethod that selects the most similar case. Additionally to task/method selection, a number of method parameters have to be set. This may require to program supporting code to parameterize the methods, or, as is the case in this simple example, to associate available CBRTerms (i.e., classes) with certain parts of the configured system. In the example, the NumericSimComputationMethod requires similarity functions to be associated with the cases so that, for instance:

44

– – – –

5

Juan Jos´e Bello-Tom´ as, Pedro A. Gonz´ alez-Calero, and Bel´en D´ıaz-Agudo

duration is compared with the intervalSim function, season with a special purpose seasonSim function, destination is compared through equalSim, and the similarity of the cbr case is obtained through averageSim.

Related Work

Related to PSMs and ontologies we should mention the work on Prot´eg´e. Prot´eg´e is an ontology and knowledge-base editor that provides an extensible architecture for the creation of customized knowledge-based applications [6]. They have developed a methodology to construct knowledge systems that strongly relies on ontologies. The work here presented is closely related to this approach and we envision an evolution of JColibri that should integrate with Prot´eg´e. The IBROW project intends to provide an Internet-based brokering service for reusing problem-solving methods. The Unified Problem-Solving Method Description Language (UPML) [10] has been developed to describe and implement such architectures and components to facilitate their semi-automatic reuse and adaptation. The main drawback of UPML is that it is a highly sophisticated formal language whose complexity is not justified by supporting reasoning tools. In the Machine Learning community we can mention a number of efforts directed to building reusable libraries of ML methods. MLC++ [15], developed at Stanford University by Ronny Kohavi, provides a library of C++ classes to aid in the development of new ML algorithms, especially hybrid algorithms and multistrategy algorithms, providing implementations for ID3, nearest-neighbor, naive Bayes, lazy decision trees, etc. David Mount, from the University of Maryland has developed ANN [3], a library written in C++, which supports data structures and algorithms for both exact and approximate nearest neighbor searching in arbitrarily high dimensions. The machine learning group of the University of Waikato, New Zealand, has developed Weka [22] a public domain class library in Java that incorporates several standard ML techniques. Weka contains implementations of a number of algorithms for classification and numeric prediction. Weka also includes a number of data filtering techniques, and two clustering algorithms. In order to exploit these efforts from the ML community we plan to incorporate in JColibri interfaces to some of the aforementioned resources. In the CBR community, the work by Michel Jaczynski [12, 13] is closely related to the one presented here. CBR*Tools is an object-oriented framework, implemented in Java, designed to facilitate the development of CBR applications. They identify the following axes of variability: the delegation of reasoning steps, the separation of case storage and case indexing, the design of indexes as reusable components, and the design of adaptation patterns. The framework concentrates mainly on indexing, providing a large number of indexing alternatives. The key difference of JColibri with respect to CBR*Tools is the explicit model of task/method decomposition that imposes a high level architecture on top of the framework, facilitating framework use and evolution. However, in a certain sense, in CBR*Tools the knowledge level is also explicit as a part of its

JColibri: An Object-Oriented Framework for Building CBR Systems

45

UML-based model. Besides, JColibri incorporates a GUI for alleviating framework instantiation effort that is based on their task/method description (at the knowledge level). The architecture of Orenge (the Open Retrieval engine from empolis.com) [19] also is related to JColibri. Orenge has been designed as a component based platform. Building an application includes the selection and composition of required components. Its pipeline/pipelet structure is very similar to the PSMs paradigm. In the same way that JColibri, Orenge also provides access to databases and XML files. JColibri enhances Orenge regarding two aspects. First, the incorporation of DLs connection. And second, regarding availability, Orenge is a commercial system and it is not available for free. JColibri will be (soon) available to the CBR community as an open source project. Also closely related to JColibri, Plaza an Arcos [18] proposed a generic architecture for adaptation that has evolved into CAT-CBR [2], a component-based platform for developing CBR systems. CAT-CBR uses UPML for specifying CBR components and provides: a library of CBR components (currently for retrieval and for classification; reuse components are being developed); a language and a graphical editor to specify new components and a syntax to implement their operational code; a broker service allowing to specify the requirements of a target CBR application and the available models in a domain, and to search for a configuration of components that satisfy the requirements. CAT-CBR generates the “glue code” that binds together the operational code of the configured components into a stand alone application. The main difference between JColibri and CAT-CBR is a technological one. CAT-CBR is developed on top of the Noos framework, a monolithic Lisp system that can not compete with a Java based approach in terms of usability, extendibility and user acceptance.

6

Conclusions

We have presented an object-oriented framework in Java to build CBR systems. This framework is built around a task/method ontology that facilitates the understanding of an intrinsically sophisticated software artifact. A key aspect of this work is the availability of a semiautomatic configuration tool that facilitates the instantiation process. The framework implementation is evolving as new methods are included. We are already porting previously developed CBR systems into the framework and, once tested, will make it publicly available to the CBR community. Our (ambitious) goal is to provide a reference framework for CBR development that would grow with contributions from the community. This reference would serve for pedagogical purposes and as bottom line implementation for prototyping CBR systems and comparing different CBR approaches to a given problem.

References 1. A. Aamodt and E. Plaza. Case-based reasoning: Foundational issues, methodological variations, and system approaches. AI Communications, 7(i), 1994.

46

Juan Jos´e Bello-Tom´ as, Pedro A. Gonz´ alez-Calero, and Bel´en D´ıaz-Agudo

2. C. Ab´ asolo, E. Plaza, and J.-L. Arcos. Components for case-based reasoning systems. Lecture Notes in Computer Science, 2504, 2002. 3. ANN. http://www.cs.umd.edu/ mount/ANN/. 4. J. A. Breuker and W. Van de Velde. CommonKADS Library for Expertise Modelling: Reusable Problem Solving Components. 1994. 5. B. Chandrasekaran, T. Johnson, and J. Smith. Task structure analysis for knowledge modeling. Communications of the ACM, 33(8):124–136, September 1992. 6. M. Crub´ezy and M. A. Musen. Ontologies in support of problem solving. In S. Staab and R. Studer, editors, Handbook on Ontologies. Springer, 2004. 7. B. D´ıaz-Agudo. Una aproximaci´ on ontol´ ogica al desarrollo de sistemas de razonamiento basado en casos. PhD thesis, Universidad Complutense de Madrid, 2002. 8. B. D´ıaz-Agudo and P. A. Gonz´ alez-Calero. An architecture for knowledge intensive CBR systems. In E. Blanzieri and L. Portinale, editors, Advances in Case-Based Reasoning – (EWCBR’00). Springer-Verlag, Berlin Heidelberg New York, 2000. 9. B. D´ıaz-Agudo and P. A. Gonz´ alez-Calero. CBROnto: a task/method ontology for CBR. In S. Haller and G. Simmons, editors, Procs. of the 15th International FLAIRS’02 Conference (Special Track on CBR, pages 101–106. AAAI Press, 2002. 10. D. Fensel, E. Motta, F. van Harmelen, V. R. Benjamins, M. Crubezy, S. Decker, M. Gaspari, R. Groenboom, W. Grosso, M. Musen, E. Plaza, G. Schreiber, R. Studer, and B. Wielinga. The unified problem-solving method development language upml. Knowledge and Information Systems, 5(1):83–131, February 2003. 11. V. Haarslev and R. M¨ oller. Description of the racer system and its applications. In Working Notes of the 2001 International Description Logics Workshop (DL-2001), Stanford, CA, USA, August 1-3, 2001, 2001. 12. M. Jaczynski. Mod`ele et plate-forme ` a objets pour l’indexation des cas par situations comportementales: application a ` l’assistance ` a la navigation sur le Web. PhD thesis, L’Universit´e de Nice-Sophia Antipolis, 1998. http://wwwsop.inria.fr/axis/papers/thesemj/. 13. M. Jaczynski and B. Trousse. An object-oriented framework for the design and the implementation of case-based reasoners. In Proceedings of the 6th German Workshop on Case-Based Reasoning, 1998. 14. R. Johnson and B. Foote. Designing reusable classes. J. Object-Oriented Programming, 1(5):22–35, 1988. 15. R. Kohavi, D. Sommerfield, and J. Dougherty. Data mining using MLC++: A machine learning library in C++. In Tools with Artificial Intelligence, pages 234– 245. IEEE Computer Society Press, 1996. Received the best paper award. 16. M. D. McIlroy. Mass produced software components. In Proc. Nato Software Eng. Conf., pages 138–155, Garmisch, Germany, 1968. 17. A. Newel. The knowledge level. Artificial Intelligence, 18:87–127, 1982. 18. E. Plaza and J. L. Arcos. Towards a software architecture for case-based reasoning systems. In Foundations of Intelligent Systems, 12th International Symposium, ISMIS 2000, pages 265–276. Springer-Verlag LNCS 1932, 2000. 19. J. Schumacher. empolis orenge – an open platform for knowledge management applications. In M. Minor and S. Staab, editors, 1st German Workshop on Experience Management: Sharing Experiences About the Sharing of Experience, Berlin, March 7-8, 2002, Proceedings, pages 61–62. Gesellschaft f¨ ur Informatik GI, 2002. 20. L. Steels. Components of expertise. AI Magazine, 11(2):29–49, 1990. 21. B. Wielinga, A. Schreiber, and J. Breuker. Kads: A modelling approach to knowledge engineering. Knowledge Acquisition, 4(1), 1992. 22. I. Witten and E. Frank. Data mining: Practical machine learning tools and techniques with Java implementations. Morgan Kaufmann, San Francisco, 2000.