Notes on GFP for Loom users


The GFP was designed to present a uniform interface that masks the details of the underlying FRS. While there are many advantages to this approach, the terminology can be confusing for users who are accustomed to interacting with one particular FRS. The problem can be particularly acute for Loom users, as the Loom style of definitions, with necessary and sufficient conditions, does not map easily into the frame, slot, value, and facet structures that make up the GFP. For this reason, we describe here how the various GFP structures are interpreted as they are applied to Loom knowledge bases, and which parts of Loom are not supported by GFP. The GFP and the GKB-Editor have been implemented and tested with Loom 2.1 using lite-instances.

Classes and slots in GFP map to concepts and relations/roles in Loom, respectively. When we create a GFP slot with a particular domain, we do two things: we create a relation corresponding to the slot, and then we redefine the domain concept to take that relation as a role (this behavior produces results analogous to setting the :domain-implies-role feature for clos-instances).

Facets are annotations on slots. The GFP uses facets as a means of defining constraints, restrictions and defaults on frames, slots and slot-values. To this effect, a set of standard facets have been defined. The GFP also supports a more general use of facets to annotate slots with arbitrary values, but this use has no corresponding expression in Loom. The standard facets currently cover only a small number of the possible restriction types available to Loom users, and unfortunately there are some quite common restrictions that cannot be expressed using the GFP (for example, it is impossible to state using GFP that some value should be less than a given number). For this reason, the GKB-Editor also offers a means by which the user can directly edit the Loom definition of a frame, without going through the GFP. We hope this measure will be just a temporary one.

The standard facets available in GFP, and their corresponding interpretations in Loom, are described below. In keeping with Loom behavior, facets can be defined on classes and slots only -- instances can inherit facet values, but cannot have any of their own values.

Loom does not permit easy incremental modification of defaults, restrictions, and superconcepts for its concepts. The GKB-Editor and the GFP, however, specifically encourage building up frames incrementally. As an implementation detail, when a class is incrementally modified by a GFP operation, the Loom concept definition is retrieved and altered, and the concept is completely redefined.

The GFP currently has no support for Loom productions, actions or methods.


Links

Return to the GKB-Editor Overview page.

Read about the Generic Frame Protocol.


Suzanne M. Paley <paley@ai.sri.com>
Last modified: Wed May 29 16:43:03 1996