This page contains links and information about my Master's Project, entitled "A Java Framework for Classificatory Diagnosis", and other projects associated with it. For the project, I developed a tool that performs hierarchical classification. To build the framework discussed on this page, the classifier was integrated with a structured matcher, built by Wing Keong Loo and Lonnie Heinke, and an abductive assembler developed by Greg Walker.

These tools are based on work done at the Ohio State University by Chandrasekaran, et al, called Generic Tasks. Chapter One from my master's project paper discusses generic tasks, including classification, structured matching, and abduction. Click here to get a PDF file containing that chapter, or here to get a PDF file containing the bibliography for my paper. Visit Ohio State University's Laboratory for Artificial Intelligence Research (LAIR) for more information.

The tree package used by this system's classifier editor was developed by Thomas Koch and obtained from Gamelan (copyright: 1995, GMD Forschungszentrum Informationstechnik GmbH, FIT.CSCW, GMD SchlossBirlinghoven, 53754 Sankt Augustin, Germany).

Here are links to the user interface object model and domain object model. They include UML diagrams and class descriptions.

The framework API is documented using javadoc.

Click here to access the Java source code.

The labs for CS397c24 were incorporated into the framework discussed on this page. Click here for information about the framework's use of Serialization and Java Beans. For information on the database and distributed computing labs, click here.

Download "classifier.zip". This code was developed using IBM's VisualAge for Java. It is based on the Java 1.1.2 specification and VM. I've run the code outside the VisualAge environment on both NT and Solaris on all versions between 1.1.1 and 1.1.6 successfully using the steps below.

Extract the contents of the zip file. On Unix, use unzip to extract the archive contents. On a Windows system, use winzip or some other program that reads zip files to extract the contents of the archive. The zip file contains several subdirectories, classifier and tree. Put these subdirectories in your classpath. For example, if your classpath contains ~/java, put the classifier and tree directories in your ~/java directory. Alternatively, append the directory that contains the newly extracted subdirectories to your classpath, e.g., "setenv CLASSPATH ~/java:.". After installing the two directories within your classpath, run the application by typing "java classifier.CAMClassifierMainUI".

The swing jar file must be specified in your classpath, as it is utilized by the structured matcher.

You should now see the application's launcher, which is shown below.

To sample data files have been provided at the top level of the zip file directory structure to assist you in learning to use the framework. The file "automech.classifier" contains a serialized classifier object and the file "auto.case" contains a serialized case object. Either of these files may be opened by selecting "Open" from the "Classifier" or "Case" menus on the launcher, respectively.

To build a classifier, select "New" from the Classifier menu. The classifier editor, shown below, appears. The editor allows you to save a classifier to disk or the database, supply information about the classifier, and add specialists to its classification hierarchy. Each of these steps is discussed below.

The editor allows you to modify the classifier's name and description fields via its text widgets.

The classifier editor allows you to add a new specialist to its classification hierarchy, or edit an existing one. To edit a specialist, select it in the classifier editor's visual hierarchy widget and select "Edit" from the "Specialist" menu. To create a new specialist, select the specialist that it should be a child of and select "Add" from the "Specialist" menu. In either case, a specialist editor like the one shown below appears.

Use the specialist editor's text widgets to change the specialist's name and hypothesis. When you are done editing the specialist, click the OK button to save your changes. But first, you may want to edit the specialist's structured matcher and add interactions with other specialists.

A specialist uses its structured matcher to evaluate the plausibility of its hypothesis at run time. A structured matcher is a collection of simple matchers. A simple matcher returns a confidence value based on the answers provided by the user to its questions. A structured matcher contains rules specifying how to interpret the outcomes of numerous simple matchers to provide one confidence value for the specialist. See the structured matcher web page for more information.

To edit a specialist's structured matcher, click the specialist editor's "Edit Matcher" button. This opens a structured matcher view showing the specialist's default matcher, a simple matcher called relevant. The structured matcher view is shown below.

Double-click the node labeled "relevant" to open its simple matcher view, shown below. The simple matcher is displayed as a table. The table's columns correspond to questions that will be asked of the user at run time. The rows specify the matcher's return value for various answer values. The value in the right-most column provides the simple matcher's return value for the answer values contained in the same table row.

After building your structured matcher, you may test it by clicking its run button. You will be prompted for each of the questions you've defined, and shown the confidence value resulting from your answers. When you are done building the matchers, close the matcher views.

Information about interactions between hypotheses is required to support the task of abductive assembly. The specialist editor allows you to capture this information. To add an interaction, click the "Add" button below the specialist editor's interactions list. This opens the interaction editor, shown below.

An interaction contains three pieces of information: the name of the interacting specialist, the type of interaction, and the strength. Select the name of the interacting specialist from the list widget. It shows all the specialists in the classification hierarchy. Then select one of the four interaction types: IMPLIES, IMPLIESN (implies not), EXPECTS, and EXPECTSN (expects not). For the types EXPECTS and EXPECTSN, the strength expresses the plausibility of the interaction or lack there of. If the interaction type is EXPECTS, the strength is added to the interacting hypothesis' confidence value. If the interaction type is EXPECTSN, the strength is subtracted from the interacting hypothesis' confidence value. The strength is ignored for the types IMPLIES and IMPLIESN because they have infinite strength.

To remove a hypothesis interaction, select the name of the interacting hypothesis from the interactions list and click the "Remove" button.

When you are done editing a specialist, click the specialist editor's "OK" button. The new or modified node appears in the classifier editor's visual hierarchy widget.

The primary persistence mechanism supported by the framework at this point is serialization to the local file system. To save a classifier to disk, select "Save As" from the classifier editor's "Classifier" menu. This opens the file dialog shown below. Select the directory to which you wish to save the file and enter a name for it. Click "OK" and the classifier is written to disk. To open the classifier, select "Open" from the launcher's "Classifier" menu and use the file dialog to locate and open your file.

The "Save To Database" menu item is a prototype for the RMI / JDBC based persistence mechanism developed for CSCI397c24 labs. See the link above for more information about the database persistence mechanism.

A case is the application of a classifier you've developed to a specific problem instance. To build a new case or edit an existing one select "New" or "Open", respectively, from the launcher's "Case" menu. To open an existing case, select and open the file containing the serialized case object using the file dialog that appears. In either case, a case editor like the one shown below opens. Use the editor's text fields to change the case's name or symptoms. In order to evaluate a case, you must associate a classifier with it. To do this, click the case editor's "Choose" button and select a serialized classifier object using the file dialog that appears. The name of the selected classifier appears in the field labeled "Classifier".

To evaluate a case using the specified classifier, select "Evaluate" from the case editor's "Case" menu. This performs the establish-refine operation on the classifier. As each specialist is invoked, it prompts the user for answers to its structured matcher's questions. This operation results in a collection of plausible hypotheses about the case. The results viewer, shown below, displays this collection of hypotheses. The list widget shows the name of each specialist that established along with its confidence value.

Abductive assembly returns the subset of plausible hypotheses that best explains the case. For more information on abduction, follow the links discussed above. To run the abductor, click the results viewer's "Run Abduction" button. This initiates the abductor based on the evaluation results. Behavior of the abduction process can be tuned using the limit menu-button, which limits hypothesis acceptance to certain minimum plausibility. The limits are listed in the order of lesser restrictiveness: confirmed, essential, clear best, weak best, and guessed. For example, if you choose "Essential", hypothesis acceptance will be limited to confirmed and essential hypotheses. Abduction results are displayed in an abduction results viewer, shown below. The viewer displays a textual description of the outcome of the abduction process.