Generic Frame Protocol

Tom Gruber <gruber>
Date: Fri, 13 May 1994 11:54:17 -0700
From: Tom Gruber <gruber>
Message-id: <199405131854.LAA03057@HPP.Stanford.EDU>
To: ontolingua@HPP.Stanford.EDU
Sent-via: ontolingua@ksl.stanford.edu
Subject: Generic Frame Protocol
Reply-to: gruber@HPP.Stanford.EDU

Now that Ontolingua has been released, we can tell you about some of the new
features.  One is a API for frame systems, called Generic Frame Protocol
(GFP).  This was developed by Peter Karp at SRI and Tom Gruber at Stanford,
after accumulating too much experience struggling with too many frame systems.
The GFP specifies a set of functions that you can call from your Lisp
program to access a variety of frame representation systems.  For example,

do-kb-frames (iterate over all frames in KB, without consing if possible)
get-frame-named (maps strings and symbols to frame objects)
get-slot-values (returns values of a named slot, optionally with inheritance)
put-slot-values
get-facet-value
get-class-all-subs (get all classes that are subclass-of it)
get-class-direct-subs (same as above without inheritance)
and so on.

What has this got to do with Ontolingua?  Two things.  

First, Ontolingua is based on a conceptualization that generalizes over a
large class of frame systems (which is specified in the frame ontology).  
This conceptualization provides the semantic model for the spec.  (It's only a
foundation; since the GFP is procedural, its specification needs to talk about
inheritance and constraint checking and other sorts of inference that are not
described in ontologies).

Second, Ontolingua now includes a little frame system inside it.  If you set
the target implementation to :generic-frame, then calls to ontolingua forms
such as define-class will create data structures in memory that store the
definitions.  These data structures can be queried, and modified, using the
GFP access functions.  This frame system is slow, but because it isn't
optimized, hopefully it is free of bugs and portable.  Also, since it is
completely GFP conformant, the generic-frame implementation provides an
example of how to write GFP back ends.

You get the latest GFP release without asking as part of the Ontolingua 4.0
release (including the alpha release).  It is simply the subdirectory called
gfp (and it is loaded into Ontolingua). If you want the GFP code without
ontolingua, you can get it standalone as described below.

Since GFP and Ontolingua users have many interests in common, we're decided to
reuse the ontolingua mailing list for general discussion about GFP as well.
That's the list you're reading now, ontolingua@ksl.stanford.edu.

Access information, from the README.TEXT file:

The Generic Frame Protocol (GFP) is an application programmer interface layer
for accessing object-centered knowledge representation systems (aka "frame
representation systems").  It comprises a set of Common Lisp functions that 
provide read and write operations on KBs, frames, slots, facets, and value
annotations.  It currently has back-ends for Loom, Theo, the KR system used by
SIPE, and Ontolingua.  From Ontolingua, one can read in KBs written in KIF (or
Ontolingua's frame syntax) and access them in GFP; or translate a GFP KB into
KIF, Loom, Epikit, or HTML.

The Lisp code and specification document are available by ftp at
  ftp://ksl.stanford.edu/knowledge-sharing/lib/gfp/

GFP distribution contains two subdirectories (lisp and spec) containing the
Lisp source code for the GFP, and its specification.

The specification document, for instance, is at
  ftp://ksl.stanford.edu/knowledge-sharing/lib/gfp/spec/paper.ps


Tom Gruber and Peter Karp