While there are several systems with knowledge representation languages similar to KM, there are only a few that have an interface that duplicates the browsing and editing capabilities of KnEd. The systems whose interfaces are most similar to KnEd are the CYC [Lenat:90] [Terveen:July90] [Terveen:Aug90] (Note: this thesis focuses on the CYC interface as it existed in 1989. Since then, the interface has changed significantly and currently bears little resemblance to its 1989 version or to the interfaces for KnEd, KEATS, and CODE4), CODE4 [Lethbridge:94], and KEATS [Eisenstadt:90] [Motta:91] systems. The interfaces for these systems support windows similar to KnEd's text and tree panes. In addition, KEATS and CODE4 support a table display. This chapter will examine the differences between these systems.
In the following discussion, KnEd terminology will be used as much as possible. In the case where KnEd doesn't support a given feature, then the terminology from the other system will be used. The matrix in Table 4 relates the terminology used in the different systems.
KnEd, CYC, KEATS, and CODE4 all support some version of a text pane. The simplest version is the one supported by KEATS. It is basically an EMACS editor window that contains the definition of the frame. The user can then edit the frame using standard EMACS commands. The text panes supported by CYC, KnEd, and CODE4 are much more complicated. They all provide a textual representation of a frame which the user can view and edit via mouse and keyboard operations.
The main difference between the KnEd, CODE4 and CYC text panes is the way in which the information in the text pane is presented. In CYC, only the slots and values of a frame are displayed. To view an embedded annotation requires displaying the frame for the embedded annotation in a separate window. In KnEd and CODE4, the slots, values and all embedded annotations can be displayed together. KnEd and CODE4 also allow the displaying of embedded annotations in separate windows.
Another feature of the KnEd text pane is that it wraps all of the slot values so that none of the values appear past the right boundary of the window. This means that the user only needs to scroll the window vertically to see all of the information associated with a frame. In CYC and CODE4, if any values appear past the right boundary of the screen, the user must either scroll the window to the right or display the information in a separate window. This methodology produces a more compact display, since each slot only requires a single line to display its contents. But, this also causes more work for the user, since the values of the slots are not always immediately visible.
Figure 30: An example of a typical CODE4 window configuration
This difference is also related to the input strategies of the different systems. CYC and CODE4 prefer to have a separate window devoted to the addition, removal, and modification of values. For example, Figure 30 displays a typical CODE4 window configuration that contains a tree pane, a text pane, and a value editing pane. In CODE4, the user clicks on a slot of interest in the text pane and the value of the slot appears in the value editing window. The user can then add, remove, or modify this value. The KB is updated to reflect the new value of the slot. But, in KnEd, the addition, removal, and modification of values is treated as an integral part of the text panes.
Another important feature provided by KnEd, CYC, and CODE4 is mechanisms for filtering the information that appears in the text panes. KnEd's mechanism is to define groupings of slots and then let the user choose which groups he/she wants to be displayed. For example, the user could choose to hide bookkeeping information about the last user to edit a frame and the time and date of that edit. CYC and CODE4 are more flexible, since they give the user the choice of displaying groups of slots or adding slots individually.
KnEd, CODE4, CYC, and KEATS all support some version of a tree pane. The main difference between the tree panes is that KnEd's tree pane is only used for viewing the contents of the knowledge base while the CYC, KEATS, and CODE4 tree panes can both view and edit the information in the knowledge base.
For editing, CODE4, KEATS, and CYC let the user place frames on the screen and then draw arcs between the frames. The user has the option of updating the knowledge base whenever a change is made to the graph, or to wait and update the knowledge base all at once. This feature is most useful for creating hierarchies in the knowledge base, since the graph visually reinforces the users idea of a hierarchy.
For viewing, KnEd, CODE4, CYC, and KEATS all label the arcs in the trees. But, in KEATS, the user can view the tree with the arcs labeled or the arcs can have different line styles, with each style corresponding to a different label. This makes the tree look cleaner since extraneous text has been removed. But, it does require the user to remember which line style corresponds with which label.
Figure 31: A stack tree version of the first three levels of the tree in Figure 24
Also, CYC and CODE4 provide a feature that lets the user view a tree textually instead of with arcs. Rather than having arcs between nodes in the tree, the trees are drawn vertically, with the value of each relation being displayed indented below the source of the relation. In CODE4, this tree is termed an outline browser. Figure 31 is an example of an outline browser tree in CODE4.
An interesting feature provided only by KEATS and CODE4 is tables. Tables let users view the values of slots across multiple frames. Table 5 is a table showing some of the energy-related slots for the frames that are children of the frame Energy-Transduction. CODE4 and KEATS also let the users add, remove, or modify the values that are displayed in the cells of the tables.
The following are features that are not directly connected to a particular display window. Instead, they can appear during the use of any of the display windows.
When entering information in KnEd, CYC, or CODE4, it's always possible to perform a keyboard action that causes the current name being entered to be completed, i.e. name completion. This is especially helpful when names in the knowledge base are very long. Also related to this is the use of names that are on the screen. When entering information, CYC lets the user click on an item on the screen and have it included in the input window. CODE4 and KnEd perform this operation in two steps. First, the user selects an item from the screen to be stored in a buffer. Second, the user yanks the item from the buffer so that it is included in the input window. KEATS doesn't support this type of input.
An important feature of KnEd is the window for copying frames. KnEd's copy window displays a copy of a frame and lets the user select which items to copy by clicking on the items to be copied. The user can also change the value of a selected copy item. The CYC copy window also offers these features, but uses a slightly different interface. In CYC, each item in the frame is displayed on a separate line. Each line also contains several boxes. The user chooses whether to add, delete, or change each value by clicking on the box that corresponds to the desired choice. In addition, by clicking on the boxes the user can specify the order in which the items are added into the knowledge base. This is especially useful with regards to constraint maintenance. As each value is added, the system checks to see if any constraints are violated (see Section 2.2.6) In CYC, the user can then process any constraint violations one at a time. But, in the KnEd copy window, all the values are added at once. So, it is possible to receive multiple violations at the same time. CODE4 and KEATS do not have a facility for copying frames other than to make a copy of the entire frame.
A nice feature only available in CYC is an agenda. As the user adds new frames to the knowledge base, certain information about these frames also needs to be added, such as where it's located in the hierarchy. CYC keeps a list of these new frames in an agenda. The user can then choose the order in which the new frames will be edited to add the additional information. Also, in CYC, if constraint violations occur, then the information about the violation is added to a checklist window. This window functions similarly to the agenda, in that the user is able to choose the order in which they will resolve the constraint violations.
KnEd, CYC, and CODE4 all provide the user with the possibility of saving his/her entire desktop. Later, when the systems are restarted, they can be initialized to the state of the saved desktop. This lets the user shutdown at the end of the day and resume working with the same desktop state the next day.
Lastly, KnEd and CYC both work in a distributed environment. KEATS and CODE4 can only work in a standalone mode.