Appeared in the Proceedings of the 1996 International Description Logics Workshop. Boston, Mass. November, 1996.
Christopher A. Welty
Vassar College Computer Science Dept.
Poughkeepsie, NY 12601
Several significant problems exist when applying knowledge representation systems to real problems. In particular, the obscurity of LISP, the resource consumption, garbage collection, and the single user nature of most KR systems can prevent the technology from being accepted in many non-research environments. This paper briefly presents one way to address these problems with a web interface, and outlines some of the general principles that guided the implementation of a web interface for Classic.
Implemented Knowledge Representation systems have much to offer in solving serious problems in the real world. In pursuing this belief, we have gathered experience transferring KR technology to users outside traditional academic circles. Most of this work has been in the context of AI & Software Engineering [Welty1995a, Welty1995b], but a recent project in building a card catalog system for the web [Welty1996] has led to some new web-based solutions for the problems facing this type of technology transfer.
This research has made use of Classic [Brachman et al. 1991] as the vehicle for knowledge representation. The paper begins with a description of the barriers that were met when trying to use Classic to solve some knowledge problems in a small software company. The paper then discusses the web interface that was devolped to address these problems and a classic-based card catalog system for the web.
The principle barriers to deploying Classic in industry are mainly related to its status as a tool for KR researchers. Specifically, in an attempt to track knowledge in a small software company related to their main product, the use of Classic was rejected for many reasons:
In the end, we used an Oracle application to represent the knowledge this company needed.
In general, just about any user interface to Classic would solve some of the problems mentioned in the previous section, but an HTML interface can address each of the barriers listed above:
The technology that made this possible was the Common LISP Hypermedia Server (CL-HTTP) [Mallery1994]. This HTTP server runs in most multi-threaded Common LISPs, and allows for active URLs to be served by LISP functions (as opposed to shell or Perl scripts). The real advantage of this is that since the server can run as a thread within the same application as Classic, it shares memory with it and no inter-process communication is necessary for the HTTP response functions to access the knowledge-base. This greatly simplified the task of creating this interface.
While the technology the web represents was clearly dated from its inception, its familiarity simply can not be taken for granted - everyone knows how to use a web browser, and navigate through hypertext documents.
That there is an analogy between semantic networks and hypertext should be clear upon the face of it, and it was this obvious connection that first made an HTML interface seem like a natural way to describe Classic objects. The interface has four basic modes: describing concepts, describing individuals, listing taxonomies, and entering queries.
It is important to realize that all of these pages are generated on the fly, that is they always reflect the current state of the knowledge base.
When describing a concept, the interface displays a web page whose name is the concept name, underneath which is the comment for that concept. If the concept has any individuals, a link is generated that when clicked on will produce a page full of links to descriptions of those individuals.
The concept's direct parents are listed by name, with each name also being a link to the description of that concept. The list of parents is followed by a list of all the ancestors, in no particular order. This is followed by a list of child concepts, followed by descendants.
Finally, the role restrictions for the concept are listed, by role. For simplicity, the interface does not display roles for which there is an at-most 0 restriction, as these tend to clutter the view. Eventually this will be generalized to obey the interesting meta-data facilty provided in the latest version of Classic.
The roles are listed in an HTML unordered (<UL></UL>) list, and the role hierarchy is displayed as nested lists below the parent role.
Any reference to another concept (such as within an ALL restriction) is, of course, a link to a description for that concept.
All derived information is display in italics.
A simple example of the text in a concept description page is shown below.
Individuals in Classic are very similar to concepts, and as a result the description pages of individuals look very similar. There are a few differences, some of which are based on the way Classic treats individuals, and some were based on the way our system used them.
From a Classic perspective, individuals can not have individuals, so that section in the concept descriptions was removed. Individuals can also have closed roles, and those were displayed in bold face.
For the purposes of our card catalog system, which was the motivating force for creating the interface, individuals were the key element. That is, users frequently did not care about concepts, and browsed almost exclusively individuals. The information provided in these descriptions, then, had to be tailored based on people's existing experiences with card catalogs and the new functionality offered by Classic.
To begin with, displaying all the information Classic maintains about an individuals was out of the question. The page quickly becomes cluttered and unusable. The interface was created before the interesting meta-data facilty was added to Classic, and so it made use of certain assumptions based, again, on our use of the system.
The key role was also always the first role displayed in the full description.
Important roles and hidden roles are accounted for in the interesting facility added to Classic in version 2.3.
Many of the compromises made above for displaying individuals seem to dilute the description logic nature of Classic, in particular the fact that only role fillers are displayed for individuals. It is important to realize that this is only the default behavior, future versions of the interface will be easily customizable for users who are familiar with Classic.
An example of an individual description is shown below.
Again, the attraction of the CL-HTTP server was that very little programming was required to produce a fairly usable interface to Classic. Graphical views, though clearly desirable particularly when viewing taxonomies, were ruled out due to their inherent complexity.
We chose to view taxonomies as HTML unordered lists. Given a concept, the children below that concept are displayed as items with their comments. Descendants are displayed in nested lists. In addition, two links are provided per concept, one (expand) allows the user to make that concept the root concept of the taxonomy being viewed. The other provides the full concept description.
Finally, each taxonomy page has a link at the top that can restrict the depth of the taxonomy being displayed. This feature helps viewing deep taxonomies, and when combined with the expand link makes it very easy to browse taxonomies.
The primary advantage of using Classic in the card catalog domain was the ability to use more expressive queries. The interface is still under development, however, and this aspect is still primitive. To enter a query, you type a classic concept expression in an HTML form, and the interface will display a list of all the individuals that are subsumed by that concept.
Clearly this aspect of the interface needs to be extended.
A demo of the web interface is accessible through my home page, under the link for the Untangle project. The Untangle project is the library card catalog system currently under development.
The interface has worked well in helping undergraduates understand the ontology and how to enter data. These undergraduates, it should be noted, have little or no KR background, and certainly no experience with description logics, and are able to navigate through the knowledge-base with fairly little training. In this respect, the interface works well.
The barriers to introducing Classic to a small software company were addressed, and initial feedback from that company indicates they are interested in seeing it.
The future use of description logics such as Classic will depend on the barriers discussed being addressed in such a way.
An HTML Interface for Classic
This document was generated using the LaTeX2HTML translator Version 96.1-g (June 11, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 dl96.
The translation was initiated by Chris Welty on Thu Oct 17 15:02:31 EDT 1996