![[OpenCyc.org Homepage]](http://www.cyc.com/cycdoc/handbook/images/opencyc-logo.gif){kind=logo}
Version 0.7
|
|
Ontological Engineer's Handbook
Version 0.7 |
The Cyc KB Browser is composed of three main frames. The top frame is the "Tools Frame" which contains the type-in box, the login prompt, and the toolbar. The "Middle Frame" is where constants and assertions are displayed. At the bottom of the page is the "System Information Frame" which displays various information about the status of your current Cyc image.
When you start up a Cyc image, you will automatically be taken to the "Login Area". Type your Cyc username (the Cyc constant that represents you) in the text box. If you are working on a specific Cyc project, you may click on the "Choose Project" button and select your project from the list. You are now logged in and your project is set.
The "Middle Frame" is where Cyc constants and assertions are displayed. When you type a recognized Cyc constant in the search window, you'll notice that your "Middle Frame" splits into two frames. The frame on the left is the "Index Frame". The right-hand frame is the "Assertion Display Frame".
The "Index Frame" allows you to access particular assertions quickly. For instance, if you click on "Documentation", you will see who created the constant, when it was created, what project it was created for, and the constant's comment and any cyclistsNotes displayed in the "Assertion Display Frame". If you click on "Lexical Info", all of the constant's lexical assertions will be shown. If you click on "All Assertions", every assertion that contains that constant in some argument position will appear.
The "Index Frame" is also where some KE Tools are located, such as "Create Similar", "Merge", and "Kill".
You can also view all collections of which the constant is an instance of, and, in the case of collections, all the supercollections of a constant by clicking on the green cross next to #$isa or #$genls under Arg1. This will display (in alphabetical order) every X for which (isa ?CONSTANT-YOU-ARE-VIEWING ?X) or (genls ?CONSTANT-YOU-ARE-VIEWING ?X) is true. If the constant is a predicate, then all the more general forms of the predicate are displayed. Similarly, you can view all the constants that #$isa or #$genls TO the constant you are viewing by clicking on the green cross next to #$isa or #$genls under Arg2. This will display all the ?Xs for which (isa ?X CONSTANT-YOU-ARE-VIEWING) or (genls ?X CONSTANT-YOU-ARE-VIEWING) is true.
For the most part, assertions are indexed in the "Index Frame" based on what position the focal constant fills in that assertion.
In the next section, we will address the hierarchy Browser which is a good tool for viewing assertions using transitive predicates.
You will notice several icons next to the constant name at the top of the "Index Frame". The red diamond is a link to the hierarchy browser. This is a tool that lets you see the a transitive hierarchy for the constant you are viewing. The most common hierarchy to examine is the #$genls hierarchy. It is also the most robust. All the constants that appear below the constant in question are "specs", or specializations of the constant you are viewing. The constants above have the constant in question as a specialization.
The default setting for most collections is #$genls, but you may view other hierarchies through this tool, such as #$isa, #$genl-CW (for #$ConceptualWorks), #$genlPreds (for predicates), or #$genlMt (for microtheories). Click on the "Change Hierarchy Browser Settings" button and enter a different binary predicate (such as #$isa) in the "Binary Predicate" box to change the hierarchy you are viewing.
For more information, please see the section on "Searching For Constants".
If an assertion has the constant you are viewing in the first argument position and a binary predicate in the Arg 0 position, the assertion is displayed in shorthand in the "Assertion Display Frame". For instance, you might see:
Mt : HumanActivitiesMt genls : Needle
If you click on the colored sphere just before "Needle", the full assertion will be displayed:
Mt : HumanActivitiesMt
HL Formula :
(genls SewingNeedle Needle)
Also, additional information about the assertion, including who asserted it and when, is displayed after selecting the colored sphere.
Note that this shorthand is not used for assertions where the constant is in the second (or any other) argument position. By convention, we only use this format when the constant is in the first argument position.
The color of the sphere says something about the assertion. Here is a key of what the different colors mean:
| White: | The assertion is monotonically true. |
| Yellow: | The assertion is default true. |
| Green: | The assertion was inferred or derived from a forward rule. |
| Purple: | The assertion is a backward rule. |
| Blue: | The assertion is a forward rule. |
| Aqua: | The assertion has been inferred and it was asserted by a Cyclist (i.e. it is redundant). |
| Red: | The assertion is a negation (not) statement and what has been negated is false. |
Suppose you are searching for the constant that represents the collection of electric guitars. You are not sure if the constant is represented as #$Guitar-Electric or #$ElectricGuitar. One way to search for this constant would be to use the "Show" button. Using this search option allows you to search for constants using only part of the constant name. An asterisk works as a wild card when placed at the beginning or end of a word. For example, if you type "*guitar*" in the text box and click the "Show" button, Cyc returns all constants that contain the word "guitar" at any point in the constant name. Similarly, you can type "guitar*" and Cyc will return all constants that begin with the word "guitar".
You can do more advanced searches using the GREP button. With this feature, you can place a ".*" at any point in the constant name (beginning and end included) and Cyc will treat this as a wild card. For instance, suppose you are searching for the constant that represents Bill Clinton. You are not sure if the constant name is WilliamClinton, BillClinton, or perhaps even BillClinton-President. You can enter ".*ill.*clinton.*" in the type-in box, click the GREP button, and Cyc will return:
BillClinton
BillClintonSpeakingIMt
HillaryClinton
One final way to search for constants is by entering a logical way to refer to that constant in English and hitting "enter" on your keyboard or the "Show" button. Every Cyc constant has at least one lexical assertion. Lexical assertions are what relate Cyc constants to the word or string we would use to refer to that concept in English. For example, if I simply type "electric guitar" into the type-in box, Cyc will bring me to the concept #$Guitar-Electric via this assertion:
Mt: EnglishMt
(multiWordString
("electric") Guitar-TheWord SimpleNoun Guitar-Electric)
For more information on search strategies, please see the section on "Searching For Constants".
Each machine runs it's own copy of Cyc called a "Cyc image". The assertions you make on your machine get processed and sent to a local transcript. You can access this transcript as well as other information about your image through the "System Information Frame".
Here is what your System Information Frame looks like:
Update Comm: Storing Only Agenda: Sleep KB: 541 System: 1.1579
Selecting the "Update" link will refresh your "System Information Frame", and, if your agenda is running (noted by the "Agenda Status" section of the "System Information Frame" as "Agenda: Run" instead of "Agenda: Sleep"), show you how many operations have passed through your agenda.
The "Comm" link brings you to the "Communication Status Area" which displays your transmitting and recieving options. The default transmitting option is "Store For Later". This is the recommended choice. If you choose this option, the assertions you make will go to your local transcript and will not be sent to everyone else until you decide to transmit them. If you choose "Do Not Record", the assertions you make will not be recorded, and therefore, can never be sent to others. The "Send Immediately To Everybody" option should be used with extreme caution (if ever). This will cause every assertion you make to be automatically sent to everyone's image. If you accidentally make a bad assertion while this option is selected, everyone else will have to deal with the problem you've created.
The "Receiving" options are very simple. If you choose "Yes", you will recieve operations that others are sending out. If you choose "No", you will not. The most common reason that people choose not to receive operations is because if large numbers of operations (or a particularly expensive one, such as a rather general forward rule) are being sent, your image may be slowed down while it processes these assertions. Otherwise, it is a good idea to be in receiving mode so that you have the most up to date information on your image.
You can also filter out certain operations if you know there is a large number of operations coming in that you do not immediately need. Click the "Edit Remote Operation Filters" link to do so.
The agenda is the local queue of operations. If you click on this link, you can see what operation Cyc is currently processing. If an operation seems to be taking a very long time to be processed, you can choose to abort the operation. If an operation comes through (asserted by you or someone else) that conflicts with existing information in Cyc, your agenda will halt. If the default option is selected on the "Agenda" page, this will be displayed as "Agenda: None" in the "System Information Frame". If you click on this link and choose "Start Agenda", the bad operation will be ignored and your agenda will start running again.
Every few days, a "new KB", or "new world" is released. A "KB" is a "new" copy of Cyc that contains all the most recent assertions, as well as all previous assertions. The reason we do this is to prevent the loss of all of Cyc due to a technical malfuction. If we lose the current KB because of some catastrophic technical problem, we will only have lost the most recently entered knowledge--no more than a few days of work. The previous KB containing the past fifteen or so years of work will still be intact.
This is the area where you can "watch" assertions others have made being processed in your local image. Cyc pulls 200 remote operations at a time. The number on the left is the number of operations waiting in the local queue to be processed. The number in the middle (in red) is the number of operations currently being worked on. The number on the right is the number of assertions that have now been processed.
"Local" only appears on the "System Information Frame" if there are currently operations in your local transcript. In addition to the "Remote" display, Cyc will also display the queue of operations for the local image under "Local". The "Local" indicator performs in much the same way as the "Remote" indicator does, although it indicates the total number of operates yet to be processed in the local queue, rather than just those left of the most recent batch of 200.
The "System" link contains a lot of information about your Cyc image. The top portion tells you how long your image has been running, the name of your image, which KB you're in, what patch level you are at, etc. Just below that is a link to your local transcript. If you click on this link, you can see all the operations you have recorded on your image but have not yet transmitted. The "Queue Information" tells you how many operations you have to process before your image is caught up with the master transcript. Finally, the "Historical Information" displays the number of operations you have recorded and the number of operations you have transmitted to the master transcript.
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 browswer. More information about the heirarchy browswer 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 heirarchy 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 desireable 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-8479329834The "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 FormulaEnter 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 interracting 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.
The vocabulary in the Cyc KB is so large, finding a constant is frequently quite difficult. A new constant should be created only when it is clear that the existing vocabulary is insufficient for your current needs. Cyclists should be very thorough in determining whether the necessary vocabulary already exists.
The most obvious first step is to run a search on the target term. This is useful because search will look both for a constant with that constant name or any constant mapped to lexically by the entered term. When entering "dog" (without the quotes) in the search window and pressing enter or clicking on the button which reads "Show", for instance, Cyc will return a choice of the following:
3 possible terms
Dog
HotDog
InsultingSomeone
#$Dog is returned for two reasons: one. First, the full constant name has been entered into the search window. Second, there is lexical information linking the word "dog" to the Cyc constant #$Dog. Because a hot dog is sometimes simply called a "dog", and because to insult someone is frequently to "dog" him, these English terms are mapped to the corresponding CycL constants. Using "Show" in the search window returns all these constants.
If, instead of pressing enter or clicking on the button which reads "Show" after typing "dog" (again, without the quotes), I had instead clicked on "GREP", Cyc would have found only one result, the one with the exact character string I had entered. Use this when you are certain you know the constant name and do not wish to have to disambiguate between results. GREP is more useful for other reasons, however.
GREP will return any constant with a particular character string in its name, depending on what is entered in the search window.
The string ".*" is a 'wildcard' character in GREP, and can be used to replace any number of characters you are uncertain of while searching. So, entering ".*dog" (without the quotes) in the search window will cause Cyc to return all the constants for which "dog" are the last three characters in the constant name. This includes #$Dog, a whole host of dog breeds such as #$Pomeranian-TheDog and #$BelgianSheepdog, as well as #$HotDog.
If "dog" are the first three characters of the constant, "dog.*" (without the quotes) should be entered into the search window before clicking GREP. This time, there are 33 terms which begin with "dog". Once again, #$Dog is returned, along with #$DOGDAYAnAdventure-TheGame, #$Dogma-TheWord, #$DogwoodOrder, and predicates such as #$doGetAccessToAccount.
In order to find all the constants that have the characters "dog" together in the constant name, the best search is a GREP on .*dog.*. In this case, there are 111 matching terms. #$Dog, #$Boxer-TheDog, and #$DogTreat were also returned by other GREP searches, but constants such as #$DavidOgdenStiers and the #$CharlestonRiverDogs-BaseballTeam have the letters "dog" together embedded in the name of the constant.
When searching for constants using the search window, it is unnecessary to precede the constant name with a #$. If the constant name is known, then Cyc will accept it, so long as this is a "Show" search and not a "GREP" search. The names of constants in CycL will be returned in alphabetical order, listing all of the constants beginning with a capital letter before any of the constant names beginning with a lower case letter. This is useful: if the constant being sought is a predicate, all the predicates will be at the bottom of the returned list (see "Naming Conventions for CycL Constants" in the chapter entitled "From Constnts to Asertions").
Entering "dog" in the search window (this time with the quotes) will reveal all terms with lexical information mapping the string "dog" to the constant. In this case, the list is almost identical to the list returned when simply doing a "Show" search on "dog" (without the quotes), with the addition of #$Dog-TheWord, revealing that lexical mappings of the English word "dog" exist, and work has been done developing grammar rules surrounding the word.
If the term for which you are searching does not appear in a term search or a GREP, before concluding that there is no corresponding Cyc term, attempt to use a few synonyms. Sometimes not all synonyms are mapped to the proper Cyc terms. If, for instance a GREP on .*retrieve.* returns only a bunch of dogs, try (assuming GoldenRetreiver is not your target term) restore, reclaim, recover, rescue, deliver, acquire, get, regain, find, etc.
The Hierarchy browser reveals superior or inferior terms in transitive hierarchies. If the starting term is a collection, the hierarchy browser will automatically show its location in the genls hierarchy. If the starting term is a predicate, the browser will start in the genlPreds hierarchy. Microtheories are found in the genlMt hierarchy, and geographical regions are found in a hierarchy of geographicalSubRegions. These are default settings; when a constant has a red diamond by it in the index, clicking on that diamond will take you to the default hierarchy.
For example, using #$Philosopher as the starting term returns the following information:
isa: PersonTypeByOccupation
genls: Person
Context: Union of all contexts
Predicate: genls
Index: 2
... (CollectionUnionFn (TheSet Person (GroupFn Person)))
Person [BaseKB]
... Animal
Person [BiologyVocabularyMt]
... HomoGenus
Person [BiologyVocabularyMt, WebSearchEnhancementMt]
... HumanOccupationConstructResident
Person [HumanActivitiesMt]
... LegalAgent
Person [BaseKB]
... NarrativeRole
Person [IMDB-AssumptionsMt]
... Omnivore
Person [BiologyMt]
... Primate
Person [BiologyVocabularyMt]
... ViviparousAnimal
Person [BiologyMt]
Philosopher
[HumanSocialLifeMt -> (Person)]
PoliticalPhilosopher [HumanSocialLifeMt] <-
Because #$Philosopher is a collection, the hierarchy browser opens with the default settings for collections. This means that we're examining the genls hierarchy: "superior terms" are generalizations of #$Philosopher, while #$PoliticalPhilosopher is a specialization of #$Philosopher.
Although there are default settings for specific types of constants, it is possible to view the hierarchy for any transitive binary predicate. By looking at the index frame for a constant in the browser, many predicates for which that constant is an argument have a small red diamond beside them. This indicates that the constant, as an argument to a particular predicate, has hierarchical information about it. For instance, in examining the reified NAT (The Aorta) in the browser, the following terms in the index have red diamonds beside them:
Under Arg 1 ( (The Aorta) is in the first argument of the predicate):
distalTo
physicalParts
Under Arg 2: ( (The Aorta) is the second argument of the predicate):
physicalParts
Examining the hierarchy at physicalParts will be interesting, since we know that our focal term is the first argument in some uses of the predicate and the second argument in other uses of the predicate.
Hierarchical display radiating from (The Aorta)
isa: Aorta, GolemRole, TheTerm
Context: Union of all contexts
Predicate: physicalParts
Index: 1
-> (The WholeBody)
(The CirculatorySystem) [VertebrateBodyStructureMt]
-> (The Person)
(The Aorta)
[GolemTestDataMt -> ((The Person))]
[VertebrateBodyStructureMt -> ((The CirculatorySystem))]
(The AorticArch) [HumanBodyStructureMt] <-
(The AscendingAorta) [VertebrateBodyStructureMt]
(The Mediastinum) [HumanBodyStructureMt] ...
(The DescendingAorta) [VertebrateBodyStructureMt]
(The AbdominalAorta) [VertebrateBodyStructureMt] <-
(The ThoracicAorta) [VertebrateBodyStructureMt] <-
(The ThoracicAorta) [VertebrateBodyStructureMt] <-
Superior terms from (The Aorta) are things of which (TheAorta) is a physical part, whereas inferior terms are things which are themselves physical parts of (The Aorta). Naturally, of course, (The AorticArch), which is a part of (The Aorta), is a part of (The CirculatorySystem) and finally (The WholeBody) because (The Aorta) is a part of those things.
If, instead of entering the hierarchy browser through a red diamond on the index of a constant, one enters the hierarchy browser through the "Cyc Navigator" page (it is found in the middle of the top center column titled "Cyc Main Menu"), the first page opened is one titled "Hierarcy Browser Parametes". This page permits you to set the focal term, the microtheories used (the default setting for this is always "All Contexts"), the binary predicate used, the argument position of that predicate that should serve as the index, the maximum height and depth to display, as well as various other features.
This page allows you to specify settings for the Cyc® Hierarchy Browser. Here you can set the starting term (the central, focal, or reference term), the microtheory or microtheories to be used, the binary predicate to be used, the argument position to use as the index, the maximum height and depth to display, and various "extra" features.
This section of the page allows you to specify the starting point, or "pivot" term, around which a hierarchical display will be constructed. "Superior" terms will be displayed above and to the left of the pivot term. "Inferior" terms will be displayed below and to the right of the pivot term. Enter the name of a CycL term (constant, non-atomic term, or lexicon entry) in the type-in space. If your input is ambiguous -- that is, if it can refer to more than one CycL term -- you will be presented with a menu of terms from which to choose.
Every CycL term is a member (element) of one or more sets (types, collections). Some types have pre-defined standard, or default, display settings (see below). If the term entered in the Starting Term type-in space belongs to one of these types, and if the checkbox labelled "Use default settings for term" is checked, then the default settings for this type of term will be used NO MATTER WHAT OTHER SETTINGS ARE SPECIFIED. In other words, if the "Use default settings for term" box is checked, and if the specified starting term belongs to a type which has default settings, then these defaults will override all other settings. To turn off the default settings (and thus prevent them from overriding other settings you might want specify), simply uncheck the "Use default settings for term" box.
Here are the types which currently have pre-defined default settings, and the settings for each type:
| Type | Microtheory | Predicate | Index Argument | Max Height | Max Depth |
|---|---|---|---|---|---|
| #$Collection | ALL | #$genls | 2 | 2 | 2 |
| #$Predicate | ALL | #$genlPreds | 2 | 5 | 5 |
| #$Microtheory | ALL | #$genlMt | 2 | 2 | 2 |
| #$GeographicalRegion | ALL | #$geographicalSubregions | 1 | 2 | 2 |
The default settings cannot (easily) be changed by an ordinary user. They are somewhat arbitrary, but are designed mainly to prevent novice users from unintentionally asking the system to construct hierarchical displays that would take several minutes of computation time and fill many screenfuls when presented. There is nothing to prevent the user from intentionally making such requests, by unchecking the "Use default settings for term" box!
This section of the page allows you to specify the microtheory or microtheories to use when constructing the hierarchical display. Note that the Hierarchy Browser is really just another way of looking at a subset of the assertions in the Knowledge Base. Like all CycL assertions, those viewed in the Hierarchy Browser are grouped, or bundled, in logical contexts (microtheories). The Hierarchy Browser allows you to select assertions from one microtheory, from a set of nested microtheories, or from all of the microtheories in the Knowledge Base:
To view assertions from one microtheory, enter the name of the microthoery in the type-in space. If your input is ambiguous -- that is, if it can refer to more than one microtheory -- you will be presented with a menu of microtheories from which to choose.
If you want to view assertions selected from one microtheory and all of its more general (nested) microtheories (i.e., those microtheories mapped to by the predicate #$genlMt), then in addition to entering the name of a microtheory in the type-in space, check the box labelled "Use its genl mts too, if possible".
If you want to view assertions selected from all microtheories in the KB, you have two choices. You can enter "ALL" in the type-in space, or you can simply check the box labelled "Use all mts".
Note that if the box labelled "Use all mts" is checked, this will override any other microtheory settings. All microtheories will be used, no matter what is entered in the type-in space, and regardless of whether or not the other checkbox is checked.
Note, also, that if the checkbox labelled "Use default settings for term" under the heading Starting Term is checked, and if the term entered is of a type which has pre-defined default settings, then these pre-defined default settings will override other microtheory settings, no matter what they are.
This section of the page allows you to specify the binary relation that will be used to construct the hierarchical display. Enter the name of a binary predicate in the type-in space. If your input is ambiguous -- that is, if it can refer to more than one binary predicate -- you will be presented with a menu of predicates from which to choose. In most cases, it makes sense to specify only a transitive binary predicate, but any binary predicate is allowed.
Note that if the checkbox labelled "Use default settings for term" under the heading Starting Term is checked, and if the term entered is of a type which has pre-defined default settings, then the pre-defined default predicate will be used no matter what is entered in the type-in space for the Binary Predicate section.
This section of the page allows you to specify which argument position the starting or "pivot" term should occupy relative to lower or "inferior" terms in CycL expressions using the predicate specified in the Binary Predicate section. This information will determine whether "broader" terms will appear above and to the left of the starting term, or below and to the right of the starting term, when the hierarchical display is constructed.
Suppose I have selected #$Dog as my starting term, and #$genls as my binary predicate. Now I am faced with this choice: do I want the terms that are more general than #$Dog to appear above #$Dog in the hierarchical display and the terms that are more specific than #$Dog to appear below it, or do I want the terms that are more specific than #$Dog to appear above it and those that are more general to appear below it? If I want the more general terms to appear above #$Dog and the more specific terms to appear below it, I would check the radio button marked "2". This means that in gathering and displaying the assertions used to construct "inferior" terms, the Hierarchy Browswer will start by finding all immediate X such that
(#$genls X #$Dog)
is true. Then, for each X, X will be substituted for #$Dog in the expression above and the process will (recursively) continue until the lower part of the hierarchical display has been constructed, or some resource constraint has been reached. Note that #$Dog occupies the 2nd argument position in the CycL expression above. To construct the upper part of the hierarchical display (the part showing terms "superior" to #$Dog), the starting CycL sentence will be
(#$genls #$Dog X)
Since the placement of "superior" and "inferior" terms depends both on the argument position of the starting term, and on the value ("1" or "2") chosen for the index argument, determining how to get the hierarchical display to look like you want it to can sometimes be confusing. If you have chosen one value for the index argument and the resulting display seems "backwards" to you, simply select the other index argument value and see if this is what you want.
Note that if the checkbox labelled "Use default settings for term" under the heading Starting Term is checked, and if the term entered is of a type which has pre-defined default settings, then the default index argument setting will override the setting specifed in the Index Argument section.
This section of the page allows you to specify how many steps (ascending) to the left from the starting term, and how many steps (descending) to the right from the starting term, should be included in the hierarchical display. It also allows you to specify a maximum number of "inferior" terms (terms appearing below the starting term) to display. The allowed maximum number of rightward (descending) levels to display, based on the specified maximum number of "inferior" terms, is quickly computed before the hierarchical display is constructed. The "Max depth" and "Max inferior terms" constraints interact in (possibly) unintuitive ways. Here is a specification of the relationship between these contraints. Note that (a) overrides (b), which overrides (c), which overrides (d):
(a) Only complete levels of inferior terms will be displayed. If the max depth setting is NONE, no inferior terms will be displayed; (b) If the max depth setting is not NONE (i.e., is > 0), then at least one complete inferior level will be allowed; (c) If a max inferior terms cutoff of N is specified, no more than N inferior terms will be displayed; (d) If a max depth cutoff of N is specified, no more than N inferior levels will be displayed.
If the max inferior terms type-in space is left blank, this will be interpreted to mean that there is NO UPPER BOUND on the number of inferior terms which may be displayed.
Note that if the checkbox labelled "Use default settings for term" under the heading Starting Term is checked, and if the term entered is of a type which has pre-defined default settings, then the default max height and max depth constraints will be used regardless of the settings specified in the Height and Depth section. There are no default settings for max inferior terms, so this constraint is always honored.
This section of the page allows you to set additional (mostly cosmetic) features:
If the checkbox labelled "Use lexicon entries, if possible" is checked, the hierarchy will be displayed using Cyc's English lexicon entries for constants, rather than constant names. Constructing the hierarchical display may take longer if this option is checked, but the English lexicon entry for a constant sometimes gives a better indication of what the constant means than does the constant name.
If the checkbox labelled "Show comments for terms" is checked, each term in the hierarchy will be followed by its #$comment entry or entries. The #$comment for a term often include a precise description of what the term means. If there is more than one #$comment entry for a term, the entries are sorted by microtheory. #$comment entries are not indented like terms in the hierarchical display. They are arranged in tabular form by microtheory, starting at the left margin of the display.
If the checkbox labelled "Show assertion's mts after terms" is checked, the microtheory (or microtheories) in which the relevant assertion occurs is printed after the "inferior" term in the assertion. Suppose the predicate #$genls is used to construct a hierarchical display of the constant #$Fish. A fragment of the display might look like this:
... AnimalBodyShape
FishlikeBodyShape [BaseKB]
... Heterotroph
Animal [BiologyMt]
... Organism-Whole
AquaticOrganism [BaseKB, BiologyMt]
Animal [BaseKB]
Fish
[BaseKB -> (Animal, FishlikeBodyShape)]
[BiologyMt -> (AquaticOrganism)]
Barracuda [BaseKB] <-
Carp [BaseKB] <-
Catfish [BaseKB] <-
The fragment above is equivalent to the following assertions:
(#$genls #$FishlikeBodyShape #$AnimalBodyShape) in #$BaseKB
(#$genls #$Animal #$Heterotroph) in #$BiologyMt
(#$genls #$AquaticOrganism #$Organism-Whole) in #$BaseKB
(#$genls #$Animal #$Organism-Whole) in #$BaseKB
(#$genls #$Fish #$Animal) in #$BaseKB
(#$genls #$Fish #$FishlikeBodyShape) in #$BaseKB
(#$genls #$Fish #$AquaticOrganism) in #$BiologyMt
(#$genls #$Barracuda #$Fish) in #$BaseKB
(#$genls #$Carp #$Fish) in #$BaseKB
(#$genls #$Catfish #$Fish) in #$BaseKB
Note that in the hierarchical display, for all assertions except those in which the "inferior" term is the starting term, the microtheory (or occasionally, microtheories) for the assertion is printed in square brackets following the "inferior" term. A different convention is used to set off the starting term. It is printed in a larger font, and in the square brackets following it, the relevant microtheories are listed with a pointer from each to the starting term's immediate "superior" terms in that microtheory.
The text input space labeled "Indent quantum" allows you to specify how deeply each new level in the hierarchical display should be indented. The value must be an integer between 0 and 50. Units (quanta) do not correspond to pixels or fixed-width font width. Depending on the font used by your browser, you may have to experiment to find a pleasing setting. 3 or 4 seem to produce the best results for a wide variety of fonts and font sizes.
The link labelled "Color and Symbols" will take you to a page that allows you to change these settings.