Exercise #2: Building and Using an Ontology (in Protégé w/JessTab)

Due Thurs, Jan 20th, 9am

Now that you've built an initial (toy) ontology, this next assignment explores what might happen when you combine a frame-based ontology with a rule-based engine. There are several ways to do this; the recommended implementation method is via the Jess tab. Please see the documentation available at the Protégé plug-in library (see the "inference and reasoning" section) and Jess Rule Engine web pages. However, since I know the developer of the Jess plug-in (I worked with Henrik from '92-'95), please see separate email for installation instructions and access to the improved, beta version of this plug-in. As a legal note, please be aware that the Jess system is not "freeware" nor open source. Instead, it is free only for academic use -- it is a violation of the license for you to use Jess for purposes outside of the University.

Your goal in this second assignment is to build a toy rule-based system using a Protege knowledge base. You may use the knowledge base you developed in assignment #1, or you may create a new knowledge base of your choosing (you may select any knowledge domain within BHI -- biology, medicine or public health). As you might see from the Jess pages, Jess is a forward-chaining rule engine in the style of a production system. Thus, the most straightforward way to accomplish this goal is to build a forward-chaining system that adds information or provides feedback on some set of Protege instances.

As a debugging hint, although you should store your Jess-rules as part of the Protege knowledge base, it will probably also be useful to create a separate text file of Jess commands to load. There are several ways to load such a file; one method is via the Jess command "(batch <filename>)".

It is not a requirement that you use Jess as your rule engine; an alternative is Algernon, which also has a rudimentary tab plug-in for Protege. Algernon's advantage is that it explicitly supports either forward or backward chaining. You may also choose some other rule engine; however, I will expect a bit more in the way of documentation if you choose a system that I am less familiar with.

Constraints:

1. You must use both a Protégé knowledge base (classes and/or instances) and a set of rules (algernon or Jess)
2. You must have at least one example of cascading rules -- rules that invoke other rules in some manner. I would recommend using Jess forward-chaining, but a backward-chaining approach is also possible.
3. You must have at least 10 rules.
4. You must provide some form of documentation for your rules and goals. The documentation may be in a separate document, or it may be embedded within the rules themselves. If you create a new ontology for this assignment, you should also provide some explanation for your ontology.

There are no contraints on what sort of rules you build or what sort of behavior you expect your rules to implement. From class, you might know that some behaviors would be question-answering, or constraint checking, or perhaps automatically filling-in parts of your ontology.

Be aware that Jess can be used as a full-fledged programming language. It is certainly acceptable for you to build functions and procedures in Jess that you would like to invoke to demonstrate some sort of fancy behavior. However, you may not use functions instead of rules -- constraint #3 still applies.

Deliverables:

1. A Protégé ontology (usually a set of three files -- .pont, .pprj and .pins). Please either email these to me, or make them available at a web site for download. The latter is prefereble if the files are large. If you use Jess, this ontology should include your rules and any supporting Jess-objects (look under :system class, under :jess-definitions).
2. A text file with your rules (and/or functions)
3. Some documentation that explains your rules, your expected functionality (e.g. a use-case), and your ontology. Please keep this relatively brief (less than 2 pages).

Grading criteria:

For this assignment, I will grade based in part on the "interesting-ness" of your rule-based system. In one week, I'm not expecting rule-based systems that are very sophisticated, but your system should effectively demonstrate some aspect of rule-based systems. Obviously, as a toy system, you will have to make simplifying assumptions about the world. However, I would prefer systems that attempt to be more "real-world": ones that make fewer assumptions, or more "reasonable" assumptions. Thus, it is good if you can find a domain that is particularly well-suited for a rule-based system. Similarly, it would be more interesting to see a set of rules that are rich (interconnected) and/or are plausibly useful in the real world.

To receive a passing grade (3.0), your system must run successfully and must meet the constraints. The subjective stuff in the prior paragraph is what I will look for to give grades from 3.3 to 4.0.