OpenCyc experimentation

Last December, OpenCyc 4.0 was released. I've been meaning to get more familiar with OpenCyc for a long time, and luckily this release adds a lot of interface improvements.

• The search bar now has a drop down set of auto-complete matches.
• The display for a selected term is cleaner and easier to use.
• Terms have a popup menu that allows easy editing or deletion.

Experiment

I was hoping to translate the D&D SRD ability modifier formula into a CycL function, so that I could at a later point calculate the modifier for the given attribute of an entity. The OpenCyc documentation was never extensive enough to describe how to do this sort of thing, and it has not been updated since the original 1.0 release. Add into that dead links, and working out how to use OpenCyc is pretty hard going.

A huge amount of browsing terms in the OpenCyc ontology browser led me to the simple formula:

(#$TruncateFn (#$QuotientFn (#$DifferenceFn ?SCORE 10) 2))

And that's ignoring that I had trouble finding DifferenceFn and QuotientFn, originally using PlusFn and TimesFn in their places.

In order to test an expression like this, it needs to be wrapped in evaluate, which binds the result to a variable allowing it to be seen in the query page.

(#$evaluate ?RESULT (#$TruncateFn (#$QuotientFn (#$DifferenceFn ?SCORE 10) 2)))

Like a SELECT statement in SQL, this effectively displays one row with one column named RESULT showing the value of 3.

Defining the standard terms for a CycL function is pretty simple.

The first step is to create a term (a generic step) with the name of the function, in this case #$AbilityScoreModifierFn. In the top frame, there is a tools link on the right hand side. Click on this, and then select Create Term.

Next various properties are asserted for the term. In the top frame, there is a Assert link. Click on this, and then simply enter the relevant expressions and assert each in turn.

(#$isa #$AbilityScoreModifierFn #$UnaryFunction)
(#$arity #$AbilityScoreModifierFn 1)
(#$arg1Isa #$AbilityScoreModifierFn #$Integer)
(#$resultIsa #$AbilityScoreModifierFn #$Integer)

And finally the remaining task, is to associate the formula with the AbilityScoreModifierFn function. I've come to the conclusion that this actually isn't possible to do from within CycL.

There are two possible ways of associating logic with a term (that I've been able to find).

1. rewriteOf
2. evaluationDefn

With rewriteOf, you might assert something like:

(#$rewriteOf #$AbilityScoreModifierFn
  (#$Lambda (?SCORE) (#$TruncateFn (#$QuotientFn (#$DifferenceFn ?SCORE 10) 2))))

Unfortunately, rewriteOf expects a reifiable function as it's second argument. What this means, is that what this does is assert (#$AbilityScoreModifierFn 18) as a fact in the ontology. This is obviously not what I want, which is simply calculate and output a value, with no side-effects.

CycL expressions cannot be associated with evaluationDefn. This is intended rather to simply specify the name of a function in the lower level lisp language, called SubL. These are apparently easy enough to define, but it has been hard enough getting to this point, let along adding further complication outside of the ontology.

Experiment conclusion

At this point, I get the feeling it isn't intended that you can directly create formulas as expressions within CycL. Instead, I assume that it is expected that these are defined in SubL.

Ontology thoughts

I'm also not entirely sure that the effort of using OpenCyc is worth it. While there is a wealth of knowledge in the ontology, it doesn't seem deep enough in the right places to be used to back a game experience.

There are definitions for Crossbow and Longbow for instance, but they don't have the depth which there is for Gun. Gun has logic to define information about its projectiles, and defines the parts that make up both guns and their projectiles. But there is no corresponding breakdown of the parts of a bow, or the projectile which a bow fires.

The humanoid body has parts, but there is no definition of how the parts join together. Actually, that's not entirely true. I believe there are a few definitions of which rib comes before the next, but little more. Torso doesn't seem to be joined to arms, neck and legs or whatever it should be joined to. Of course, cutting up corpses is not a crucial MUD feature, but I believe this is illustrative of a general lack of depth where it counts.

OpenCyc thoughts

Do you know how much memory OpenCyc requires to run out of the box? A minimum of 5 gigabytes. Who wants to run a MUD and to have to run a second process which they connect to via SOAP, which uses this much memory? And who wants to write their own SOAP encoding of their queries and other commands directed at the OpenCyc process, because there are only Java bindings provided?

At this point I am wondering if there is any reason to bother experimenting further.