[MUD-Dev] OpenCyc, design implications of ontological systems?
bruce at cubik.org
Sun Apr 21 00:18:55 New Zealand Standard Time 2002
Robert Zubek wrote:
> From: Miroslav Silovic
>> Robert Zubek wrote:
>>> This will break the translation of an OpenCyc ontology into an
>>> OO representation. AFAIK, the OO model doesn't allow for an
>>> equivalent of instantiation between collections. C++ programmers
>>> sometimes unknowingly kluge this by trying to represent
>>> something that looks like instantiation using the superclassing
>>> mechanism, but that seems suboptimal because it muddles the
>>> distinction between instances and specializations...
>> This only applies to certain OO systems. In CLOS, each class is
>> an instance of a metaclass. The metaclass defines such things as
>> inheritance precedence, method lookup and sorting algorithm, and
>> even class definition syntax (you can override class definition
>> parser on the metaclass). Metaclass may also track other things;
>> basically it defines the beheviour of its instances with fairly
>> low granularity.
> I agree, MOP is wonderful - it lets you do runtime adjustment of
> the class hierarchy, modify class and slot definitions, and all
> the other good stuff that meta-objects ought to do, but I'm still
> not sure it lets one do a direct translation of the OpenCyc
> representation into CLOS. Using CLOS, can a *class* be an instance
> of another base-level class (not of a metaobject class)?
> In any case, isa and genl (the instantiation and generalization
> relations) are just two of the difficulties of representing Cyc in
> an OO model. Then there is the problem of translating relations
> and attributes, which I'm not sure how one would even begin to
> approach... :)
In this context, the set of comments from Eric Kidd quoted below
seemed relevant and interesting ...
There was some discussion of a language 'GOO' or Generic Object
Oriented language on Lamba the Ultimate recently:
and Eric's mail directly:
--- begin ---
From: Eric Kidd <eric.kidd at xxxxxxxxx>
Subject: Prototypes (was Re: kickoff)
Date: 18 Apr 2002 01:06:06 -0400
I participated in these discussions, and I'll try to summarize
some of the main points for you. Jonathan may want to correct me
here. I only contributed a small amount of code to Goo, and none
of my statements should be taken as anything more than personal
1. <foo> is typically not an instance of <foo>.
We found that--in most of our programs--that the prototype for
class <foo> typically had several missing fields. These were
filled in by individual instances cloned from <foo>. So (isa?
<foo> <foo>) returned true, but the "class" <foo> did not obey
the contracts of an "instance" of <foo>.
So a variable of type <foo> could hold either "subclasses" of
<foo> or "instances" of <foo>. This had lots of weird
consequences, and made some of our code smell funny.
Now, you could work around this by making sure that the "class"
<foo> was also an "instance" of <foo>. This is quite easy for
<rectangle> (just set all the co-ordinates to 0), but rather
awkward for <input-stream> (what input should it return?).
2. We wanted first-class types.
Goo, like Dylan, makes extensive use of types. You can dispatch
on them, instantiate them, introspect them, and use them in
Since types are a major, first-class abstraction in Goo, we
wanted to have such classes as <type>, <class>, etc. But since
you can't tell classes from instances in a prototype-based
language, these abstractions never work right.
In short: "Dog" isn't a dog. The furry thing wandering down the
hall is a dog. "Dog" is a word, or a platonic category, or a
biological classification. But none of these things have long
floppy ears and a tail.
Prototype-based languages are simple and easy to program. And if
you have no more of a type model than SmallTalk, you probably
don't even pay any conceptual penalty. But once you start having
type declarations and first-class types, prototypes blur a
So it's basically a matter of taste, and consistency with other
parts of the language design. (Language design is not an
especially orthogonal problem--too many features interact in
---- end ----
His concerns/opinions echo some of my own experiences with having
worked with prototype-based object-oriented langauges (like ColdC)
for some years now. They're also a restatement of some of the
differences between #$genls and #$isa in OpenCyc and why a direct
mapping of something like OpenCyc or the Cyc object model to a
different object oriented language that doesn't share those object
model features may not be productive or a good thing.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev