Overview

A web-based ontology editor uses HTML pages to support browsing and editing a knowledge base. Several are mentioned here and here.

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:


The Exercises


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.

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

Now define a MOP editing interface. You can design your own, if handy with forms and Javascript, or you can try starting with this sample page. This page uses some simple Javascript along with the jQuery Javascript library. It just lets you update the form on-screen but nothing is sent anywhere. The interface is simple but non-standard.

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:

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.

Faculty: Chris Riesbeck
Time: Monday, Wednesday, Friday: 1pm - 2pm
Location:Annenberg G15

Contents

Important Links