KM's most important feature is that it allows the annotation of values, assertions, and slots with extra details. KM supports three types of annotations:
• value annotations
• semantic annotations
• slot annotations
Value annotations are used to represent information contextually. Consider the assertion "Rose plants have broad green leaves." To represent this, the "Rose plants" relation needs to be connected to the "Leaf shape Broad" and "Leaf color Green" assertions. Figure 3 is an example of how this assertion is represented in KM. In this case, the parts slot of Rose-Plant is filled with the value Leaf, and Leaf is annotated to include information about the size and the shape of the Leaf.
Semantic annotations are used to specify the necessary or sufficient characteristics of pieces of information. Consider the assertion "Rose plants aren't usually found living the desert." To represent this, the "Rose-Plant habitat desert" assertion needs to be modified to indicate that the assertion only holds a small percentage of the time. Figure 4 is an example of how this assertion is represented in KM. In this case, the entire "Rose-Plant habitat Desert" assertion is annotated with the <likelihood, Low> attribute.
Slot annotations are used to constrain the values of slots.
Consider the assertion "Rose-Plants are only found in temperate regions." The slot that would be used for this assertion is "Habitat". But, the habitat slot says that its filler may be any type of Earth-Region, not necessarily a Temperate-Region. So, the habitat slot of Rose-Plant needs to be constrained to specify that the values for the habitat slot of Rose-Plant must be Temperate-Regions. Figure 5 is an example of this modified assertion.
Figure 6: An example of a nested annotation that represents the assertion "Texas Bluebonnets secrete nectar that contains a low concentration of sugar."
Unlike most other knowledge representation languages, KM allows the recursive nesting of its annotations. This recursion makes knowledge representation more convenient and helps to retain contextual information about the nested annotations [Acker:92]. Figure 6 demonstrates the manner in which value annotations are recursively nested.
Nested annotations can also be frames. In this case, the nested annotation is called an embedded frame. For example, the following embedded frames exist in Figure 6:
• (Texas-Bluebonnet secretes Nectar)
The nectar that is secreted by the Texas Bluebonnet.
• (Texas-Bluebonnet secretes Nectar contains Sugar)
The sugar that is contained in the nectar that is secreted by the Texas Bluebonnet.
Figure 7: An example of the use of an address. This figure represents the assertion that "Bees consume a particular type of sugar." The particular type of sugar is identified by the (Texas-Bluebonnet secretes Nectar contains Sugar) address.
Figure 8: An example of a nested annotation that represents the assertion "Texas Bluebonnets secrete nectar that contains sugar that is consumed by Bees."
Addresses are formed of a list of frames and slots surrounded by parenthesis. They have two uses in KM:
• to locate information in the knowledge base by referring to a particular slot on a frame. For example, the address that refers to the contains slot in Figure 6 is:
(Texas-Bluebonnet secretes Nectar contains)
• to represent embedded frames. For example, Figure 7 shows the use of an embedded frame in the representation of the inverse of the assertion in Figure 8. Lastly, since annotations can be recursively nested, addresses have no fixed length.
KM has a variety of commands for editing the knowledge base. The most common commands are for:
• adding values to an address
• removing values from an address
• changing values of an address
• copying values from one address to another
Figure 9: An example of an assertion and its inverse
Most slots in the BKB have an inverse slot. When an assertion is added to the BKB using KM's commands, a second fact is automatically added, based on the inverse of the slot of the attribute. For example, the inverse of the "Rose-Plant habitat Temperate-Region" assertion is the "Temperate-Region habitat-of Rose-Plant" assertion (Figure 9).
Another important aspect of inverses is that values of slots that are addresses can also have inverses. For example, the inverse of the assertion in Figure 8 is represented in Figure 7.
Figure 10: A nonsensical assertion
Constraint checking is one method KM uses to help the knowledge engineers keep the knowledge base in a consistent state. Consider the assertion "Rose-Plant habitat Temperate-Region" (Figure 9). It is a valid assertion since it doesn't violate the domain and range constraints of the habitat slot (see Section 1.3.2). Namely,
• Rose-Plant is a type of Biological-Taxon
• Temperate-Region is a type of Earth-Region
If an assertion is added to the KB that violates any constraints, then the knowledge engineer is notified that a constraint violation has occurred. For example, if "Rose-Plant habitat Moon" is asserted (Figure 10), then the following warning message occurs:
--------------Range Violation-------------------
You can't add the value:
MOON
to:
(ROSE-PLANT HABITAT)
KM supports the use of inheritance. When asked for the values of an address, KM will look not only at the values of the address, but to all of the values in the address's ancestry. For example, all of the parts of a Rose-Plant are:
Root Stem Leaf Corolla Calyx Xylem-Network Phloem-Network
But, only the values: Root, Stem, and Leaf are stored locally at the (Rose-Plant parts) address. The rest of the values are inherited from the parts slots of the ancestors of Rose-Plant. Figure 18 shows the ancestors that the values are inherited from