In these exercises, we start with a Lisp image containing a knowledge base, i.e., a set of defined MOPs. The exercises begin the simplest possible way to display a single given MOP, then improve on that interface to be more readable, then to allow easy one-click browsing, and finally to allow MOPs to be defined or redefined by changing fields on a web page.
These exercises require:
HTML MOP Browser
Use WebActions to define mop-browser webapp. The URL http://localhost:8000/mop-browser/ should open a page that lets a user browse a MOP memory.
Design a simple readable format that makes it easy to get to any MOP with just point and click. Look at some ontology browsers for ideas. Note the pros and cons of some of the example, such as the demos here or this one.
Don't go crazy with animation. In fact, some of the most usable browser are the simplest.
- Be RESTful, i.e., each MOP should have its own URL that can be bookmarked.
- Include the MOP name in the page's title that shows in the browser title bar, history, and bookmarks.
- Make it easy to go and down the hierarchy, and into the MOPs that are fillers of slots.
Test with the memory examples in mop-examples.lisp.
Submit: The primary CLP page for browsing MOPs and the Lisp functions that page calls. Don't send auxiliary pages, if you have them, for error messages or login or whatever.
MOP Editor Interface
- Select an existing MOP from the menu on the right, then click a field to store the MOP in that field.
- Or, click on a field with nothing selected and enter a new value.
- To add an abstraction or role-filler, use the empty fields given.
- To edit a different existig MOP, select the MOP and click Change.
- To create a new MOP, click Unselect if necessary, then Change and enter the new name.
There's no "undo" facility, but the Cancel button resets the form to its original state.
Don't worry about implementing Save Changes. Just write the code so that the right MOP data is displayed in the MOP editor interface, including choosing a new MOP to edit. If a new MOP name is entered, the fields should be empty.
Submit: The primary CLP page for editing MOPs and any new Lisp functions you wrote that that page calls. Don't send auxiliary pages, if you have them, for error messages or login or whatever.
MOP Editor Updating
Now fix it so that clicking Save Changes does the following defines a MOP with the name, abstractions, and slots specified by the current values of the fields in the form. A slot with an empty role or filler should be ignored.
NOTE: Store MOPs with add-frame. Don't make an DEFMOP and call eval. That would require calling the compiler to create a MOP or instance. It would also require any deployed application would have to include the Lisp compiler..
There's one other tricky bit of logic. There's three ways this form might get called:
- from some other page, in which case the source MOP should be displayed, but nothing saved
- from this page, if the user clicks Cancel Changes, or Use MOP to change the MOP being edited, which should be handled like the previous case
- from this page, if the user clicks Save Changes, in which case the current MOP settings should be stored and redisplayed
You'll need to change the opening <FORM> tag to read:
<form name="mainForm" method="POST" action="/cs325/mopedit">
MOP Editor Persistence
The last big thing you need to add to your editor is the ability to make your changes persistent. Currently, all your changed MOPs only exist in the current Lisp server image. You need to save those MOPs to a file that will be reloaded when your server restarts.
Add code to write all MOPs that have been changed to a file. Every time the user clicks Save Changes, the file of changed MOPs should be re-written. This is to save changes in case the server or browser crashes. Because there might be mistakes, and because you don't want to write every single MOP to a file when only a few have changed, this file should be separate from your master file of MOPs, i.e., it should not be mop-examples.lisp.
Commonly in situations like this, an administrator will go through the changed MOPs, check for errors, and, if there are no problems, move the changed MOPs to the master file.
Whatever file of code builds your server should load the master files then the file of changes. You'll need to keep a list or table of what MOPs have changed, and it should always include everything in the file of changed MOPs.