Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

frames vs. objects

155 views
Skip to first unread message

Herve GARNOUSSET

unread,
Feb 28, 1993, 10:52:31 PM2/28/93
to

Hello world!

Does anyone out have informations about differences between frame-based systems
and OOP?
Any help should be welcome.
Please e-mail answers...
--Hg

--
Herve E. Garnousset
BULL CEDIAG PRODUCTS
(LV 4B21)
68, Route de Versailles Phone : [33] (1) 39-02-47-31
78430 Louveciennes Fax : [33] (1) 39-02-46-52
FRANCE E-Mail: h.garn...@frlv.bull.fr

Potdevin Ralph

unread,
Mar 8, 1993, 7:08:08 AM3/8/93
to
As far as I know, it is more a difference of approach, of philosophy.
I don't see a fundamental difference between frames and classes, slots
and fields/attributes, daemons and methods and so on...
Perhaps the OOP approach is more clearly involved with software
ingeneering matters such as encapsulation, reutilisability, etc. but
you can find --or at least simulate-- all this with a frame-flavoured
language.

Finally, it all seems to be a matter of taste or personal experience
to choose between the two.

Ralph Potdevin
Supelec CRIN
57 METZ 54 NANCY
FRANCE FRANCE

e-mail: potd...@esemetz.ese-metz.fr
potd...@loria.loria.fr

DEFRANCESCO Massimo

unread,
Mar 23, 1993, 2:53:04 PM3/23/93
to
I just saw the end of this thread today (I haven't read comp.ai for
a long time).

I asked the same question a couple of year ago, and got some interesting
answers. Can anybody send to me the address of the original poster,
so that I can forward them to him?

Thanks.

Massimo


DEFRANCESCO Massimo

unread,
Mar 24, 1993, 6:51:55 AM3/24/93
to


I've received many requests for the replies I have, so I will post
them here:

Original question (back in January 91):

Hello networld.

I'm not directly involved with frame languages, but as a teaching assistant
I have to deal with AI basics, actually semantic networks and frames.

What seems to me not very clear, at least in AI introductory manuals,
is the real difference between the concepts of OOPL (especially OO extension
of "AI languages") and frames.

Indeed, both frames and objects are hierarchical structures with inheritance
and slot daemons.

This similitude has grown, since I know at least a frame system which allow the
user to define methods and which implements a message mechanism.
What is worse, most of the examples found in AI manuals or research
papers are actually best suited to OOP than frame systems, and the same
examples are used in OOP tutorials
As well, even when frames are used in their context (i.e. KR and reasoning
systems), most of the time the same functionality can be achieved
with objects. The only exception is maybe the matching (recognition) problem,
in which an undefined instance is matched against the frame hierarchy
to find the class that best fits its description, but this is a rarely
addressed problem.

The main differences between frames and objects I'm aware of are:

1) syntax: frames are usually easier to write than objects,
whose syntax depends on the underlying language and is
complicated by the greater number of features of object systems
(In CLOS it is easy to make syntactic changes (macros) to simplify
the writing of objects)

2) Inheritance: in pure frames the inheritance is (should be)
dynamic, i.e. values of superframes slots are not propagated;
it is the inheritance mechanism which search through the inheritance
path each time that an unfilled slot is retrieved. Objects
usually complete the instance when it is created, for performance
reasons.
This is no more true; hybrid techniques are today used in
frame systems to avoid the time penalty of dynamic inheritance.

3) Encapsulation: in object oriented languages, data and control are
usually encapsulated in 'black boxes' (the "object"), complicating
data modification and reasoning. Frame systems don't have
encapsulation.
This is not true of every Object system; in CLOS again, it is not
the case.

I think the biggest one is: origin/purposes: Objects are Software engineering
tools and Frames are AI tools for Knowledge Representation.

The point is that today we have object extensions to "AI languages" (flavors,
CLOS) that can be used as AI tools, and Frame systems that tend to include
more and more features of OOP.

The question which emerges from such a mess is the following: can we
say that it exists a theoretical framework for 'hierarchical structures'
of which objects and frames are just two different implementations?, and,
as a corollary, is it justified to merge frames and objects to obtain a
unified paradigm?

Any comments are welcome.


-- Massimo


------------------------------------------------------------------------------
Massimo de Francesco email: mas...@cuisun.unige.ch
Computer Science Center voice: (+4122) 7876582
University of Geneva



=============================================
Afzal Ballim <af...@divsun.unige.ch> writes:

Hi,
I believe that the difference is mainly historical. Frames go back
a long way in AI (at least as far back as Minsky's 1974 paper, and similar
things can be found in even earlier work, although without the name
"frames"). The first languages with what we might today call "objects"
would be Smalltalk and Lisp Flavors. This are around the same era as the
Minsky paper, but (at least in the case of Lisp Flavors) may well have
been influenced by Minsky's work.

I hesitate to say that OO is derived from AI, however I do believe
that AI at least pushed it along. Today the reason they remain separate is
largely terminological. People brought up in the AI schools where "Frames"
are an important notion will of course stay with that term. For the rest
of the world, now that almost every language has a version with "OO" the
term "objects" is more appropriate. Of course, now people in AI are also
using those languages (CLOS for example; or even people like me who use
C++) so maybe the term "frame" will disappear in some usage. I think it
will stay around, however, because one difference that it was meant to
capture was a psychological one based on focus of thought, stereotypes,
and prototypes.

-Afzal


==========================================
Schneider Daniel <schn...@divsun.unige.ch> writes:
[Sorry, this is in french]

salut,

pour moi la difference essentielle entre oo et frame langages ne
reside pas dans les objets ou dans les difference entre leur
structures, mais dans le fait que dans un frame-langage on te donne
des tas d'outils pour gerer une sorte de base de donnees. Par exemple,
tu peux retrouver les frames selon certaines criteres; meme dans un
petit langage comme XRL dans le livre de Charniak, McDermott.. (AI
Programming). On peut implementer relativement facilement un reseau
semantique avec un frame-language je crois. J'estime que Winston a
plus ou moins fait cela pour ses programmes de raisonnement
analogique...... donc, dans ma perception, un langage frame c'est une
extension d'un langage oo... comme les langages de simulation oo qui
representent un autre type d'extension.

Par contre, le frame en tant qu'idee en AI n'a pas grand chose a voir
avec les langages oo ou les langages frame comme FRL. ... mais
certaines idees orginales de l'article de minsky ont eu un impact.
(Mais du cote implementations de frames, je regarderai plutot du cote
des MOPS et TOPS etc de Schank et al. ou alors aupres certains gens
qui font le raisonnement analogique en droit ......)

....voila rapidement mon grain de sel - Daniel

Daniel K.Schneider, TECFA (Educational Technologies and Learning)
Faculte de Psychologie et des Sciences de l'Education, University of Geneva,
1211 Geneva 4 (Switzerland), Tel.(..41)22 705 7652, Fax. (..41) 22 20 29 27.


========================================
Rene Bach <re...@tech.ascom.ch> writes

I just read your questions. I would be interested if you get the reference
to the overall theoretical OO scheme over both OOP and Frames. However,
I would ask this question to the people around you. What is their answer ?
what is Oscar's answer ?

My answer is that historically those approaches share a lot (cross-fertilization
of ideas). It is just that the strong-typing proponents have recuped the
ideas and formalized them (over-formalized them ?) according to their believes.
There is a lot of jargon (such as operator overloading) coming from those
people which has to do more with the implementation issues than the conceptual
level. (as far as I am concerned, there is no operator overloading in OOP)
It just happens that the same symbol is used to perform different operations
depending on who the receiver of the message is.

just my $.2 cents worth

Rene
_______________________________________________________________________
Rene Bach - Ascom Tech AG - CH-4503 Solothurn - Switzerland
Email: re...@tech.ascom.ch - Phone: +41 65 243028 - Fax: +41 65 235761

=======================================
Roland Hubscher <rol...@tigger.Colorado.edu> writes

Hi Massimo,

how are you? Are you almost finished with your thesis or still far
away from the end (like I am)?

I have been interested with knowledge representation for several years
now and had several discussions about the difference between objects
and frames (and knowledge bases and data bases). Let me try to point
out the important differences (which might be right or wrong but are
certainly influenced by a Brachman/Levesque course I had a few years
ago and the use of KEE in Rolf Pfeifer's AI Lab (Uni ZH)).

> Indeed, both frames and objects are hierarchical structures with
> inheritance and slot daemons.

To see the difference better we should probably use "pure" frames and
OO systems. Therefore, frame slots have demons (and no methods) and
objects have methods (but no slots and no demons). [This is not
necessarily true in practice but if you want to convince your students
that there are important diffs then tat might be the way to go.]

> As well, even when frames are used in their context (i.e. KR and
> reasoning systems), most of the time the same functionality can be
> achieved with objects. The only exception is maybe the matching
> (recognition) problem, in which an undefined instance is matched
> against the frame hierarchy to find the class that best fits its
> description, but this is a rarely addressed problem.

The functionality is the same, however some implementations are more
natural with frames others with objects. Even more important, the
choice of frames or objects results in different proramming styles as
I will point out later. With respect to classification, see KL-ONE
(frame based system/semantic network) which has a classification
mechanism (which is at least NP-hard, as far as I can remember (I
guess it is decidable, but I'm not sure)).

> The main differences between frames and objects I'm aware of are:
>
>1) syntax: frames are usually easier to write than objects,
> whose syntax depends on the underlying language and is
> complicated by the greater number of features of object systems
> (In CLOS it is easy to make syntactic changes (macros) to simplify
> the writing of objects)

Probably not a very important difference and dependent on the very
system you are using.

>2) Inheritance: in "pure" frame systems the inheritance is (should be)

In frame systems you normally have hierarchies with respect to
specialization (or set inclusion, ...), i.e., you have inheritance
along "objects" that are more special with respect to their STRUCTURE.
In OO systems you often prefer to have hierarchies based on similar
BEHAVIOR, i.e., if you want to add a new class you add it where yo
have an object with a similar (slightly more general) behavior but not
necessarily a similar structure.

>3) Encapsulation: in object oriented languages, data and control are
> usually encapsulated in 'black boxes' (the "object"), complicating
> data modification and reasoning. Frame systems don't have
> encapsulation.
> This is not true of every Object system; in CLOS again, it is not
> the case.

I'm not usre whether that's a good distinction. Frame systems are used
by access orientend programming, i.e., you access a slot and methods
may or may not fire (they are hidden (in a black box, if you will)).
Objects are accessed by methods and the slots are hidden. You access
the structure of frames and you ask for a behavior of an object.

> I think the biggest one is: origin/purposes: Objects are Software
> engineering tools and Frames are AI tools for Knowledge
> Representation.

I guess, SIMULA is the OO's father.

> The question which emerges from such a mess is the following: can we
> say that it exists a theoretical framework for 'hierarchical structures'
> of which objects and frames are just two different implementations?, and,

Apparently no, if you agree with what I have said about the
structure/behavior distinction.

> as a corollary, is it justified to merge frames and objects to obtain a
> unified paradigm?

Yes, but not really as a corollary because I said no to the first
question. In KEE, these concepts are merged: units are like frames but
the slots may also contain methods. If you are more intereted in these
unification you probably should have a look at KEE. In case you don't
have one around in Geneva you certainly could have a closer look at it
at the Univ of Zurich where they (incl me) wrote a demo expert system
that uses all the concepts of KEE (if you are once in Zurich you could
contact somebody (e.g. Matthias Gutknecht gu...@ifi.unizh.ch) from the
AI Lab and I'm sure they are glad to show you the system).

Do my comments make some sense. I'm not anymore into knowledge
representation that much (I'm drifting to the associationist's side)
so I might be quite wrong (although I don't hope so).

Hope to hera something from you. Take care,


[Hi Roland! Did you receive my message? Are you still in Colorado?]

-roland

(rol...@boulder.colorado.edu || rol...@cs.colorado.edu)


==============================
Peter F. Patel-Schneider (pf...@allegra.att.com) writes

I saw your message of about a month ago on frames and objects and, after
some deliberation, I thought I would send you a short note on this subject.

There are at least two approaches to frame and objects in the AI world.
One approach, embodied in systems like CLOS (the Common Lisp Ojbect
System), is, as you state, almost indistinguishable from OOPLs. I would
say that systems like CLOS are not really representation systems at all.

The second approach, embodied in systems like KL-ONE, KANDOR, BACK, LOOM,
and CLASSIC, treats frames as definitions or concepts. It is this approach
to frames that retains and builds on their representational aspects. In
this approach one does not talk about inheritance per se, but instead talks
about deducing properties of more-specific concepts from properties of
more-general concepts. Inheritance is then a mechanism for implementing
this inference.

If you are interested in this, there are quite a number of papers available
on the second approach to frames. In particular, I have a couple of papers
that sort of talk about the difference between the two approaches. They
are

@Article{patel-schneider:practical-obkr,
author= "Peter F. Patel-Schneider",
title= "Practical, Object-Based Knowledge Representation for
Knowledge-Based Systems",
journal= "Information Systems",
volume= 15,
number= 1,
year= 1990,
pages= "9--19"}

@InCollection{patel-schneider:inheritance,
author= "Peter F. Patel-Schneider",
title= "What's Inheritance got to do with Knowledge Representation?",
booktitle= "Inheritance Hierarchies in Knowledge Representation and
Programming Languages",
editor= "M. Lenzerini and D. Nardi and M. Simi",
publisher= "John Wiley and Sons",
year= 1991,
pages= "1--11"}


If you have any more questions, don't hesitate to ask.


Peter F. Patel-Schneider
pf...@research.att.com

0 new messages