INTEGRATING CASE-BASED AND RULE-BASED …oucsace.cs.ohiou.edu/~marling/cbr_rbr.pdfINTEGRATING...

Computational Intelligence, Volume 15, Number 3, 1999

INTEGRATING CASE-BASED AND RULE-BASED REASONING TOMEET MULTIPLE DESIGN CONSTRAINTS

C. R. MARLING

School of Electrical Engineering and Computer Science, Ohio University

G. J. PETOT

Department of Nutrition, School of Medicine, Case Western Reserve University

L. S. STERLING

Department of Computer Science, University of Melbourne, Parkville, Victoria, Australia

Although case-based reasoning (CBR) was introduced as an alternative to rule-based reasoning (RBR), thereis a growing interest in integrating it with other reasoning paradigms, including RBR. New hybrid approaches arebeing piloted to achieve new synergies and improve problem-solving capabilities. In our approach to integration,CBR is used to satisfy multiple numeric constraints, and RBR allows the performance of “what if” analysis neededfor creative design.

The domain of our investigation is nutritional menu planning. The task of designing nutritious, yet appetizing,menus is one at which human experts consistently outperform computer systems. Tailoring a menu to the needsof an individual requires satisfaction of multiple numeric nutrition constraints plus personal preference goals andaesthetic criteria.

We first constructed and evaluated independent CBR and RBR menu planning systems, then built a hybridsystem incorporating the strengths of each system. The hybrid outperforms either single strategy system, designingsuperior menus, while synergistically providing functionality that neither single strategy system could provide. Inthis paper, we present our hybrid approach, which has applicability to other design tasks in which both physicalconstraints and aesthetic criteria must be met.

Key words: case-based reasoning, rule-based reasoning, multimodal reasoning, hybridization, knowledge-based systems, expert systems.

1. INTRODUCTION

Menu planning is both an art and a science.– Eleanor Eckstein

Since the 1960s, the goal of computer-assisted menu planning has been an elusive one(Eckstein 1978). The task of designing nutritious, yet appetizing, menus is one at whichhuman experts consistently outperform computer systems. Tailoring a menu to the needsof an individual requires satisfaction of multiple numeric nutrition constraints plus personalpreference goals and aesthetic criteria.

There are several related, but distinct, forms of menu planning. A “caterer,” such asJULIA, plans a single meal for the enjoyment of many guests (Hinrichs 1992). A restaurantowner plans a multichoice menu, allowing each customer to choose his own favorites, whileensuring that kitchen capacity, supplies, and personnel are adequate to implement the plan. Adietitian in a hospital or community outreach program designs a menu for a single individual,taking dietary requirements and personal preferences into account. We focus on planningmenus of the last type. Our experts are nutrition professors in Case Western Reserve Univer-sity’s School of Medicine. We aim to provide practical assistance to those who, for medicalreasons, must adjust their daily diets.

Address correspondence to C. R. Marling, School of Electrical Engineering and Computer Science, Ohio University,Athens, OH 45701; e-mail:[email protected].

c© 1999 Blackwell Publishers, 350 Main Street, Malden, MA 02148, USA, and 108 Cowley Road, Oxford, OX4 1JF, UK.

INTEGRATING CASE-BASED AND RULE-BASED REASONING 309

It takes a nutritionist from thirty minutes to three hours to plan a daily menu man-ually for an individual. Dozens of nutrients and thousands of foods may be involved.The more nutrient constraints there are, the harder it is to plan a menu the individualwill find acceptable. A recent study found that even professionally designed and pub-lished menus may fail to meet all nutrient constraints (Dollahite, Franklin, and McNew1995).

There are at least three factors which make nutritional menu planning difficult. First,there are many numeric constraints, some of which conflict with others. For example, ifyou cut back on red meat, in accordance with the Dietary Guidelines for Americans (U.S.Department of Agriculture 1995), it becomes hard to meet the minimum daily requirementfor zinc set forth in the Recommended Dietary Allowances (Food and Nutrition Board 1989).Second, the constraints are not constructive in nature. They allow you to evaluate a menu,but they do not specify how to produce a good menu. Furthermore, it is not possible tofully evaluate a menu before it is entirely constructed. A nutritionist does not evaluatemenus on a food-by-food or meal-by-meal basis. The goodness of having egg salad forlunch depends on how much cholesterol is present in the rest of the menu. Third, thereis a large amount of common sense involved. There is asensethat some meals appealwhile others do not. There is a sense that some foods go together (e.g., roast turkey withstuffing), and a sense that some foods do not (e.g., roast turkey with ketchup and pickles).Early automated menu planners made nonsensical proposals, such as eating a single car-rot stick, drinking a gallon of lemonade, or having chocolate-covered almonds and stewedtomatoes for breakfast (Sterling et al. 1996) though the menus may well meet nutritionconstraints.

We have developed an integrated system to design a daily menu for an individual inaccordance with accepted nutrition guidelines and aesthetic standards for color, texture, tem-perature, taste, and variety. We did this through a systematic study of independent case-basedreasoning (CBR) and rule-based reasoning (RBR) systems built to perform the same task. ACBR system solves new problems by finding, adapting, and reusing the solutions to previouslyencountered problems (Riesbeck and Schank 1989; Kolodner 1993). An RBR system solvesnew problems by drawing inferences from rules that embody problem-solving knowledge.We constructed and evaluated CBR and RBR nutritional menu planners, then used the resultsof our analysis to design and implement a hybrid.

In our hybrid system, CBR enables satisfaction of multiple numeric constraints, and RBRfacilitates creative menu design through interactive “what if” analysis. The hybrid systemoutperforms either single strategy system. It provides a framework for planning specialpurpose menus needed to prevent, control, or treat a variety of medical conditions. Webelieve our approach to integration will also prove useful in other design domains in whichnumeric constraints and aesthetic goals must be met.

Our systems, described in Sections 1 and 2, are the CAse-based Menu Planner (CAMP)and the Pattern Regulator for the Intelligent Selection of Menus (PRISM). The two systemshave identical problem statements and the same domain experts, but their implementationsare independent. Each system is intended for use by a qualified nutritionist, in consultationwith an individual. A nutritionist would use the system to assist an individual who mustlearn to adjust his or her diet to constrain intake of calories, fat, sodium, calcium, protein,cholesterol, or other nutrients. To focus on the most critical aspects of the task, we makethe simplifying assumption that the individual is an essentially healthy adult who can afford,obtain, and prepare the recommended foods. We compared and contrasted CAMP and PRISMto identify the strengths and weaknesses of each. Then, we combined the best of both systemsin a hybrid system, CAMP Enhanced by Rules (CAMPER). This system is described inSection 3.

310 COMPUTATIONAL INTELLIGENCE

2. THE CASE-BASED MENU PLANNER (CAMP)

CAMP is a “pure” case-based reasoner. As much knowledge as possible was kept directlyin cases, so as not to overlook opportunities or gloss over shortcomings of CBR in ourdomain.

2.1. The Case Base

The heart of a CBR system is its case base. CAMP’s case base holds 84 daily menus, eachobtained from a recognized nutrition source and reviewed by our experts for adequacy. Thesecond author modified menus as needed to ensure that each one conforms to the ReferenceDaily Intakes (RDIs) as determined by the Food and Drug Administration (1993) and theDietary Guidelines for Americans, while also meeting aesthetic standards. Each case containsa “good” menu, at least for some individuals. Because individuals vary in their tastes andnutrition needs, no one menu is good for all individuals.

In a CBR system, a case contains a past solution and the features that indicate whenthe solution is likely to be useful again. A solution in CAMP is a daily menu. Featuresthat indicate a menu’s usefulness are: its nutrient vector, the types of meals and numberof snacks included, and included foods. A representative case, based on a menu from theAmerican Dietetic Association and the U.S. Department of Agriculture (1982), is shown inFigure 1.

2.2. System Operation

CAMP operates by retrieving and adapting daily menus from its case base. A flowchart for CAMP is shown in Figure 2. An individual’s calorie level and any optional nu-trition and personal preference criteria are input first. Nutrition criteria are added to en-sure that the RDIs are met. Pennington indicators, as described in Pennington (1976),are used for this purpose. The menu best suiting the criteria is retrieved from the casebase.

2.3. Retrieval

A reusability metric is used to select and retrieve a case based on the ease of adapt-ing it to meet current goals. Before a case can be reused in CAMP, it must be adapteduntil it meets all user-specified constraints, plus additional constraints imposed as mini-mum RDIs. To find the best case, CAMP checks each case against all constraints. Anycase meeting all constraints constitutes an exact match and is retrieved. When a casedoes not comply with a constraint, a penalty score is assigned based on how difficult itwould be to bring the case into compliance. The penalty scores were determined throughconsultation with the expert and refined through trial and error. CAMP finds the casethat is easiest to adapt, striking a balance between the number and severity of constraintviolations.

Early CBR systems, such as HYPO (Ashley and Rissland 1988) and CHEF (Hammond1989), relied on similarity as the primary indicator of case utility. More recent systems, suchas Deja Vu (Smyth and Keane 1995a) and TOVE (Bilgic and Fox 1996), rely on ease ofadaptation and compliance with constraints, as does CAMP. CAMP’s retrieval algorithm isshown in Figure 3. The top level algorithm for the reusability metric is shown in Figure 4.


FIGURE 1. A representative case in CAMP.

A detailed account of case retrieval in CAMP is available in Marling, Petot, and Sterling(1996a).

2.4. Adaptation

If the best case, as determined by the reusability metric, is not an exact match, it isadapted until it complies with any unmet constraints. Adaptation is generally consideredto be the most difficult part of CBR, and Ralph Barletta declared, at the Second EuropeanWorkshop on CBR, that it ought to be avoided altogether due to its complexity. Intentionallyor not, this seems to have spurred interest in research on case adaptation (Hanney, Smyth,and Cunningham 1995; Voss 1996). The primary case adaptation methods are substitution,


FIGURE 2. A flow chart for CAMP.

FIGURE 3. CAMP’s retrieval algorithm.

transformation, and derivational analogy (Kolodner 1993). In substitution, replacements arefound for parts of an old solution which do not suit current needs. In transformation, individualcomponents of an old solution are modified to suit the current problem. In derivationalanalogy, as exemplified by PRODIGY/ANALOGY (Carbonell and Veloso 1988), an oldproblem-solving method, rather than an old problem solution, is reused. CAMP employssubstitution and transformation during adaptation.


FIGURE 4. CAMP’s reusability metric: Top level.

CAMP’s adaptation framework, based on our expert’s manual approach to adaptingmenus, is as follows:

1. Check the number of snacks. Adjust, if necessary.2. Check meal types. Swap meals to accommodate preferences, if necessary.3. Eliminate any forbidden food items.4. Check calorie level. Adjust serving sizes, if necessary.5. Fix any nutrient specific deficiencies.

Meal level and food level adaptations are made before nutrient level adaptations. Froma nutritionist’s perspective, this order of adaptation avoids rework, as later modificationsare designed not to undo the effects of earlier ones. From an AI perspective, it helps tomaintain global consistency during adaptation. The highest level adaptations are made toaccommodate personal preferences. For these adaptations,snippets, as first described inRedmond (1990), are used. In CAMP, snippets are parts of other reusable menus. They maybe whole meals or parts of meals, such as dishes or individual foods. For example, when anadditional snack is needed, it is obtained from another case rated as highly reusable by thereusability metric. When a menu contains a food the user has asked to exclude, a substitution


may be found among foods serving the same role in other reusable menus. Using wholemeal snippets is most advantageous, because aesthetic qualities such as color combinations,textures, temperatures, shapes, and compatible flavors are maintained. Snippets have naturalanalogs in manual menu planning. Both the American Diabetes Association (1989) andWeight Watchers, International (1994) promote a mix-and-match meal approach to planningmenus.

Adaptation to meet nutritional needs does not employ snippets, but is wholly rule-governed. The adaptation rules used by CAMP are like those commonly used in CBR systems,and are distinct from those used later by the hybrid system. CAMP takes the same approachas expert human menu planners. It adjusts calorie level first, then makes nutrient-specificadjustments that do not impact the established calorie level.

Calorie level is adapted by adjusting serving sizes. Our expert prefers not to add orremove foods from menus, except as a last resort, because this upsets overall balance andmenu structure. Calorie adjustment is a difficult problem for nutritionists, and CAMP’ssolution was rated highly by nutritionists during system evaluation. Published menus oftenomit serving sizes to avoid the issue, but precise quantities are necessary for nutritionalanalysis. Early menu planning systems sometimes suggested unusual or impractical servingsizes, such as 0.599999 tablespoons of butter. To implement the calorie adjustment strategy,small, medium, and large serving sizes were established for every food in every case ofCAMP. A potential problem, which we were able to avoid, is that the same food in a differentcontext may have different small, medium, and large serving sizes. For example, when bakedbeans are served as a side dish next to a pork chop, a smaller amount is served than if the beansare the main dish in a vegetarian meal. In CAMP, a case provides the context in which eachfood is used. Our 84 cases contain a total of 540 different foods-in-context. Our database offoods includes multiple entries for each food used in multiple contexts.

CAMP’s database plays two roles in case adaptation. First, it maintains the small,medium, and large serving sizes for each food, used to adjust serving sizes. Second, itmaintains the nutrient vector for each food, used to calculate the effects of making changesto the menu. The nutrient data in CAMP’s database was primarily obtained from the USDASurvey Nutrient Data Base, Release 7 (Haytowitz 1995).

The adapted menu becomes the system output. Figure 5 shows a representative menuplanned by CAMP. The menu shown was constrained by the user to include one snack, a totalof 1800 to 2200 calories, at least 800 mg of calcium, and no more than 30% of calories fromfat. It provides one snack, 2109 calories, 1557 mg of calcium, and 26% of calories from fat,meeting all constraints.

A demo version of CAMP is available on the World Wide Web at: http://pearson.cwru.edu/camp.

3. THE PATTERN REGULATOR FOR THE INTELLIGENT SELECTION OFMENUS (PRISM)

PRISM, the rule-based menu planner, performs the same task as CAMP in a differentway (Kovacic 1995). PRISM superseded an earlier RBR system, the Expert System on MenuPlanning (ESOMP) designed by Yang (1989). ESOMP planned menus for patients on aseverely restricted low protein diet. PRISM expands on ESOMP by planning menus for awide range of dietary requirements. To do this, PRISM relies on menu and meal patterns. Adaily menu pattern takes the form:

breakfast optional-snack lunch optional-snack dinner optional-snack


FIGURE 5. A menu planned by CAMP.

Each meal within the menu pattern may fit one of several patterns. PRISM’s algorithm forplanning a meal, given a pattern, is shown in Figure 6. Ago-with food, as used in Figure 6, issomething a person normally expects to eat with another food. For example, butter and jellyare go-with foods for bread, at least in the American heartland.

PRISM’s approach to menu creation is one of generate, test, and repair. A daily menuis initially generated by successively refining patterns for meals, dishes, and foods, fillinggeneral pattern slots, such asbreakfast bread dishwith specific foods, such as1 slice ofcinnamon raisin toast with 1 teaspoon of margarine. A multilayered hierarchical structure,relating meal parts to each other, was implemented to ensure that each meal conforms tocommonsense expectations for the form of a Western meal. At the implementation level,this structure consists of four databases, containing meal types, dish types, food types, andfoods. At the conceptual level, the structure can be viewed as a four-layered network ofnodes connected by arcs defining relationships. Arcs are unidirectional, and may connecttwo nodes within a layer, or a node in one layer to a node in an adjacent, more specific,level. An example relationship within a layer is: acontinental breakfastis one type oflightbreakfast. An example interlayer relationship is: acontinental breakfastincludes abreakfastbread dish. PRISM’s hierarchical structure is illustrated in Figure 7.


FIGURE 6. PRISM’s meal planning algorithm.

Another view of PRISM’s initial menu generation process is that the multilayered net-work implements a context-free grammar for the production of well-formed menus. Exampleproduction rules of this grammar are:

〈breakfast〉 −→ 〈light breakfast〉 | 〈heartybreakfast〉〈light breakfast〉 −→ 〈continentalbreakfast〉 | 〈cerealbreakfast〉〈continentalbreakfast〉 −→ 〈breakfastbreaddish〉〈breakfastbeveragedish〉 |

〈juice dish〉〈breakfastbreaddish〉〈breakfastbeveragedish〉〈breakfastbreaddish〉 −→ 〈muffin dish〉 | 〈quick breaddish〉 | 〈toastdish〉〈muffin dish〉 −→ 〈muffin food〉 | 〈muffin food〉〈muffin spread〉〈muffin food〉 −→ corn muffin | branmuffin | blueberrymuffin

After a menu is generated in compliance with both user specifications and commonsenseexpectation as to form, it is tested to see if it meets nutritional constraints. Because nutritionconstraints are not context-free, they cannot always be built into the menu up front, so repairis often necessary. Repair, in PRISM, is a backtracking process in which new foods, dishes,or meals are substituted for those found to be nutritionally lacking. The PRISM implementorhas noted that repair is most likely to be successful when the original menu comes close tomeeting constraints. When the original menu did not meet constraints, early PRISM couldchurn nonproductively, correcting one nutritional deficiency only to create another. PRISMnow always produces a menu within reasonable time limits, but not always one that meets allconstraints.

After PRISM generates a menu, it displays it, and then allows the user to perform “whatif” analysis. The user can choose to delete foods from and add foods to the menu. PRISMkeeps a running total of the effects on the nutritional value of the menu. This allows a user toevaluate trade-offs: if he wants a chocolate milkshake, then he can learn what else needs tochange in his daily menu to accommodate it. In practice, a nutritionist can use this analysisfor educational purposes and to better satisfy individual preferences.


FIGURE 7. PRISM’s hierarchical structure.

A menu designed by PRISM, to meet the same constraints as the menu shown in Figure 5,is shown in Figure 8. This menu provides one snack, 1982 calories, 27% of calories from fat,and 735 mg of calcium. It meets the snack, caloric, and fat constraints and nearly meets the800 mg minimum for calcium.

4. THE CBR/RBR HYBRID

CAMPER was built to synergistically combine CAMP and PRISM. The two systems wereevaluated, and their strengths and weaknesses were identified. In the first phase of evaluation,the systems were tested on a wide variety of test cases, designed to produce different kinds


FIGURE 8. A menu planned by PRISM.

of menus. Testing for nutrition constraints was straightforward, as numeric constraints areclearly either met or unmet. Expert opinion was the yardstick for measuring how well systemoutputs met aesthetic criteria. This type of evaluation was ongoing and iterative. Systemoutputs were reviewed with an expert, and problems were corrected as they were identified.For CAMP, this meant adding new cases to improve system coverage. For PRISM, this meantrefining the rule set. In the next phase of evaluation, feedback was solicited from practicingnutritionists and from nutrition students who had recently been taught how to plan menusmanually. Evaluators were asked to use the systems and to complete questionnaires. Bothsystems were deemed to successfully generate useful menus, but they were found to havedifferent strengths and weaknesses. An account of the system comparison is presented inMarling and Sterling (1996).

CAMP’s biggest advantage is its ability to satisfy multiple nutrition constraints. It iseasier to find a menu that nearly meets all contraints and to modify it than to create such amenu from scratch. PRISM can use context-free rules to form aesthetically pleasing menus,but it cannot determine the nutritional validity of a menu before it is fully planned, as nutritionconstraints are not context-free. This delayed evaluation forces a reliance on backtrackingand menu repair. Because repairing one problem may create another, PRISM can satisfyfewer constraints at once than CAMP.

PRISM’s biggest advantage is its creative flair. It has more than 1200 foods in its databaseand it can combine them in a wide variety of ways. Its “what if” analysis capability also allowsusers to propose and evaluate their own creative food combinations. “What if” analysis is a


useful thinking process, not easily supported by CBR, with its alternate emphasis on “whatdid.” Although research in extending the CBR paradigm to support more creative design isunderway (Wills and Kolodner 1996), CBR systems are presently good at remembering oldsolutions that can be reused, not at considering new possibilities. New possibilities are highlyvalued in this domain, where today’s perfect menu becomes tomorrow’s leftovers.

We also found that designing a menu from scratch is a more complex process thanretrieving and adapting one, primarily because of the large amount of common sense requiredin menu planning (Sterling et al. 1996b). The expert provided a rule, for example, thatbreakfast should include two fruit exchanges, and expected PRISM toknowthat these shouldnot be half a cup of orange juice and half a cup of apple juice. Representing common sense,as PRISM does, is still a grand challenge for AI. On the other hand, the common senseof an expert nutritionist is already embedded in each of CAMP’s menus. CAMP can neverretrieve an implausible menu. It need only guard against introducing bad combinations duringadaptation.

We considered the effort involved in knowledge engineering, but were unable to concludethat either approach offered a significant advantage. Although it has been claimed that CBReliminates the knowledge acquisition bottleneck that hampers RBR system development,we are not alone in finding that case engineering is also a complex and demanding task(Mark, Simoudis, and Hinkle 1996). As for naturally framing the problem in terms an expertunderstands, our experts told us they use both types of reasoning while manually planningmenus.

The hybrid system CAMPER combines CAMP’s ability to satisfy nutrition constraintswith PRISM’s capacity for creativity. A flow chart for CAMPER is shown in Figure 9, wheresolid lines represent functionality taken from CAMP and dashed lines represent rule-basedenhancements taken from PRISM.

4.1. CBR Module

CAMPER’s CBR module was taken intact from CAMP. However, instead of directlyoutputting a recommended menu as CAMP does, CAMPER passes the menu to an RBRmodule, described below.

4.2. RBR Module

CAMPER’s RBR module was modeled on PRISM. This module was built by expandingCAMP’s database and by adding new functionality to perform “what if” analysis. We describeeach in turn.

Database Expansion.CAMPER’s database not only includes more food items thanCAMP’s, but also allows the food items to be used in different ways. In CAMP, a fooditem is viewed only in context within a case. The database supports serving-size adjustmentand calculation of nutrient vectors. It is never queried to find particular menu items thatmight fit current needs. In PRISM, a food item is viewed as a building block for configuringmenus. The roles a food item may play in a menu are fully described in the layered databasescontaining meal types, dish types, and food types. The ability to configure multiple buildingblocks in multiple ways allows PRISM to create a broader variety of menus than CAMP canproduce.

CAMPER’s database contains data for 608 food items. Supplemental configurationfiles were built to describe the role each food item can fulfill. Conceptually, CAMPER’sconfiguration files function like theis-a arcs in PRISM’s hierarchical databases, which are


shown in Figure 7. Initial configuration files were built by including every food in CAMP’sdatabase in its original role. For example, there is a file containing every food used as abreakfast breadand one containing every food used as asandwich filling. The initial fileswere refined in two ways, to move beyond description of “what was” and into a considerationof “what if.” First, the larger files were subdivided into more specific categories. For example,the file formain dishwas subdivided intovegetarian main dish, poultry main dish, seafoodmain dish, andred meat main dish. Forty-five different food categories were established in all.

Next, additional menu items were added to the smaller files, and to any files consideredto be lacking in variety by the expert. Of these menu items, 68 were foods not includedin CAMP’s database, and 53 were items originally used in different contexts. For example,blueberries were originally included as a snack fruit option, but not as a breakfast fruit option.The expert added blueberries to the breakfast fruit file as well. It should be noted that it wouldnot have been easy to infer such additions automatically. The expert relied on her knowledgeof culturally acceptable roles for foods in determining the additions to make. For instance,the cola soft drink originally included as a snack beverage option wouldnot have made agood addition to the breakfast beverage file.

“What If” Analysis. CAMPER’s “what if” analysis was modeled on PRISM’s. Theuser might ask to add, delete, or replace foods in the recommended menu. When the user asksto replace a food, CAMPER presents a choice of alternative foods that could reasonably fulfillthe same role. These alternative foods come from CAMPER’s configuration files. When auser wants to replace a dessert, for example, he may choose from ice creams, pastries, orfancy fruits, but not from bread spreads, beverage accompaniments, or sandwich fillings.This is partly a matter of allowing the intelligence already built into the system to assist theuser with interactive menu modification; it also reflects the new way in which rules and casesfunction in CAMPER, as described in Section 4.3.

CAMPER displays the nutrient effects of each change to a menu. It does not automaticallyprevent changes that cause constraint violations because any change may cause a temporaryviolation that is corrected in further steps. The nutritionist may have a series of changesin mind at the outset, or may use the information provided to compensate for unexpectedviolations. It should be noted that CAMPER may not be able to meet every constraint,just as a nutritionist may not be able to do so during manual menu planning. For example,vitamin B12 occurs naturally only in animal products, and so it is not possible to meet theRDI for vitamin B12 in a strict vegetarian menu. Such inherent conflicts are well known tonutritionists.

CAMPER is able to save in its case base menus that have been made significantly differentby the user. CAMP did not save the menus it generated because each new menu was aderivative of old ones. CAMPER can reuse the newly generated menus to expand its menu-planning capabilities in the future. This feature was made possible by the synergy betweenCBR and RBR, as described in Section 4.4. Saving a new case is at the discretion of thenutritionist who modified it. The user saves only those menus that have been extensivelyreworked and that seem likely to appeal to future clients. Because the original cases in thecase base were selected to be different from each other, and because the design space ofpossible menus is so large, the user need not worry that a new menu will duplicate an old onebesides the one under consideration.

4.3. Rules and Cases in CAMPER

The new rules in CAMPER are of a different nature than the rules used originally in CAMP.CAMP uses heuristic rules for determining the ease of adapting each case during retrieval.


During adaptation, it uses transformational rules to compensate for nutrient deficiencies. Forexample, one rule replaces whole milk with skim milk to reduce fat. The cases in CAMP areviewed as ground instances, specific experiences, or precomposed solutions, to be recalledand reused. Roast beef, roasted potatoes, and brussels sprouts go together in CAMP becausethe entire combination was once deemed satisfactory,notbecause a well-formed dinner mustbe composed of meat, potato, and vegetable.

Rules in PRISM, on the other hand, compose solutions by configuring components togenerate well-formed menus. There are no ground instances or cases, but there is common-sense understanding of the roles foods can play and the ways in which different types of foodsfit together to form menus. It is this type of rule that was used to enhance CAMP in buildingCAMPER.

To appreciate how rules function in CAMPER, it is necessary to understand how CAMPERexpands the role of the case. Each case in CAMPER may be viewed as one instantiation of anunderlying menu pattern. The pattern then becomes an abstraction of a case, thereby allowingthe case to serve as a prototype for many possible menus. Specific foods are no longer integralcomponents of the menu, but are suggestions or possibilities that may be changed to obtainnew menus.

Should a user decide to replace roast beef as the dinner entr´ee for a menu, a context-freegrammar for well-formed menus will define the allowable substitutions. This grammar is likePRISM’s, although the two systems implement their grammars in different ways. Exampleproduction rules of the grammar are:

〈main dish〉 −→ 〈vegetarianmain dish〉 | 〈poultry main dish〉 |〈seafoodmain dish〉 | 〈red meatmain dish〉

〈vegetarianmain dish〉 −→ cheeseravioli | vegetarianlasagne|soyburgerpatties| ...

〈poultry main dish〉 −→ stir-fry chickenwith vegetables| chickencurry |turkey tetrazzini| ...

〈seafoodmain dish〉 −→ bakedsalmon| broiled cod| fried oysters|cookedshrimp| ...

〈red meatmain dish〉 −→ roastbeef| hamburger| pork chop|beefenchiladaswith cheese| ...

The derivation for roast beef, then, would be:

〈main dish〉 −→ 〈red meatmain dish〉〈red meatmain dish〉 −→ roastbeef

In CAMPER, there are 94 different terminals in this subset of rules, representing 94 maincourse options for the user. Such rules allow each food item in the menu to take on a variety ofsuitable values. Naturally, as substitutions are made, the nutrient vector for the case changesas well. Reflecting these changes in the case, however, requires only the rules of arithmetic.This integrated approach allows us to derive benefit from cases in two different ways: Acase may provide a specific reusable solution, and it may also provide a useful abstraction,or framework, for defining a range of possible solutions.

4.4. CBR/RBR Synergy

CBR and RBR complement each other in CAMPER. CBR contributes an initial menu thatmeets design constraints by capitalizing on food combinations that have proven satisfactory


in the past. RBR allows analysis of alternatives, so that innovation beyond the tried and truebecomes possible.

The ability to produce new cases in an RBR module for later use by a CBR moduleis significant. It is important in the nutritional menu planning domain because good dailymenus are difficult to find and incorporate into the system. In CAMPER, when a nutritionistsubstantially changes a proposed menu, the new menu can be saved for future use by anotherindividual.

This capability is also important for CBR research because it provides a way of addressingthe utility problem, a central CBR issue. The utility problem is the problem of knowingwhich cases to include in a case base for optimal performance. Early CBR systems, suchas CHEF (Hammond 1989), saved every newly generated case. The assumption was thatmoreexperiences equated to more knowledge, so that collecting additional cases, in and ofitself, constituted machine learning. Over time, researchers found that unrestricted case baseexpansion actually led to performance degradation (Smyth and Keane 1995b). It took longerto process more cases, and it was also possible to miss optimal cases that were “buried”beneath less optimal alternatives. This special case of the utility problem became known astheswamping problem: the case-based reasoner became swamped by too many cases. Thereis still no concrete methodology for determining when a case base is large enough, or fordetermining if a particular new case should be added. CAMP did not save cases, as all menusit proposed were derivative of old ones and could easily be regenerated if needed. CAMPERsaves new cases that a nutritionist has made different from existing cases and believes areworth saving. From a nutrition perspective, this adds variety, providing more menu optionsfor individuals. From a CBR perspective, this expands system coverage and enables thesystem to improve its performance over time. CAMPER, taking advantage of CBR/RBRsynergy, provides this new capability, which neither CAMP nor PRISM provided.

4.5. User Interaction

It takes a nutritionist from one-half to three hours to plan a daily menu manually to meetan individual’s nutrient constraints, so the opportunity to interact with a tool that reduces thetask to minutes is valued. Rules guide the user during “what if” analysis, but the user’s owncommon sense and aesthetic judgement are important in preserving pleasing combinationsof color, texture, temperature, and taste. The user also decides whether or not a new menu isworth maintaining for future use.

Other CBR systems have included interactivity as a key component. PROTOS depends onuser interaction for knowledge acquisition, to build up an initial case base that can later be usedfor diagnostic classification (Bareiss 1989). JULIA asks the user for intermediate feedbackon designs under construction and allows the introduction of new constraints throughout thedesign process (Hinrichs 1992).

Kolodner (1991) has suggested that CBR systems can aid both novices and experts indecision-making, without automatically making decisions for them. Such systems supportthe user by remembering and suggesting appropriate cases, but count on the user to adaptthe cases without system support. One such system is ARCHIE, which helps architectsdesign office buildings by retrieving and displaying past designs, along with suggestionsand warnings (Goel et al. 1991). ARCHIE-2 is a hypermedia browsing system that allowsarchitects to peruse a library of courthouse designs, with associated stories and guidelines(Domeshek and Kolodner 1992).

Smith and colleagues built the system Interactive Design using Intelligent Objects andModels (IDIOM) to more actively support architectural design (Smith, Lottaz, and Faltings1995; Smith, Stalker, and Lottaz 1996). IDIOM neither requires the user to adapt cases


manually, nor attempts to fully automate design. Rather, it interactively involves the userthroughout the design process. A case in IDIOM is part of the design of a constructedapartment building, such as a living room, bedroom, or kitchen. IDIOM allows the user tocombine cases to create new designs. The user selects the design components to include, andthe system incrementally solves constraints, while resolving undesired interactions amongcomponents. IDIOM also employs models, which provide domain knowledge in the formof rules, guidelines, technological considerations, and designer preferences. These modelssuggest design constraints. A graphical user interface allows the user to modify a drawingof the layout, or floor plan, as components are added. User characteristics and feedbackaccount for this very high degree of interaction. IDIOM users rejected the idea of automatedlayout generation, therefore IDIOM never automatically proposes a design for consideration,as does CAMPER. Further, IDIOM users typically work from design components, rather thanfrom whole designs, when they produce layouts manually. When it is possible to start fromwhole designs, as CAMPER does, the amount of work done by the system and the user to fitcomponents together harmoniously is reduced.

4.6. System Performance

CAMPER has been deemed by nutrition experts to be superior to either CAMP or PRISM.CAMPER subsumes CAMP, in that it initially produces the same menu as CAMP for anygiven criteria. If the initial menu is satisfactory, the user need not conduct a “what if” analysis.However, nutritionists consider the ability to modify and improve computer generated menus adefinite advantage. Because CAMPER’s initial menus are more goal compliant than PRISM’s,the user can use “what if” analysis for creative purposes, but need not tweak menus just toachieve nutrition goals. In other words, the user starts out closer to an acceptable solutionwhen using CAMPER than when using PRISM.

A menu planned by CAMPER is shown in Figure 10. The user-specified constraintswere that it should include 1,600 calories, at most 30% calories from fat, and at least 1,000milligrams calcium in a cereal breakfast, a sandwich lunch, a pasta dinner, and a fruit snack,and that the menu should exclude nuts and shellfish. The menu in Figure 10 meets allconstraints, but the user may still want to experiment to find an even better menu. For instance,the user might try to substitute American cheese for the roast beef at lunch, but would findthat fat and calories rise, while zinc and vitamin B12 fall to unacceptably low levels. On theother hand, substituting two chocolate chip cookies for the cantaloupe would not violate anynutrition constraints, should an individual decide that cookies would be preferable to fruit.

4.7. Framework for Special-Purpose Menu Planning

CAMPER plans menus for essentially healthy adults, but its framework and methodologyalso apply to planning special-purpose menus for use in medical settings. The early RBRsystem ESOMP planned menus for patients on a severely restricted low protein diet. Dietitiansalso plan special purpose menus for cardiac patients, diabetics, pregnant and lactating women,renal patients, and burn patients. Metabolic diets are planned in clinical research centers tostudy the effects of nutrition on individuals with a variety of medical conditions. The dietprescriptions used in clinical research can be complicated, so it takes a nutritionist extra timeto plan suitable menus. Because metabolic diets are so carefully designed, measured, andtracked, their planning would especially benefit from computer assistance.

A Special Purpose CAMPER (SP-CAMPER) would maintain CAMPER’s flow chart,as shown in Figure 9, and CAMPER’s case structure, as shown in Figure 1. However, thecase base would need to be customized to ensure that each menu is suitable for an individual


FIGURE 9. A flow chart for CAMPER.

with the special condition under consideration. New database entries would be needed forany new food items appearing in the cases. Adaptation strategies would need to be tuned toaccommodate any new constraints on menus. Any changes in adaptation strategies wouldneed to be reflected in the reusability metric as well.

A practical SP-CAMPER could be built for diabetics. The American Diabetes Associa-tion publishes menus specifically designed for diabetics, which would supply suitable casesfor the case base. They also publish strategies for manually modifying these menus to suitindividual tastes, which could be encoded as adaptation strategies. One constraint specificto menus for diabetics is that calorie intake at each time of the day must remain constantfrom one day to the next. Healthy individuals often “splurge” at one meal, and then balancetheir daily diet by eating sensibly at other meals. Diabetics must eat more consistently. Allmenus included in the American Diabetes Association (1989) menu planner have breakfasts


FIGURE 10. A menu planned by CAMPER.

with approximately 350 calories, lunches with approximately 450 calories, and dinners withapproximately 550 calories. Adapting menus using whole meal snippets would maintain thiscaloric balance, but many of CAMPER’s adaptation strategies would not. New adaptationrules would be needed to maintain calories on a meal-by-meal, rather than on a daily, basis.Finally, to be a practical tool, the system would need to produce menus for extended timeperiods, rather than for a single day. This could be accomplished by enlarging the case baseand eliminating cases used previously from consideration on subsequent days.

5. RELATED RESEARCH

5.1. Research in Computer-Assisted Menu Planning

Although computer-assisted menu planning systems are seldom used in practice (Spears1995), the first attempts to build them date from the 1960s. Balintfy (1964) used linearprogramming techniques to build the first computer-assisted menu planner, which optimizedmenus for nutritional adequacy, cost, and palatability. This work, though a good pioneeringeffort, was considered by practicing dietitians to be of more theoretical interest than of practi-cal use. The menus met nutrition constraints but were deemed to be aesthetically unappealing.


The linear programming approach is still used today to plan nutritious diets for animals. Inanother early attempt, Eckstein (1967) adopted a “random” approach to satisfy, rather than op-timize, menus. Using a simple meal pattern, she composed each menu of a meat, starchy food,vegetable, salad, dessert, bread, and beverage. Within each category, a food item was selectedrandomly and evaluated with respect to constraints. The evaluation criteria were cost, color,texture, shape, calories, variety, and acceptability, where acceptability indicated the propor-tion of the target population known to enjoy the food. The program would iterate until satis-factory items were found. Eckstein was optimistic about the prospects for computer-assistedmenu planning in 1967, but conceded, “Expansion and refinement of the program must pre-cede any attempt at widespread use.” Neither Balintfy nor Eckstein attempted to capture thebreadth of knowledge about foods which we find essential to successful menu planning.

Two decades later, AI approaches to menu-planning were first tried. Both case-basedand rule-based menu planners have been implemented, primarily in research settings. Thebest known is JULIA, as described in Hinrichs (1992). Hinrichs noted that menu planning isan informal, commonsense task that people perform flexibly despite ambiguities, incompleteknowledge, and informal criteria for success. He combined CBR with constraint propagationtechniques to build JULIA, an interactive menu planner for dinner parties, functioning in therole of caterer. It does not attempt to provide nutritionally balanced meals; rather, it is aself-proclaimed “party animal.” This focus proved useful in light of the past concentrationon the quantifiable parts of the menu-planning task. JULIA plans a single meal to satisfy agroup of guests, despite conflicting food preferences and evolving constraints. More recently,Ganeshan and Farmer (1995) have implemented a Prolog catering system for a large Australiancatering corporation.

In nutritional menu planning, Yang (1989) built ESOMP to plan therapeutic menus. Sheencoded heuristic rules and numeric constraints in Prolog. Galotra et al. (1991) developeda Prolog expert system to plan therapeutic menus for patients in India. They combinedOperations Research methods to match nutrition requirements to specific food items withheuristic rules and reasoning to convert the food items into complete menus. Research inusing CBR to design diet prescriptions, especially for weight loss, is currently underway inBrazil (Camargo et al. 1998).

5.2. Research in Integrating CBR with Other Reasoning Paradigms

The first CBR/RBR hybrids took one of two approaches to integration. The first approachis to have independent CBR and RBR modules, each of which can solve the problem inde-pendently of the other. The second approach is to take an essentially RBR system, and add aCBR module to provide some portion of the system’s overall functionality. CAMPER differsfrom these approaches in that it enhances an essentially CBR system with an RBR module.

Rissland and Skalak’s (1989) CABARET is a system with independent CBR and RBRproblem solvers. CABARET grew out of an effort to extend the HYPO system (Ashley andRissland 1988), which operates in the trade secrets law domain, to another legal domain, that oftax law. HYPO’s domain is primarily case-based; tax law has statutes, or rules. These rules arevague because they include words that are open to interpretation. For example, a tax deductionmay be taken for a home office that isexclusively usedon aregularbasis as aprincipal place ofbusinessor formeeting or dealingwith customers. What constitutes exclusive use, regularity,principal place, or meeting or dealing is determined by past interpretations made in courtsof law for similar cases. In effect, cases determine whether or not rules apply. CABARETinterleaves CBR and RBR, using heuristics to post CBR and RBR tasks to an agenda. Risslandand Skalak’s work has been influential in the legal domain, where other coreasoning hybridshave been built (Branting 1991; Zeleznikow and Hunter 1994).


Golding and Rosenblum’s (1991) ANAPRON is a system that uses a CBR module toprovide one portion of an essentially RBR system’s functionality. ANAPRON is a speechsynthesizer that pronounces American surnames aloud. This task is challenging because ofthe large number of languages from which American surnames originate and because of theways in which the original names are Americanized. ANAPRON uses rules to generate aprobable pronunciation for a name, and then uses cases to handle exceptions to the rules.Golding found that rules and cases had complementary strengths. Rules were good forcapturing large trends, and cases were good for filling in small pockets where there wereexceptions to the rules. He noted that an alternative to hybridization would have been torefine his rule set. However, with more than 600 rules in his system, he had reached a pointof diminishing returns. He found it easier to integrate cases than to formalize more rules.

More recently, there has been a tremendous interest in integrating CBR with differenttypes of general knowledge. Bartsch-Sp¨orl, Althoff, and Meissonnier (1997) found in a surveyof CBR systems, including CAMP, that general knowledge is frequently required in additionto the knowledge contained in cases, especially for solving complex problems. Bergmannet al. (1996) incorporate general knowledge by means of case completion and adaptationrules without fully integrating additional reasoning modalities. However, the current trendis to exploit other paradigms, such as rule-based reasoning, induction, constraint satisfactionproblem-solving, and model-based reasoning, in multimodal reasoning systems.

Induction is an approach in which general knowledge is derived from specific experiences.It may complement CBR, in which specific experiences are used directly. Induction was firstused with CBR to build decision trees for organizing case libraries to facilitate retrieval, butother couplings have also been proposed (Auriol et al. 1994). An and Cercone (1998) inducerules from cases for both classification and numeric prediction purposes. The induced ruleshelp to select the most appropriate cases, which are then used to derive a numeric solutionfor a given problem. They have applied their approach to the task of predicting daily waterdemand. Armengol and Plaza (1994) induce class prototypes from cases in a knowledgemodeling framework, which they have applied to the task of generating purification plans forbiological proteins. Their cases represent purification experiments. New purification plansmay be derived from specific past experiments or from prototypical experiments generatedby induction from the concrete cases. Though CAMPER does not employ induction in anyformal sense, it does derive prototypes from specific cases by using the underlying menupatterns of specific menus.

Constraint satisfaction problem (CSP) solving is another artificial intelligence paradigmthat has been integrated with CBR. In CSP, values are found for problem variables such thatgiven restrictions on combinations of values are met. CSPs are represented as constraintgraphs with vertices representing variables and edges representing constraints between vari-ables. CSPs are solved through a process of search with backtracking and inference using arcconsistency methods. Squalli and Freuder (1998) have combined CSP and CBR in the do-main of interoperability testing of protocols in asynchronous transfer mode (ATM) networks.They model their problem as a CSP and use CBR to compensate for any incompleteness orincorrectness in their model. They relate their work to CBR integrations with other typesof model-based reasoning, which are described below. Purvis and Pu (1995) integrate CBRwith CSP in a different way. They worked initially on assembly planning and configurationdesign problems, but generalize their approach to any problem that can be formalized as aCSP (Purvis 1998). They found that CBR increases the efficiency of CSP, and that CSPhelps to formalize the adaptation process for CBR. They represent each case in a CBR sys-tem as a CSP and they use CSP techniques to combine and adapt cases to obtain globallyconsistent solutions. Their motivations to reuse existing designs, to avoid complex designfrom scratch, to minimize the inefficiencies of backtracking, and to combine parts of previous


designs are all shared by CAMPER. The advantage of their approach, for problems that canbe expressed as CSPs, is that adaptation and reusability metrics become domain independent.CSPs have a drawback in that the time to solve them can increase exponentially with thesize of the problem. However, it is not primarily the size of the nutritional menu-planningproblem that precludes our use of this approach. More importantly, the creative, aesthetic,and commonsense aspects of the task do not lend themselves to formalization as CSPs.

Model-based reasoning (MBR) is similar to RBR, except that the models tend to be math-ematical or physiological in nature, rather than heuristic, legal, procedural, or grammatical.MBR was first combined with CBR in CASEY, which diagnoses heart failures (Koton 1988).CASEY succeeded in using CBR to improve the efficiency of an early MBR system thatperformed the same task. A subset of knowledge representing a physiological model of theheart was included in CASEY to match current cases to old ones and to derive new diagnosesfrom old ones. When CASEY could not find a close enough match, it would invoke the olderMBR system, which was considered to be accurate and reliable. CBR’s contribution wasan increase in efficiency. More recent CBR/MBR hybrids aim, as does CAMPER, to pro-duce better solutions than can be produced using a single paradigm. CARMA is an advisorysystem that helps ranchers deal with grasshopper infestations (Branting 1998). It predictsforage loss and provides a cost/benefit analysis for the treatment options in a given situation.CARMA incorporates numeric models developed by entomologists as well as specific casesof past infestations. Because the models are incomplete and the cases are few, neither MBRnor CBR alone can make accurate predictions. Integrating the two paradigms improves ac-curacy. In CARMA, CBR is used to select a similar case and the model assists in adaptingthat case’s prediction by simulating the effects of different treatment options. It is interestingthat, like CAMPER, CARMA uses CBR to derive an initial solution and another method toanalyze alternatives. In effect, the model provides a form of “what if” analysis. The user doesnot participate interactively but is presented with a cost/benefit analysis of different options.Branting believes his approach is most useful for predicting behavior in complex physicalsystems.

CBR has also been integrated within the Decision Support System (DSS) frameworkemployed in Management Information Systems (MIS). The usefulness of CBR in aidinghuman decision-makers was described in Kolodner (1991). DSS researchers have combinedCBR with constraint posting and multicriteria decision making techniques in a new approachto decision support (Sinha and May 1996). They fielded their approach in the design assistantIDEA, which operates in the domain of rolling mill designs for the worldwide ferrous andnonferrous producers’ market. IDEA helps a designer generate a mill design proposal inresponse to customer specifications. Sinha and May characterize this task as one of routinedesign, and note that their approach might not be as applicable to creative design or to ill-defined problems, as encountered in nutritional menu planning. As in JULIA (Hinrichs 1992),which also incorporates CBR and constraint propagation, new constraints may be dynamicallyintroduced during processing. This feature may be employed in a “what if” analysis mode, inwhich users see the effects of changes to constraints on designs. This is inverse to CAMPER’s“what if” analysis mode, in which users see the effects of changes to designs on constraints. Inthe multicriteria decision-making component, IDEA optimizes multiple objectives to identifya set of Pareto optimal designs. Different designs may be optimal with respect to differentobjectives, including adaptability, cost, level of detail, and composition requirements. In thisdomain, users do not expect to find one globally optimum design, but, instead, they evaluatealternatives and make their own trade-offs. IDEA proposes a set of solutions, and the userselects one to serve as the basis of a design proposal. Each proposed solution includes valuesfor all design parameters, required adaptations, and equipment lists, but the user must stilladd many details, including drawings and cost estimates, to finish the design proposal. Sinha


and May find that providing assistance, rather than automated solutions, leads to greater useracceptance.

Work that parallels ours in many respects has recently been reported in the domain ofharmonizing melodies (Sabater, Arcos, and L´opez de Mantaras 1998). The domain parallelsours in that there is a definite structure to musical composition, but there is asensethat somecompositions are pleasing while others are not. There are well-established harmonizationrules, which reflect the organization and structure of musical composition, but which are notconstructive in nature. Sabater et al. wrote, “the rules don’t make the music; it is the musicwhich makes the rules.” Their system, GYMEL, uses cases, which are musical phrasesfrom Catalan folk songs, and general harmonization rules. As in CAMPER, GYMEL’spredominant reasoning mode is CBR, and RBR serves to assist. Unlike CAMPER, GYMELuses rules when CBR cannot supply a solution. CAMPER’s CBR module can always supplya solution, but its RBR module can improve that solution. Like CAMPER, GYMEL stores thenew solutions generated using RBR in its case base to improve future performance. Sabateret al. believe that their approach is especially well suited to domains where it is difficult tofind enough cases and where it is unsuitable to work with rules alone. As we have previouslyreported, finding enough cases was a major obstacle in building our CBR module (Marlingand Sterling 1996). We agree that rules can compensate for a paucity of cases, but we suggestthat the creative and aesthetic aspects of harmonizing melodies may play a role in the successof this approach to CBR/RBR integration.

6. SUMMARY AND CONCLUSIONS

A nutritional menu planning system was built that incorporates the strengths of indepen-dent CBR and RBR systems built to perform the same task. The task is to design daily menusin accordance with accepted nutrition guidelines and aesthetic standards for color, texture,temperature, taste, and variety. A CBR module to store, retrieve, and adapt potential menuscontributes toward the design of menus that meet multiple nutrition and personal preferenceconstraints. It reduces system complexity by embedding commonsense knowledge in cases,rather than representing it explicitly. An RBR module to perform “what if” analysis and tointroduce new foods into menus contributes creativity in design. It allows the user to interactwith the system, evaluating trade-offs and customizing menus. These customized menus canbecome new cases, which are otherwise difficult to acquire. The two modules then functionsymbiotically, designing better menus in concert than either single strategy system can de-sign. Our hybrid approach has real-world applicability for planning menus to prevent, treat,or control a variety of medical conditions. We believe our approach would be useful in otherdomains, such as architecture, college course advising, and new product design, in whichboth physical constraints and aesthetic considerations are important.

ACKNOWLEDGMENTS

This work represents joint research between the Department of Computer Engineeringand Science, in the Case School of Engineering, and the Department of Nutrition, in theSchool of Medicine, at Case Western Reserve University. The contributions and support ofRandy Beer, George Ernst, Karen Fiedler, Ashish Jain, Miles Kennedy, Kathy Kovacic, TekinOzsoyoglu, and Nan Yang, are gratefully acknowledged.


REFERENCES

AMERICAN DIABETES ASSOCIATION. 1989. Month of Meals: A Menu Planner.

AMERICAN DIETETIC ASSOCIATIONand U. S. DEPARTMENT OFAGRICULTURE. 1982. Food 2.

AN, A., and N. CERCONE. 1998. Multimodal reasoning with rule induction and case-based reasoning.In Multi-modal Reasoning: Papers from the 1998 AAAI Spring Symposium. AAAI Press, Menlo Park, CA, pp. 118–123.

ARMENGOL, E., and E. PLAZA . 1994. Integrating induction in a case-based reasoner.In Advances in Case-BasedReasoning: Second European Workshop, Selected Papers, EWCBR-94.Edited byJ. P. Haton, M. Keane,and M. Manago. Springer-Verlag, Berlin, pp. 3–17.

ASHLEY, K. D., and E. L. RISSLAND. 1988. A case-based approach to modeling legal expertise. IEEE Expert,3(3):70–77.

AURIOL, E., M. MANAGO, K. D. ALTHOFF, S. WESS, and S. DITTRICH. 1994. Integrating induction and case-basedreasoning: Methodological approach and first evaluations.In Advances in Case-Based Reasoning: SecondEuropean Workshop, Selected Papers, EWCBR-94.Edited byJ. P. Haton, M. Keane, and M. Manago.Springer-Verlag, Berlin, pp. 18–32.

BALINTFY , J. L. 1964. Menu planning by computer. Communications of the ACM,7(4):255–259.

BAREISS, R. 1989. Exemplar-Based Knowledge Acquisition: A Unified Approach to Concept Representation,Classification, and Learning. Academic Press, San Diego, CA.

BARTSCH-SPORL, B., K. D. ALTHOFF, and A. MEISSONNIER. 1997. Learning from and reasoning about case-basedreasoning systems.In Proceedings of the Fourth German Conference on Knowledge-Based Systems.

BERGMANN, R., W. WILKE, I. VOLLRATH, and S. WESS. 1996. Integrating general knowledge with object-oriented case representation and reasoning. Fourth German Workshop: Case-Based Reasoning—SystemDevelopment and Evaluation.

BILGIC, T., and M. S. FOX. 1996. Constraint-based retrieval of engineering design cases.In Artificial Intelligencein Design ’96.Edited byJ. S. Gero and F. Sudweeks. Kluwer, Boston, pp. 269–288.

BRANTING, L. K. 1991. Building explanations from rules and structured cases. International Journal of Man-Machine Studies,34:797–837.

BRANTING, L K. 1998. Integrating cases and models through approximate-model-based adaptation.In MultimodalReasoning: Papers from the 1998 AAAI Spring Symposium. AAAI Press, Menlo Park, CA, pp. 1–5.

CAMARGO, K. G., M. A. L. THE, R. WEBER, A. MARTINS, and R. BARCIA. 1998. Designing nutritional programswith case-based reasoning. Sixth German Workshop on Case-Based Reasoning, Berlin.

CARBONELL, J. G., and M. M. VELOSO. 1988. Integrating derivational analogy into a general problem solvingarchitecture.In Proceedings: Workshop on Case-Based Reasoning (DARPA). Morgan Kaufmann, SanMateo, CA.

DOLLAHITE, J., D. FRANKLIN , and R. MCNEW. 1995. Problems encountered in meeting the recommended dietaryallowances for menus designed according to the dietary guidelines for Americans. Journal of the AmericanDietetic Association,95(3):341–347.

DOMESHEK, E., and J. KOLODNER. 1992. A case-based design aid for architecture.In Artificial Intelligence inDesign 1992.Edited byJ. S. Gero. Kluwer, Boston.

ECKSTEIN, E. F. 1967. Menu planning by computer: The random approach. Journal of the American DieteticAssociation,51:529–533.

ECKSTEIN, E. F. 1978. Menu Planning, 2nd ed. AVI Publishing, Westport, CT.

FOOD AND DRUG ADMINISTRATION. 1993. Department of Health and Human Services. Federal Register58(3):2228.

FOOD AND NUTRITION BOARD. 1989. Recommended Dietary Allowances, 10th ed. National Academy Press,Washington, D.C.

GALOTRA, V., S. RAMACHANDRAN , H. SINGH, and K. BAJAJ. 1991. Nutrition diet programme—An expert system.Unpublished report, Artificial Intelligence Division, National Informatics Centre, New Delhi, India.

GANESHAN, K., and J. FARMER. 1995. Menu planning system for a large catering corporation.In Proceedings ofthe Third International Conference on the Practical Application of Prolog, Paris, pp. 263–265.


GOEL, A. K., J. L. KOLODNER, M. PEARCE, R. BILLINGTON, and C. ZIMRING. 1991. Towards a case-based tool foraiding conceptual design problem solving.In Proceedings: Workshop on Case-Based Reasoning (DARPA).Morgan Kaufmann, San Mateo, CA.

GOLDING, A. R., and P. S. ROSENBLUM. 1991. Improving rule-based systems through case-based reasoning.InProceedings AAAI-91. AAAI Press/MIT Press, Cambridge, MA, pp. 22–27.

HAMMOND, K. J. 1989. Case-based Planning: Viewing Planning as a Memory Task. Academic Press, San Diego.

HANNEY, K., B. SMYTH, and P. CUNNINGHAM. 1995. Systems, tasks and adaptation knowledge: Revealingsome revealing dependencies.In Case-Based Reasoning Research and Development: First InternationalConference, Proceedings ICCBR-95.Edited byM. Veloso and A. Aamodt. Springer-Verlag, Berlin, pp. 461–470.

HAYTOWITZ, D. B. 1995. Information from the USDA’s nutrient data bank. Journal of Nutrition,125:1952–1955.

HINRICHS, R. R. 1992. Problem Solving in Open Worlds: A Case Study in Design. Erlbaum, Northvale, NJ.

KOLODNER, J. 1991. Improving human decision making through case-based decision aiding. AI Magazine,12(2):52–68.

KOLODNER, J. 1993. Case-based reasoning. Morgan Kaufmann, San Mateo, CA.

KOTON, P. 1988. Reasoning about evidence in causal explanations.In Proceedings AAAI-88. Morgan Kaufmann,San Mateo, CA, pp. 256–261.

KOVACIC, K. J. 1995. Using common sense knowledge for computer menu planning. Ph.D. dissertation, Depart-ment of Computer Engineering and Science, Case Western Reserve University, Cleveland, OH.

MARK, W., E. SIMOUDIS, and D. HINKLE. 1996. Case-based reasoning: Expectations and results.In Case-BasedReasoning: Experiences, Lessons, & Future Directions.Edited byD. B. Leake. AAAI Press/MIT Press,Cambridge, MA, pp. 269–294.

MARLING, C. R. 1996. Integrating case-based and rule-based reasoning in knowledge-based systems development.Ph.D. dissertation, Department of Computer Engineering and Science, Case Western Reserve University,Cleveland, OH.

MARLING, C., G. PETOT, and L. STERLING. 1996a. Adaptation-oriented retrieval in a case-based reasoning system.Technical report, Department of Computer Science, University of Melbourne, Melbourne, Australia.

MARLING, C., G. PETOT, and L. STERLING. 1996b. Planning nutritional menus using case-based reasoning.InWorking Notes of the AAAI Spring Symposium on Artificial Intelligence in Medicine, Palo Alto, CA,pp. 109–113.

MARLING, C. R., and L. S. STERLING. 1996. Designing nutritional menus using case-based and rule-basedreasoning. In Artificial Intelligence in Design ’96.Edited byJ. S. Gero and F. Sudweeks. Kluwer, Boston,pp. 211–227.

PENNINGTON, J. A. T. 1976. Dietary nutrient guide. AVI Publishing, Westport, CT.

PURVIS, L. 1998. Synergy and commonality in case-based and constraint-based reasoning.In Multimodal Rea-soning: Papers from the 1998 AAAI Spring Symposium. AAAI Press, Menlo Park, CA, pp. 80–84.

PURVIS, L., and P. PU. 1995. Adaptation using constraint satisfaction techniques.In Case-Based ReasoningResearch and Development: First International Conference, Proceedings ICCBR-95.Edited byM. Velosoand A. Aamodt. Springer-Verlag, Berlin, pp. 289–300.

REDMOND, M. A. 1990. Distributed cases for case-based reasoning: Facilitating use of multiple cases.In Pro-ceedings AAAI-90. AAAI Press/MIT Press, Cambridge, MA.

RIESBECK, C. K., and R. C. SCHANK. 1989. Inside Case-Based Reasoning. Erlbaum, Hillsdale, NJ.

RISSLAND, E. L., and D. B. SKALAK . 1989. Combining case-based and rule-based reasoning: A heuristic approach.In Proceedings IJCAI-89, Detroit, MI, pp. 524–530.

SABATER, J., J. L. ARCOS, and R. LOPEZ DEMANTARAS. 1998. Using rules to support case-based reasoning forharmonizing melodies.In Multimodal Reasoning: Papers from the 1998 AAAI Spring Symposium, AAAIPress, Menlo Park, CA, pp. 147–151.

SINHA, A. P., and J. H. MAY. 1996. Providing design assistance: A case-based approach. Information SystemsResearch,7(3):363–387.

SLADE, S. 1991. Case-based reasoning: A research paradigm. AI Magazine,12:42–55.


SMITH, I., C. LOTTAZ, and B. FALTINGS. 1995. Spatial composition using cases: IDIOM.In Case-Based ReasoningResearch and Development: First International Conference, Proceedings ICCBR-95.Edited byM. Velosoand A. Aamodt. Springer-Verlag, Berlin, pp. 88–97.

SMITH, I., R. STALKER, and C. LOTTAZ. 1996. Creating design objects from cases for interactive spatial com-position.In Artificial Intelligence in Design ’96.Edited byJ. S. Gero and F. Sudweeks. Kluwer, Boston,pp. 97–116.

SMYTH, B., and M. T. KEANE. 1995a. Experiments on adaptation-guided retrieval in case-based design.In Case-Based Reasoning Research and Development: First International Conference, Proceedings ICCBR-95.Edited byM. Veloso and A. Aamodt. Springer-Verlag, Berlin, pp. 313–324.

SMYTH, B., and M. T. KEANE. 1995b. Remembering to forget: A competence-preserving case deletion policy forcase-based reasoning systems.In Proceedings IJCAI-95, Montreal, pp. 377–382.

SPEARS, M. C. 1995. Foodservice Organizations: A Managerial and Systems Approach. Prentice Hall, EnglewoodCliffs, NJ.

SQUALLI , M. H., and E. C. FREUEDER. 1998. Integration of CSP and CBR to compensate for incompleteness andincorrectness of models.In Multimodal Reasoning: Papers from the 1998 AAAI Spring Symposium. AAAIPress, Menlo Park, CA, pp. 74–79.

STERLING, L., G. PETOT, C. MARLING, K. KOVACIC, and G. ERNST. 1996. The role of common sense knowledgein menu planning. Expert Systems with Applications: An International Journal,11(3):301–308.

U.S. DEPARTMENT OFAGRICULTURE. 1995. Nutrition and your health: Dietary guidelines for Americans, 4th ed.U.S. Government Printing Office, Washington, D.C.

VOSS, A. 1996. A study of case adaptation systems.In Artificial Intelligence in Design ’96.Edited byJ. S. Geroand F. Sudweeks. Kluwer, Boston, pp. 173–189.

WEIGHT WATCHERSINTERNATIONAL. 1994. Superstart meal ideas.

WILLS, W. M., and J. L. KOLODNER. 1996. Towards more creative case-based design systems.In Case-Based Rea-soning: Experiences, Lessons, & Future Directions.Edited byD. Leake. AAAI Press/MIT Press, Cambridge,MA, pp. 81–92.

YANG, N. 1989. An expert system on menu planning. M.S. thesis, Department of Computer Engineering andScience, Case Western Reserve University, Cleveland, OH.

ZELEZNIKOW, J., and D. HUNTER. 1994. Building Intelligent Legal Information Systems: Representation andReasoning in Law. Kluwer, Deventer, The Netherlands.

INTEGRATING CASE-BASED AND RULE-BASED …oucsace.cs.ohiou.edu/~marling/cbr_rbr.pdfINTEGRATING...

Documents

Transcript of INTEGRATING CASE-BASED AND RULE-BASED …oucsace.cs.ohiou.edu/~marling/cbr_rbr.pdfINTEGRATING...