Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!sri-unix!SHEBS@UTAH-20.ARPA
From: SHEBS@UTAH-20.ARPA
Newsgroups: net.ai
Subject: Frames Question
Message-ID: <1388@sri-arpa.UUCP>
Date: Tue, 26-Jun-84 13:44:04 EDT
Article-I.D.: sri-arpa.1388
Posted: Tue Jun 26 13:44:04 1984
Date-Received: Sun, 1-Jul-84 04:45:52 EDT
Lines: 56

From:  Stan Shebs <SHEBS@UTAH-20.ARPA>

As a relief from the insubstantial debates on insubstantial souls, I
have a question about frames.

>From my studies, I have observed two fundamentally ways of viewing
slots in frames: as heads of predicates, or as instance variables of
objects.

In the first view, if a FIDO frame has an AGE slot with the value 2,
then that is equivalent to making the assertion AGE(FIDO,2).  Thus the
name of the slot becomes the head of a predicate.  The advantages of
this view are twofold: the inheritance mechanism of a frame system
then appears as an inference rule, and slots can be made into frames
themselves, thus making meta-level knowledge easy (for instance, one
could say DATATYPE(AGE,NONNEGATIVE_NUMBER) to assert that AGE could
only hold values of a certain type).  This view of slots as
first-class concepts or frames is exemplified by RLL, and by simple
frame systems built on top of logic languages.

The second view is exemplified by FRL, its descendants, and any of a
number of object-oriented systems.  Here, slots are in some sense
"local" to frames or classes of frames, and an AGE of FIDO may have a
completely different meaning than an AGE of PINOT_NOIR.  Meta-level
knowledge generally resides in facets and other subparts of a slot, so
in a well-developed system, the "value" of a slot is often a rather
complex entity.  Interestingly enough, the facets (such as $VALUE,
$IF-ADDED etc) are usually quite consistent in meaning (which no doubt
simplifies meta-knowledge; one then needs only a few frames named
$VALUE, $IF-ADDED, ... to express the meanings of facets).

Each view can be simulated using the other.  To simulate the "slot as
frame view", the "objects view" can make all slots be defined for a
toplevel frame THING, and then have frames with the same names as the
slots; while the "slot as frame view" can have slots of slot frames
that point to many different ones (so for instance the AGE slot frame
has a slot VERSIONS that points to ANIMAL_AGE and WINE_AGE slots - all
the associated paperwork is handled automatically by the system).  Of
course, such simulations may be extremely inefficient! but I just
mention them to show that neither method is inherently more capable
than the other.

Now for the question: which view is favored by practitioners, and why?
Do any existing KRLs allow the view of slots to be changed according
to the problem, or do the two views require such fundamentally
different implementations that it's just better to stick to one or the
other?  Is it possible to do work using frames without being concerned
about the particular view imposed by the frame system? (my own
experience says no - converting an FRL-based program to an RLL-based
one is not easy!).  Are there problem domains in which one view is
distinctly superior to the other?  If so, what are they, and why is
that view superior?

Any answers or insights will be greatly appreciated...

                                                        stan shebs