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

[Sean Kelly]

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.

> For better or for worse, the Cyc representation is more powerful
> than OO representation. In particular, Cyc uses the vocabulary of
> collections, individuals, generalization, and instantiation -
> which in certain respects is mirrored in OOP, but not
> always. Collection is roughly like a C++ class, and individual is
> like an C++ instance of a class; instantiation is pretty much like
> in OO, a relation between an exemplar of a collection and the
> collection itself, while generalization/specialization is akin to
> superclassing/subclassing (it specifies that all of the instances
> of a collection are also instances of that collection's
> generalization).

> So for example, the collection Dog can have an instance called
> Fido. Mammal is a collection that's a generalization of Dog (which
> makes Dog a specialization of Mammal), and Animal is a collection
> that's a generalization of Mammal; hence Animal is also a
> generalization of Dog. Any instance of a collection is also an
> instance of its generalizations, which makes Fido an instance of
> Mammal and Animal as well. Fido can't have instances, being an
> individual.

> However, the OO model only supports instantiation between a
> collection and an individual, while Cyc also allows for
> instantiation between collections.  For example, collections Dog,
> Mammal, and Animal are also instances of collections
> BiologicalSpecies, BiologicalClass, and BiologicalKingdom,
> respectively. Notice that Dog is an *instance* of
> BiologicalSpecies, and not its specialization. So Fido is an
> instance of Dog, and Dog is an instance of BiologicalSpecies, but
> Fido is *not* an instance of BiologicalSpecies. :)

So a Mammal is an instance of a BiologicalSpecies, but you obviously
can't create an instance of type Mammal (in OO terms).  The simplest
means of representation would be to have all internal nodes be
abstract classes, and only the actually instantiable classes be
concrete (pretty standard OO stuff).  All instances of a parent
could be found by an in-order traversal of the inheritance
heirarchy.

This would work pretty well in C++ if it were done in template
language.  Only problem is that it would almost definately rely on
partial template specialization to work properly, and that is a
language feature that is almost universally not supported yet.
Still, check out TypeLists in the "Modern C++ Design" book for an
idea of how you might represent ontological heirarchies in C++.
I've written a fairly straightfoward factory class that uses these
TypeLists to define what it can generate, so it would be quite
simple to do things like gather a collection of all instantiable
BiologicalSpecies.

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

See above.  This type of thing is where template metaprogramming is
headed.  Another good book aside from the one I mentioned above is
"Generative Programming."  Both deal heavily with some of the
fancier backflips possible in the template language defined by the
latest ratification of the C++ standard.


Sean

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