Ontology-Driven Development of Conversational CBR Systems *

Ontology-Driven Development of Conversational CBR Systems ? Hector G´omez-Gauch´ıa, Bel´en D´ıaz-Agudo & Pedro Gonz´alez-Calero Dep. Sistemas Inform´ aticos y Programaci´ on Universidad Complutense de Madrid, Spain email: {hector,belend,pedro}@sip.ucm.es

Abstract. Conversational CBR has been used successfully for several years but building a new system demands a great cognitive effort of knowledge engineers and using it demands a similar effort of users. In this paper we use ontologies as the driving force to structure a development methodology where previous design efforts may be reused. We review the main issues of current CCBR models and their specific solutions. We describe afterwards how these solutions may be integrated in a common methodology to be reused in other similar CCBR systems. We particularly focus on the authoring issues to represent the knowledge.

1

Introduction

Conversational Case-Based Reasoning (CCBR) has been proposed to bridge the knowledge gap between the users and the case bases in CBR systems. It means that if users are not able to give a well-defined problem description (query), the CBR system will not be able to find a similar and appropriate case. CCBR approaches are appropriate when users have vague ideas about their problems at the beginning of the retrieval process. The system guides the user to a better understanding of his problem and what aspects he should describe. CCBR provides the means to dialog and guide users to refine their problem descriptions incrementally through a question-answer sequence. Conversational CBR has been used successfully for several years but to build a new system demands a great cognitive effort on knowledge engineers and to use it demands a similar effort on users. While a lot of effort is being devoted to identify the problems related to building a new CCBR system from scratch, work on tool support and development methodologies for CCBR applications is still in its infancy. Different kinds of CCBR systems have proposed different approaches, issues and solutions. Our approach proposes defining ontologies that can be exploited by different CCBR applications. Many works share our goal:[16] to minimize the cognitive effort demanded on users to use the system successfully and on the knowledge engineers to build the system. In [18] it is pointed how the design and development of CCBR systems would greatly benefit from the existence of generic inference methods. ?

Supported by the Spanish Committee of Education (TIN2005-09382-C02-01)

These methods can be used to anticipate user needs and to reduce the amount of information that the user must provide (e.g., number of answered questions) prior to successful case retrieval [4, 9, 17]. There are approaches based on the definition of special relations among questions, such as causal or taxonomical relations [18]. Other approaches are based on the creation of inferencing rules used to control the conversation and to infer new answers from answers to other related questions [9, 3]. In the line of defining reusable and generic methods, Gu & Aadmodt [16] propose to decompose the selection of the most discriminative questions through several subtasks: feature inferencing, question ranking, consistent question clustering, and coherent question sequencing. Apart from the query formulation process there are works regarding other more specific aspects. We emphasize the study of user variability: to deal with user preferences [9]; to adapt to the level of expertise [10]; to consider the user temperament and current mood [11]; to introduce different conversation styles [28] and conversation strategies [13]; and to improve the case authoring bottleneck, i.e.: building case bases, by new tools and specific techniques [21]. The knowledge representation issue has an important role in most of the previous solutions. Most of the recent CCBR works tend to use a knowledge rich approach which includes general knowledge of the domain in ad-hoc representations [16]. In general, the diversity of applications generates many types of conversational systems with specific characteristics. Regarding to the domain task, we distinguish between diagnosis systems [16, 22], decision support systems [10, 3, 24], recommenders [9] and systems which justify their recommendations [27], generation systems that are capable of generating expressive musical performances with user interaction [5], design systems [20], interactive teaching of didactic methods [17], textual CCBR [26], and planning [24]. In order to deal with so different issues, our proposal is based on the idea that if we can formalize each issue separately and find a solution for each issue, we are able to find partial solutions incrementally until we cover the main issues. This way we keep very few inter-relations among different issues. To represent all these different issues and their inter-relations we use an ontologydriven approach to help designing different types of CCBR systems. Our framework COBBER [11] formalizes different aspects of conversational systems. We have defined CCBRonto, an ontology which has two layers: a meta-model and a content-model. The meta-model is where most of the reuse takes place. The meta-model includes the skeleton where we can define additional characteristics of CCBR systems, like tasks, methods, domain knowledge issues, representation formalisms (textual, graphics, multimedia), conversation issues (strategies, conceptualization), and user’s issues. We describe how we solve the user’s issues in [14] where we describe a model dealing with temperaments and emotions. In this article we have three goals: to propose the ontology-driven approach as a common methodology to integrate the diversity of CCBR types (Section 3), to present the CCBRonto ontology as a knowledge model to support the methodology (Section 4). And to show the model at work in a classic CCBR domain: a diagnosis/help-desk system (Section 5). In the same section we de-

scribe the conversation reasoning tasks which CCBRonto supports. They belong to COBBER [13], which includes other tasks not relevant to this article.

2

The Scenario

To illustrate this article we use a domain example, which is to design and develop a conversational help-desk system to solve problems about company management software. We have several sources of knowledge, such as documents and experts. In Figure 1 we depict the conversation with the ideal characteristics we want in our scenario. We want to reduce the Knowledge Engineering and cognitive efforts reusing other CCBR models, their static domain knowledge, tasks and problem solving methods. There are many CCBR systems but they are difficult to reuse because they have ad-hoc solutions for a particular domain. We look for a common knowledge representation model, which supports different CCBR types and domains with text, images and multimedia materials. This model should support different levels of abstraction and case sizes. The language we use should be formal and support the implementation at the same time. We need an incremental methodology to define CCBR systems and a knowledge model which supports the methodology. We want to design the system in a structured and incremental way, with no scalability problems for large domains. The model should have elements which guide us in the development process of the CCBR system, such as conversation basic structures –or skeletons–, task and method decompositions in hierarchies –or skeletons–. The system should keep a conversation which guides the user to formulate the query in an incremental way. In Figure 1 we see how the system asks questions to complete the query and to obtain the data to solve it. The user may answer only some questions and the system does the completion task. The system should decide which are the relevant questions to ask in the next cycle, e.g.: in the figure the sentence “deduces what information to show” indicates it. The system should avoid the repetition of questions and answers. Besides asking questions, the completion task should include several aspects: deductions, calculations and function executions. The system should deduce and calculate answers from previous answers, as depicted in Figure 1: the system deduces that the company type is “AA” because it corresponds to companies considered small, i.e.: 15 is the maximum number of employees and 1300 is the maximum benefit per employee in a year. If the system needs the “benefit by year”, the system should be able to calculate it, e.g.: in the figure the calculated answer is 12000. The system should be able to execute actions outside the CCBR system, such as displaying images or the execution of functions, e.g.: in the figure the IncomeTaxFormulaAA. The system should adapt the conversation to the user, i.e.: his domain expertise level, his preferences, his temperament and his mood. In Figure 1 there are two different paths of the conversation: example A for a novice user, where the indications (suggestions) are very basic and example B for an advanced user, where the indications are more conceptual, assuming that he knows better the

START A SESSION

--> CONTINUATION:

(User) (System) No, I don´t understand step-1 Please, describe your problem I need to see an image of the GUI for option 2 (User) I don´t know how to obtain my income Tax (system) (System) -Decides (with the USER CHARACTERISTICS ) I need several data to help you, -to adapt the answer to the user expertise Level, answer some of these questions: -what information to show: (suggestions) - What CompanyType? example a: NOVICE expertise Level (BAsic answer) - EmployeeNum? - Try to click on the “Money Menu” - BenefitByEmployee - Click on option 2 OR BenefitByYear? - Introduce your personal data (User) in the IncomeTaxFormulaAA The EmployeeNum is 12 and the BenefitByEmployee is 1000 (system) example B: advance expertise Level (More conceptual answer) -deduces CompanyType= AA - You have a small company, AA type -calculates BenefitByYear= 12000 - You need to type in personal data -decides what information to show:(suggestions) in the formula for small companies. You may use the IncomeTaxFormulaAA COMMON for xamples A & B: and the Tax Calculation Steps are, -ACtions: Display GUI Image for step-1: click on option 2 incomeTaxCalculation step-2: fill the total income -Are you satisfied with the solution? step-3:............. -decides which questions to ask: (User): Yes Do you understand step-1? -ACtions: executes IncomeTaxFormulaAA (system) This ends your session (as an example)

Fig. 1. The conversation example for our scenario: a help-desk domain.

domain concepts. The temperament and mood adaptation consists in treating the user in different way according to his current mood and temperament (this is described in [14].) In next sections we describe our approach which improve the issues described in the scenario.

3

The Ontology-Driven Development

Ontology Engineering [15] has similar difficulties to the Knowledge Acquisition and Representation fields of Knowledge Engineering. There are several methodologies to build ontologies [8], but we find limitations dealing simultaneously with diverse sources of knowledge, such as texts and experts, and to have a structured cycle of the development process. To overcome these limitations we developed a conceptualization methodology which includes, in a refinement cycle manner, the main guidelines of the current methodologies, Information Retrieval techniques and interviews techniques with experts. For details see a complete description in [12]. We focus this article on the application of the methodology to Conversational CBR systems. This is an overview of the proposed ontology-driven approach applied to develop a CCBR system. We perform several tasks: 1. To describe in a text format the domain and the problem to be solved. To decompose the description into a set of –prototypical– situations, each of

2.

3.

4.

5.

6.

them has a description of a problem and its solution. We need a vocabulary which represents each situation: to define relevant concepts (classes) and relations (properties) among them. See [12] for a description of techniques. To define the questions which are relevant to the situation and all their possible answers. To build a question hierarchy to help organizing the question sequence, which is the path to find the solution. To build the cases: each situation may need a set of related cases, which are defined at different level of abstraction, going from abstract general cases to their specific versions. Cases are independent, only related semantically by the questions and answers which describe the situation represented by each case. They can be represented graphically as a hierarchy or a network, but they do not have hardwire links among them. This design gives a lot of flexibility and creates several different possible conversation sequences driven by the answers of the user. This description is specific for our model explained in next sections. The designer performs three tasks for each case: – To assign which set of questions and answers define the specific situation represented by the case. – To define the solutions for that case (suggestions and actions.) – To link the questions to be asked in the next cycle (intentional questions.) To select one of the available case similarity methods from our model library of reusable problem solving methods (PSMs) or to build your domain specific method. To build or select from the reusable PSMs library the set of appropriated tasks and methods for the system type in development. To adapt the chosen tasks and methods to the domain. To define the queries to test the cases. To refine the cases. Experts supervise these tasks.

We claim that this approach reduces the cognitive effort in several aspects. We use a common vocabulary for the domain in a formal representation that supports the implementation. The ontology presents a global picture of the domain: concept taxonomies, explicit relationships or properties, tasks and methods. The ontology building process drives the analysis of the domain and its functionality. Ontologies based on Description Logics (DLs) have inference capabilities [6], which we describe in section 3.1. This feature simplifies the implementation of relations among questions, the inference and calculation of new answers. The definitions of relations and conditions are declarative and independent to the software (we use a standard reasoner), this simplifies an incremental development, re-engineering, prototyping and testing. Other works use ontologies in CCBR as well: they use in [23] the SERVO ontology, written in RDF language, as representation of the domain or metadata. Other use an ad-hoc representation similar to an ontology, e.g.: in [16], Gu and Aamodt use an Object-Level Knowledge Representation Model, part of the model reuse from CREEK [1]. The main differences between these approaches and our approach is that a Description Logics based ontology has built-in reasoning mechanisms and declarative conditions, which are easily updatable with

a standard ontology editor such as Prot´eg´e [19]. Both, the reasoning mechanisms and the declarative conditions are independent of the CCBR system. In the next section we introduce Description Logics. 3.1

Description Logics

Description Logics are considered one of the most important knowledge representation formalism unifying and giving a logical basis to the well known traditional approaches: Frame-based systems, Semantic Networks and KL-ONE-like languages; Object-Oriented representations; Semantic data models; and Type systems. In a DL, there are three types of formal objects: concepts and relations, and individuals. The first two types are descriptions with a potentially complex structure. It is formed by composing a limited set of description-forming operators. Individuals are simple formal constructs intended to directly represent objects in the domain of interest. Individuals may be recognized as concept instances, and related to other individuals through relation instances. DL’s reasoning mechanisms are based on: subsumption, which determines whether a description –concept or relation– is more general than another; and instance recognition, which determines if a individual belongs to a concept. This is performed by checking if the individual satisfies the asserted conditions of the concept definition. The instance recognition may be applied to check if a tuple of individuals satisfy some relations as well. Subsumption supports classification, i.e., the ability of automatically classifying a new description within a –semi– lattice of previously classified descriptions. We use this in our model for case description similarity. Instance recognition supports completion, which is the ability of drawing logical consequences of assertions about individuals. We use this to infer new answers from previous answers. Contradiction detection is used for descriptions and assertions about individuals. It completes the basic set of reasoning mechanisms provided by DL systems. We use these mechanisms in the retrieve phase as well. In the next section we describe how we use DLs based ontologies in our model.

4

CCBRonto: An Ontology for CCBR Systems

We define a knowledge representation model, CCBRonto, to support the methodology. CCBRonto is a DLs based ontology, which extends CBRonto [7]. CBRonto is our ontology to develop CBR systems. It has two main aspects: task-method decomposition and concepts which define the structure of domain knowledge. In this article we focus on extending the second aspect: the concept structure which supports the main functionality of the conversation mechanism. Figure 2 outlines our layered architecture where we integrate different types of knowledge: CBROnto provides CBR vocabulary for describing terms involved in the CBR problem-solving processes, while CCBROnto provides a conceptualization of the knowledge needed in a conversational CBR system. The use of

Domain independent

CBROnto

Question Model

Case Model

Domain Model

User Model

Skeleton Elements

[META-MODEL]

CCBROnto Content Elements

[CONTENT-MODEL]

Domain specific

Fig. 2. The specialization layers in our ontology approach

this organizing knowledge allows the CBR processes to have semantic information about the domain. CCBROnto helps to organize the domain knowledge within the cases. It has four interrelated models: the domain model, the case model, the question model, and the extended user model. We define cases using these models. In our models we have elements which are concepts and relations. The two bottom layers in Figure 2 are two different levels of our models: a meta-model with skeleton elements defines domain independent elements –written with squared thick font in next figures– and a content-model with content elements defines domain dependent concepts –written with round thin font in next figures– and extends the skeleton elements. Content elements include the individuals created for a domain –a diamond shape in next figures–. The skeleton elements give a structure to the domain elements. It is important to mention that our models are domain independent, but we describe them in the next sections using a the help-desk domain, presented in Section 2, for clarity purposes. For each model we describe only what seems more relevant to understand the whole approach. 4.1

The Question Model

In Figure 3 we describe the question model applied to the help-desk domain. There is a taxonomy of question types defined at different levels of abstraction. Questions have three roles: questions in the user query describe the problem to be solved; questions inside cases, as input slots –see hasActivatingQuestions and their expected answers hasConceptAnswerValuePairs in Figure 4–, describe the case itself for explanatory purposes in the case authoring phase; and questions inside cases, as output slots, guide the conversation in the next reasoning cycle. A question may belong to one or more cases. Once a question has an answer, all the cases associated to the question see the answer. The system only asks a question if the system retrieves the case and there is no answer yet. The system stores the answers in the user model to perform this process. Each question has semantic relations (properties) with other questions. We can declare explicitly any kind of relation among questions. Some are predefined, such as taxonomical, causal, temporal (before, after, simultaneous, mu-

Relations(PROPERTIES) Font Meaning: -Skeleton Elements -Content Elements

Concepts(CLASSES)

IntentionalQuestions DomainQuestion GettingInformationQuestion DirectQuestion WhatDomainKnowledgeLevel WhatHelpDeskLevel DiscoveringQuestion FindingOutUserMoodQuestion ModifingQuestion ChangingMoodQuestion ChangingSubjectQuestion SupportingQuestion .... AnswerConcept CompanyType EmployeeNum AnswerValue CompanyTypeValue CoTypeValueAA CoTypeValueAB EmployeeNumValue BenefitByEmployeeValue BenefitByYearValue

hasRelatedQuestions hasDirectionRelatedQ hasTemporalRelatedQ hasBeforeTempRelatedQ hasAfterTempRelatedQ hasSimultaneousTempRelatedQ hasCausalRelatedQ hasIsARelatedQ hasAnswerValue hasAnswerConcept

Instances(Individuals) DomainQuestion - What CompanyType? - EmployeeNum? - BenefitByEmployee? - OR BenefitByYear?

Asserted Conditions EmployeeNumValue see question model hasConceptAnswerValuePairs hasOutputSlots Instances(Individuals) DomainCase hasSuggestions hasIntentionalQuestions --> sEE Figure hasActions “conversation interaction”

Relations(PROPERTIES) HasActionDescription hasActionTask hasActionMethod

Instances(Individuals) Suggestion (a) Please, describe your problem (b) I need several data to help you (c) Use IncomeTaxFormulaAA (d) This ends your session, thank you

Instances(Individuals) ExecuteIncomeTaxFormula DisplayMoneyMenuGUIimage

Fig. 4. Case model: main components and their links with other models.

to rules among questions in other models [4]. The difference with our approach is the characteristics of DLs mentioned before. 4.2

The Case Model

We define a case skeleton with a set of domain independent concepts to simplify case authoring. In Figure 4 we show the most relevant elements of the case model. There are specialized case types for specific moments in the conversation, with fix values, such as InitialDomCase. It is used to start a conversation session with a welcome message. And there are other general types to use throughout the conversation. The input slots represent the description of the case. They include concepts to retrieve the case: if the system asks the ActivatingQuestions and obtains similar ConceptAnswerValuePairs of a case, the system retrieves the case. Cases have a set of output slots: – IntentionalQuestions: One important difference of our model in respect of the other systems is that we include references to the questions inside the cases. This mechanism discriminates which questions to ask in the next cycle and simplifies case authoring. – Suggestions are the solution to the problem. If the case is abstract, the solution is only partial. It needs to continue the conversation to get to the specific solution. Suggestions may have any kind of format to be displayed: text, graphics, multimedia. – Actions are operations to execute outside the CCBR system, e.g.: in our domain we have ExecuteFormula or DisplayGUIImage.

Font Meaning: -Skeleton Elements -Content Elements

Concepts(CLASSES) DomCaseBase DomCase --> See Case Model DomQuestion --> See Question Model DomConcept

Relations(PROPERTIES) HasDomCBname hasDomCBdescription hasDomCBobjectives hasDomCBallowedTasks hasDOmCBallowedMethods hasDomCases hasDomSimilarityMeasure

DomFormula IncomeTaxFormula Instances(Individuals) ITF-AA-15-1300 ITF-AB-50-2500

Fig. 5. Domain model main components and their links with other models.

4.3

The Domain Model

The domain model defines all the knowledge about the domain and includes the question and case models described in sections 4.1 and 4.2. The most relevant skeleton elements of the domain model are: DomainDescription, DomCaseBase, DomCase and a generic concept DomConcept – for auxiliary concepts, such as DomFormula–. The main element is the DomCaseBase concept. Besides its description and cases, it has the objectives of the case base and the possible tasks and methods which can be performed with it. The content elements are domain specific: cases, questions, tasks, methods, and other auxiliary concepts, such as the IncomeTaxFormula. Our domain model example is the composition of Figures 3, 4 and 5. 4.4

The Extended User Model

We define an extended user model to support some of the previously described tasks, those related to question-answer optimization and system adaptation to the user. The two main concepts for those tasks are UserExpertiseLevel and the SessionData which are depicted in Figure 6. We use UserExpertiseLevel for the task to adapt the conversation to the user domain expertise level, e.g.: level 1 is novice, level 2 is knowledgeable, level 3 is expert. Figure 7 and Section 5 describe the role of this concept, which is to select cases according to the complexity level. We use SessionData to optimize the question-answer process. If the user has already answered a question in the current or a previous session, the system does not ask again the same question. To support this task, the model stores the names of the visited domain cases and their questions and obtained answers –ConceptAnswerValuePairs of the case model in Figure 4–. Another task of the extended user model is to be able to anticipate user behaviors and answers. To support this task we use a temperament ontology. We can retrieve

Font Meaning: -Skeleton Elements -Content Elements

Concepts(CLASSES) User UserType

Relations(PROPERTIES) hasPersonalData hasPreferences hasUserExpertiseLevel hasUserType hasSessionData

Session Data

Personal Data

Instances(Individuals) User SmithUser

Relations(PROPERTIES) hasSessionDate hasCaseNames hasConceptAnswerValuePairs (See Case Model)

Instances(Individuals) Session Data Smith19022006Session

Fig. 6. User model main components.

similar users to the current user and their answers from previous sessions. For more details of this temperament ontology see the article [14].

5

The Model at Work

We extend the standard CBR cycle [2] to include the conversational issues but keeping all the original tasks. In a CCBR, the query definition and the retrieval tasks keep a short subcycle until the user agrees with the description and the retrieved answer. Then, he may need to continue with the next tasks: reuse, repair and retain. We define a control task to support the interactions among tasks and ontologies. This control task is in charge of calling the next task with the right knowledge. This is implemented in our prototype with an agenda, where each task, at the end of its execution, modifies the agenda according to its conclusions. In the prototype we use a blackboard implementation to transfer the correct knowledge –cases, questions and answers– among tasks. To perform the knowledge authoring task of the help-desk domain we have as domain sources: a set of manuals about the software to be supported with the help-desk system, and an expert with limited time for us. We follow the steps of section 3. The first step is to create a domain model with an ontology, which includes a question model with all kinds of relations and several levels of abstraction. We reuse the skeleton elements and specialize new content elements of our domain. In the next step we define the case base where each case is defined by a set of answers to some questions. And the third step is to get the tasks and methods. We create them or reuse them from a library, if there already are adequate tasks and methods available. Finally, after several refinements, we came up with the set of models described in previous sections. Figure 7 depicts the reasoning process of the system. We show three cycles. Previous to them there is a standard initial case to start the conversa-

-- CYCLE 3 --

-- CYCLE 2 --

Font Meaning: -Skeleton Elements -Content Elements USER: 12 1000

DEDUCED: AA

-- CYCLE 1 -Case189 Textual Description: “tax data .” INPUT SLOTS - incomeTaxCalculation OUTPUT SLOTS suggestions I need several data to help.. Intentional questions - What CompanyType? - EmployeeNum? - BenefitByEmployee? - OR BenefitByYear? .... actions

Case865 Case123 Textual Description: “bla bla..” Textual Description:“income..AA” -- CYCLE 3 A-- INPUT SLOTS INPUT SLOTS - NounderstandStep1= true - CompanyType = AA - UserExpertiseLevel = 1 - EmployeeNum < 15 - Image=yes - BenefitByEmployee