In this (mostly arbitrary) layout of our frame data, the first item in each list is the name of the frame, the second item is a list of ancestors of the frame, and the remainder of the data consists of slot names and their values. Storing the information in a hierarchy of frames allows us to succinctly describe the information about each item- For instance, when we defined lettuce, it was not necessary to give any detailed information about lettuce, because lettuce already inherits default slots from salad_bar_station_food that are appropriate in describing lettuce as a cold, non-fattening vegetable. Other items, however, have to override some default slots because they represent and exception: Cheese, for instance, breaks the rules for salad bar items in that it is not a vegetable and also is fattening.
The moral of this buffet example is that frames allow you to organize knowledge in a manner that is practical and efficient- It is practical because the information can be organized in a natural manner for a given purpose- The layout that we choose, for instance, is close to how a human might think of a buffet in their his/her head: If the person were on a diet, for instance, it might make sense for them to spend most of their time at the salad bar, since the items there would typically be less fattening- Looking at our frames makes that very clear. Also, the data is efficient because we use default information about groups of food assign default properties to individual foods, making the representation of the knowledge very succinct.
Limitations of Representing Knowledge in Frames
Our buffet example shows us some of the strengths of frame systems, foremost being their simplicity. However, The simplicity that makes frame systems so easy to work with can also lead to many problems.
First of all, if we try to use our information for multiple domains we run into difficulties because of assumptions that can be built into our data. For example, if a botanist wanted to use our buffet database to describe different plants it would be nonsensical to the botanist to find lettuce described as a salad_bar_food- A far more useful description would be to describe lettuce as a species in the genus Lactuca. Since frame systems allow the data designer to be so flexible in how data is organized, many arbitrary decisions can be made that may later on prove to be a hindrance when new knowledge needs to be included.
Second of all, primitive frame systems like this do not really have a strong mathematical underpinning... We're just using a simple observations about information- that observation being that "things" can usually be placed into "groups" and items in those groups tend to have similar properties- We're welcome to put in all kinds of contradictory and paradoxical information into our frames and our software would not be able to tell this is happening, since a frame system stores information in a willy-nilly fashion.
The final major limitation of simple frame systems is that they can impose extra burdens on the user because they can't distinguish between between necessity and sufficiency. For instance, a program using our buffet frames has no ability to say to the user "Hey! Those radishes you told me about are salad_bar_station_food!"- This is impossible because we can't express in our frame system that any specific food item that has "such and such" properties has been sufficiently described for the software to deduce that it must be part of the salad bar.
Not surprisingly, most modern frame systems have extensions that remove most of the limitations that we have discussed in this section. However, often the limitations have been overcome by borrowing concepts from other representation systems, such as first order logic and description logics, which we will discuss next.
Description Logics >>