The Generic Frame Protocol (GFP), jointly developed at SRI International and Stanford University, provides a set of functions that support a generic interface to underlying frame representation systems (FRSs). The interface layer allows an application some independence from the idiosyncrasies of specific FRS software and enables the development of generic tools that operate on many FRSs.

Although there are significant differences among FRS implementations, there are enough common properties that one can describe a generic model of frame representation and specify a set of access functions for interacting with frame representation systems. An application or tool written to use these access functions provides portability over a variety of systems and knowledge bases (e.g., the GKB-Editor).

GFP is based upon a generic model of frame representation systems (with frames, classes, slots, etc.) and consists of a set of access functions (e.g., get a frame by its name, change a slot's value in a frame). These functions can be used by an application to access knowledge stored in any compatible FRS (e.g., USC/ISI's Loom, SRI's SIPE-2 sort hierarchy, CMU's Theo, Stanford's Ontolingua). The implementation consists of a simple translation layer between the generic knowledge-base functions and an existing FRS-specific functional interface. The translation is done by a library of object-oriented methods. To support a new FRS requires implementing a set of methods that specialize these generic functions for the particular representation system. Since many of the generic functions have reasonable default methods written in terms of other generic knowledge-base methods, only a core subset of the generic functions in the specification must be implemented for a given system. The default methods can be overridden to improve efficiency or for better integration with development environments.

While GFP necessarily imposes some common requirements on the organization of knowledge (e.g., frames, slots, and values) and semantics of some assertions (e.g., instances and subclass relationship, and inherited slot values, slot constraints), it allows for some variety in the behavior of underlying FRSs. The protocol achieves this heterogeneity by parameterizing FRSs themselves, providing an explicit model of the properties of FRSs that may vary. An application can ask for the behavior profile of a FRS, and adapt itself accordingly.

Additional Information


Back to Peter D. Karp, <pkarp@ai.sri.com>
Back to Vinay K. Chaudhri, <chaudhri@ai.sri.com>
Back to Artificial Intelligence Center
Back to SRI International

GKB-Editor is a trademark of SRI International.
Copyright © 1995 SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025 USA. All rights reserved.