[MUD-Dev] OpenCyc, design implications of ontological systems?
Bruce Mitchener
bruce at cubik.org
Mon Apr 15 19:22:10 CEST 2002
I haven't had the time to follow up to Robert Zubek's reply quite
yet, but this appeared in the OpenCyc forums over the weekend:
http://sourceforge.net/forum/message.php?msg_id=1538343
<EdNote: Reformatted for clarity, attribution added>
--- begin ---
From: Douglas Miles <dmiles at users.sourceforge.net>
Date: 14 April 2002
Subject: RE: Applications
I have plans to use OpenCyc in project shown at
http://logicmoo.sourceforge.net
The project is based on hooking OpenCyc into an existing RPG system
called Jamud. (Java MUD)
This to accomplish three goals: (also the three stages of the
project)
Stage 1
Goal: To test and do practical Knowledge Engineering about a
virtual realm:
1) Build an existing simple realm inside of Jamud.
2) Create rules that interface to the realm Jamud mapping
existing object types into cyc Collections
a) Enumerate the possibilities and confirm the ontology of how
things work or exist.
b) Map/Align to Cyc's ontology
c) Create a BroadMicrothery to reflect this
d) Create an import routine to build the world into a
DataMicrotheory
3) Inference in Cyc about the DataMicrotheory and see how many
commonsense rules we can make about our possible world.
4) Complete the interface for querying/asserting to OpenCyc from
Jamud telnet interface.
5) Create synchronization: (choices)
a) Each time a subscribed event occurs in Jamud, use the
existing OpenCyc Java API to update Cyc (current)
b) Make each object instance get/set methods query/assert into
OpenCyc into a DataMicrotheory (could easily be done)
c) Create HL interface predicates to query the existing Jamud
objects into a DataMicrotheory (supported yet?)
Stage 2
Goal: To animate non-player character agents from Cyc rules
1) Create an ontology of non-player character roles and jobs.
2) Leverage commonsense rules from stage 1 into rules about how
to conduct actions
a) Create cyc queries (and the rules to satisfy) that
consequent in a form of (actorStateAction ?Actor ?State
?ActionsToGetThere)
b) Map the agent categories into partitions of background
commonsense required
c) Create a Microtheory system for single agents based on
'knows about' and 'know how to' that can instance individual's
current knowledge states.
3) Interface!
a) Create methods in Jamud that builds and initializes a new
Cyc microtheories per agent.
b) genlMt the agent character ?Mt based on job types for their
commonsense
c) Agent character enumerates his intrinsic goals by making a
query to OpenCyc
d) Agent character per-tick initiates query about its goal and
gets bindings back for his next action
e) Perform action inside Jamud and update states
4) Practice and refine knowledge engineering for stage 1 and 2
Stage 3: Expertly build rooms with objects based on rules.
An example:
(isa Mold FirstOrderCollection)
(isa Mold ExistingObjectType)
(isa Mold StuffType)
(forAll ?Rooms
(implies
(and
(isa ?Room Room)
(hasProperty ?Room Damp))
(thereExists ?Mold
(and
(isa ?Mold Mold)
(objectFoundInLocation ?Mold ?Room)))))
(forAll ?Action
(implies
(and
(isa ?Action TakingPartOfObject)
(occursAt ?Action ?Room)
(objectFoundInLocation ?Object ?Room)
(rolePart ?Action Actor ?Actor )
(rolePart ?Action Object ?Object)
(rolePart ?Action Region ?Room)
(isa ?Object StuffType))
(thereExists ?PartStuff
(and
(part ?Object ?PartStuff)
(objectControlledBy ?PartStuff ?Actor))))
So we should be able to telnet into Jamud, enter a "damp room"
and find and take parts of mold.
1) Use the information from above stages to 'reflect back' into
Jamud.
a) Find which state-action-state rules from stage 2 are
administrative tasks
b) Write a Microtheory that contains rules that both antecede
and consequent in the DataMicrotheory like the first of the
rules shown above.
c) create a robust colorful environment that may go beyond
persisted Jamud
Practice running queries until the results make good sense
2) Interface
a) Jamud queries the DataMicrotheory (leveraging the above
rules) and gets a map of the expected state.
b) Confirm that each object exists and has the expected
properties in Jamud.
c) Make sure that the world transitions make sense to players
in the MUD.
Stage 4
Goal: Apply virtual environments beyond this MUD/MOO/RPG
analogy.
1) Confirm the constancy, soundness and operational completeness
of the above.
2) Create agents/objects in Jamud that will propagate/query
state to another application realm
3) Do knowledge engineering like the above for the new
application
4) Evaluate and improve tools used.
The project is realized into finite number of non-vague tasks and
diverse enough.
ETAs?
Stage 1, sometime at the end of next weekend. We should have
Jamud completed tonight. (Alpha6) Alpha5 (build version) had too
many tangled objects (not all reifiable to data). But is now
converted to a very simple Node-by-Node object system that
translates to a single DataMicrotheory. We are on 'Stage 1 Step
2d' and learning what was incomplete from 'b' and 'c' By the end
of this week should be experimenting with 'Stage 1 Step 5b' (5c is
not yet available)
Stage 2 should be started (i find very exciting!) sometime late
April (this month). But it is possible that other people could
contribute ideas and methodologies to speed this up. This is
mainly made up of Knowledge engineering since the java code time
is only a couple days. I am a programmer before a logician and
there are people that are better Cyclists. So I will have to make
sure they have a solid application framework to play with
scripting NPCs.
Stage 3 is a little vaporous since it depend on how we synchronize
in this stage. But the knowledge engineering required should be
something others can work on after this Friday once they are able
to import the 'DataMicrotheory'.
Stage 4 is of course is contingent upon success of the previous
stages
---- end ----
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list