When a Cyclist is ready to add assertions to the knowledge base, there are several means by which she can add them.
There are a couple of methods of adding assertions directly to the knowledge base. In these cases, all of the constants used in the assertions must be in the KB already.
(isa LouiseBrooks Actress)
would be rejected unless #$LouiseBrooks is already a constant. Therefore, before a Cyclist can assert anything using a constant, the constant must be created. There are several ways a Cyclist can do this in the Cyc Browser.
In the first column on the “Browser Tools” there are two tools: “Create”, and “Create Term”, both of which are labled “Create Cyc Constant”. Using the first, a Cyclist will simply enter the name of the Cyc term and will be responsible for adding any defining assertions later (see the section called “Anatomy of a Constant” near the end of this chapter). If I am creating #$LouiseBrooks, I would simply add the constant’s name to the dialogue box and the constant would be created.
The second could prove to be useful for creating individuals or collections. Using the second, a Cyclist is prompted for #$termstrings (rough English translations of the CycL term), a comment, appropriate microtheory placement, and #$isa and #$genls information. Since this information must be entered anyway, this seems like an easy and convenient way to do it. In order to create #$LouiseBrooks, I would fill that in for the “name” dialogue box. In the “termstrings” box, I would type “Louise Brooks” and “Lulu”, each on a separate line. In the “comment box”, I might briefly describe the actress. Note that quotation marks in the “termstrings” box or in the “comment” box are not required. Once this is finished, clicking on “Create Constant” will take me to the next screen. I am asked for the appropriate Mt (I would use #$PeopleDataMt), a similar term (if there is one), and #$isa and #$genls information. The “Complete” clickbox to the left of the dialogue boxes will complete a Cyc constant based on the first few letters in the dialogue box. I do not believe there is a term terribly similar to my new “#$LouiseBrooks”, so I would skip the “Similar to” box, although if I had used it, Cyc would prompt me with a list of assertions I may or may not wish to copy from the old constant to the new one. I would add “ActorActress” to the “Instance of” dialogue box and leave the specialization box empty, since #$LouiseBrooks denotes an individual, not a collection, and click “Categorize”. Since I have not offered Cyc a similar term, the next page is titled “Conceptually Related”. This was useful at one time, but we no longer do OE with the #$conceptuallyRelated predicate, so I have completed creating this constant and I can move on to making assertions on it.
On the other hand, in the event that the playwright Gao Xingjian were not in the KB, and I wanted to create a constant for him, I might just find another Nobel Prize winning playwright to use as a template for creating the constant #$GaoXingjian. Finding such a constant, I would select “Create Similar” on the top of the index page of a similar constant. In the new window I would enter the new constant name and select all the assertions I would like to be cloned, replacing the old constant with the new one. Once finished, I select “Create Similar”, and the new constant is created with whichever assertions I choose to copy.
Once a constant is created, it is easy to add assertions in the Cyc Browser. Once again, there are several ways that this can be done. For instance, perhaps a Cyclist wishes to assert that Louise Brooks has a bob haircut, and I find the following assertion in the KB:
Mt : PeopleDataMt (personsHairstyle BillyRayCyrus MulletHairstyle)
which looks quite like the assertion I would like to make. I would then click on the assertion ball by the assertion, which would give me more information about the assertion. Furthermore, I am given several options regarding what to do with this assertion. I would select “Assert Similar” and I would be taken to a screen titled “Assert Similar Formula”. This screen has two dialogue boxes, one for a \ microtheory, and one for the assertion itself. All the boxes are filled in, but it is possible to make any changes. While #$PeopleDataMt seems like a good place for my new assertion, I have to change this one:
(#$personsHairstyle #$BillyRayCyrus #$MulletHairstyle).
I would replace #$BillyRayCyrus with #$LouiseBrooks, and MulletHairstyle with BobHairstyle and click “Cyclify”. To make certain that the assertion is well formed, I could then select “Diagnose”, which would then wff-check my new assertion for me. Finally, I would “Assert Formula”, and be finished.
Of course, I’ve changed quite a bit of that assertion, and it would perhaps be easiest to start from scratch. If I use the “Assert Formula” tool, then I am given a screen with two blank dialogue boxes that looks almost identical to the screen which permits me to make a similar assertion. In the first, I will need to specify the microtheory for my new assertion (I’ll add #$PeopleDataMt). In the second I should enter
(personHairstyle LouiseBrooks BobHairstyle)
being sure to remember the parenthesis. Clicking “Cyclify” will add ‘#$’ to all the CycL constants. If a term remains without a #$, it is not a CycL constant. Once again, “Diagnose” permits Cyclists to wff-check an assertion without actually asserting it. If the wff-checker says it’s ok, then I can “Assert Formula” and add it to my agenda.
Entering knowledge with the Browser Tool “Compose KE Text” is much quicker than with the “Assert Formula” tool and still encourages users to interact with Cyc as they enter larger chunks of knowledge. Opening the “Compose KE Text” page will reveal a large dialogue box. Enter a manageable portion of KE text into the dialogue box. If Cyc does not recognize a term or syntax in the file, there will be an alert on the next page enumerating the errors and on which lines those errors can be found. If all is well, all the new constants and assertions will be listed on the next page. Once they have been looked over, select “Add Forms to the Agenda”.
Once assertions have been added to the agenda, they are then checked for well-formedness. It is important to keep an eye on the Agenda Status Bar (the bottom frame of the Cyc Browser). The first option in the Agenda Status Bar is “Update”. Selecting this will reload the Agenda Satus Bar. This should be done several times while loading operations. “Agenda” opens the Agenda page, which will reveal which operation Cyc is currently processing. The Agenda status follows the Agenda link. If this reads “Sleep”, Cyc is not processing any operations. If this reads “Run”, Cyc is currently processing operations. If it reads “None”, then Cyc has had a problem processing an operation and the agenda is currently halted. Most likely it is trying to process an operation that is non-wff. The Agenda page will identify the problematic assertion and state what the problem is with the assertion. Clicking “Start Agenda” will skip the problematic operation and continue working through the assertions. If skipping that assertion will cause problems in the file, it may be best to delete the rest of the assertions waiting to be processed (this can be done by selecting “Delete Local Queue” at the bottom of the Agenda Page) and start the agenda again. I t is important to continue to update the status bar until the Agenda is sleeping and all the loaded operations have been processed. For more information about the Status Bar, read “The Cyc Browser Layout”, in chapter 1.