Contents of the OOPS.TXT file

This file was captured from a series of messages written by Gordon Lee anduploaded to the OOPS conference on the Interlink network. Lee is the AIconference moderator on that network. Unfortunately, a couple of messagesin the sequence were not posted for some reason.

An Example In terms of the house-painting example, the COLOUR slotmight have a symbolic representation (e.g., "RED" rather than"fire-engine red" or "colour 7329"), while the PRICE slot mighthave a decimal representation. The SURFACES slot might be amultivalued slot containing a number of terms on which the paintcould be applied. The INSTRUCTIONS slot might contain Englishtext describing the manner of application of the paint, while theGLOSS slot might have a logical representation (e.g., "TRUE") asin Figure 3.

Value Forms As the example illustrates, many different forms mightappropriately be used to represent values. An applicationdeveloper would typically employ some of the following types ofrepresentation in a system:

Restrictions So far, no restrictions have been placed on the possiblecontents of a particular slot. Thus, while a decimal value mightlogically be expected in the price slot (e.g., 12.99), nothingwould prevent an entry of TWELVE DOLLARS AND NINETY NINE CENTSfrom being made. Even worse, a nonprice value could be stored inthe slot (e.g., LATEX). Since such values would not be verymeaningful, certain restrictions on slot contents must often beapplied. Although several types of restrictions might beapplied, only three are discussed at this point:

1. Restrictions on the form of the representations (e.g., only decimal values permitted) 2. Restrictions on the value that can be stored (e.g., only prices between 9.99 and 19.99 permitted) 3. Restrictions that are independent of specific values (e.g., no more than three values in the slot.

Representation Restrictions To be able to process knowledge contained in the slots offrames, the reasoning system must be able to interpret the valuesin a slot unambiguously; it must know (and be able to understand)the form of representation of the knowledge in the slot.Consider the COLOUR slot, for example, containing the value RED.For the term to be meaningful, the inferencing mechanism mustinterpret RED as a symbol (from which the meaning "fire-enginered" might be inferred) rather than as text (i.e., the threeletters R, E, and D).

To accomplish this the knowledge engineer can attach arestriction to a slot, limiting the form of the value(s) that canbe stored in it. In the case of the COLOUR slot, for example,the following restriction could be applied:

RESTRICTION: (VALUE-TYPE:SYMBOL)

Similarly, the PRICE slot might be restricted to holddecimal values, the GLOSS slot logical values, and so forth.

Value Restrictions Ensuring that a slot's value has the proper form ofrepresentation only solves part of the problem, for the valueitself, when interpreted correctly, must also be meaningful.Assume for the moment that there are only four colours of outsidepaint - fire-engine red (with symbol RED), chocolate brown (withsymbol BROWN), creamy pearl (with symbol WHITE), and forest moss(with symbol GREEN). Under these circumstances, the symbolMAGENTA in the COLOUR slot would be in error, just as a value of$ or % would be in error. Yet, both MAGENTA and $ are validsymbols. Thus, a further restriction must be attached to theslot, limiting the specific symbols that can be stored in it toonly those that represent valid paint colors. In the case of theCOLOUR slot, for example, the following restriction could beapplied:

RESTRICTION: (CONTENT-ONE-OF: RED BROWN WHITE GREEN)

This restriction would exclude values that represented paintcolours not offered (e.g., MAGENTA) as well as values that do notrepresent a paint colour (e.g., $).

A variety of similar restrictions might be placed on otherslots. For example, values in the PRICE slot might beconstrained to fall within a range of numbers or to excludecertain numbers (e.g., even dollar amounts). Consider, forexample, a slot containing the floor on which a particular officeis located in a 50-story building. The restriction placed onsuch a slot might contain a mixture of ranges and specificvalues, such as:

RESTRICTION: (CONTENT-ONE-OF: G B LL M 2:12 14:48 P R)

On the other hand, because of the variety of floor namesthat might be possible (e.g., garage, basement, lower-level,mezzanine, penthouse, roof), the developer may need to specifyonly what may not be used as a floor name (e.g., the 13th floor).

RESTRICTION: (CONTENT-NOT-ONE-OF: 13)

Other Types of Restrictions The developer might wish to apply several other types ofrestrictions in appropriate situations. For example, the maximum(or minimum) number of values that could be placed in a slot atany one time might be specified. Consider the house paintingexample again. If the mixing of paint colours is to prevented,the COLOUR slot could be constrained to holding a single colouras follows:

RESTRICTION: (MAX-NUMBER-OF-VALUES: 1)

Similarly, the relation that the frame might bear to other framescan be constrained.

What Controls How a Slot Is Treated? The previous subsection described some of the types ofrestrictions that a developer might wish to place on the contentsof a slot, but such restrictions are not the only type ofspecification that might be used to control particular aspects ofslot value processing. For example, the developer might like tospecify the type font and point size with which a value should bedisplayed. Thus, some mechanism is needed by which a valueshould be displayed. Thus, some mechanism is needed by whichsuch control information can be attached to slots in a frame.

Facets This mechanism is the "facet." Facets contain certain typesof information that are related to a slot. A variety ofdifferent facets may be attached to the same slot, each providinga different type of control parameter or characteristic. Thecontents of the appropriate facet are checked whenever aparticular type of action is to be performed (e.g., fetch, store,display, query) in connection with a slot value.

Standard Facets A knowledge-based application development tool (shell)offering frame-based representations will likely provide a numberof standard facets. That is, any application generated using thetool would contain the necessary program code or instructions toperform the required processing of any values contained in one ofthese standard facets. The application developer need onlyprovide the appropriate contents of a facet in order for thatfacet to be effective in providing its intended function.

Adding a facet structure to a frame, then, provides amechanism for representing the various types of slot valuerestrictions discussed previously as well as for representingother characteristics such as display format. Some of thestandard facets that a knowledge-based application developmenttool (shell) might provide for each slot in a frame include:

* Permitted representational form(s) for the values in the slot * Permitted values for the slot * Maximum number of values permitted in the slot * Minimum number of values permitted in the slot * Display format for the slot's value * Explanation about the purpose or meaning of the slot * Text of question to be asked in the event that the user is requested to provide a value for the slot * Text of response to be provided should the user question the purpose of the request for a slot value.

A variety of other facets that relate to inheritance and classstructure relationships might also be made available.

Active Values Facets can be used to support a number of special-purposecapabilities. Since access to a slot value in a frame takesplace only after the system refers to the relevant facetscontrolling access, setting up a facet to indicate that a slotvalue is active is relatively easy. That is, any access to anactive slot turns control over to an "active value" routinebefore access is made.

Frame-based systems commonly provide a number of standardactive value routines that will plot, graph, or signal the valueeach time the slot's contents change. However, the knowledgeengineer can also use active values as a monitoring capability byspecifying a routine to be given control each time access is tobe made to a slot. Access may be intercepted just prior to adata store or immediately after a data fetch. The routinereceiving control may then modify or substitute values, log theaccess, or turn control over to the user to browse the knowledgebase. This mechanism provides the knowledge engineer with aneasily created filter, enabling values to be range- and type-checked either before they are stored or before they are returnedto the requesting program or rule.

Active values can be used as a regular part of the knowledgerepresentation. Thus, the storage of a particular value in astate slot can be used as the trigger to initiate the processingof a specified rule-set. However, active values also offer theknowledge engineer a handy debugging mechanism. An active valuecan readily be attached to a slot, with control being turned overto the knowledge engineer (or his/her debugging routine) whenactivated. Various system values can be examined and displayedbefore regular execution of the application is resumed. Thiscapability is perhaps the most valuable testing and debuggingtool provided by a frame-based system.

Developer-Specified Facets Generally speaking, a knowledge-based applicationdevelopment tool cannot provide all of the facets that adeveloper might wish to attach to a particular slot. The onesdescribed in the previous subsection could be viewed as genericfacets, facets that are related to the reasoning process ingeneral and that are unrelated to any particular application.Because additional problem-dependent facets are also needed,however, the development tool should offer a mechanism that willenable the developer to define and add facets that are related tothe particular application. Of course, the developer will alsohave to provide the necessary programming to implement handlingof the facet!

Consider the following example of a developer-specified orapplication-dependent facet, in which the developer wants to usethe facet to record the source from which the current value of aslot was obtained (e.g., input by the user, initialized defaultvalue using Rule 7 of Rule-Set 3). This facet would be analogousto the "why" facet. Instead of containing the text of anexplanation, however, the facet would contain the source fromwhich the current slot value was obtained. Specifying a newfacet is generally quite easy with tools (shells) that permitdeveloper-specified facets. In addition to creating the facet,however, the developer must also provide the mechanism toimplement the facet's intent. In the case of the "how" facet,the developer would have to create a mechanism to trap any storeinto the slot, backtrack to determine the appropriate sourcedesignation for that value, store that designator in the facet,and complete the trapped store (i.e., putting the value in theslot as originally attempted).

Where Are Frames Useful? Frames are useful in categorizing knowledge when thatknowledge has some underlying structure. If the knowledge can berelated to a set of objects or concepts, then at least a portionof the facts contained in the knowledge base can be clusteredaround those objects or concepts.

To illustrate, consider a knowledge base dealing withautomobiles. By clustering the knowledge around each type ofautomobile, a user could obtain information on Chevrolets withouthaving to search through all the knowledge about automobiles.This type of retrieval would take advantage of the framestructure, referring only to the slots in a particular frame.Similarly, the user could obtain information on tire typeswithout having to search through all the knowledge in theknowledge base, looking at a particular slot in a number offrames. This type of retrieval would take advantage of the slotstructure. These two types of access to the knowledge areillustrated in Figure 5. The frame structure permits theknowledge engineer and the domain expert to view the contents andstructure of the knowledge base in a way that facilitates greaterunderstanding as well as a greater ability to detect inconsistentor incomplete data.

Thus, in the rough design portion of the feasibility study,the knowledge engineer should be looking at the characteristicsof the knowledge that is expected to be placed in the knowledgebase, identify whether it will likely consist of a loosecollection of unrelated facts or whether it will likely consistof a number of clusters of related facts. The knowledge engineershould search to identify not only what objects or concepts(around which knowledge can be clustered) but also how many suchobjects and concepts might exist. The larger the number, thegreater the advantage a frame-based representation can provide.

STRUCTURE

Thus far, frames have not been related to each other in anyway. The illustrations have just shown frames without anyconnection among them. In practical applications, however, theobjects or concepts represented by frames often do bear somerelationship to each other. Part of the power of a frame-basedrepresentation is its ability to capture such relationships andto represent this structure in the knowledge base.

One way to view such relationships is with the concept ofrefinement. That is, as attention shifts systematically from oneframe to the next in a collection of related frames, the idea orobject represented by each frame becomes progressively eithermore general or more specific. The description in the followingsubsections moves in what is commonly viewed as the downwarddirection, from general to specific. (Related frames aregenerally displayed as a two-dimensional hierarchy, with the moregeneral frames at the top of the display and the more specificframes at the bottom. Hence, traversing frames from general tospecific implies movement down the page.)

Classes The term "class" is used to denote a frame containing theknowledge about a set or class of objects of a given type. Thus,a frame might be established for the class AUTOMOBILE. All otherclusters of knowledge about particular aspects of automobileswould be associated with subordinate frames. However, knowledgeabout unrelated concepts would be associated with frames indifferent classes. Thus, the knowledge base might contain theclasses AUTOMOBILE, KITCHEN-UTENSILS, and SHOES, as shown inFigure 6.

Subclasses The frames in a "subclass" represent a particularization ora specialization of the class to which they relate. Thus, theclass AUTOMOBILES might have the subclasses of DOMESTIC andIMPORTED, as shown in Figure 7. The frames representing thesetwo subclasses would have more specialized information thatpertains to one of the two types of automobiles (i.e., domesticcars or imported cars) but that does not pertain to the class ofautomobiles as a whole. The subclass provides additionalknowledge beyond what is available at the class level. Thesubclass is thus different from a mathematical subclass; itrepresents a narrowing of the concept but also an expansion ofthe information about the concept. _____________________ | AUTOMOBILES | |_____________________| ______|______ __________________|___ ___|_________________ | DOMESTIC | | IMPORTED | |______________________| |_____________________|

Figure 7: Two Subclasses of Automobiles

Note that subclasses are themselves classes, for they inturn can have subclasses. To avoid confusion, we shall refer toclasses and subclasses alike as classes. Since classes derivingfrom another class can give rise to further derivative classes,the concept specialization process can continue iteratively.Each lower class in the hierarchy represents a furtherspecialization of the concept. (Or, looking at the hierarchy theother way, each class represents a generalization of asubordinate class.) Thus, the class DOMESTIC might have threesubclasses representing automobiles manufactured by threecompanies: CHEVROLET, FORD, and CHRYSLER. The class FORD mightin turn have two subclasses representing two different modelsmanufactured: RANCHERO and LTD. This process could continue onto body type (e.g., sedan, station wagon) and other features.This class hierarchy is shown in Figure 8.

Although not shown in Figure 8, each of the other domesticautomobile classes (e.g., CHEVROLET) could be broken down intomodel based subclasses, and the IMPORTED class could have asimilar class graph attached to it.

This class structure serves to structure the knowledge, andthe resulting class hierarchy is often referred to as a"taxonomy." Thus, the structure in Figure 8 would be referred toas the automobile taxonomy.

The graph of the class hierarchy can be viewed as an upside-down tree. The class at the top represents the root of the tree,while the instance at the bottom represents the leaves. Just asnothing grows from the leaves of a real tree, so does nothinggrow from the leaves of the frame tree. There is nocategorization more specialized than the instance.

Intersecting Hierarchies The automobile taxonomy illustrated in Figure 9 was createdas an isolated knowledge structure, but this need not be thecase. Classes and instances can be related between taxonomies.Consider two other taxonomies about trucks and the other theknowledge about engines.

Figure 10a shows the class TRUCKS broken down into twosubclasses, SPECIAL-PURPOSE and CARGO. The SPECIAL-PURPOSE classis further broken down into two subclasses, FIRE-TRUCK and TOW-TRUCK, while the CARGO class is broken down into GENERAL-GOODS,TANK, and CATTLE. The general goods class is broken down into1/2-TON, 1-TON, and 2-TON subclasses, and the 1/2-ton class hastwo instances. A much broader taxonomy could be developed, butthis brief one will serve to illustrate a point.

The Ranchero is an interesting vehicle in this context.Because it consists of the front half of a passenger car and therear half of a truck, the RANCHERO class (or any instance of thatclass) relates to concepts in both hierarchies. Thisrelationship is represented in Figure 10b by the dotted lineconnecting the instance MY-FORD to the class RANCHERO (making ita member of AUTOMOBILES) and to the class 1/2-TON (making it amember of TRUCKS), which means that MY-FORD is an instance ofboth classes and has all the properties of a Ranchero automobileand all the properties of a 1/2-ton truck. Such a passing ofproperties from class to class or instance and from multipleclasses to another class or instance illustrates the"inheritance" of properties down through the knowledge taxonomy.The concept of inheritance is discussed later. ______________________ _____________________ | AUTOMOBILES | | TRUCKS | |______________________| |_____________________| | | __________|___________ __________|__________ | DOMESTIC | | CARGO | |______________________| |_____________________| | | __________|___________ __________|__________ | FORD | | GENERAL-GOODS | |______________________| |_____________________| | | __________|___________ __________|__________ | RANCHERO | | 1/2-TON | |______________________| |__________.__________| : : __________:___________ : | MY-FORD |................: |______________________| :

Figure 10b: Skeleton of Two Taxonomies

Connections can also be made higher up in the taxonomy(i.e., between classes). For example, the class RANCHERO couldbe related as a subclass of both the FORD and GENERAL-GOODSclasses, as shown in Figure 10c.

This relationship would imply that all Ranchero were domesticFord automobiles and that they were all general-goods carryingtrucks (no cattle trucks or fire engines), but it would not implyanything about the load-carrying capacity of the Ranchero. Thus,the connection between RANCHERO and GENERAL-GOODS implies thatthe RANCHERO automobiles are a particularization of the classFORD (and all classes above it). However, none of the knowledgein the tree extending below GENERAL-GOODS has any fixed relationto RANCHERO automobiles. Thus, RANCHERO vehicles are potentiallyeligible to have either 1/2-TON, 1-TON, or 2-TON capacities.

Now consider the engine taxonomy. As shown in Figure 11a,the class ENGINES is broken down into the subclasses DIESEL andGASOLINE. The GASOLINE class is further broken down intoCARBURETED and FUEL-INJECTED subclasses. The FUEL-INJECTED classis further divided into cylinder-based subclasses. Although notshown in Figure 11a, similar subtrees would extend down from theCARBURETED and DIESEL classes.

Assume for the moment that MY-FORD has an 8-cylinder, fuel-injected, gasoline engine. The novice knowledge engineer mightbe tempted to establish a relation similar to the one shown inFigure 11b, making MY-FORD a subclass of both RANCHERO and 8-CYLINDER. After all, MY-FORD does have an 8-cylinder engine withall the properties indicated in the 8-CYLINDER, FUEL-INJECTED,GASOLINE, and ENGINES classes. However, while MY-FORD is aparticularization of the classes RANCHERO, FORD, DOMESTIC, andAUTOMOBILES, it is not a particularization of any of the classes8-CYLINDER, FUEL-INJECTED, GASOLINE, or ENGINES. The car I amdriving has an engine, but it is "not" an example or instance ofan engine. Therefore, a different type of connection is needed.

The proper relationship is of the form "contains" or"has-a." Thus, the knowledge engineer could specify that allRancheros contain fuel-injected engines by using the relation:

RELATION: RANCHERO HAS-A FUEL-INJECTED

This relation is indicated by the solid line connecting thesides of the RANCHERO and FUEL-INJECTED class boxes in Figure11c. Such a relation indicates that every Ranchero vehicle has afuel-injected, gasoline-powered engine. All of thecharacteristics of such an engine are available to the RANCHEROframe, but there is no implication that the RANCHERO is aninstance of FUEL-INJECTED. Relations are discussed in greaterdetail in the section of relationship knowledge.

Where Are Structures Useful? The arrangement of frames in a structural relationshipoffers several advantages. Most importantly, the visualrepresentation of the relationships between frames aids theknowledge engineer in understanding the underlying structure ofthe knowledge, thereby facilitating the development of theapplication. Not only does it aid in determining where to placeknowledge in the knowledge base, but it can guide the knowledgeacquisition process. By viewing the structure and consideringthe areas in which knowledge has and has not been acquired, theknowledge engineer can determine where further acquisitionefforts might appropriately be directed.

The structured relationship of frames in a taxonomy is alsoa means of storing knowledge. The fact that MY-FORD is aRANCHERO provides additional knowledge about MY-FORD. Similarly,additional knowledge is provided by the linkages indicating thatthe car is manufactured by Ford, that it is a domestic vehicle,that it is a general-goods carrying truck, and so forth. Thisknowledge is available not only to the knowledge engineer but toinference mechanisms as well.

Frame-Based Reasoning Because the knowledge contained in a frame's slots isavailable to inference mechanisms, a rule could reason about thecharacteristics of a frame by referring to its slot values.Assume that the application involves planning a route to bedriven and that a rickety bridge is to be avoided if the vehicleis too heavy. A rule such as the following might be placed inthe knowledge base:

RULE 1: IF WEIGHT of MY-FORD >3000 pounds THEN take detour around rickety bridge

If the value of the WEIGHT slot of the frame MY-FORD is greaterthan 3000 pounds, then the plan should include a detour aroundthe rickety bridge.

Similarly, rules can be used to process the structuralknowledge contained in a taxonomy. The following rule, whichmight be one of a set determining at what type of service stationthe driver should stop to refuel his car, is illustrative.

RULE 2: IF ?VEHICLE is MEMBER-OF AUTOMOBILES AND ?VEHICLE HAS-A ?ENGINE AND ?ENGINE is MEMBER-OF DIESEL THEN set REFUEL of ?VEHICLE to TRUCKSTOP

Rule 2 is a bit more complicated that it looks. On thefirst line the inference engine attempts to "instantiate" thevariable ?VEHICLE with every frame, but only those instantiationsthat are members of the class AUTOMOBILES are kept. At thispoint several vehicles might qualify, so several instances of therule would be established (e.g., with vehicle-1, vehicle-2). Thesecond line instantiates the variable ?ENGINE with any frame that?VEHICLE points to with a HAS-A relation. Thus, if vehicle-1 hadan engine and, say, a fuel-tank, the rule would be instantiatedtwice - once with ?VEHICLE = vehicle-1 and ?ENGINE = ENGINES andonce with ?VEHICLE = vehicle-1 and ?ENGINE = FUEL-TANK.

The third line of the rule then throws out any instantiationof the rule for which ?ENGINE is not a member of the classDIESEL. Thus, only those rule instantiations for which thespecified conditions are satisfied will be left at the end ofline three. The fourth line then sets the slot REFUEL of theassociated vehicle to the value TRUCKSTOP. If there were fiveautomobiles with diesel engines, Rule 2 would be instantiatedfive times and would fire five times, once with each eligibleautomobile.

Similarly, rules can be developed that create structure inthe taxonomy, associating one class with another. Reasoning witha knowledge taxonomy is not the exclusive province of rules,although many frame-based systems use rule-based knowledgeextensively. However, procedural knowledge of the type found in"blackboard" systems can process frame-based knowledge quiteefficiently.

Hierarchical Reasoning The arrangement of knowledge from general to specific withina knowledge taxonomy matches the type of reasoning that is usedin many types of applications. For example, consider the problemof classifying a truck by its purpose or function. Usually thetruck is categorized more by eliminating all of the functionsthat is cannot serve than by identifying its purpose. Thiselimination can take place at various levels in the hierarchy,depending on the type of knowledge known about the candidatetruck. Thus, at one level there might be a rule:

RULE: IF MANUFACTURER of ?TRUCK is CHRYSLER THEN ?TRUCK is NOT MEMBER-OF FIRE-TRUCK

Assuming Chrysler does not manufacture any fire trucks, a singlerule at this level can eliminate a number of class and subclasspossibilities.

Another method of elimination can be illustrated at anotherlevel. For example, assume that the capacity of the truck couldbe identified as 1/2-TON. Then a rule as the following wouldserve to put the identified function of any frame having a 1/2-ton capacity in the slot POSSIBLE-FUNCTIONS:

RULE: IF CAPACITY of ?TRUCK is 1/2-TON AND CAPACITY of ?POSSIBILITY is 1/2-TON AND ?TRUCK NOT ?POSSIBILITY THEN ADD FUNCTION of ?POSSIBILITY to POSSIBLE-FUNCTIONS of ?TRUCK

Because of the tree structure of the knowledge taxonomy,fewer frames need be considered at a higher level than at a lowerlevel. Thus, the reasoning can take place more efficiently at ahigher level if data availability and desired output permit. Forexample, consider the problem of identifying the type of truck touse to satisfy a particular requirement such as carrying aliquid. In this case, the inference engine might be able toselect a tank truck as belonging to a class of trucks that wouldsatisfy the requirement without ever considering the type orvolume of liquid to be carried.

Planning can be carried out on multiple levels. Forexample, at the first level the reasoning goal would be todetermine whether a type of truck equipped to transport a liquidcargo existed. Having determined this, the inference mechanismmight then focus on a narrower problem, namely, checking the costand availability of each qualifying tank truck.

Should no tank truck satisfying the cost and availabilityrequirements exist, the inference mechanism might go back up alevel to consider another type of truck that might be able totransport a liquid cargo (e.g., a general-cargo carrier with aportable tank placed in the cargo area).

The hierarchical structuring of frame-based representationsis consistent with this type of reasoning. Even if theapplication does not involve a sequence of objects or concepts atprogressively greater levels of detail, it may well involvemultilevel reasoning, using completely different sets of objectsat each level. Such reasoning can be greatly facilitated byhaving a compatibly structured knowledge representation.

At the time of the feasibility study and during the earlydesign phases of the project, the knowledge engineer shouldtherefore be looking at the characteristics of the expertise thatis to be captured about the application domain. Questions suchas the following should be asked:

* Do the objects and concepts of the domain bear a relationship to each other? * Are there large numbers of related frames? * Does the reasoning process involve multiple levels of detail about particular types of objects?

Affirmative answers tend to indicate an appropriate situation forthe use of a frame-based representation.

INHERITANCE

The previous section indicated that frames at lower levelsof a taxonomy could obtain properties from frames at higherlevels in the taxonomy. Knowing that FORD is a subclass ofDOMESTIC automobiles and of AUTOMOBILES permits certainadditional information about Fords to be inferred, namely, thatthey had the general properties of automobiles (e.g., fourwheels) as well as the additional properties of domestic cars(e.g., English rather than metric dimensions). The mechanism forpassing such knowledge from frame to frame down through thetaxonomy from general to specific is known as "inheritance."

Passing Properties Each subclass can be given certain properties of its parentclass. Thus, the general knowledge about automobiles would beinherited (made available) in every frame at the DOMESTIC classlevel. This knowledge would further be inherited by each frameat the manufacturer class level (e.g., FORD), by the framesrepresenting all the models of a manufacturer (e.g., the LTDclass), as well as by each instance frame (e.g., MY-FORD).Similarly, the additional knowledge provided by the DOMESTICclass (i.e., the additional knowledge that is not contained inthe class AUTOMOBILES) would also be inherited downward to allframes at the manufacturer, model, and instance levels of thehierarchy.

The discussion thus far has focused on the inheritance ofslot values from a parent frame to a child or offspring frame inan iterative manner throughout a structured hierarchy. However,a frame can inherit many types of properties from its parents.No individual development tool (shell) may provide the full rangeof inheritance capabilites, but the discussion in the nextsubsection is intended to show the types of inheritance that aknowledge engineer might find useful for a particularapplication.

Types of Inheritance A slot in a frame might inherit a variety of properties,ranging from specific values to structural characteristics, asillustrated by the four types of inheritance described below.

Types of Inheritance: Slot "Slot inheritance" takes place when the slot itself, but notits value, is inherited from a parent frame. Thus, in Figure12a, the WHEELS slot would be inherited by every descendantsubclass from the class AUTOMOBILES, but the slot value would notbe inherited. That is, the classes DOMESTIC and IMPORTED wouldhave a property called WHEELS, but there would be no implicationabout how many wheels a domestic or imported automobile mighthave. The (3 4) values of the WHEELS slot of AUTOMOBILES wouldnot be inherited.

Further, the WHEELS slot of DOMESTIC might be given a valueof 4, since no 3-wheeled automobiles are made domestically. Asshown in Figure 12b, this assignment would not affect the valuesof the WHEELS slot of any other frame in the hierarchy.

Types of Inheritance: Value "Value inheritance" takes place when the value of a slot ina frame is inherited from the corresponding slot of the parent.Thus, if the AUTOMOBILE frame had a slot called CARRIES with avalue of (PASSENGERS, CARG0), the corresponding slot in theDOMESTIC and IMPORTED frames would be given the value(PASSENGERS, CARGO), indicating that those vehicles similarly cancarry both passengers and cargo. Similarly, this value wouldautomatically appear in the CARRIES slot of each descendant framein the hierarchy as shown in Figure 13a.

Types of Inheritance: Restriction "Restriction inheritance" takes place when it is therestrictions on values, rather than the values themselves, thatare inherited. Thus, a constraint on the WHEELS slot ofAUTOMOBILES to permit only 3- and 4-wheeled vehicles would bebinding on all subclasses and instances of AUTOMOBILES, but nospecific value would be implied (see Figure 14).

Types of Inheritance: Null In some cases inheritance is not desirable, and all of itsforms should be inhibited. Thus, for example, the FORD frameshown in Figure 15 might have a slot named FLEET-MPG, containingthe average miles-per-gallon rating of all the cars produced bythe manufacture. This rating is a property of the class FORD; itis not a description of any class or instance properties. Thus,neither the slot FLEET-MPG nor its value should be inheriteddownward from the manufacturer frames.

Multiple Inheritance Figures 10b and 10c showed how a given frame (whetherinstance or class) might derive from more than one parent. Inthe latter figure, the RANCHERO class was shown to be aparticularization of the class FORD as well as of the classGENERAL-GOODS. Conceptually, it is easy to see that the RANCHEROautomobile has properties of Ford automobiles and also ofgeneral-goods carrying trucks. As long as the parents share nocommon slots, inheritance from multiple parents is a simplematter. The difficulty arises when the parents have common slots(potentially with different values). How should inheritance behandled in such a circumstance? Two common types of inheritancemight be used to deal with this situation: union andintersection.

Multiple Inheritance: Union "Union inheritance" takes place when a frame's slot receivesthe union of the values in each of the parent's slots bearing thesame name. Thus, in Figure 16, the CARRIES slot of RANCHEROreceives the value PASSENGERS from FORD and the value CARGO fromGENERAL-GOODS.

Multiple Inheritance: Intersection "Intersection inheritance" takes place when a frames's slotreceives the intersection of the values in each of the parent'sslots bearing the same name. The COLOURS slot reflects thecolours that the vehicle can be painted. If Fords can be paintedred, white, blue, brown, and green and if goods-carrying truckscan be painted red, blue, black, and brown, then intersectioninheritance would provide red, blue, and brown as the possiblecolours for Ranchero. This intersection inheritance isillustrated in Figure 16.

A variety of other inheritance methods is also possible.For example a slot value might be inherited from only the first(last) of the listed parents. Thus, Fords might have 6 cylindersand trucks might have 8. Rather then ending up with acombination (e.g., 7 cylinders), the Ranchero will end up witheither 6 or 8 cylinders. (The CYLINDERS slot for RANCHERO inFigure 16 has a value of 6, reflecting inheritance from the FORDframe.)

When multiple values are involved, further inheritancepossibilities arise. For example, a developer might like valuesto be inherited in the same order (reverse order) as they appearin the parent's slots or to be combined in the same (reverse)order in which the parents are listed. Depending on thefacilities of the particular knowledge-based applicationdevelopment tool (shell) being used, these and other inheritancemechanisms may or may not be available. The knowledge engineershould investigate the inheritance needs of the form of knowledgerepresentation being selected and compare those needs with thecapabilities of the available tools (shells) when selecting atool (shell).

RELATIONSHIP KNOWLEDGE

The preceding subsections have focused on the storage ofvalues in slots and the association of various types ofrestrictions with those slots. Knowledge about relationships canalso be stored in slots. Consider, for example, a knowledge basewith the classes AUTOMOBILES, ENGINES, and SPARK-PLUGS. Asection of the AUTOMOBILE taxonomy that was displayed in Figure 9consists of the classes DOMESTIC, FORD, and RANCHERO, and theinstance MY-FORD. A section of the ENGINES taxonomy that wasdisplayed in Figure 11a has classes GASOLINE, FUEL-INJECTED, and8-CYLINDER. An additional taxonomy on SPARK-PLUGS is shown witha single subclass, CERAMIC. These three structures areillustrated in Figure 17a.

Some specific relations have been defined between theseclasses, relating RANCHERO to GASOLINE and relating GASOLINE andCERAMIC. The basic relation is the HAS-A relation, so thatRANCHERO HAS-A GASOLINE engine and GASOLINE engine HAS-A CERAMICset of spark-plugs. HAS-A is what is termed a complementaryrelation; its complement is CONTAINED-IN. If RANCHERO HAS-AGASOLINE, then GASOLINE CONTAINED-IN RANCHERO. When eitherrelation of a complementary pair is defined, the other can bedefined automatically. One way to implement such relations is tostore them in appropriate slots in the relevant frames. The fourrelations shown in Figure 17a are:

Instances The frame representation for part of a knowledge base willoften remain static during analysis. Thus, the knowledgeengineer would create relationships such as those shown in Figure17a during development of the application system, and theseframes and relationships would not be changed. However, becauseother parts of the knowledge base will change dynamically duringan analysis, the inference engine must be able to create (ordestroy) frames and relationships programmatically duringexecution of the application.

Consider the case of Susan buying a new Ranchero. Heracquisition will necessitate creating a new instance of RANCHERO,SUSAN'S FORD, as well as other relationships. Because RANCHEROHAS-A GASOLINE, an instance of GASOLINE will need to be createdand SUSAN'S-FORD given a HAS-A relation to it. Similarly,because GASOLINE is linked to CERAMIC with a HAS-A relation, aninstance of CERAMIC will need to be created and a HAS-A relationestablished from the GASOLINE instance to the CERAMIC instance.These relationships are depicted in Figure 17b, which isidentical to Figure 17a except for the addition of all the framesand relations implied by the addition of the instance, SUSAN'SFORD.

Rather than having to create each frame individually and toestablish each relationship within the family, some knowledge-based development tools (shells) will automatically create allreferenced frames (that do not already exist) and all of therelationships between those frames whenever a new frame iscreated. Thus, the creation of SUSAN'S-FORD would trigger thefollowing:

* Creation of an instance, SUSAN'S-GASOLINE, of GASOLINE * Linking the instance to the parent (SUSAN'S-GASOLINE to GASOLINE) * Establishing a HAS-A relation between SUSAN'S-FORD and SUSAN'S-GASOLINE * Establishing a CONTAINED-IN relation between SUSAN'S- GASOLINE and SUSAN'S-FORD * Creation of an instance, SUSAN'S-CERAMIC, of CERAMIC * Linking the instance to the parent (SUSAN'S-CERAMIC to CERAMIC) * Establishing a HAS-A relation between SUSAN'S-GASOLINE and SUSAN'S-CERAMIC * Establishing a CONTAINED-IN relation between SUSAN'S- CERAMIC and SUSAN'S-GASOLINE.

This ability to create a full subtree simply by creating aninstance of a class is a very powerful capability.

Facets Revisited In view of the class relationships that can exist betweenframes, additional facets can be created to constrain slotcontents in terms of these relationships. Thus, the possiblevalues that might be placed in a slot might be restricted to thename of a frame that is an instance of a particular class or thename of a class that is derived from another class. In terms ofthe automobile example, the following restriction would restrictthe possible values for a slot to instances of DOMESTIC:

RESTRICTION: (INSTANCE-OF: DOMESTIC)

Thus, any instance of one of the domestic manufactures(e.g., CHRYSLER) or of any of the domestic manufacturer's carmodels (e.g., LTD) would be permitted. However, one of themanufacturers (e.g., the class CHRYSLER) or one of the car modelclasses (e.g., LTD) would not be permitted. Likewise, noinstances deriving from the IMPORTED side of the taxonomy wouldbe permitted.

Similarly, restrictions such as DERIVES-FROM, NOT-MEMBER-OF,INHERITANCE-TYPE, INSTANCE, and EXCLUSIVE-MEMBERSHIP can be usedto control the use of and reasoning with relations. Again, thisarea offers considerable additional power to a representationalform, but different knowledge-based application development tools(shells) provide these types of capabilities in different ways,if at all.

Where Is Inheritance Useful? Inheritance is particularly useful when the reasoningprocess involves creating new instances, modifying relationships,or adding new relationships. A change made to a slot in asubclass frame as a result of the reasoning process will beinherited down to all subordinate subclasses and instances. Theknowledge engineer need not worry about, and the knowledge baseneed not make provision for, finding every instance and makingthe corresponding change.

Thus, if the application domain seems well-suited for frame-based representation, the knowledge engineer should examine thedegree to which that structure may change or be filled out duringthe reasoning process. The more dynamic the knowledge base, themore important an inheritance mechanism may become. Even forstatic knowledge bases, inheritance can be valuable during thedevelopment process. (Although the ultimate knowledge base maybe static, the knowledge base during the engineering process islikely to be anything but static.)

Order Out of Chaos For example, one system that was examined involved thechecking of equipment configurations for completeness andconsistency. This type of problem is a common one for a fairlybroad range of manufacturing industries. This system wasentirely rule-based and involved an extensive set of rules, eachchecking some aspect of the configuration. Understanding some ofthe relationships between rules was difficult because or thenumber of rules to be examined.

A small version of this system was assembled using a frame-based representation (as well as a rule-based representation),which permitted the rules to be categorized and their numbersreduced. By taking advantage of the ability to reason aboutstructures and relationships of equipment components, it waspossible to substitute a smaller number of rules operating at amore abstract level for a larger number of the original rules.Not only did this change provide an efficiency in representation,but it made the system less complex logically. This lattercharacteristic facilitated the developer's modification of theknowledge base.

Thus, the combination of a frame-based knowledge basestructure with a rule-based reasoning mechanism can provide anapplication system structure that is far more powerful andefficient than the system that might be built using eitherrepresentational form alone. In this case, the whole isdefinitely greater than the sum of the parts.

OTHER TYPES OF SLOT CONTENTS

The preceding subsections have discussed two types ofknowledge that can be stored in a slot - basic facts or values,and frame relationships. Additional types of knowledge can beplaced in a slot, however. For example, rules or even entirerule-sets might be placed in a slot. Similarly, procedural orbehavioral knowledge can be accommodated by placing a function ina slot. As a practical matter, however, rules are likely to begathered in a rule taxonomy, with just a reference to theappropriate rule class contained in the slot. In this manner thecategorization power of a frame-based representation can bebrought to bear on rule-based and procedural-based knowledge.The association of functions with a frame also provides themechanism for implementing object-oriented programming, a conceptthat is discussed later in this brief.

Rule-Sets In some knowledge-based development systems (shells) anentire rule-set may be stored in a slot, permitting rule-basedknowledge as well as facts and relationship knowledge to bestructured in the knowledge taxonomy. At the other extreme, eachrule could be placed in a single frame, with a parent framerepresenting the entire rule-set. The inclusion of rules withina frame permits an application's rule-based knowledge to bestructured in the same manner as the factual knowledge. Rulescan thus be organized in a taxonomy and referenced from slots ofother frames. Such rule references can be inherited downward inknowledge hierarchies from classes through subclasses to specificinstances.

To illustrate, consider a frame-based taxonomy of rulesrelating to automobiles failure diagnostics. The knowledgetaxonomy has a root class called DIAGNOSTIC-RULES. This classcontains no rules but represents the class of all diagnosticrules. It serves as the parent to three subclasses thatrespectively contain the individual rule-sets for each type ofdiagnostic: CARBURETOR-DIAGNOSTICS, ELECTRICAL-SYSTEM-DIAGNOSTICS, and BRAKE-SYSTEM-DIAGNOSTICS. As shown in Figure18, the rules are distributed one rule per slot within thoseframes. Alternatively, each of these three frames could serve asclasses representing the rule-set, with the rules containedindividually in instances of those classes. Thus, not only doesthe frame representation provide a mechanism for decomposing therule-sets and for referencing them, but it also provides amechanism for structuring the relationship between the rule-sets.

This structure permits not only a better understanding ofthe rule-based knowledge, but also a more efficient applicationof the rules, since only the rules in the relevant rule-set needbe considered at any one time. Further, the frame-basedstructuring of rules permits relevant rules to be inherited fromclasses through subclasses to specific instances of rules.

Similarly, references to rules or rule classes can beinherited down through nonrule knowledge taxonomies. Considerthe CARBURETOR-DIAGNOSTICS rule-set in Figure 18 to determinewhether a carburetor is working properly. A reference to theserules might be contained in a slot within the AUTOMOBILES frame,representing the class of automobiles. These rules would then beinherited by all subclasses of AUTOMOBILES (e.g., CHEVROLET andCHRYSLER) as well as by specific instances of classes (e.g., MY-FORD). Thus, the carburetor diagnostic rule-set would beavailable to every class and instance for use as needed.

The inheritance of rule-sets (or reference to rule-set)offers a number of advantages. Assume that the carburetordiagnostic for Chevrolet and Chrysler are basically similar butdiffer slightly with respect to certain details. Thus, a basicset of diagnostic rules could be referenced at the level ofAUTOMOBILES, and this set would automatically be made availableto every subclass of AUTOMOBILES, as well as to any specificinstance of AUTOMOBILES. The inherited rule-set could beslightly modified at a subclass level (e.g., CHEVROLET) by addingand deleting rules to reflect considerations unique to aparticular brand of automobile.

Then each specific instance of an automobile (e.g., MY-FORD)would inherit references to an appropriate set of carburetordiagnostic rules. Given any instance of AUTOMOBILES, theinference mechanism could reference that frame's carburetordiagnostic rules without having to determine which rules might beapplicable to that particular vehicle. Any general changes indiagnostic procedures could be reflected in the basic rules, andthese changes would automatically be available to derivativeclasses and instances in the knowledge taxonomy.

Similarly, a change to the rules pertaining to Fordautomobiles could be made to the FORD frame. These changes wouldbe reflected not only in FORD, but also in all frames descendentfrom the class FORD (e.g., LTD, MY-FORD). However, these changeswould not be reflected in the frames for any other type of car(e.g., CHRYSLER) or in frames representing more generalsubclasses of automobiles in the hierarchy (e.g., DOMESTIC). Thebenefits that can be gained from this representational form areenormous.

An alternative way of organizing the carburetor rules isreflected in Figure 19. The individual rules can be representedas instances, as shown in the right-hand side of the diagram.These are gathered together into classes (e.g., CHEVY-GENERAL,CHEVY-SPECIFIC). Because many of the general rules are common toseveral types of vehicles, they are related to more than oneclass.

The DIAGNOSTIC slot of the class AUTOMOBILES would thencontain a reference to the GENERAL-RULES class, which in turnwould provide access to the individual diagnostic rules.However, the reference to these rules would not be inherited;only the slot would pass down through the hierarchy. At thelevel of the CHEVROLET class, a reference would be placed in theDIAGNOSTICS slot to the CHEVY-RULES. These in turn would provideaccess to the CHEVY-GENERAL rules (which are a subset of thegeneral rules) and the CHEVY-SPECIFIC rules, which are unique tochevrolets. CHEVY-GENERAL and CHEVY-SPECIFIC then provide accessto the specific rules that are to be used for diagnosing aproblem in a Chevrolet.

Procedures (Methods) Slots may also contain functions, permitting proceduralknowledge to be incorporated within the frame representation.(Such functions, when used to support object-orientedprogramming, are often referred to as "methods.") Analogous tothe inclusion of rules within a slot, the inclusion of a functionor method provides a very powerful way to structure thedistribution of procedural or behavioral knowledge within anapplication.

The automobile example of the previous subsection can easilybe adapted to this case. Just substitute the term "function" forthe term "rule-set" to create an appropriate example. All of thearguments made above with respect to rule-sets and inheritanceapply equally well for functions and procedural knowledgerepresentations.

In the case of functions, however, some specialized types ofinheritance are provided by various knowledge-based systemdevelopment tools (shells). These inheritance mechanisms permitsome procedural code at a subordinate level to be combined with afunction inherited from a parent frame rather than being replacedby it. Thus, instead of making local changes to the inheriteddiagnostic function at the manufacture class level (e.g.,CHEVROLET) to reflect differences in procedures between differentautomobiles, those changes can be placed directly in the slots ofthe descendant frames. Then, instead of replacing the inheritedfunction (as would customarily be the case), the modificationswould be applied to that function. This technique permits localchanges to be made to a function automatically at each level inthe knowledge taxonomy. The knowledge engineer need not worryabout whether all changes were made or whether they were madecorrectly in every frame.

Method Inheritance Function or procedural knowledge can be inherited fromparent to descendant frame in the usual ways. However, somespecial types of inheritance are desirable for proceduralknowledge. The following two forms illustrate some of thepossibilities.

Method Inheritance: Before "Before inheritance" is so named because the function storedin the child's slot is applied "before" the inherited functionfrom the parent has been applied. The top portion of Figure 20shows a function in each of two frames (DOMESTIC and CHRYSLER)when those two frames are unrelated. One references a generaldiagnostic function. The lower portion of the figure shows theresultant function in the CHRYSLER frame, named "modifieddiagnostic function" for clarity, after inheritance has takenplace (after CHRYSLER has been made a child of DOMESTIC).

Figures 21a and 21b show the respective skeletons of the"code" for the two original functions, while Figure 21c shows theskeleton of the combined function. Note that the functions arecombined; they are not just called one after the other. Thus,the before-function call can actually exit, in which case theinherited function would not be performed at all.

Before inheritance can be used for several purposes. Thechild function can serve as a monitor, reporting or recordingdata whenever the function is called. It can serve as a filter,checking whether the conditions are such that the general routineshould be skipped. It can also serve as a preprocessor,modifying or adjusting values before supplying them to thegeneral routine. Two different parameters sets were used for thetwo functions in the example for the sake of clarity; however, inpractice a common set is often used.

Method Inheritance: After "After inheritance" is so named because the function storedin the child's slot is applied "after" the inherited functionfrom the parent has been applied. The situation is the same asdepicted in Figure 20 and Figures 21a and 21b, but the functionsare combined differently, as shown in Figure 21d.

After inheritance can also be used for several purposes.Again, the child function can serve as a monitor, reporting orrecording the effects of the application of the parent routine.It can also serve as a post-processor, modifying or adjustingvalues before they are returned from the function. Again, twodifferent parameter sets were shown, but the child functionusually uses the parent function's parameters.

Method Inheritance: Other Inheritance can be defined and implemented in many otherways. For example, the parent function could be inherited intothe "middle" of the child code. Rather than combining thefunctions to form a new function associated with the child, theknowledge engineer could achieve the equivalent processing bysending the child function up to be processed with the parentfunction.

OBJECT-ORIENTED PROGRAMMING

The development of programs on the basis of associating alldata and programmed behaviour (e.g., functions) with each objectin the application system is known as "object-orientedprogramming." Messages are sent to objects requesting thatparticular functions or services be performed. The objectresponds, relying on methods (functions) to provide the requestedaction. Necessary data are obtained from the requesting message,from data stored with the object, and from other objects as

necessary.

Such message passing may appear similar to function orsubroutine calls, and well it should. However, it differs inthat the definition of the function is taken from the object"receiving" the message, not the object sending the message.

Each object can be represented as a frame, with the dataabout that object stored in slots in its frame. The variousbehaviours of the object are provided by methods that are alsostored in the frame's slots. Messages are then exchanged betweenobjects to provide a collection of behaviours that represent thepurpose of the entire system.

Many people have concluded that object-oriented programmingis nothing more than the development of programs using subroutinecalls to a core set of subroutines. While technically true, thatopinion misses the point that object-oriented programmingrepresents a methodology for thinking about a problem, anapproach to structuring a computer program. The modularizationand the association of data with each object provides a number ofbenefits including error reduction and comparatively easymaintenance.

Example Consider a knowledge-based application dealing with failurediagnostics for automobiles. Objects would be constructedrepresenting various kinds of automobiles. A frame-basedrepresentation, such as shown in Figure 9, would be a typicalmeans for representing such a system. As was discussedpreviously in the subsection on procedures and functioninheritance, various diagnostic routines could be provided atvarious levels of the knowledge taxonomy, with localmodifications made to reflect differences between manufactures'products, differences between models, and so forth.

The diagnostic routines would be called into play by a setof rules that analyzed symptoms exhibited by a car. A message toa particular automobile (object) would trigger the performance ofthe requested diagnostic function for that car. The inferencemechanism would not need to perform tests to isolate whichprocedures should be applied given the identity of the particularcar being examined. The appropriate diagnostic routines wouldalready be associated with that car. The inference mechanismwould only need to execute the function (perform the method).

Thus, in developing the diagnostic logic of the system, theknowledge engineer need not be concerned about providing thenecessary tailoring each time a particular diagnostic procedureis to be used to produce additional information about the failurein the automobile. All such specialization will already bereflected in the methods for the diagnostics associated with eachgiven automobile.

Obviously, this approach has several benefits in terms ofdevelopment efficiency, ease of modification, simpler applicationlogic, clarity of documentation, and reduction in number oferrors. Further, development of a complete set of methods for"every" object is not as formidable a task as it might at firstappear. Because of the hierarchical structure of the objects andthe inheritance capabilities, much of the method development ofindividual objects (frames) is provided implicitly throughinheritance rather than explicitly through separate coding.

The key observation to be made about object-orientedprogramming is how the benefits are derived from the integrationof the approach with the various facilities of a frame-basedrepresentation.

Method Inheritance: Other Inheritance can be defined and implemented in many otherways. For example, the parent function could be inherited intothe "middle" of the child code. Rather than combining thefunctions to form a new function associated with the child, theknowledge engineer could achieve the equivalent processing bysending the child function up to be processed with the parentfunction.

OBJECT-ORIENTED PROGRAMMING

The development of programs on the basis of associating alldata and programmed behaviour (e.g., functions) with each objectin the application system is known as "object-orientedprogramming." Messages are sent to objects requesting thatparticular functions or services be performed. The objectresponds, relying on methods (functions) to provide the requestedaction. Necessary data are obtained from the requesting message,from data stored with the object, and from other objects asnecessary.

Such message passing may appear similar to function orsubroutine calls, and well it should. However, it differs inthat the definition of the function is taken from the object"receiving" the message, not the object sending the message.

Each object can be represented as a frame, with the dataabout that object stored in slots in its frame. The variousbehaviours of the object are provided by methods that are alsostored in the frame's slots. Messages are then exchanged betweenobjects to provide a collection of behaviours that represent thepurpose of the entire system.

Many people have concluded that object-oriented programmingis nothing more than the development of programs using subroutinecalls to a core set of subroutines. While technically true, thatopinion misses the point that object-oriented programmingrepresents a methodology for thinking about a problem, anapproach to structuring a computer program. The modularizationand the association of data with each object provides a number ofbenefits including error reduction and comparatively easymaintenance.

Example Consider a knowledge-based application dealing with failurediagnostics for automobiles. Objects would be constructedrepresenting various kinds of automobiles. A frame-basedrepresentation, such as shown in Figure 9, would be a typicalmeans for representing such a system. As was discussedpreviously in the subsection on procedures and functioninheritance, various diagnostic routines could be provided atvarious levels of the knowledge taxonomy, with localmodifications made to reflect differences between manufactures'products, differences between models, and so forth.

The diagnostic routines would be called into play by a setof rules that analyzed symptoms exhibited by a car. A message toa particular automobile (object) would trigger the performance ofthe requested diagnostic function for that car. The inferencemechanism would not need to perform tests to isolate whichprocedures should be applied given the identity of the particularcar being examined. The appropriate diagnostic routines wouldalready be associated with that car. The inference mechanismwould only need to execute the function (perform the method).

Thus, in developing the diagnostic logic of the system, theknowledge engineer need not be concerned about providing thenecessary tailoring each time a particular diagnostic procedureis to be used to produce additional information about the failurein the automobile. All such specialization will already bereflected in the methods for the diagnostics associated with eachgiven automobile.

Obviously, this approach has several benefits in terms ofdevelopment efficiency, ease of modification, simpler applicationlogic, clarity of documentation, and reduction in number oferrors. Further, development of a complete set of methods for"every" object is not as formidable a task as it might at firstappear. Because of the hierarchical structure of the objects andthe inheritance capabilities, much of the method development ofindividual objects (frames) is provided implicitly throughinheritance rather than explicitly through separate coding.

The key observation to be made about object-orientedprogramming is how the benefits are derived from the integrationof the approach with the various facilities of a frame-basedrepresentation.

Example Continued Assume that the critical facts associated with a particularautomobile undergoing a diagnostic test are to be printed out.This request may arise from the execution of a rule-set, or froma knowledge engineer or a user browsing the knowledge base andseeking certain information.

In this case, however, an extensive set of programs is notneeded. A single message to the frame containing the automobileof interest, requesting that its critical data be displayed onthe screen, will suffice. The "critical data" method for thatparticular automobile will assemble the necessary data for thatcar directly; an extensive set of tests to determine which typesof data are considered critical for particular brands and modelsof automobiles is not needed. Next, this method sends a messageto an "output" object that has routines for displaying a set ofdata on the screen. (If the data were to be sent to a printer ordisk file, the process would be similar except that the messagewould be sent to a different method. No local program code isinvolved in determining the way to package and transfer that datato any particular device.)

The benefits from such modularization are striking. Achange in the diagnostic procedure for a particular model ofautomobile can be made directly to the appropriate methodassociated with that automobile. All changes would be localizedto a single method. The knowledge engineer would not need tosearch for all sections of the entire program that referenced orwere in some way involved with that particular diagnostic. Evenscattered revisions can often be made in a single place, sincethe revision would be inherited downward in the representationhierarchy to all descendants.

If a developer modifies a printer driver (e.g., as a resultof a change to the printer actually attached to the computersystem), only the one method that is responsible for displayingdata on that printer need be changed. No other code fragmentswould be involved with the printer, eliminating the need for theknowledge engineer to search through the application looking forcode fragments and then to examine that code to determine whethermodifications would be required to reflect the change made to theequipment.

Where Is Object-Oriented Programming Useful? The preceding paragraphs have focused on the maintenanceadvantages of object-oriented programming; however, therepresentational benefits are available in a wide variety ofapplications. Any time the application involves the behavioralrepresentation of a set of objects, object-oriented programmingis a candidate development style or approach. Similarly, theobject-oriented approach should be considered any time theapplication logic involves such behavioral performance ortriggering of a behaviour from several locations. Keep in mindthat the benefit of this means of structuring and applyingknowledge derives from the structural characteristics of theapplication, not the particular domain knowledge to be associatedwith the system.

As a practical matter, object-oriented programming isinextricably intertwined with a frame-based representation andthe organization of the knowledge base. Many of the benefits ofthe object-oriented approach will be lost if a frame-basedrepresentation is not used. This provides two hints for useduring the design process:

* Any time a frame-based representation appears to be appropriate, an object-oriented programming approach should be considered. * Any time an object-oriented approach appears to be appropriate, based on the expected behavioral characteristics of the application, employing a frame- based representation should be considered (though perhaps in conjunction with other representational forms as well).

Interestingly, despite the close relationship between frame-based organizations, rule-based systems, and object-orientedprogramming, a rule-based system operating with a frame-basedrepresentation generally represents a violation of object-oriented programming principles. Technically, in a pure object-oriented approach, data from a frame (e.g., slot definitions andvalues) must be kept within the object itself and are notaccessible from outside. Only the functions operating within theobject have free access to the data. This restriction enforcesthe modularity and independence required to achieve the benefitsof object-oriented programming. However, this requirement, ifenforced, would prevent a rule-based knowledge representationfrom accessing the information contained in a companion frame-based representation!

ADVANTAGES OF FRAME-BASED REASONING

The chief advantage of frame-based reasoning is that itprovides a means for structuring a variety of types of data inthe knowledge base and a framework whereby not only the data butalso the structure of those data can be reasoned about. Thus, aframe-based representation:

* Greatly aids in structuring the design for a knowledge-based application * Enables rules and procedures in an application to be more generic, thereby reducing rule-set or procedure size and making the knowledge base easier to understand and test * Compartmentalizes the data in the knowledge base, oftentimes reducing the complexity so that an application can be built and tested in less time * Permits greater understanding of knowledge structure and relationships through graphical displays of the structure * Enhances the maintainability of the knowledge base * Provides many of the essential characteristics of an object once that type of object has been identified, ousting the need to derive these aspects individually.

Engineering a Knowledge-Bases Application Usinga Frame-Based Representation An early step in studying frame-based reasoning is toexamine various information taxonomies. Such taxonomies areinteresting to manipulate. Soon the student knowledge engineerhas an opportunity to relate a taxonomy to a rule-set and torelate taxonomies to one another. Making these relations canalso be enjoyable, but soon interest turns toward developing suchtaxonomies.

In a rule-based reasoning system, where rules or rule-setsare the only medium for representing and storing knowledge,getting started is (supposedly) easy. The student knowledgeengineer just starts "writing rules."

In a frame-based reasoning system many more issues need tobe considered. First, the type of reasoning that will benecessary must be planned. Then the tasks to be performed by therules have to be specified and the requirements to accomplishthat processing must be determined. Only then can the developerstart to sketch out a few rules, identify a small hierarchy offrames, and actually test that the structural concept performs asexpected.

It has been found that, in developing the beginnings of aframes-based representation for an application, blackboard andpaper sessions held among the knowledge engineering team membersare best interspersed with sessions at the workstation to testthe ideas. Frame-based application development systems aretypically implemented for use with AI workstations andincorporate a considerable number of graphical aids for creatingand testing the application. This hardware-software combinationoffers remarkable efficiency early in the development cycle;teams can often sketch out an implementation for two hours' worthof designing at the blackboard in about one hour at aworkstation.

The consequences of this efficiency are significant. First,developers are much less reluctant to throw away a design that isonly partially correct; second, it does not take very long to getthe design correct. In addition, the success or failure of agiven design can be determined in rather short order so thatdevelopers can usually find an opportunity to test and measure apet design.

PROBLEMS WITH FRAME-BASED REASONING

Perhaps the most detrimental aspect of frame-based reasoningsystems are that frame-based and object-oriented programmingtechniques are not yet commonplace in the computer world andpeople need time and patience to master the techniques and usethem both fluently and properly. These techniques arefundamentally simple, although at first they seem complex. It iswell worth the several months' time that it might take for aknowledge engineer to become highly proficient in their use.

Efficiency Considerations One of the major dissatisfactions expressed with frame-basedreasoning concerns efficiency. The structures and capabilitesthat have been described in this brief offer a wide variety ofbenefits, but these benefits are achieved only at a price. Thedynamic ability to modify the knowledge structure or to modifythe facets associated with a slot during execution of theapplication system requires that a considerable amount ofchecking be performed at execution time. The computer cannotstore a fact in a frame with the execution of a single storeinstruction. Instead, the various facets governing the slot mustbe references to verify that storage of this particular value ispermitted, to check whether this action is to be trapped, and soforth. A simple store command that would involve a singlecomputer instruction in systems using other forms of knowledgerepresentation can easily explode into the tens and hundreds ofinstructions. This expansion, of course, is accompanied by aconcomitant degradation in the application's execution speed.

Abuse of Frame-Based Reasoning This brief has focused on the advantages that a developercan gain using a frame-based approach for representing certainaspects of an application's knowledge base, but the process canalso be abused. In a desire to build taxonomies, a new knowledgeengineer can easily become overly enthusiastic and createinappropriate taxonomies. Such mistakes can lead to severedifficulties subsequently when the knowledge engineer must reasonabout the knowledge. Person having this difficulty are labeledas having contracted "taxonomic fever."

"Taxonomic Fever" A novice can easily succumb to taxonomic fever, which causesa taxonomy to be devised to represent every phenomena in sight.While most of the outward signs of this disease disappear afterthe first few days of exposure to object-oriented programming orframe-based reasoning, the inward vestiges of the disease canlinger, with a wayward taxonomy creeping into a design every nowand then. Therefore, a certain litmus test needs to be appliedto each taxonomy in the design, namely:

* How does this taxonomy support the reasoning process? * Does the taxonomy refine the reasoning concept, that is, does each unit of the taxonomy in the direction of the leaves represent a specialization of the root (most general) unit?

If the knowledge engineer has difficulty verifying these tests,the taxonomy and the results that use it may not be well-designed.

An Example Consider the automotive diagnostic application, for example.In such an application, the taxonomy and the rules shouldrepresent the order and structure of the automotive diagnosticprocess, which could easily have several taxonomies (with some,perhaps, containing only rules). Among these taxonomies,however, it would be surprising to find a car parts taxonomy thatstarts with the car as a whole and goes down through all thevarious assemblies and subassemblies to the final nuts and bolts.Why? Because the complete parts structure of a car is not usedto diagnose an automotive malfunction; the mechanic does notselectively test each nut, bolt, and washer. He does not reasonover the whole car, and his underlying reasoning in isolating aproblem and diagnosing it is quite different from that describedby the parts taxonomy.

A Taxonomic Mistake One of the mistakes frequently made by novice knowledgeengineers is the construction of an inconsistent taxonomy. If,for example, AUTOMOBILES is the top frame in a taxonomy and if 4-CYLINDER is a leaf frame at the bottom of the taxonomy, then 4-CYLINDER should be a specialization of AUTOMOBILES. Althoughrepresenting a more specialized object, 4-CYLINDER should stillcharacterize something that would be known as an automobile.Since 4-CYLINDER is a more specialized engine rather than a morespecialized automobile, the taxonomy is at least mislabeled ifnot in error. Such mislabeling can really confuse and obfuscateknowledge in a frame-based representation.

Unfortunately, the knowledge engineer can fairly easily fallinto this type of trap. An example was shown in connection withFigure 11b, in which MY-FORD as depicted as an instance of bothAUTOMOBILES and ENGINES. Another example is shown in Figure 22.The taxonomy is consistent until the class FORD is reached. Atthis point rather than the class being broken down into differenttypes of Ford automobiles, the class is broken down by componentsthat go into a car. The fact that the remainder of the hierarchyis consistent with those components does not eliminate theproblem. The switch in logical progression has already beenmade. The best procedure to test for such representationalerrors is to ask at each level whether those objects representtypes of objects belonging to parent classes.

Frame-based reasoning offers an attractive range oftechniques for structuring a knowledge-based application and forsupporting very rapid prototype development. It can provideenormous benefits in knowledge representation and systemmodification. However, these tools do not replace the detailedanalysis of the application necessary for it to be a success, andblind application of these tools can lead to problems.

A Warning The rather broad range of frame-based capabilites describedin this brief does not imply that any particular knowledge-basedapplication development tool (shell) has all these capabilites.Some tools, of course, do not offer any frame-basedrepresentational capabilities; others offer subsets of thecapabilities described herein. Part of the feasibility study andthe early design work involves examining the problem's naturalknowledge representations, comparing these requirements with therepresentational capabilities of eligible tools, and finallyselecting a development tool (shell) and organizing the knowledgeto fit within the representations available.

Rule of Thumb Frame-based reasoning is in many ways like physics. In thatdomain, the behaviour of the physical world generally has asimple explanation. Thus, if the researcher finds that theexplanation of a particular phenomenon (or the solution of aparticular problem) is becoming difficult or "messy," thedifficulty is an indication that a different approach should betaken, that a different representation of the problem should beconsidered.

Similarly, reasoning with frame-based knowledge is generallya relatively straightforward process. If the knowledge engineerfinds that working with a particular representation is becomingincreasingly difficult, that difficultly is usually an indicationthat the representation is wrong. It has been found thatstopping at this point and trying a different structure for theknowledge usually significantly reduces the logical complexity ofthe problem.

Because frame-based reasoning development tools are largeand normally require large, specialized workstations,applications developed using them are difficult to move intoenvironments where delivery versions of these tools may notexist. More and more delivery environments are being supportedby the manufactures of these software tools; as time progresses,this problem should become less critical. Also, new personalcomputer systems built around the Intel 80386 chip may provide acost effective delivery vehicle for many application using frame-based reasoning tools.