Buy Smart: a frame-based expert system - Frame-based expert systems

Frame-based expert systems

5.6 Buy Smart: a frame-based expert system

To illustrate the ideas discussed above, we consider a simple frame-based expert system, Buy Smart, which advises property buyers.

We will review the main steps in developing frame-based systems, and show how to use methods and demons to bring frames to life. To aid us in this effort we will use the Level5 Object expert system shell.

Are there any differences between the main steps in building a rule-based expert system and a frame-based one?

The basic steps are essentially the same. First, the knowledge engineer needs to obtain a general understanding of the problem and the overall knowledge structure. He or she then decides which expert system tool to use for developing a prototype system. Then the knowledge engineer actually creates the knowledge base and tests it by running a number of consultations. And finally, the expert system is expanded, tested and revised until it does what the user wants it to do. The principal difference between the design of a rule-based expert system and a frame-based one lies in how the knowledge is viewed and represented in the system.

In a rule-based system, a set of rules represents the domain knowledge useful for problem solving. Each rule captures some heuristic of the problem, and each new rule adds some new knowledge and thus makes the system smarter. The rule- based system can easily be modified by changing, adding or subtracting rules.

149 BUY SMART: A FRAME-BASED EXPERT SYSTEM

In a frame-based system, the problem is viewed in a different manner. Here, the overall hierarchical structure of the knowledge is decided first. Classes and their attributes are identified, and hierarchical relationships between frames are established. The architecture of a frame-based system should not only provide a natural description of the problem, but also allow us to add actions to the frames through methods and demons.

The development of a frame-based system typically involves the following steps:

1 Specify the problem and define the scope of the system. 2 Determine classes and their attributes.

3 Define instances. 4 Design displays.

5 Define WHEN CHANGED and WHEN NEEDED methods, and demons. 6 Define rules.

7 Evaluate and expand the system.

Step 1: Specify the problem and define the scope of the system

In our Buy Smart example, we start by collecting some information about properties for sale in our region. We can identify relevant details such as the property type, location, number of bedrooms and bathrooms, and of course, the property price. We also should provide a short description and a nice photo for each property.

We expect that some of the properties will be sold and new properties will appear on the market. Thus, we need to build a database that can be easily modified and then accessed from the expert system. Level5 Object allows us to access, modify, delete and perform other actions on data within a dBASE III database.

Can we store descriptions and pictures of the properties within a database?

Property descriptions and pictures should be stored separately, descriptions as text files (*.txt) and pictures as bit-map files (*.bmp). If we then set up a display that includes a text-box and a picture-box, we will be able to view a property description and its picture in this display by reading the text file into the text-box and the bit-map file into the picture-box, respectively.

Now we create an external database file,house.dbf, using dBASE III or Microsoft Excel, as shown in Table 5.1.

The next step is to list all possible queries we might think of: . What is the maximum amount you want to spend on a property? . _{What type of property do you prefer?}

. _{Which suburb would you like to live in?} . How many bedrooms do you want? . How many bathrooms do you want?

Once these queries are answered, the expert system is expected to provide a list of suitable properties.

Step 2: Determine classes and their attributes

Here, we identify the problem’s principal classes. We begin with the general or conceptual type of classes. For example, we can talk about the concept of a property and describe general features that are common to most properties. We can characterise each property by its location, price, type, number of bedrooms and bathrooms, construction, picture and description. We also need to present contact details of the property, such as its address or phone number. Thus, the class Table 5.1 The property databasehouse.dbf

Area Suburb Price Type Bedrooms

Central Suburbs New Town 164000 House 3

Central Suburbs Taroona 150000 House 3

Southern Suburbs Kingston 225000 Townhouse 4

Central Suburbs North Hobart 127000 House 3

Northern Suburbs West Moonah 89500 Unit 2

Central Suburbs Taroona 110000 House 3

Central Suburbs Lenah Valley 145000 House 3

Eastern Shore Old Beach 79500 Unit 2

Central Suburbs South Hobart 140000 House 3

Central Suburbs South Hobart 115000 House 3

Eastern Shore Cambridge 94500 Unit 2

Northern Suburbs Glenorchy 228000 Townhouse 4

. . . . .

Bathrooms Construction Phone Pictfile Textfile

1 Weatherboard (03) 6226 4212 house01.bmp house01.txt

1 Brick (03) 6226 1416 house02.bmp house02.txt

2 Brick (03) 6229 4200 house03.bmp house03.txt

1 Brick (03) 6226 8620 house04.bmp house04.txt

1 Weatherboard (03) 6225 4666 house05.bmp house05.txt

1 Brick (03) 6229 5316 house06.bmp house06.txt

1 Brick (03) 6278 2317 house07.bmp house07.txt

1 Brick (03) 6249 7298 house08.bmp house08.txt

1 Brick (03) 6228 5460 house09.bmp house09.txt

1 Brick (03) 6227 8937 house10.bmp house10.txt

1 Brick (03) 6248 1459 house11.bmp house11.txt

2 Weatherboard (03) 6271 6347 house12.bmp house12.txt

. . . . .

151 BUY SMART: A FRAME-BASED EXPERT SYSTEM

Propertycan be presented as shown in Figure 5.12. Note that we added the attributeInstance Numberas well. This attribute does not characterise the property but will assist Level5 Object in accessing the external database.

Step 3: Define instances

Once we determined the class-frame Property, we can easily create its instances by using data stored in the dBASE III database. For most frame-based expert systems like Level5 Object, this task requires us to Figure 5.12 ClassPropertyand its instances

tell the system that we want a new instance to be created. For example, to create a new instance of the classProperty, we can use the following code:

MAKE Property

WITH Area := area OF dB3 HOUSE 1 WITH Suburb := suburb OF dB3 HOUSE 1 WITH Price := price OF dB3 HOUSE 1 WITH Type := type OF dB3 HOUSE 1

WITH Bedrooms := bedrooms OF dB3 HOUSE 1 WITH Bathrooms := bathrooms OF dB3 HOUSE 1 WITH Construction := construct OF dB3 HOUSE 1 WITH Phone := phone OF dB3 HOUSE 1

WITH Pictfile := pictfile OF dB3 HOUSE 1 WITH Textfile := textfile OF dB3 HOUSE 1

WITH Instance Number := Current Instance Number

Here, the classdB3 HOUSE 1is used to represent the structure of the external database file house.dbf. Each row in the property database, shown in Table 5.1, represents an instance of the class Property, and each column represents an attribute. A newly created instance-frame receives the values of the current record of the database. Figure 5.12 shows instances that are created from the external database. These instances are linked to the classProperty, and they inherit all attributes of this class.

Step 4: Design displays

Once the principal classes and their attributes are determined, we can design major displays for our application. We need theApplication Title Display to present some general information to the user at the begin- ning of each application. This display may consist of the application title, general description of the problem, representative graphics and also copyright information. An example of theApplication Title Display

is shown in Figure 5.13.

The next display we can think of is the Query Display. This display should allow us to indicate our preferences by answering the queries presented by the expert system. The Query Display may look like a display shown in Figure 5.14. Here, the user is asked to select the most important things he or she is looking for in the property. Based on these selections, the expert system will then come up with a complete list of suitable properties.

And finally, we should design theProperty Information Display. This display has to provide us with the list of suitable properties, an opportunity to move to the next, previous, first or last property in the list, and also a chance to look at the property picture and its description. Such a display may look like the one presented in Figure 5.15. Note that the picture-box and text-box are included in the display.

153 BUY SMART: A FRAME-BASED EXPERT SYSTEM

Figure 5.13 TheApplication Title Display

How are these displays linked?

Level5 Object allows us to link these displays by attaching theContinue

pushbutton on the Application Title Displayto the Query Display, and theSearchpushbutton on theQuery Displayto theProperty Information Display. When we run the application, clicking on either theContinue

orSearchpushbutton will cause a new display to appear. Now we have to bring these displays to life.

Step 5: Define WHEN CHANGED and WHEN NEEDED methods, and demons

At this point, we have already created the problem principal classes and their attributes. We also determined the class instances, and established the mechanism for creating these instances from the external database. And finally, we designed static displays for presenting information to the user. We must now develop a way to bring our application to life. There are two ways to accomplish this task. The first one relies on WHEN CHANGED and WHEN NEEDED methods, and demons. The second approach involves pattern-matching rules. In frame-based systems, we always first consider an application of methods and demons.

What we need now is to decide when to create instances of the class

Property. There are two possible solutions. The first one is to create all instances at once when the user clicks on theContinuepushbutton on theApplication Title Display, and then remove inappropriate instances step-by-step based on the user’s preferences when he or she selects pushbuttons on theQuery Display.

The second approach is to create only relevant instances after the user has made all selections on the Query Display. This approach Figure 5.15 TheProperty Information Display

155 BUY SMART: A FRAME-BASED EXPERT SYSTEM

illuminates the necessity to remove inappropriate instances of the class

Property, but may add to the complexity of the system’s design. In our design here, we give preference to the first approach. It will provide us with an opportunity to use demons instead of rules. However, you could use the other approach.

Let us now create an additional class, the classAction Data, shown in Figure 5.16. The WHEN CHANGED method attached to the attribute

Load Propertiesallows us to create all instances of the classProperty. How do we make this method work?

To make it work, we attach theContinuepushbutton on theApplication Title Display to the attributeLoad Properties. Now when we select this pushbutton at run time, the attributeLoad Propertiesreceives a value of TRUE, causing its WHEN CHANGED method to execute and create all instances of the class Property. The number of the instances created equals the number of records in the external database.

Now the Query Display appears (remember that we attach the

Continue pushbutton of the Application Title Display to the Query Display), and the user is required to choose the most desirable features of the property by selecting appropriate pushbuttons. Each pushbutton here is associated with a demon that removes inappropriate instances of the classProperties. A set of demons is shown in Figure 5.17. How do demons work here?

A demon does not go into action until something happens. In our application, it means that a demon is fired only if the user selects a corresponding pushbutton.

Let us consider, for example,DEMON 1associated with theCentral Suburbs pushbutton. When the user clicks on the Central Suburbs

pushbutton on theQuery Display,DEMON 1is fired. The first command of the demon consequent tells Level5 Object to find the classProperty. The WHERE clause,

WHERE Area OF Property <> ‘‘Central Suburbs’’

finds all instances of the class Property that do not match the user selection. It looks for any instance where the value of the attribute Figure 5.17 Demons for theQuery Display

157 BUY SMART: A FRAME-BASED EXPERT SYSTEM

Area is not equal to Central Suburbs. Then, the FORGET CURRENT command removes the current instance of the classPropertyfrom the application.

Once the property features are selected, the user clicks on theSearch

pushbutton on theQuery Displayto obtain a list of properties with these features. This list will appear on theProperty Information Display(recall that the Search pushbutton is attached to the Property Information Display).

Can we view pictures and descriptions of the properties?

Let us first create two more attributes, Load Instance NumberandGoto First Property, for the classAction Dataas shown in Figure 5.18. Let us also attach theSearchpushbutton on theQuery Displayto the attribute

Load Instance Number. Now when we click on theSearchpushbutton at run time, the attribute Load Instance Number will receive a value of TRUE, causing its WHEN CHANGED method to execute. This method determines the total number of instances left in the class Property. It also assigns the attribute Goto First Property a value of TRUE, sub- sequently causing its WHEN CHANGED method to execute.

The method attached to the attributeGoto First Propertyensures that we are always positioned at the first property when we enter the

Property Information Display. It also loads the value of the attribute

Pictfile into the display’s picture-box and the value ofTextfileinto the text-box. As a result, we can see the property picture and its description as shown in Figure 5.15.

Figure 5.18 The WHEN CHANGED methods of the attributesLoad Instance Numberand

Step 6: Define rules

When we design a frame-based expert system, one of the most important and difficult decisions is whether to use rules or manage with methods and demons instead. This decision is usually based on the personal preferences of the designer. In our application, we use methods and demons because they offer us a powerful but simple way of representing procedures. On the other hand, in the credit evaluation example considered earlier, we applied a set of rules. In general, however, rules are not effective at dealing with procedural knowledge. Step 7: Evaluate and expand the system

We have now completed the initial design of our Buy Smart expert system. The next task is to evaluate it. We want to make sure that the system’s performance meets our expectations. In other words, we want to run a test case.

1. To begin the test, we click on the Continue pushbutton on the

Application Title Display. The attributeLoad Properties of the class

Action Data receives a value of TRUE. The WHEN CHANGED method attached to Load Propertiesis executed, and all instances of the classPropertyare created.

2. The Query Display appears, and we make our selections, for example:

)Central Suburbs DEMON 1

IF selected OF Central Suburbs pushbutton THEN FIND Property

WHERE Area OF Property <> ‘‘Central Suburbs’’ WHEN FOUND