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

[dmiles at users.sourceforge.net]

--<cut>--
Note: This message was written via the list web archives.  There is
no guarantee that the claimed author is actually the author.
--<cut>--
Original message: http://www.kanga.nu/archives/MUD-Dev-L/2002Q2/msg00200.php

Perhaps together, we can work out an ontology of a sample Mud.  Here
is a start..  I list some things I don't like about it below and
welcome more critiques additions, renamings and modifications.  If
it developes into a D&D pragma we can also try to see how the upper
branches could get even more generic for example a MagcialItem could
become 'SpecialOperatorItem' and subdivided into 'SupernaturalItem'
'HighTechItem'

The best way to develope an ontology is to nitpick it and keep
discovering exceptions and try to come up with a better design.

  MudObject
        |__AreaMudObject
                |__InclosedAreaMudObject
                     |__GenericRoomInstance*
                     |__CaveInstance*
                |__NonInclosedAreaMudObject
                     |__ForestInstance*
        |__ComponentMudObject (Meaning it is a part to something)
                |__AreaPartMudObject
                     |__GroundInstance** 
                     |__AirInstance** 
                |__BodyPartMudObject
                     |__HeadInstance** 
                     |__NeckInstance** 
        |__NonComponentMudObject
                |__SentientMudObject
                        |__PlayerMudObject
                                |__PlayerInstance*
                        |__NPCMudObject
                              |__HeroInstance* (only one)
                              |__MobInstance* (multiple)
                |__FurnitureMudObject
                     |__FountainInstance* 
                     |__EntranceInstance*
                |__EquipmentMudObject
                     |__FlaskInstance*
                     |__SwordInstance*
                     |__GhostedPlayerInstance*
                     |__DeadHeroInstance*


  * Has Prototype Specs

  ** Is Reified from MudObject example: (AirInstanceFn ?Area) =>
     AirInstance*

Having two ontogies is generally usefull.

One for the Objective view above and another for a Subjective view bellow:

  MudObject
        |__ToolMudObject 
             |__KeyTypeMudObject 
             |__LightGivingMudObject 
        |__MagicalItemMudObject
             |__CreationMagicMudObject
             |__DestructionMagicMudObject
        |__ConsumableMudObject 
             |__DrinkableMudObject 
             |__ChewableMudObject 
        |__NonConsumableLiquidMudObject 
        |__WearableMudObject
             |__WearableOnHeadMudObject
             |__WearableOnFeetMudObject
        |__MovableMudObject
        |__AnnamateMudObject
        |__InannamateMudObject
        |__SolidMudObject 
        |__LiquidMudObject 

As we develope a strong ontology, we can map it to an existing AI
system that can learn and experment inside our Muds.

-Douglas Miles




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