next up previous contents index
Next: The GFP Procedure Language Up: The Generic Frame Protocol Previous: GFP Operations

Differences amongst FRSs

  GFP supports extensions to the knowledge model to capture the features of frame representation systems (FRSs) that are different from the core model. This diversity is supported through a mechanism called behaviors for an FRS, which provide explicit models of the knowledge model properties that may vary. Since FRSs are different and may not support every aspect of the GFP knowledge model, we also discuss what it means for a GFP back end implementation to be compliant.

Knowledge Base Behaviors

  Each behavior has a name that is a symbol in the keyword package and is associated with a set of values describing the variations of that behavior that are supported for a KB. GFP does not provide any operations using which the behavior values supported by a KB can be specified. An implementor must encode the values of the behaviors for each KB type in the implementation so that they can be queried using   get-behavior-supported-values. The initial behavior values for a KB are the same as the behavior values for its KB-type.

The supported values of a behavior can differ from the current value of a behavior. For example, if a KB type supports both immediate and deferred constraint checking, the :constraint-checking-time behavior will have two supported values representing alternative times when constraints can be checked. An application program can choose one of the two values as the current value and expect the FRS to act based on it. The current value of a behavior for a KB can be set using the operation   put-behavior-values. If a KB supports only one value of a behavior, its current value is always equal to its supported value. An application program can query the current value of a behavior of a KB, using   get-behavior-values or   member-behavior-values-p and use the result in executing code specific to the values of that behavior.

A user program accesses the behaviors of an FRS either for a KB-type or for a specific KB. The initial values of the behaviors a KB are obtained from its KB-type. The behaviors of a KB-type, in turn, depend on the behaviors of an FRS. Therefore, from now on, we use the terms ``behavior of a KB'', ``behavior of a KB-type'' and ``behavior of an FRS'' interchangeably.

Frame Names

As a user convenience, many FRSs allow a user to refer to frames by frame names that are unique within a KB. Some FRSs, however, do not support such a feature and require use of special data structures, for example, frame handle, to refer to frames or allow anonymous frames. An FRS may advertise the support for frame names by the :frame-names-required behavior. When the value of :frame-names-required is true, it means that each frame is required to have a name, each frame name is unique in the KB, and the frame name supplied at the time of creating a frame can be used at a later time to locate the frame using   coerce-to-frame until changed by   put-frame-name. When the value of :frame-names-required is false, frame names are not required, and may be non-unique in a KB. One may not be able to locate a frame using the name that was supplied when the frame was created.

Value Constraint Checking

Many FRSs provide runtime constraint checking. For every update to a KB, some FRSs evaluate constraints that have been defined by the user.

Constraint checking is described by three behaviors: :constraint-checking-time controls when constraint checking is performed, :constraint-report-time controls when constraint violations are signaled, and :constraints-checked specifies which constraints are checked.

The value of :constraint-report-time is one of the following

The values of the :constraints-checked behavior are a set the standard facet names described in Section 2.10.2. The presence of a facet name in the set of values of :constraints-checked means that the FRS checks the constraint defined by that facet. For example, if the values of the :constraints-checked behavior are {:value-type, :cardinality}, it implies that every time a value of a slot is updated, the constraints defined by :value-type and the cardinality of the slot (See Axioms in Section 2.10.2) are checked.

Frame Representation of Entities

FRSs differ on which entities are represented as frames in a KB. For example, in some FRSs, each slot is represented by a frame, which we call a slot frame, whereas, in other FRSs, a slot is represented by a symbol, and there is no frame in the KB corresponding to each slot. The result of some GFP operations depends on whether slots are represented as frames. For example, if an FRS supports slot frames, the GFP operation get-kb-frames will typically include slot frames in its return value.

To encode such differences, GFP supports a behavior called :are-frames whose value is a set of one or more of the following: :class, :slot, :instance, :facet, and individual. If the value of :are-frames contains a certain entity type, it implies that frames are used to represent those entities. If :slot is a member of the value of :are-frames, it means that slots may be represented by frames. It does not, however, preclude the existence of slots that are not frames. In most FRSs, classes and instances of those classes are represented as frames, and therefore we expect the most common set of values for :are-frames to be {:class :instance}.


The behavior called :defaults describes the model of default inheritance used by an FRS. The GFP knowledge model does not take any position on how the default values are inherited, but the :defaults behavior is provided to advertise the support for some commonly used inheritance algorithms. The valid values of the :defaults behavior include


  The behavior called :compliance describes the compliance classes a GFP implementation satisfies. At present, three compliance classes are defined.

The :user-defined-facets compliance class is contained in the :facets-supported class. The :read-only compliance class overlaps the :facets-supported compliance class. The above compliance classes have been defined based on our past experience in using FRSs. We expect the list of compliance classes to evolve with the continued usage of the protocol.

Class Slot Types

As discussed in Sections 2.2 and 2.4, there can be two types of slots for classes: template and own. A template slot is inherited by all instances of the class, while an own slot describes values associated with that particular class but not inherited by the instances of that class or necessarily by the subclasses of that class.

Certain FRSs support both template and own slots for classes, while others support template slots only. The behavior :class-slot-types indicates the types of slots supported by a given FRS. The value of :class-slot-types is a set containing zero or more of the following values.


  The :collection-types behavior specifies how the FRS interprets multiple values for a slot. The possible values are

Some FRSs may support more than one possible interpretation of multivalued slots, in which case, the :collection-type facet can be used to specify how multiple values are to be interpreted for a particular slot. If a slot has a value for the :collection-type facet, it overrides the value of the :collection-type behavior for that slot. The default collection type for a slot (when multiple collection types are supported) is the first member of the list of values of the :collection-type behavior. It is an error to change the collection type for a slot after slot values have been asserted for it. If the collection type for a slot is changed when the slot already has values, the resulting behavior is undefined. The :list collection type only specifies the order of direct slot values. The order of inherited slot values for a slot with collection type :list is undefined.

Compliance to the GFP Specification

The GFP specification allows a considerable variation amongst the FRSs that may be accessed using it. Therefore, it is important for us to understand the minimum requirements that a GFP back end implementation must satisfy. We have identified three rules that can be used to check the compliance of a GFP back end implementation.

Compliance Rule 1: Legal values for all behaviors must be specified

A GFP back end must specify a legal value for all the required behaviors. As listed in Section 4.1, the required behaviors are :frame-names-required, :compliance, :class-slot-types, :collection-type, :defaults, :constraint-checking, :are-frames. The legal values of behaviors have been chosen so that a satisfactory value for representing most FRSs is available.

Compliance Rule 2: An implemented GFP operation must obey the specification

We say that a GFP operation is implemented and compliantly obeys the specification if the following three conditions are met.

It accepts all legal encounterable values of its input parameters.

It must return the documented return values for all legal encounterable inputs.

It must have the effects on the KB as specified in the knowledge model and the documentation of the operation.

These three conditions have been designed to make it easy to use a GFP application across multiple FRSs. They also allow us to exclude any trivial GFP implementations that may provide GFP operations that do not conform to the intention of the specification.

For example, the GFP specification requires that any operation accepting a frame argument must accept at least a frame handle or a frame object as a valid argument. If the :frame-names-required behavior is true, the operation must also accept a frame name as a valid value for the frame argument. An implementation that accepts only frame objects as a valid value for the frame argument will not be compliant. Some systems may not support all values of input arguments. For example, the GFP specification defines three values for inference-level: :direct, :taxonomic, and :all-inferable. We can imagine an FRS that does not support any inferences beyond taxonomic inferences. It must still accept :all-inferable as a legal input value for the :inference-level.

GFP operations must return all the documented return values. For example, get-slot-values is documented to returns three values: a list of slot values, exact-p, and more-status. To be compliant, it must return these three values. For a function accepting an error-p argument, with a value of true for error-p, an error must be signaled if required.

GFP operations must have specified effects on the KB. For example, an add-slot-value implementation should result in the addition of a given value to the specified slot so that it can be retrieved using the get-slot-values operation. The GFP operations have been documented to a degree of precision that was practical and sufficient room is left for FRSs to differ. For example, with an inference-level value of :direct, to be compliant, an application must return at least locally asserted values. An application is free to return additional values without being non-compliant.

Compliance Rule 3: Systems may choose a compliance class

  In Section 4.1.5, we defined four compliance classes -- :facets-supported, :user-defined-facets, :read-only, and :monotonic. The GFP implementations may choose to implement a subset of GFP operations to conform to these compliance classes. For example, an implementation that supports all the read operations satisfying the compliance rule 2, can claim to be GFP-compliant in the :read-only compliance class.

next up previous contents index
Next: The GFP Procedure Language Up: The Generic Frame Protocol Previous: GFP Operations

For questions regarding GFP