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 objectoriented 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 instanceframe 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 framebased 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 framebased 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 classlevel 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.