Limitations and Future Work

Current Limitations and Bugs

Please report bugs, preferably with enough context for us to reproduce the problem, to paley@ai.sri.com.

• There is minimal constraint checking. If the underlying FRS does constraint checking, then the GKB-Editor may allow an operation that the FRS forbids, which can cause a number of problems, depending on how the violation is handled by the FRS, e.g. the FRS may break to the lisp debugger, frames may be marked incoherent, or the GKB-Editor may change its display to reflect changes that never occurred. Even if the violation is handled correctly, there may be little or no feedback to the user as to why the operation failed. If the FRS does not do constraint checking, then operations may be allowed that nevertheless violate KB constraints. In order to address this limitation, we would need either a) better communication between the FRS and the GKB-Editor (through GFP) about which operations are allowed, and whether or not an operation has succeeded, or b) a mechanism by which constraints could be expressed using GFP and taken advantage of by the GKB-Editor in a uniform fashion.
• There is no way to enter such things as methods for computed slots, complicated constraints that cannot be expressed using simple facet values, or enumerated sets (other than with the :one-of value-type). There also should be a more intuitive graphical way to enter :and, :or and :one-of value-types.
• Most of the editing commands in the relationships editor will not work (and may cause problems) if they are attempted while browsing slot-types rather than slot-values.
• Facet and Annotation commands may break if these operations are not supported by the FRS.
• There is no existing way to edit the list of KBs in the Knowledge Base Open menu, for example, removing a KB that is no longer in use, or changing the KB package.
• The Kill Ring does not work in all situations. For example, it cannot be used in motif text gadgets. It also cannot handle strings with embedded newlines (currently, we replace such newlines with spaces).
• Many of the gadget-based dialogs will break or look awkward under Lucid CLIM 1.1 (which does not implement gadgets).
• Under CLIM 1.1, we sometimes get some residual display ghosts that we think are CLIM bugs. Most of these go away if you bury the window and then bring it to the top again.
• Renaming an instance frame in Loom can cause problems (since that operation is not supported by Loom) for frames that were linked to the frame under its original name.
• Completion doesn't work properly in all cases. This is a bug.
• When working with Loom, the relationships viewer will not expand slots (relations) with a domain of Thing (or no specified domain).
• Various operations in the Frame Editor and the Relationships Viewer may break or produce incorrect results with FRSs that do not implement slotunits (such as Sipe).

Future Plans

Short-term plans

• Use multiple coordinated processes so that the user can interact with multiple viewers simultaneously. Allow objects selected using one viewer to be used as input for a request in another viewer.
• Improve error-checking so that the graph doesn't get out of synch with the KB when editing operations fail.
• In the relationships viewer, give the option of distinguishing slots by using different color edges, with a key, instead of labeling every edge.
• Add a spreadsheet-type viewer to edit selected slots in multiple frames.
• Make better use of color (suggestions?).
• Add some additional preferences (suggestions?), and revamp the remaining dialogs left over from the previous release.

Longer-term plans

• Implement an Undo command
• Birds-eye view
• Add an interactive query generator
• Enhanced constraint checking
• Improve GFP to support more systems (e.g. CLOS), more operations.
• Port the GKB-Editor to the WWW
• Improve the KB Analysis tools

Troubleshooting

Q. Why are all the commands in the command menus disabled?
A. If there is no current KB (i.e. if you just started running and have not opened a KB yet, or you have recently closed or destroyed the current KB), the frame-editing and viewing commands will all be disabled. Commands that should still be available to you are New, and Open in the Knowledge Base menu, and Quit and Kill in the Application menu. Once you open a KB, the other commands should become active. If you have just created a new KB, there will be no frames to view or manipulate. In this case, the only additional command to be enabled is Create Class from the Frame menu. Once you have created a single frame, the other commands should become active also.

Q. I changed a slot value while in the frame-editing viewer, but the new value isn't showing up in the relationships graph. Why is that?
A. You may be having package problems. If your current package is different from the package your frames are in, then the new value you typed may not be interpreted as corresponding to an actual frame, and therefore will not show up in the relationships viewer (only values that are frames show up in the relationships viewer). To ensure that you get the correct frame in this case, when you enter the new value, preface it with the appropriate package name (e.g. sipe-cl::army rather than just army).

Q. I'm using Loom. I created a new slot while in the frame-editing viewer, added a value, and exited the frame-editing viewer. I have just started editing the same frame again, and notice that the value I added is missing. What happened?
A. When you create a new slot, Loom doesn't know what the slot range is supposed to be, so Loom assumes that the value you added is supposed to be a frame, unless the value is obviously something else. You can tell that Loom is expecting a frame because when you enter a value that is not a frame, you will be asked whether or not you wish to create the corresponding frame. If no frame corresponding to the value you specified exists (or gets created), then the value is rejected. The frame editor doesn't know the value was rejected (our bug), so it goes ahead and displays the value. However, next time you try to edit the frame, the value will be missing. Possible ways to prevent this situation from occurring are:

• If you mean the value to be the name of the frame, make sure the frame already exists or gets created.
• If you mean the value to be a symbol or string, you must quote it (for a symbol) or surround it with double quotes (for a string), OR
• Edit the slot specification, giving a value for the facet :SLOT-VALUE-TYPE of either SYMBOL or STRING. If you do this, you don't need to use quotes when entering new values: the values will automatically be interpreted correctly.

Q. I'm using Loom, and when I try browsing (or editing) the relationships graph, I am told that there are no slots to follow. I know my KB has relations in it!
A. The relationships browser works by looking at the roles of a concept or instance. Normally, when you create a Loom relation using GFP, GFP alters the domain concept to take that relation as a role. If the domain is Thing, however, then the domain concept cannot be altered, so no role is created, and the relationship cannot be detected. If your KB was created other than through GFP, you may run into a similar problem, even if your relations have domains defined other than Thing. This is a GFP problem for which we currently have no solution (the workaround would be to examine every relation in the KB, which would be too time-consuming). The only thing you can do is to use the Frame Editor to change the domain of your relations.

Links

Return to the beginning of the GKB User Manual.