next up previous contents index
Next: The GFP Knowledge Model Up: The Generic Frame Protocol Previous: Contents

Introduction

This document specifies a protocol for accessing knowledge bases (KBs) stored in frame knowledge representation systems (FRSs). By FRS we mean both systems that would traditionally be considered FRSs, as well as ``any system that admits a frame-like projection,'' which could include other types of knowledge representation (KR) systems, and database systems. The protocol, called the Generic Frame Protocol (GFP), provides a set of operations for a generic interface to underlying FRSs. The interface layer allows an application some independence from the idiosyncrasies of specific FRS software and enables the development of generic tools (e.g., graphical browsers and editors) that operate on many FRSs. GFP implementations exist for several programming languages, including Java, C (client implementation only), and Common Lisp, and provide access to KBs both locally and over a network.

GFP is complementary to language specifications developed to support knowledge sharing. KIF [[4]], the Knowledge Interchange Format, provides a declarative language for describing knowledge. As a pure specification language, KIF does not include commands for knowledge base query or manipulation. Furthermore, KIF is far more expressive than most FRSs. GFP focuses on operations that are efficiently supported by most FRSs (e.g., operations on frames, slots, facets -- inheritance and slot constraint checking). GFP is intended to be well impedance-matched to the sorts of operations typically performed by applications that view or manipulate frame-based KBs.

The Need for a Standard FRS Access Library

There are several motivations for creating a generic access and manipulation layer for FRS services. An application programmer may wish to use more than one FRS during the life of an application. An application that initially used the representation services of FRS might later use FRS because FRS is faster, more expressive, cheaper, or better supported. Or, an application might use FRS in addition to FRS -- FRS might be more expressive for a subset of tasks, or the application might later require access to a KB that was implemented using FRS . In addition, GFP supports reuse and composition of multiple ontologies and KBs. GFP also allows users to reuse tools and utilities across various FRSs and applications, such as graphical knowledge editors or machine-learning programs.

Although there are significant differences among FRS implementations, there are enough common properties that we can describe a common knowledge model and an API for FRSs. An application or tool written to use these operations has the potential of portability over a variety of FRSs and knowledge bases.

Overview of the Protocol

GFP specifies a knowledge model of FRSs (with KBs, classes, individuals, slots, and facets). It also specifies a set of operations based on this model (e.g., find a frame matching a name, enumerate the slots of a frame, delete a frame). An application uses these operations to access and modify knowledge stored in a GFP-compliant FRS.

The current implementations of GFP is object-oriented: methods in the appropriate object-oriented programming language for an application are used to implement GFP operations. We refer to the set of methods that implement the protocol for a particular FRS as a back end. Many GFP operations have default implementations written in terms of other GFP operations; therefore, the programmer need define only a core subset of all GFP operations in order to implement a compliant back end. These GFP operations are called mandatory, and they comprise the GFP kernel. The default implementations can be overridden within a given back end to improve efficiency.

  
Figure 1.1: The architecture of the Common Lisp implementation of the Generic Frame Protocol. GFP back ends now exist for all the FRSs pictured here.

Design Objectives

The design objectives for GFP are as follows.

Simplicity: It is important to have a relatively simple specification that can be implemented quickly, even if that means sacrificing theoretical considerations or support for idiosyncrasies of a particular FRS.

Generality: The protocol should apply to many FRSs, and support all the most common FRS features. For example, it should support all the knowledge access and modification functionality that will be required by a graphical KB editor.

No legislation: The protocol should not require numerous changes to an FRS for which the protocol is implemented. That is, the protocol should not legislate the behavior of an underlying FRS, but should serve as an interface between an existing FRS and an application.

Performance: Inserting the protocol between an application and an FRS should not introduce a significant performance cost.

Consistency: The protocol should exhibit consistent behavior across different FRSs. That is, a given sequence of operations within the protocol should yield semantically equivalent results over a range of FRSs.

Precision: The specification of the protocol should be as precise and unambiguous as possible.

Extensibility: The protocol must support the variability in capabilities of FRSs, and the need to add new FRS features over time without penalizing users of less powerful systems.

Satisfying all of these objectives simultaneously is impossible because many of them conflict, such as simplicity and precision, simplicity and generality, and generality and performance. The deepest conflicts, however, exist simultaneously between generality, no-legislation, performance, consistency, and precision, as the following example shows. To specify the behavior of the operation that retrieves the values of a slot precisely and completely, we would have to specify exactly how the local values of a slot are combined with the inherited values of a slot (which may be inherited from multiple parent classes). That is, we would have to specify the exact inheritance mechanism that the protocol expects. Yet, different FRSs use a variety of different inheritance mechanisms [[7]]. For an FRS to conform to a precise specification of inheritance, it might be required either to alter its inheritance mechanism (violating no-legislation), or to emulate the desired inheritance mechanism within the implementation of the protocol (violating high performance and generality, since the inheritance method used by that FRS would then be inaccessible through the protocol).

The preceding quandary is central throughout the protocol, and we know of no simple solution to the problem. Our approach is for each GFP implementation to advertise programmatically the capabilities that it provides. Each KB manipulated by the protocol is serviced directly by a single underlying FRS. The GFP implementation for that FRS must declare what set of GFP behaviors the implementation can support, and under what set of behaviors it is operating currently. For example, the implementation might declare that it can support only one of the two semantics for the behavior :inheritance, which we call :when-consistent and :override. (If it can support only the :when-consistent behavior, for example, then it must be currently operating under that behavior.) GFP predefines alternative FRS behaviors, based on the properties of existing FRSs. The application can interrogate the implementation at any time it feels appropriate to determine which of several actions the application might take, or whether it needs to change the current behavior of the underlying FRS.

Many operations in the protocol use language such as, ``The operation returns at least the values derivable from the definition of direct assertions.'' This language defines a lower bound on the capability of any compliant GFP implementation. An implementation is at liberty to deliver more results as long as they are logically consistent with the documentation of the operation. In this example, we are saying that the server must be aware of the class-subclass and class-instance relationships in the KB, and must perform logically correct taxonomic inferences. The same GFP implementation is at liberty to perform arbitrary theorem proving as well as the minimal specified inferences. Such theorem proving may well derive other values in addition to those derived by taxonomic inference.

On Terminology

The goal of GFP is to serve as an interface to many different FRSs. In a review of FRSs, Karp identified more than 50 of these systems [[7]]. He also observed that there is a lack of agreement regarding terminology in the field of knowledge representation because different researchers often use different terms to mean the same thing, and use the same term to mean different things. For example, there are 10 different terms for the notion of a class, 4 terms for an individual, 4 terms for the relationship between a concept and an individual, 3 terms for the notion of slot values, and 2 terms for the slot and for the slot frame.

The operations within GFP require names. It is clearly impossible to choose a set of names for the protocol operations that will be considered ideal by the developers of every FRS. We ask readers of this document who are considering adapting the GFP to their FRS to recognize these facts, and to be tolerant of the terminology herein.

GFP History

GFP was originally motivated by a review of FRSs authored by Peter Karp [[7]], by related earlier work by Barnett and colleagues [[1]], and by specifications used at the Stanford Knowledge Systems Laboratory for accessing Cyc [[11]], KEE [[10]], and Epikit. Karp and Tom Gruber began developing GFP in 1993 for use with the EcoCyc [[6]], GKB Editor [[9]], and Ontolingua projects [[3]]. In 1995 Karp et al. authored a publication describing the version of GFP in use at that time [[8]]. The protocol has undergone many revisions, based on input from many people, including Fritz Mueller, Karen Myers, Suzanne Paley, and Robert MacGregor.


next up previous contents index
Next: The GFP Knowledge Model Up: The Generic Frame Protocol Previous: Contents

For questions regarding GFP