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

[Robert Zubek]

From: Bruce Mitchener

> You could view the item hierarchy (if you have one) of a mud as
> the start of an ontology in a primitive form.  Those who have read
> _Game Architecture and Design_ by Rollings and Morris may be
> familiar with their discussion of the tokenization of a game
> design (Chapter 17 I think).  That's also like an ontology.

[ sample of OpenCyc-like representation snipped... ]

> And, from that, rather than checking all of those rules at
> runtime, have the ontological system output a body of code that
> implements the ruleset, including the correct inheritance
> relations and any properties and methods that are necessary.


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.

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

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

What do you think?

Rob

--
Robert Zubek
rob at cs.northwestern.edu
http://www.cs.northwestern.edu/~rob

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