I am very interested in models for knowledge representation. Below is an excerpt from a very good condensed introduction to the frame based representation systems. Just to set the record straight - I did not write any of the following text myself. I have compiled it from the original materials by Peter D. Karp and Thomas Gruber from Artificial Intelligence Center at SRI International. They talk specifically about Lisp, but all the concepts are the same for other implementations.

I hope they forgive me for recopying it in hope that more casual readers get exposure to the topic.

---

Frames

A frame representation systems (FRS organizes) knowledge in an ``object-oriented'' manner, which means that facts are associated with the objects mentioned in the facts. A frame is an object with which facts are associated. Frames have the required property of being named; that is, the FRS maintains a mapping from names to frame objects. These frame objects denote entities in the conceptual world, in the usual sense of a symbol denoting an object in the universe of discourse. In some languages one may denote an object by an expression rather than a symbol. For example, the expression (+ 2 3) denotes the integer 5. However, in the Generic Frame Protocol, a frame is accessed by a name which is a Lisp symbol, and each frame has a unique identifying name. When a frame is renamed all of the facts associated with the previous name are then associated with the new name. Operationally, then, it does not matter whether a renamed frame is the ``same'' frame or a new one with all the same associations.

A frame exists in the finite storage of a knowledge base. Whether the entity denoted by the frame exists in the world is an orthogonal question. The existence of a frame in a knowledge base is determined by the functions that map from names to frames. There is no assumption about how the information associated with frames is stored in Lisp memory.

Slots

Information is associated with a frame via slots. A slot is a mapping from a frame to a set of values. A slot is also known by a name. For example, the fact that Fred's favorite foods are potato chips and ice cream might be represented by a slot called favorite-food on the frame called fred, where that slot has the values potato-chips and ice-cream. Slots and frames share a common namespace. That is, a symbol might name both a frame and a slot, both of which denote the same entity in the world. This is because in some FRSs, slots are reified as binary relations and denoted by frames of the same name. When this is the case, each application of the slot to a frame is a specialization of the same binary relation. For example, the symbol favorite-food might be the name of a frame which stands for all of the mappings between entities like Fred and their favorite foods. However, in GFP, slots may be used polymorphically; the frame/slot relationship is described by both the slot name and the name of the frame to which the slot has been applied. There is no assumption that a slot mapping a particular frame to some values has any relationship to a slot of the same name applied to a different frame. However, good software engineering practice suggests that slots of the same name should be used to represent at least analogous relationships when applied to two similar frames. We will see that this convention is enforced by some FRSs when we describe inherited slots.

A slot value can be any Lisp object (symbol, list, number, string, etc). When the value of a slot on a frame is a symbol there is no requirement that this symbol name a frame, although this is a conventional interpretation in some applications.

Slots can be viewed as binary relations. However, in many FRSs there is no facility for supporting relations of higher arity. To accommodate these systems, the Generic Frame Protocol imposes no format for expressing higher-arity predicates.

Knowledge bases

A knowledge base or KB is a collection of frames and their associated slots and values. KBs are also named using symbols. KBs share a namespace with frames and slots, the name of a KB could be the name of a frame that denotes it (although this is not a requirement). The Generic Frame Protocol provides functions for storing and retrieving KBs to secondary storage, but a KB is simply a named collection of frames regardless of how it is encoded or stored.

Template & Own slots

A template slot is a description of a slot that is associated with a class Frame, but that applies to all instances of that class. In many FRSs template slots are presented as if they were literally slots. But they are actually a way of specifying, in one place, slots for all the instances. For example, if we wanted to say that all instances of the class female-person have a slot called gender with the value female, we could define a template slot called gender for the female-person frame and give it value female. Then if we created an instance of female-person called mary, and we asked for the value of the slot gender on mary, we would be told that her gender is female.

What would we get if we asked for the gender slot of female-person? The question is ambiguous, because we could mean the template slot on the frame female-person viewed as a class, or the slot on the frame viewed as an instance (e.g., of a class of classes). To disambiguate these senses we make a clear distinction in the protocol between template slots and own slots, which are the normal slots on an instance. We know from common sense that the gender could not be an own slot on the female-person frame, because that would be specifying the gender of a class! Instead, we say that gender is a template slot on female-person with the template slot value female. For mary, an instance of female-person, the value female is an inherited value for the own slot gender. We say that the value is known by monotonic inheritance from the female-person class, to distinguish it from nonmonotonic inheritance described in the next section.

An own slot value of an instance can be inherited from a template slot of any class that is a type for the instance, not only direct types of the instance. If mary were a direct instance of single-working-mother, which is a subclass of single-mother, which in turn is a subclass of female-person, then the value of the gender slot for mary would still be inherited from the class female-person.

Classes and instances

A class is a set of entities, which are called the instances of the class. An entity can be an instance of many classes, which are called its types, and a class can be a type of many classes. A frame denoting a class is called a class frame, and a frame denoting an entity that is an instance of a class is called an instance frame. A class can also be an instance, i.e., an instance of a class of classes (a metaclass). The relation that holds between a instance and a class is a primitive, akin to set membership. With this primitive we can define the sub relation that holds between classes. A class is a sub of class if all instances of are also instances of . In other words, all instances of the subclass are instances of the superclass, and the superclass may have other instances.

Facets

Facets are annotations on slots. Facets have values, which, like slot values, may be any Lisp data structure. Since slots are identified by a slot name and a frame, facets are identified by a facet name, a slot name, and a frame. Some facets pertain to the values of a slot; for example, a facet can be used to specify a slot constraint or a method for computing the value of a slot. Other facets are about the slot itself, such as documentation. The Generic Frame Protocol provides a set of a standard names for a few facets, and applications may assert other facets as well. For example, to assert the value-type restriction on favorite-food, one could assert that the facet :value-type has value edible-food on the template slot favorite-food of class frame human.

FRSs have a variety of ways of specifying facets. Some systems allow for uniform nesting of facets (i.e., facets on slots, facets on those facets, etc). Systems that represent slots as reified binary relations (slot frames) may represent slot constraints using slots on global slot frames. The Generic Frame Protocol only provides a notation for a single level of facets on slots, and makes no requirement that a facet on a slot has any relationship to a slot on a frame that represents a binary relation. In fact, only those facets that describe slot constraints have any semantics in the protocol. All other facets are simply annotations for applications to use as needed.