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

[Bruce Mitchener]

Robert,

Thanks for the obvious time that you spent in thinking through your
reply.

Robert Zubek wrote:

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

I do agree that there are significant difficulties in doing so.  (I
recognize what Miro said about CLOS, and some of the same things are
true if one were to attempt to map it to the Cold object model as
well. But, as you said in your follow up to him, that is by no means
the sole problem in creating a mapping from Cyc->OO.)

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

So, I'd stopped by #opencyc on the OpenProjects IRC network and
talked with a couple of CycCorp people (and also where I met Doug
Miles whose post I forwarded earlier about LogicMOO).

They say they can do work in the future to disk-base portions of the
DB (like textual portions of constants since that's for humans, not
for the logic engine, and the documentation/comments).  Performance
is also pretty good at this point.

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

Finally, OpenCyc can/will be able to fetch data from external
sources. This lets you not have to store every bit of data inside
the logic DB, only handing it to the logic engine when it needs the
data.

That would seem to make it reasonable to try basing a system
directly on OpenCyc and doing some experimental work in that
direction.

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

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

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

(And as a quick final aside, Doug Miles just pointed me at
http://www.cl.inf.tu-dresden.de/compulog/lectures/winter99/lpisa/mod_1_11.html
which has some maybe-interesting work on multi-agent systems
involving muds. (Items 8 and 10))

And that's it for tonight. :)

  - Bruce

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