Frame-based Knowledge Representation

1. Introduction

• Knowledge in a computer can be represented through several techniques.

• In this chapter, we will use frames for the knowledge representation.

1.1 What is a frame?

• A frame is a data structure with typical knowledge about a particular object or concept.

• Frames, first proposed by Marvin Minsky in the 1970s (Minsky, 1975), are used to capture and represent knowledge in a frame-based expert system.

• Boarding passes shown in Figure 5.1 represent typical frames with knowledge about airline passengers.

• Both frames have the same structure.• Each frame has its own name and a set of

attributes, or slots, associated with it.

• Name, weight, height and age are slots in the frame Person.

• Model, processor, memory and price are slots in the frame Computer.

• Each attribute or slot has a value attached to it.

• In Figure 5.1(a), slot Carrier has value QANTAS AIRWAYS and slot Gate has value 2.

• In some cases, instead of a particular value, a slot may have a procedure that determines the value.

1.2 Why is it necessary to use frames?

• Frames provide a natural way for the structured and concise representation of knowledge.

• In a single entity, a frame combines all necessary knowledge about a particular object or concept.

• A frame provides a means of organizing knowledge in slots to describe various attributes and characteristics of the object.

• If we are searching for knowledge about Qantas frequent flyers, then we want to avoid the search through knowledge about Air New Zealand or British Airways passengers.

• In this situation, we need frames to collect the relevant facts within a single structure.

• Basically, frames are an application of object-oriented programming.

1.3 What is object-oriented programming?

• Object-oriented programming can be defined as a programming method that uses objects as a basis for analysis, design and implementation.

• In object-oriented programming, an object is defined as a concept, abstraction or thing with crisp boundaries and meaning for the problem at hand (Rumbaugh et al., 1991).

• All objects have identity and are clearly distinguishable.

• Michael Black, Audi 5000 Turbo, IBM Aptiva S35 are examples of objects.

• An object combines both data structure and its behaviour in a single entity.

• This is in sharp contrast to conventional programming, in which data structure and the program behaviour have concealed or vague connections.

• Object-oriented programming offers a natural way of representing the real world in a computer, and also illuminates the problem of data dependency, which is inherent in conventional programming (Taylor, 1992).

• When programmers create an object in an object-oriented programming language, they first assign a name to the object, then determine a set of attributes to describe the object’s characteristics, and at last write procedures to specify the object’s behaviour.

• A knowledge engineer refers to an object as a frame, the term introduced by Minsky, which has become the AI jargon.

2. Frames as a knowledge representation technique

• The concept of a frame is defined by a collection of slots.

• Each slot describes a particular attribute or operation of the frame.

• In many respects, a frame resembles the traditional ‘record’ that contains information relevant to typical entities.

• Slots are used to store values. • A slot may contain a default value or a pointer

to another frame, a set of rules or procedure by which the slot value is obtained.

In general, slots may include such information as:

1. Frame name.2. Relationship of the frame to the other

frames. – The frame IBM Aptiva S35 might be a member of

the class Computer, which in turn might belong to the class Hardware.

3. Slot value. • A slot value can be symbolic, numeric or

Boolean. • For example, in the frames shown in Figure

5.1, the slot Name has symbolic values, and the slot Gate numeric values.

• Slot values can be assigned when the frame is created or during a session with the expert system.

4. Default slot value. • The default value is taken to be true when no

evidence to the contrary has been found. • For example, a car frame might have four

wheels and a chair frame four legs as default values in the corresponding slots.

5. Range of the slot value. • The range of the slot value determines

whether a particular object or concept complies with the stereotype requirements defined by the frame.

• For example, the cost of a computer might be specified between $750 and $1500.

6. Procedural information. • A slot can have a procedure (a self-contained

arbitrary piece of computer code) attached to it, which is executed if the slot value is changed or needed.

• There are two types of procedures often attached to slots:– (a) WHEN CHANGED procedure is executed when

new information is placed in the slot.– (b) WHEN NEEDED procedure is executed when

information is needed for the problem solving, but the slot value is unspecified.

• Such procedural attachments are often called demons.

• Frame-based expert systems also provide an extension to the slot-value structure through the application of facets.

2.1 What is a facet?

• A facet is a means of providing extended knowledge about an attribute of a frame.

• Facets are used to establish the attribute value, control end-user queries, and tell the inference engine how to process the attribute.

• In general, frame-based expert systems allow us to attach value, prompt and inference facets to attributes.

• Value facets specify default and initial values of an attribute.

• Prompt facets enable the end-user to enter the attribute value on-line during a session with the expert system.

• And finally, inference facets allow us to stop the inference process when the value of a specified attribute changes.

2.2 What is the correct level of decomposition of a problem into frames, slots and facets?

• Decomposition of a problem into frames, frames into slots and facets depends on the nature of the problem itself and the judgment of the knowledge engineer.

• There is no predefined ‘correct’ representation.

• Figure 5.2 illustrates frames describing computers.

• The topmost frame represents the class Computer and the frames below describe instances IBM Aptiva S35 and IBM Aptiva S9C.

• Two types of attributes are used here: string [Str] for symbolic information and numeric [N] for numeric data.

• Note default and initial value facets attached to the slots Floppy, Power Supply, Warranty and Stock in the class Computer.

• The attribute names, types, default and initial values are the properties inherited by instances.

2.3 What are the class and instances?

• The frame may refer to a particular object, for example the computer IBM Aptiva S35, or to a group of similar objects.

• To be more precise, we will use the instance-frame when referring to a particular object, and the class-frame when referring to a group of similar objects.

• A class-frame describes a group of objects with common attributes.

• Animal, person, car and computer are all class-frames.

• In AI, however, the abbreviation ‘class’ is often used instead of the term ‘class-frame’.

• Each frame in a frame-based system ‘knows’ its class.

• In other words, the frame’s class is an implicit property of the frame.

• For example, instances in Figure 5.2 identify their class in the slot Class.

• Grouping objects into classes helps us to represent a problem in an abstract form.

• Minsky himself described frames as ‘data structures for representing stereotyped situations’.

• In general, we are less concerned with defining strictly and exhaustively the properties of each object, and more concerned with the salient properties typical for the entire class.

• Let us take, for example, the class of birds.– Can a bird fly? – A typical answer is yes.

• Almost all birds can fly, and thus we think of the ability to fly as being an essential property of the class of birds, even though there are birds, such as ostriches, which cannot fly.

• In other words, an eagle is a better member of the class bird than an ostrich because an eagle is a more typical representative of birds.

• Frame-based systems support class inheritance.

• The fundamental idea of inheritance is that attributes of the class-frame represent things that are typically true for all objects in the class.

• However, slots in the instance-frames can be filled with actual data uniquely specified for each instance.

• Consider the simple frame structure represented in Figure 5.3.

• The class Passenger car has several attributes typical for all cars.

• This class is too heterogeneous to have any of the attributes filled in, even though we can place certain restrictions upon such attributes as Engine type, Drivetrain type and Transmission type.

• Note that these attributes are declared as compound [C].

• Compound attributes can assume only one value from a group of symbolic values, for example the attribute Engine type can assume the value of either In-line 4 cylinder or V6, but not both.

• The class Mazda is linked to its superclass Passenger car by the ‘is-a’ relation.

• The Mazda inherits all attributes of the superclass and also declares the attribute Country of manufacture with the default value Japan attached to it.

• The class Mazda 626 introduces three additional attributes: Model, Colour and Owner.

• Finally, the instance-frame Mazda DR-1216 inherits its country of manufacture from the Mazda frame, as the Mazda 626 does, and establishes single values for all compound attributes.

• An instance-frame can overwrite, or in other words violate, some of the typical attribute values in the hierarchy.

• For example, the class Mazda 626 has an average fuel consumption of 22 miles per gallon, but the instance Mazda DR-1216 has a worse figure because it has done a lot of miles.

• Thus the Mazda DR-1216 frame remains the instance of the class Mazda 626, with access to the properties further up the hierarchy, even though it violates the typical value in its class.

• Relationships between frames in such a hierarchy constitute a process of specialization.

• The class-frame on the top of the hierarchy represents some generic concept, class-frames further down stand for a more restricted concept and the instances are closer to exemplification.

2.4 How are objects related in a frame-based system?

• Is the ‘is-a’ relationship the only one available to us?

• In general, there are three types of relationships between objects: – Generalization,– aggregation and – association.

1) Generalization • denotes ‘a-kind-of’ or ‘is-a’ relationship

between a superclass and its subclasses. • For example, a car is a vehicle, or in other

words, Car represents a subclass of the more general superclass Vehicle.

• Each subclass inherits all features of the superclass.

2) Aggregation • is ‘a-part-of’ or ‘part-whole’ relationship in

which several subclasses representing components are associated with a superclass representing a whole.

• For example, an engine is a part of a car.

3) Association • describes some semantic relationship between

different classes which are unrelated otherwise. • For example, Mr Black owns a house, a car and a

computer. • Such classes as House, Car and Computer are

mutually independent, but they are linked with the frame Mr Black through the semantic association.

• Unlike generalization and aggregation relationships, associations usually appear as verbs and are inherently bi-directional.

• Does a computer own Mr Black? • Of course, the name of a bi-directional

association reads in a particular direction (Mr Black owns a computer), but this direction can be changed to the opposite.

• The inverse of owns is belongs to, and thus we can anticipate that a computer belongs to Mr Black.

• In fact, both directions are equally meaningful and refer to the same association.

• Figure 5.4 illustrates all three types of relationships between different objects.

3. Inheritance in frame-based systems

• Inheritance is an essential feature of frame-based systems.

• Inheritance can be defined as the process by which all characteristics of a class-frame are assumed by the instance-frame.

• A common use of inheritance is to impose default features on all instance-frames.

• We can create just one class-frame that contains generic characteristics of some object or concept, and then obtain several instance-frames without encoding the class-level characteristics.

• A hierarchical arrangement of a frame-based system can be viewed as a tree that is turned over.

• The highest level of abstraction is represented at the top by the root of the tree.

• Branches below the root illustrate lower levels of abstraction, and leaves at the bottom appear as instance-frames.

• Each frame inherits characteristics of all related frames at the higher levels.

• Figure 5.5 shows a hierarchy of frames representing zero-emission (ZE) vehicles.

• The root, ZE vehicle, has three branches: – Electric vehicle, – Solar vehicle and – Muscle vehicle.

• Let us now follow just one branch, the Electric vehicle branch.

• It is subdivided into – Car, – Motorcycle and – Scooter.

• Then Car branches into – Sedan, – Van and – Truck.

• Finally, the leaf, the instance-frame Ford Ecostar, appears at the bottom.

• The instance Ford Ecostar inherits all the characteristics of its parent frame.

• The instance Ford Ecostar indeed has only one parent, the class-frame Van.

• Furthermore, in Figure 5.5, any frame except the root frame ZE vehicle has only one parent.

• In this type of structure, each frame inherits knowledge from its parent, grandparent, great-grandparent, etc.

3.1 Can a frame have more than one parent?

• In many problems, it is quite natural to represent objects relating to different worlds.

• For example, we may wish to create a class of muscle-solar-electric vehicles.

• In such vehicles, people can pedal, while an electric drive system is used to travel uphill, and solar panels assist in recharging batteries for the electric system.

• Thus, the frame Muscle-Solar-Electric vehicle should combine specific properties of three classes, – Muscle vehicle, – Solar vehicle and – Electric vehicle.

• The only requirement for multiple parent inheritance is that attributes of all parents must be uniquely specified.

• In frame-based systems, several classes can use the same attribute names.

• However, when we use multiple inheritance, all parents must have unique attribute names.

• If we want, for example to create a child class Muscle-Solar-Electric vehicle related to parents Muscle vehicle, Solar vehicle and Electric vehicle, we must get rid of such properties as Weight and Top speed in the parent classes.

• Only then can we create the child class. • In other words, to create multiple inheritance

we must reconsider an entire structure of our system, as can be seen in Figure 5.6.

• In frame-based systems, inheritance means code reuse, and the job of the knowledge engineer is to group similar classes together and reuse common code.

• The most important advantage of inheritance is the conceptual simplification, which is achieved by reducing the number of independent and specific features in the expert system.

3.2 Are there any disadvantages?

• Brachman and Levesque (1985) argue that if we allow unrestrained overwriting of inherited properties, it may become – impossible to represent either definitive

statements (such as ‘all squares are equilateral rectangles’) or

– contingent universal conditions (such as ‘all the squares on Kasimir Malevich’s paintings are either black, red or white’).

• In general, frame-based systems cannot distinguish between – essential properties (those that an instance must

have in order to be considered a member of a class) and

– accidental properties (those that all the instances of a class just happen to have).

• Instances inherit all typical properties, and because those properties can be overwritten anywhere in the frame hierarchy it may become impossible to construct composite concepts when using multiple inheritance.

• This appears to undermine the whole idea of the frame knowledge representation.

• However, frames offer us a powerful tool for combining declarative and procedural knowledge, although they leave the knowledge engineer with difficult decisions to make about the hierarchical structure of the system and its inheritance paths.

• Appeals to so-called ‘typical’ properties do not always work, because they may lead us to unexpected results.

• Thus, although we may use frames to represent the fact that an ostrich is a bird, it is certainly not a typical bird, in the way that an eagle is.

• Frame-based expert systems, such as Level5 Object, provide no safeguards against creating incoherent structures.

• However, such systems do provide data and control structures that are more suited for the simulation of human reasoning than any conventional programming language.

• Furthermore, to combine the power of both techniques of knowledge representation – rules and frames – modern frame-based expert systems use rules for interaction with information contained in the frames.

4. Methods and demons

• As we have already discussed, frames provide us with a structural and concise means of organizing knowledge.

• However, we expect an expert system to act as an intelligent assistant – we require it not only to store the knowledge but also to validate and manipulate this knowledge.

• To add actions to our frames, we need methods and demons.

• A method is a procedure associated with a frame attribute that is executed whenever requested (Durkin, 1994).

• We write a method for a specific attribute to determine the attribute’s value or execute a series of actions when the attribute’s value changes.

• Most frame-based expert systems use two types of methods: – WHEN CHANGED and – WHEN NEEDED.

• In general, a demon has an IF-THEN structure. • It is executed whenever an attribute in the

demon’s IF statement changes its value.

• In this sense, demons and methods are very similar, and the two terms are often used as synonyms.

• However, methods are more appropriate if we need to write complex procedures.

• Demons, on the other hand, are usually limited to IF-THEN statements.

4.1 WHEN CHANGED method

• A WHEN CHANGED method is executed immediately when the value of its attribute changes.

• The class Action Data, shown in Figure 5.8, is used to control the input display.

• The user can move to the next, previous, first or last request in the list of requests and examine the business data.

• The WHEN CHANGED methods here allow us to advance through a list of requests.

• Note that all attributes in Figure 5.8 are declared as simple [S].

• Simple attributes can assume either a value of TRUE or FALSE.

• Let us examine the WHEN CHANGED method attached to the attribute Goto Next.

4.2 How does this method work?

• Any method begins with the reserved words WHEN CHANGED or WHEN NEEDED, which are followed by the reserved word BEGIN and a series of commands to be executed.

• The reserved word END completes a method. • To refer to a particular attribute in a method,

we must specify the class name as well as the attribute name.

• The syntax is: <attribute name> OF <class name>• To show the attribute values on the input

display, we have to create value-boxes (display items that show data) and then attach these value-boxes to the appropriate attributes.

• When we run the application, the value-boxes show the attribute values of the currently selected instance of the class Request and WHEN CHANGED methods cause actions to occur.

• In many applications, an attribute is assigned to some initial or default value.

• However, in some applications, a WHEN NEEDED method can be used to obtain the attribute value only when it is needed.

• In other words, a WHEN NEEDED method is executed when information associated with a particular attribute is needed for solving the problem, but the attribute value is undetermined.

• We will return to this method when we discuss rules for our credit evaluation example.

5. Interaction of frames and rules

• Every rule has an IF-THEN structure, and every rule relates given information or facts in its IF part to some action in its THEN part.

• However, in frame-based systems, rules often use pattern matching clauses.

• These clauses contain variables that are used for finding matching conditions among all instance-frames.

5.1 What causes rules to fire?

• In a rule-based expert system, the inference engine links the rules contained in the knowledge base with data given in the database.

• When the goal is set up – or in other words when an expert system receives the instruction to determine a value for the specified object – the inference engine searches the knowledge base to find a rule that has the goal in its consequent (THEN part).

• If such a rule is found and its antecedent (IF part) matches data in the database, the rule is fired and the specified object, the goal, obtains its value.

• If no rules are found that can derive a value for the goal, the system queries the user to supply that value.

• In a frame-based system, the inference engine also searches for the goal, or in other terms for the specified attribute, until its value is obtained.

• In a rule-based expert system, the goal is defined for the rule base.

• In a frame-based system, rules play an auxiliary role.

• Frames represent here a major source of knowledge, and both methods and demons are used to add actions to the frames.

• Thus, we might expect that the goal in a frame-based system can be established either in a method or in a demon.

• Let us return to our credit evaluation example.• Suppose we want to evaluate the credit

request selected by the user. • The expert system is expected to begin the

evaluation when the user clicks the Evaluate Credit pushbutton on the input display.

• This pushbutton is attached to the attribute Evaluate Credit of the class Credit Evaluation shown in Figure 5.10.

• The attribute Evaluate Credit has the WHEN CHANGED method attached to it, and when we select the Evaluate Credit pushbutton at run time, the attribute Evaluate Credit receives a new value, a value of TRUE.

• This change causes the WHEN CHANGED method to execute.

• The PURSUE command tells Level5 Object to establish the value of the attribute Evaluation of the class Credit Evaluation.

• A simple set of rules shown in Figure 5.11 is used to determine the attribute’s value.

5.2 How does the inference engine work?

• Based on the goal, Evaluation OF Credit Evaluation, the inference engine finds those rules whose consequents contain the goal of interest and examines them one at a time in the order in which they appear in the rule base.

• That is, the inference engine starts with RULE 9 and attempts to establish whether the attribute Evaluation receives the Give credit value.

• This is done by examining the validity of each antecedent of the rule.

• In other words, the inference engine attempts to determine first whether the attribute Collateral has the value of Excellent, and next whether the attribute Financial rating is Excellent.

• To determine whether Collateral OF Credit Evaluation is Excellent, the inference engine examines RULE 1 and RULE 2, and to determine whether Financial rating OF Credit Evaluation is Excellent, it looks at RULE 8.

• If all of the rule antecedents are valid, then the inference engine will conclude that Evaluation OF Credit Evaluation is Give credit.

• However, if any of the antecedents are invalid, then the conclusion is invalid.

• In this case, the inference engine will examine the next rule, RULE 10, which can establish a value for the attribute Evaluation.

• Based on the set of rules provided for credit evaluation, the inference engine cannot establish the value of the attribute Evaluation in some cases.

• This is especially true when the collateral is good and the financial rating of the business is excellent or good.

• In fact, if we have a look at Figure 5.10, we find cases that are not represented in the rule base.

• However, it is not necessary always to rely on a set of rules.

• We can use the WHEN NEEDED method to establish the attribute value.

• The WHEN NEEDED method shown in Figure 5.10 is attached to the attribute Evaluation.

• The inference engine executes this method when it needs to determine the value of Evaluation.

• When the WHEN NEEDED method is executed, the attribute Evaluation receives the value Consult a superior.

• In our case, if the WHEN NEEDED method were executed first, the attribute Evaluation would always receive the value Consult a superior, and no rules would ever be fired.

• Thus, the inference engine has to obtain the value from the WHEN NEEDED method only if it has not been determined from the rule base.

• In other words, the search order for the attribute value has to be determined first.

• It can be done, for example, by means of the SEARCH ORDER facet attached to an attribute that tells the inference engine where, and in what order, to obtain the value of this attribute.

• In Level5 Object, a search order can be specified for every attribute, and in our credit evaluation example, we set the search order for the Evaluation value to RULES, WHEN NEEDED.

• It makes certain that the inference engine starts the search from the rule base.