The following discussion refers to (numbers) in the above diagram. The discussion is organized in terms of the client programs, in the order which they were developed. All are currently in use, although only the first is used in production. Click on the heading for a screen cpature of each client.
The semantic network comprising our current symbolic knowledge base is stored as two tables in a relational database, a terms table and a links table. Our initial and current production inplementation is stored in the Sybase relational database that came free with the original NeXT computers (1). This database is accessed by means of the Sybase relational database server (2).
The Knowledge Manager client(3) is an authoring program that allows anatomist authors to add information to our symbolic knowledge base. This program is written in Objective C. It runs on the NeXT computer and accesses the Sybase server directly by means of Sybase library calls. It was originally written by Kraig Eno, and later modified by Jeff Prothero. Cornelius Rosse and Onard Mejino currently use this program to generate the terminology and semantic relationships for Cornelius's contract to extend the UMLS with anatomic terminology.
In the current representation, textual definitions are stored in text files, where the name of the text file is the name of the structure (4). These text files stored in a Unix directory that is visible to the Sybase version of the Knowledge Server (5).
The Knowledge Server is written in our Slisp programming environment [Brinkley 1995a], in which C routines can be encapsulated as functions in a small version of Lisp. Additional Lisp functions can then be written in Lisp to glue the primitive C functions together as Lisp programs. Any Slisp program can be run as a standalone server, in which case it accepts Lisp expressions over the network, and returns the results of evaluating those expressions.
One of the C modules in the Sybase Knowledge Server (5) is called xsybase. This module encapsulates the Sybase dblib calls as a set of Lisp functions that communicate with the Sybase server. Another set of functions can access the definitions in the text files. A client program can therefore send high-level Lisp commands to the Lisp server, without caring about the underlying form of the database.
Using this mechanism we have developed many experimental versions of Lisp functions (written in Lisp using the DEFUN Lisp function for defining new functions) (6). These functions can then be called from the command line to access and modify the knowledge base.
As an example, a set of Lisp object classes have been defined to create an object model over the Sybase relational database. Instances of these classes can then be populated from rows in the database, and can be queried using server-accessible functions such as kb-show-node, or kb-get-children. The Slisp and Lisp functions were written by Jim Brinkley, with help from Kraig Eno and Scott Bradley.
The forms-based client (10) uses HTML forms to access the Slisp Knowledge Server (5) by means of a CGI program called kbrow (8). The CGI program is called by a standard Web server (9), after which it establishes a connection to the Knowledge Server using C-callable network routines that are part of Slisp. State information is maintained by hidden form elements that are passed to kbrow. This client was written by Scott Bradley.
In an attempt to move from the older NeXT technogy, Scott Bradley created a version of the knowledge base in msql (12), a free relational database that runs on most hardware, in our case SGI Irix. The msql database is accessed by the Msql Server (13), which can be accessed from C programs by means of the msql library. Scott Bradley encapsulated these calls in an Slisp module called xmsql, which then became part of an Msql-based Knowledge server (14). The Lisp functions loaded by this version of the knowledge server (15) are almost the same as those loaded by the sybase version.
Scott then wrote the beginnings of a Java-based Knowledge Browser (16), that contacts the Msql knowledge server (it could also have contacted the Sybase server with no very little - if any - change to the code).
The Knowledge base now contains over 20,000 terms and a similar number of links. The biggest problem now is that it is too slow. So we are looking at ways to speed it up, and to introduce inference procedures. One possibility is to substitute an object-oriented database for the relational databases, and a more robust Lisp for Slisp, while keeping a java front end.