Notes on Case-Based Reasoning

The fundamental intuition behind the "scruffy" informal symbolic approach to computational intelligence is that intelligence is a knowledge problem, not an algorithm problem. In other words, a representation problem, and not a logic problem.

The historical antecedents to this are:

  • the "frame" (slot, filler, inheritance) approach, from Minsky (note these are "semantic" structures in that concepts are connected by a relatively small (usually fixed) set of "relations"

  • the "semantic network" idea, from Quillian (note these were originally "associational" in that concepts are simply connected by some notion of "distance".

These ideas quickly merged into the commonly accepted idea of semantic memory being a collection of complex concepts connected by a schema of fairly primitive relations.

The first attempts to use these structures were in the area of Natural Language Processing

  • the formal versus informal contention actually started with the controversy around syntax versus semantics in NLP

  • conceptual dependency (Schank) and preference semantics (Wilks) were the two most visible approaches

  • the procedural semantics of Winograd was a related departure

The next innovation was the idea of a "script" (Schank and Abelson) which is a frame that captures a default sequence of events in a scene. The most famous being the "restaurant script".

  • scripts add value because they allow "prediction" and the associated notion of "expectation failure".

  • scripts are unique in being adopted as a cognitive model among psychologists

Scripts and the older idea of frames were then "generalized" to Memory Organization Packets (MOPs).

MOPs became the technique used to build "cases", leading to the idea of case-based reasoning.

Cases are complex structures (like frames) that generally encapsulate an instance of problem solving.

The idea is to encode a problem, and its solution, in terms of its relevant concrete and abstract features. The problem/solution are also usually captured in the form of a story.

To represent a case entails

  1. Knowledge acquisition of conceptual structure.
    This is achieved by interviewing experts and browsing standard documents

  2. Knowledge acquisition of cases of prototypical problem solving.
    This is achieved by the same procedure as above, plus sometimes data mining historical records of past problems, if such are available

  3. Knowledge analysis and knowledge representation design.
    This is an exercise in knowledge engineering (sometimes known as indexing), where the data are iteratively organized into taxonomies of conceptual and procedural knowledge: both concrete and abstract. The resulting structures, sometimes referred to as a "theory" of the domain, are used to represent cases

  4. An iterative procedure of

    • Knowledge structure building.
      The domain theory and prototypical cases are translated into objects (sometimes called Memory Organization Packets (MOPs); which are further imbued with problem-solving advice, and sometimes conversational networks, resulting in a case-library

    • Retrieval engine implementation and testing.
      This is a matter of implementing a case retrieval algorithm usually enlarging the case library as a consequence of use

  5. Interface design, implementation, testing, and evaluation.
    The user interface to the case-based system varies by application but usually supports questions, suggestions, and scripted interactions, sometimes with tutors visiting and remediating on the basis of retrieved cases

In the "reminding" phase of case-based reasoning, the usual procedure is to

  1. describe a "problem" case
    This is often done with form-filling or a simulated "fact gathering" interview or, most commonly, a combination of the two

  2. translation of "facts" gathered into features defined for the domain

  3. fairly simple algorithms to determine similarity with stored cases

  4. retrieval of the most relevent case(s)

Note, it is important to combine the notion of "raw" similarity with the necessity of finding matches at both a concrete and an abstract level.

To solve problems with case-based reasoning,

  • retrieved cases are presented and "discussed" somehow
    see question-based networks

  • further information is solicited by asking the user to evaluate the retrieved cases

  • acceptable cases are saved in memory

  • etc, etc.

Modified: 15Apr03; Contact: