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

[Bruce Mitchener]

Sean Kelly wrote:
> From: "Robert Zubek" <rob at cs.northwestern.edu>

>> I completely agree with the notion of trying to represent the
>> ontology of game objects more precisely as a proper ontology. But
>> I thought about what you proposed in terms of compilation into an
>> OO model, and translating faithfully from a scheme such as the
>> Cyc Upper Ontology into an OO model is going to be rather
>> problematic.

> It shouldn't be too bad, though there isn't a direct 1-1 mapping.
> What I'm wondering is why one would want to build a class
> structure based on an ontology for the sake of code generation as
> it applies to game programming?  Just as a way to classify static
> game objects in a metalanguage and let the code generator
> determine the inheritance structure for you?  IMO the strength of
> ontologies, if I understand them correctly, is in their ability to
> represent knowledge and define relationships (it seems to be along
> the lines of what I'm kicking aroung in the ecolohy thread).  I
> would think that this would be more useful if applied within AI at
> runtime than in defining the compile-time object heirarchy.

Well, in my original post [1], I'd referred to outputting a body of
code, not just a class hierarchy.  Given my background of working
with dynamic rather than static systems, I'd been thinking about
using the logic system to control the actual OO system at runtime,
so that changes could be reflected in realtime, rather than with a
re-compilation/linking phase.  (I have that with Cold, why would I
want to give that up? :)

So, given that, I wasn't looking at it to generate a "compile-time
object hierarchy" but more as using it as a reflective/dynamic way
of editing/looking at the system as a whole, including code,
assigned behaviors, and the object hierarchy.  Just that it would've
been caching a lot in imperative code. :)

In one of my responses to Robert Zubek, [2], I'd explained some of
the reasongs for looking at that sort of implementation, rather than
just using OpenCyc directly:

     "I should take some time to explain my motivation in wanting to
     create that mapping from Cyc to an OO model and how I have
     since found that the reasons for some of that motivation are
     not entirely valid.

     "Coming from a text mud where we have 2+ gigs of data, I was
     worried about the size of the logic database under Cyc, whether
     or not it could be disk-based effectively without impacting
     query performance.  Query performance with it being hit
     (potentially) fairly heavily for operations within the
     gameworld seem like they could become staggeringly complex (and
     frequent)."

But, I've gotten over that and am willing to look at interacting
directly with OpenCyc at runtime.  (But not yet interested in
getting rid of all of the imperative code from the system.)

Something that had helped get me going downt his path originally
were some discussions with Doug Orleans (are you still on this list
Doug?), where he had talked about a commonality between aspect
oriented programming [3] and (one of my favorite things) predicate
dispatch [4].

He wrote a paper that he just presented and is now available online:

   http://www.ccs.neu.edu/home/dougo/papers/aosd02/

    "Languages that support incremental programming, that is, the
    construction of new program components by specifying how they
    differ from existing components, allow for clean separation of
    concerns. Object-oriented languages support incremental
    programming with inheritance and dynamic dispatch features:
    whenever a message is sent, a decision occurs, but the branches
    of the decision can be specified in separate
    components. Aspect-oriented programming and predicate
    dispatching both introduce language mechanisms that improve on
    this support by allowing an extensible decision to depend on
    information about the message send other than just the dynamic
    type of the receiver or arguments. A small prototype language is
    presented that unifies the best features of these mechanisms,
    providing uniform support for incremental programming whether
    concerns are crosscutting or not. The language is demonstrated
    with a running example, a small data structure library that is
    incrementally extended with optimizations and new operations."

What I really want to see are systems that are more maitainable over
time, as the number of rules, entities, relationships and behaviors
grow.  I'm hoping that OpenCyc, or something like it, may help me
down that path.

  - Bruce

[1]: http://www.kanga.nu/archives/MUD-Dev-L/2002Q2/msg00099.php
[2]: http://www.kanga.nu/archives/MUD-Dev-L/2002Q2/msg00247.php
[3]: http://agora.cubik.org/wiki/view/Main/AspectOrientedProgramming
[4]: http://agora.cubik.org/wiki/view/Main/PredicateDispatch

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