Anatomy of A Constant

Although the knowledge base is currently littered with undefined constants, populating the KB with undefined and underdefined constants is inadvisable and considered poor OE. A good constant is well-defined in the #$isa and #$genls hierarchy, well-documented, and ideally well-axiomatized. Without the relevant definitional and axiomatic information, a constant is basically worthless in inference. While it is possible to use the constant in CycL, it is inappropriate to say that Cyc has any worthwhile knowledge about the constant. Suppose, for instance, that I use the word "nictitating" while speaking with someone. He asks me what "nictitating" means, and I tell him "Nictitating is different than meal worms." I have told him nothing about how to use "nictitating", despite the fact that I have related it to something in his vocabulary. All CycL constants should be meaningfully defined. Thus, fleshing out a constant properly is a must.

There are a few requirements for defining a new constant, regardless of type. The following is the bare minimum for inclusion on every constant:

3.4.1.  All Constants


Unless a constant is, at minimum, a member of some collection, it is completely inert.

(#$comment TERM "String") 

Every constant should have documentation. The only rare exception is of an instance level constant where all the information that would be in the comment is in the CycL about the constant. Please refer to the section on documentation.

Every constant should be axiomatizable. That is, if it's difficult to relate it to other constants in the KB via rules and GAFs in such a way that distinguishes it from other constants, perhaps it isn't properly an independent concept. Further, a constant is considered well-defined in CycL if all of the information contained in the comment is represented in assertions in which the constant appears.

In addition, different types of constants have different sorts of requirements.

3.4.2.  Collections


Be sure that you have identified the nearest collections.

(#$termStrings TERM "string") 

Make this assertion in the #$TemporaryLexicalAssertionsMt. Without an assertion of this type, the members of the NL department will be unable to find the term in order to lexify your new constant.

3.4.3.  Predicates

(#$genlPreds TERM PRED)

It is tempting to leave a predicate out of the #$genlPreds hierarchy. Finding the nearest generalization of the relation is much more difficult than finding the nearest generalization of a collection. But mindful construction of the #$genlPreds hierarchy is necessary for producing good, but not necessarily obvious, inferences.


Try to do as much semantic pruning as possible. Wallets, for instance, can never be mathematical proofs, and most predicates about mathematical theories will not also be useful for tangible things.

(#$argFormat TERM N FORMAT)

It is important to constrain the legal number of values for an argument once the rest of the argument places are filled. If there should be no such constraint, then the format should be #$SetTheFormat. Note that there are very useful instances of #$Format other tahn #$SingleEntry or #$SetTheFormat. If all fillers for the argument position must be part of the same object, for instance, use #$PartsFormat.


If the collection in some argument position of the predicate semantically constrains the possible values for another argument, this should be noted with an inter-arg constraint. For instance,

(interArgIsa2-1 issuesCredential Visa-Permit GovernmentOfCountry)

means that the second argument is constrained by the first argument: if the credential which is issued is an instance of a Visa, then some instance of a national government must be the second argument. In addition to #$interArgIsa, also examine #$interArgGenls.

3.4.4.  Functions


As in the case with predicates, you'll want to constrain the domain of every function.

(#$resultIsa/ resultGenls TERM RESULT)

Once you have created a function, you must identify what the resulting NAT will be: if you have created a collection-denoting function, for instance, the resulting NAT will be a spec of what larger collection? If the result is an individual, the individual is an instance of what collection? An assertion beginning with #$resultGenls is mandatory is the #$resultIsa is a spec of #$Collection and prohibitied if it is not.

3.4.5.  Specializations for Events

(#$rolesForEventType TERM ROLE)

This predicate relates #$Events with its most natural actor slots. One expects that every translocation event has an origin and a destination, as well as some object moving, and perhaps even a path that object traverses in the translocation event. When creating an event, it is helpful for non-Cyclists doing KE to know what sorts of actor slots need to be filled by some object.

3.4.6.  A Few Words About KE Facilitation Predicates

KE facilitation predicates assist the Cyclist and the naive user decide how to craft knowledge entry based on the particular concepts he or she is representing. Since they are currently in development, many terms that should have KE Facilitation rules on them do not. Please refer to the handbook section on KE Faciliation Predicates.

3.4.7.  A Few Words About Lexification

The Natural Language department attempts to create tools that translate smoothly between CycL and English (although in principle, we can represent any natural language using the same tools, something we can look forward to later down the road). This involves providing lexical information for every CycL constant. While they are best qualified for this and do not expect much lexical work from ontologists, they have created a tool that will help OEers create elementary lexical assertions on constants. Having created a new constant, an ontologist should view the constant in the Cyc browser. In the upper section of the "Index Frame", there are various browser tools. Clicking on [Lexify] will take the ontologist to the Lexification Wizard. Following the instructions provided, ontologists will easily create a small number of useful lexical assertions.