next up previous contents index
Next: Design Objectives Up: Introduction Previous: The Need For a

The Proposed Solution

We propose a generic model of frame representation systems (with frames, slots, classes, etc) and specify a set of access functions based on this model (e.g., get a frame by its name, get the slots of a frame, etc). The specification is given as a set of Common Lisp functions that can be used by an application to access knowledge stored in any compatible FRS. As an implementation strategy we propose a translation layer between the Generic Frame functions and an existing FRS-specific functional interface. The translation would be done by a library of CLOS generic functions that implement the specification given in this document (see Figure 1.1). To support a new FRS, we must implement a set of methods that specialize these generic functions for the particular representation system. We refer to the methods that implement the protocol for a particular FRS as a back end. For example, there is currently a LOOM\ back end for GFP, and a THEO back end (and several others). Since many of the generic functions have reasonable default methods written in terms of other Generic Frame methods, only a core subset of the generic functions in the specification must in fact be defined for a new back end. The default methods can be overridden to improve efficiency or for better integration with development environments. Appendix B provides guidance to implementors of new back ends for the protocol.

  
Figure 1.1: The architecture of the Generic Frame Protocol. GfP back ends do not currently exist for all of the FRSs pictured here.



  • Peter Karp