Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


6.1. CASE REPRESENTATION

How are cases defined and represented? There are many ways of representing a case, including predicate representations, frames, or even entries resembling database records. In general, there are three features that need to be captured: the problem-situation description, the solution, and the outcome. The problem-situation is essentially a description of the characteristics of the problem, the context, or situation in which it occurs. The representation must match the reasoning goals of the system. However, it is not always obvious what a case should be. A problem description may need to include features that are intermediary, or solution-in-progress. A description, after some reasoning, may need to be redescribed to reflect the situation more accurately (for example, the condition of a patient as the disease progresses). Most of the difficulty comes when information is time-based, or which changes over time. Current methods of representing cases are mostly static; how should the case representation be made dynamic in order to reflect changes? Should a situation be represented as one large monolithic case or distributed cases with portions related to each other? How can such distributed cases be retrieved and judged similar?


TABLE 2
Suitability of Tools for Different Categories of Applications
 
CBR express ESTEEM KATE 3.0 ReMind S3-CASE
 
Classification
    Prediction [closed diamond] [bullet] [closed diamond]
    Assessment [closed diamond] [bullet] [bullet] [bullet] [bullet]
    Help Desk [flower] [closed diamond] [bullet] [bullet] [bullet]
    Diagnosis [bullet] [closed diamond] [bullet] [closed diamond] [bullet]
    Data Mining [closed diamond] [closed diamond]
    In-process control [closed diamond] [closed diamond]
    Off-line Control [bullet] [bullet] [bullet] [closed diamond]
Synthesis
    Design [closed diamond]
    Planning
    Configuration [closed diamond] [closed diamond]
From Althoff, K.D., Auriol, E., Barletta, R., and Manago, M. (1996). A Review of Industrial Case-based Reasoning Tools. An AI Perspectives Report. Series Editor: Alex Goodall. With
permission.

An important problem to be addressed is the question of when to admit a new case as a new case and not as an adaptation of an existing case. In other words, what should be the extent of dissimilarity between two cases before they are considered to be two separate cases? Is it when they differ in sufficient number of features, or is it when they differ in significant features but differ significantly, or is it some combination of the two? Should there be a "metric of goodness" developed to decide whether a case is sufficiently different for being treated as a new case?

With the introduction of video clips as evidence in a court of law, it may also be time to start addressing the challenges of managing cases that are multimedia in nature. Questions such as "What aspects of a video?" are important to a case. Is there a significant segment in the video that alone is sufficient to be captured? When can one say that two video clips represent the same content or different content? Research in this direction may not yield immediate results since it touches upon the territory of making computers understand in a human manner, a problem that has not been successfully addressed even in a context-sensitive situation.

Another issue worth addressing is to understand whether it is important to know that a case was derived from another case. If such knowledge is important, then should such derived cases be handled as versions of the initial case? Also, should comparisons always be made with the original cases only, or should similarities tested against the derived ones as well? One may argue that it may be sufficient to test similarities against the most recent cases, as is normal in the fields of medicine and law. If such is a position, then one needs to address the potential pitfall of reaching the old case by modifying the most recent ones. In other words, how much of past cases need to be considered without worrying about reinventing some really old cases?

Although a number of CBR applications tend to represent and treat the structured information, it may be worthwhile to establish the goodness of the model chosen for representation of the features? Will the unstructured information left out from consideration for the purposes of either similarity calculation or indexing contribute to some false negatives and, if so, what impact is it likely to have on the application?

Another research issue might be to examine how the different clustering techniques would help in deciding which problem cases should become the new cases.


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.