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

[Bruce Mitchener]

Hello again, Rob. :)

Robert Zubek wrote:
> From: Bruce Mitchener

>> 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'm interested in both, but to differing extents.  I like what I've
seen of the engine underlying OpenCyc, as well as the toolset and
community that they're trying to build up around it.

The knowledge base itself as a whole still scares me for the reasons
I gave in the last email. I don't think that Microtheories solve
those problems but that could still be a matter of ignorance on my
part and my not knowing the full feature set.  I'll elaborate below
after your mention of Microtheories.

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

And that is something that I'm considering. :)

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

Some of this thinking on my part sprung from an observation of
patterns in code that I was writing.  I would find myself writing
small methods here and there to determine whether or not a given
object could do something.  The bird flying example is good enough.
Can the bird fly? The method to determine that might be overriden on
various objects (even non-bird objects) to make that determination.
At that point, it becomes far simpler to have a logic
system/knowledge base that can be queried. I'm not sure that I want
to (or see the need to) model everything within the logic system.

But maybe I just haven't drank enough of the kool-aid yet to become
a true believer. :)

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

Such is life.  There are no silver bullets. :) But that's probably
also a good argument for a slimmed own KB with a set of facts that
does little to nothing extra.

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

I like the Microtheories and they make some interesting bits of
functionality much easier to implement. (And I wish that Kwon
Ekstrom was reading this thread since much of his talk about NPC
stuff at the moment seems to be duplicating this type of feature. :)

The problem isn't just within my own facts, but if I'm importing
another microtheory (like one of the standard Cyc ones) and it has
facts in it that are counter to principles within the game (or
produce unwanted effects), I'm not sure that I can do anything about
that, without forking a copy of the microtheory and editing out
those facts.  (And hoping that the microtheory isn't dependent upon
the presence of those facts.)

Maybe at this point, it would be best to start looking at some
actual implementation issues, and looking at some sample problems
and how one might solve them differently in a logic system.

  - Bruce

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