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

[Robert Zubek]

Hi Bruce!

From: Bruce Mitchener

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

[snip!]

> Talking with Jon Leonard on DevMUD, he thinks there must be ways
> to aggressively cache results to help reduce the frequency of
> executing queries.

Ouch, that's a lot of data! :) If you mean speeding up querying
assertions made on the knowledge base, it's possible to cache quite
a bit, but it's going to be tricky. The problem lies in assertion
removal. Inference systems are usually quite good at caching
inferences (using some kind of a truth-maintenance system), as long
at the data being added is free of contradictions. But when previous
assertions are removed, contradicted, or otherwise invalidated (for
example, because the inferences were made based on a state of the
world that is no longer the case), then all of the inferences based
on that information will have to be retracted, which gets
complicated. Building a knowledge base that does so reasonably
quickly is possible, but *very* messy. :)

Which brings about a question - you mention both the OpenCyc
ontology and its reasoning engine as potentially useful for MUD
development. Does either of them interest you more than the other?

I mean, if you're not interested in the ontology as much as in
automated reasoning, have you considered using other reasoning
systems (even plain prolog) and building a custom MUD ontology
inspired by Cyc? This might actually be advantageous, as the OpenCyc
ontology is a wonderful but *huge* piece of knowledge engineering,
and the sheer amount of knowledge it contains may end up slowing
inference down too much. Perhaps a re-translation of just the
relevant bits into the MUD domain would help?

Just something to consider. :)

> Doing that would of course bring forth a new set of concerns and
> worries. :)

>     - Familiarity.  People just aren't used to that sort of
>     system.  How hard will it be for them to learn?  How many
>     mis/pre-conceptions will they have?  (Since I'm not talking
>     about AI, I'm not talking about using Prolog, and people that
>     I've talked off list about this seem to make those assumptions
>     immediately.)

You don't want to be using anything like Prolog? But what you were
mentioning before (the "all birds fly, except for ostrich" example)
is a typical case of logical inference, and arguably most naturally
implemented in a Prolog-like system... Sorry, I'm confused now as to
what the system is supposed to do...?

>     - Knowledge Engineering.  How hard is it to do rigorous enough
>     entries?  How much damage could a small error or loophole
>     cause?  How hard will it be to detect/notice?

Yes, this is hard to say. Designing knowledge-based AI systems is
hard, especially if one attempts to model real-life
phenomena. There's always the danger of the system making strange
inferences because the operator wrote the knowledge entries
incorrectly. But like with programming bugs, they're difficult to
predict. :)

>     - Pollution.  Using something like OpenCyc is interesting
>     because it has a community around it and an existing body of
>     knowledge.  But how do you deal with conflicts where a core
>     bit of the knowledgebase subtlely conflicts with an element of
>     the game design or game world?  If you fix that in the core
>     knowledge base, do you now lose interoperability with other
>     agents because you're not using "pure OpenCyc"?

This is where microtheories come in handy. They afford basic
modularity in Cyc, allowing one to separate off different bits of
the knowlege base. One can even go as far as making statements in
one microtheory that contradict other microtheories. So you might be
able to define a new MUD-world microtheory, and build within that...

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