## Agenda Process Control Help

E-Mail Comments to: opencyc-doc@cyc.com
Copyright© 1997-2002 Cycorp. All rights reserved.

This facility allows the user to enter new knowledge into the CYC® KB using the KE Text format. For users unfamiliar with this special knowledge entry format, see the KE Text Documentation.

### Composing KE Text

To enter new knowledge, simply type KE Text expressions into the input window, then press the [Eval] button. Remember to include a period after each expression, and place semi-colons in front of any comments (text not to be processed). Also remember that KE Text syntax does not use the "#$" in front of constant names.

To take advantage of constant completion, type the first part of a CYC® constant in the input window, then press the [Complete] button. Remember that a list of completions will appear in a separate HTML browser window if the completion is not unique.

To clear the input field, press the [Clear] button.

### Options for Compose

Compose KE Text contains two options. To set an option, simply click on the checkbox to the left of the option. When the [Eval] button is pressed, the selected option(s) will be used during the evaluation of the KE Text.

- Remove non-printing characters in strings: If this option is checked, then all characters occurring in CYC® system strings in prospective entries (e.g., #$comment strings, #$cyclistNotes strings, etc.) must have a character code between 31 and 127, or they will be replaced with a space at assert time. This means that with this option checked, all tabs, returns, linefeeds, and wacky Genera font characters occurring in CYC® system strings will be replaced with an equal number of spaces. So if people want to include tabs and linefeeds in their #$comment strings (possible, but not recommended), they should not check this option.
- Check for existing assertions: If this option is checked, the user will be notified if an assertion they want to enter is already in the KB.. If it is not checked, then the user will not be so notified (and KE File will not go to the trouble of checking to see if the prospective entries are already in the KB). Generally speaking, it takes longer to check to see if assertions are already in the KB than to just evaluate a batch of (possibly redundant) entries. In general, no bad consequences result from evaluating a ke-assert for a form that is already in the KB. However, some people want to know if any of the assertions they are about to enter are already in the KB.

### Processing KE Text

After the [Eval] button is pressed, the KE Text will be processed as follows:

1. CYC® will check for any syntax errors, ask the user to fix those errors and retry.
2. Any constants unknown to CYC® will be collected, and the user will be asked if they want to make constants out of these strings. Click on "Make Constants" to confirm, or go back to make sure constant names have been entered correctly.
3. Wait a few moments for the constants to be created before proceeding. If you proceed before CYC® has had a chance to create all of the new constants, the CYC® Agenda may get an error when processing certain operations.
4. All expressions will be listed for review by the user. Confirm to proceed.
5. The CYC® Agenda will then process all operations in order. Errors will be handled depending on the Error Handling Mode selected. To set the Error Handling Mode, click on the "Mode" link in the Agenda Status Bar.

Go to Top