Searching for Constants

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.

1.3.1.  The Search Window

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.

1.3.2.  The Hierarchy Browser

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.

1.3.2.a. Hierarchy Browser Settings

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.

1.3.2.b. Starting Term

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.

1.3.2.c. Default Settings

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!

1.3.2.d. Microtheory

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:

  1. 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.

  2. 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".

  3. 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.

1.3.2.e. Binary Predicate

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.

1.3.2.f. Index Argument

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.

1.3.2.g. Height and Depth

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.

1.3.2.h. Extras

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.