The beginning of the search frame at the top of the KB browser is reserved for the browser toolbar: a collection of tools an individual Cyclist considers most useful and wishes to access easily. These are selected from all the Browser Tools found on the Tools page, accessed itself by the “Tools” option on the toolbar. (This tool option is automatically included in all browser toolbars). Clicking on the check box by the tool and then selecting “Update Toolbar” will add a particular tool to the toolbar. Returning a tool’s check box to a non-checked position and clicking “Update Toolbar” will remove it from the toolbar if it is currently listed there. ‘Update’, which refreshes the browser, is automatically included in all browswer toolbars. This chapter is an overview of some of these browser tools, organized in alphabetical order. Some of the tools on the ‘Browser Tools’ page are very specialized and either have their own section in the handbook, or are not of general interest to ontologists.
Selecting “Alph” will direct a browser to the alphabetical index of all Cyc constants. By default, this browser starts at the first page of constants that begin with digits. “Page Down” scrolls through the constant list, returning the next page, while “Page Up” will return the previous page. “Top” and “Bottom” return the first and the last pages of the list, respectively, and choosing any letter on the list at the top will return the first page of constants beginning with that letter. Selecting a constant will pull up that constant’s page in the browser, while selecting the red diamond will bring up that constant in the hierarchy browser. More information about the hierarchy browser can be found in this section under “Hier”.
The “Ask A Query” page is used for posing questions to the inference engine. For information regarding the use of the inference engine, please see the “Using the Inference Engine” section of the handbook.
This tool brings up a page for entering assertions into the KB. Please refer to the section “Creating Constants and Making Assertions” in the chapter entitled “From Constants to Assertions”.
This is a search of conceptually related terms. When a collection is entered into the dialogue box, Cyc searches for all conceptually related terms and all terms that could possibly be conceptually related. Through this search, it is possible to enter new assertions conceptually relating objects or collections, but this is not advised.
The “Compose KE Text” page contains a large dialogue box that accepts Cyc Assertions written in KE text format. Please see the section “Creating Constants and Making Assertions” in the chapter entitled “From Constants to Assertions”.
The “Create Constant” page creates a new constant from the name of a constant entered into the dialogue box. It is important to remember that any constant created in this fashion has no definitional information on it and thus is not useful to users of Cyc in any way. After creating a constant using this page, Cyc knows a constant name, but this is useless without making assertions on that constant. Please see the sections “Creating Constants and Making Assertions” and “Anatomy of a Constant” in the chapter entitled “From Constants to Assertions” for more information about how to create a Cyc constant.
Like the “Create Constant” tool, “Create Term” creates a Cyc constant. This tool, however, permits Cyclists to add critical definitional information in this same step. “Create Term” will ask for a term name, its term strings (English translations for the Cyc term), a comment, the proper defining Mt, a similar constant (if such a constant exists), its #$isas and #$genls, and conceptually related terms. This tool is useful as it requests much of the required information when creating a constant. Because it does not assert any non-definitional information on a term, and, indeed, if the term being created is a predicate, no argument constraints are requested, a constant created in this fashion is by no means complete, but it is at least slightly defined for Cyc. For more information, please read “Creating Constants and Making Assertions” in the chapter entitled “From Constants to Assertions”.
This is the front page of Cycorp Proprietary Documentation. When looking for any company information, whether it is information about administrative policies, various deptartments, projects, or public information about Cycorp, this should be the first place to look. Specific sections worth noting include the Cyc-out page (a list of company absences) and the Ontological Engineering page, which has links to home pages of all the Special Interest Groups (SIGs; these are groups of Cyclists formed to discuss and iron-out specific areas of the ontology).
This testing tool is useful for determining what assertions are true in an Mt given the rules true in that Mt.
The Cyc hierarchy browser gives the superior and inferior terms of a particular Cyc term in a hierarchy based on either a default or specifically chosen predicate. Inputting a collection, for instance, will relate that collection to its generalizations and specializations, that is, those collections related to it an a hierarchy based on the predicate #$genls. More complete information about this tool is available in the “Search methods” chapter, under the “Hierarchy Browser” subheading.
“Recent KB Browser History” is the default frame of the Cyc browser. After logging in or making assertions, this is the page the browser opens. This useful page gives a list of all the recently viewed terms. Conveniently, for a particular browser session (defined by the time a Cyclist logs in and then logs out), Cyc maintains a history of all the constants, NATs (non atomic terms), and assertions that Cyclist has visited. If a constant has already been viewed, it is unnecessary to enter the constant name in the search window again, as it is stored and accessible through the history page. This is especially useful when viewing constants like “Dog”, which, when accessed through the search window, will require disambiguation. It’s also useful for constants with particularly long names, especially if the especially long names are likely to be forgotten. Further, to view assertions again, it is not necessary to view the constant again on the browser page.
When doing knowledge-entry, it is sometimes desirable to hypothesize a formula to the KB. This is sort of like saying, “What if proposition P were true?”
When a formula is hypothesized to Cyc in a particular #$Microtheory, Cyc creates constants for any variables, and treats the resulting assertion(s) as true. For example, if the following formula were hypothesized in the #$BiologyMt:
(#$and (#$isa ?DOG #$Dog) (#$isa ?CAT #$Cat) (#$considersAsEnemy ?DOG ?CAT))
two things would happen:
- New constants would be dynamically created for the variables, in this case ?DOG and ?CAT. These variables would have names along the lines of:#$HYP-DOG-42375192581 #$HYP-CAT-8479329834
The “HYP” shows that the constant was created through hypothesizing (as opposed to being created by a user, or through skolemizing). The number at the end is used to uniquely identify the new constant. Remember that an individual dog and an individual cat are being hypothesized here, not a #$Collection, and Cyc may hypothesize many over time. So the number is needed to set each new instance apart from prior ones.
- The assertions involving these new constants would be asserted to the KB in the microtheory chosen for the hypothesizing. For the example above, the following assertions would appear in the #$BiologyMt:(#$isa #$HYP-DOG-42375192581 #$Dog) (#$isa #$HYP-CAT-8479329834 #$Cat) (#$considersAsEnemy #$HYP-DOG-42375192581 #$HYP-CAT-8479329834)
In other words, the two new individual animals created are enemies of each other. Note that we have NOT said that all cats and dogs are enemies, only that these two particular ones are.
Entering a Formula
Enter the formula to be hypothesized in the “Formula” input window, as in the example above. Note that conjunctions and atomic formulas make the best hypothesized formulae. Use the [Complete] button on any partial constant being entered in the window.
In the “Mt” input window, enter the #$Microtheory (Mt) where the results of the hypothesizing should go (minus the “#$”), using the [Complete] button if necessary. The default Mt is the #$BaseKB.
Press the [Hypothesize] button to hypothesize the formula in the desired microtheory.
The [Reset Values] button will return both input windows to their initial settings.
Normally, all assertions should be reviewed before they are entered into the KB. Occasionally, however, reviewers might want to test the consequences of OE that has been completed. In these cases, it is useful if the OE has already been loaded into an image. If the KE is already in the KB, this tool is helpful for review. This tool allows you to enter the name of a Cyclist or several Cyclists who have entered assertions and the dates these assertions were entered. If an assertion was made by the indicated Cyclists during the time interval noted, the assertion appears in the KB with a small cyan arrow next to it. Selecting this arrow will open a page in which a reviewer can either indicate that an assertion has been reviewed and it has also been approved for admission into the KB, add a Cyclist note to the assertion, or send an e-mail to the person who has made this assertion. Once an assertion has been approved, the tool adds a meta-assertion on the assertion indicating that the reviewer has reviewed it.
The Navigator links to an extensive list of useful tools in the Cyc System, whether they be browsing tools, lexification tools, or tools used for interacting with the master transcript server.
This tool permits the user to view all the operations on the local image. If there are no operations on the local image, the user is prompted for a path and filename where a transcript is stored, and will display all the operations in that transcript.
This KE review tool permits a user to view all the assertions or constants created by a particular Cyclist during a set time frame. If the text box for the Cyclist is left blank, the list that is generated is made up of constants aor assertions created by all Cyclists. If the text boxes for beginning and ending dates are left blank, the list that is generated will contain all constants or assertions created by a particular Cyclist.