[MUD-Dev] OpenCyc, design implications of ontological systems?

[Bruce Mitchener]

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:

   http://www.ai.mit.edu/~jrb/goo/index.htm
   http://lambda.weblogs.com/discuss/msgReader$3165

and Eric's mail directly:

   http://www.ai.mit.edu/~jrb/goo/mail-archive/msg00013.html

--- 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
    opinions.

    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
    variable declarations.

    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
    useful distinction.

    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
    surprising ways.)

    Cheers, Eric
---- 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.

Cheers,

  - Bruce

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev