Limitations and Future Work

Current Limitations and Bugs

Some of the problems described below are fundamental limitations of the Generic Frame Protocol or the various underlying frame systems, and cannot be fixed until those problems are addressed. Others may be patched shortly or fixed in future versions of the GKB-Editor.

Please report bugs, preferably with enough context for us to reproduce the problem, to

Future Plans

Your comments and suggestions can have an impact on which changes we make, and how we prioritize them. We will probably not implement all of these items. Send suggestions to

Short-term plans

Longer-term plans


Remember that the current release of the GKB-Editor is a beta release! Although most operations should work correctly when you do the right thing, it is not hard to get into a broken or wedged state. For example, if you are using Loom as your underlying FRS, and you perform an operation that violates a Loom constraint or causes a Loom or GFP error, there may not yet be a graceful way to get out of the resultant inconsistent state, especially if the GKB-Editor thinks a command has succeeded when it in fact failed, and it tries to update the display accordingly. If you find yourself thrown into the debugger in such a situation, first try to return to the GKB-Editor command or top level, and fix the problem using GKB-Editor commands. If you have some in-depth knowledge of the underlying FRS, you may also try to fix the problem while in the debugger. (Sometimes after returning from the debugger, the interface does not respond to pointer clicks. Type Control-z and try again.) If the problem is not that the KB itself is inconsistent, but that the current graph's view of the KB doesn't match the state of the KB, try beginning a new browse: this will eliminate the current graph's view of the KB, and reconstruct a new one. If these attempts fail, probably the best thing you can do is to revert to the saved version of the knowledge. For this reason, it is important to save your work frequently! Finally, if this fails to correct the problem, you may need to quit and restart the application and/or the Lisp process.

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:

You can tell if you need to quote your values or not by looking at the prompt in the pop-up window. If it says to enter a string or symbol, then you know that your value will be interpreted as the appropriate type, even without the quotes. If it says to enter a form, then Loom doesn't know what type to expect, so you need to use the quotes.

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.


Return to the GKB-Editor Overview page.

Return to the beginning of the GKB User Manual.

Suzanne M. Paley <>
Last modified: Wed May 29 15:53:42 1996