Development environments for ontology definition and knowledge modeling

Transcription

1 Using JessTab to Integrate Protégé and Jess Henrik Eriksson, Linköping University Development environments for ontology definition and knowledge modeling require integration with other types of software for example, to communicate Integration with external systems, such as problem solvers, is becoming increasingly important for ontology development and knowledge-modeling tools. The author s JessTab extension lets you write Jess programs that manage Protégé ontologies and knowledge bases. with and control external programs. External programs must sometimes control a development environment. For example, it is often useful to create programs that perform operations on ontologies or modify a knowledge base in certain ways. We might want to define rules that trigger actions after matching knowledge base patterns, or run a problem-solving method and record the results in a knowledge base. Integrating development environments with other software is a critical factor for using these systems in a range of organizations and a key to widespread acceptance of such environments. Protégé 1 is a popular, modular ontology development and knowledge acquisition tool. It produces output (that is, ontologies and knowledge bases) that other programs can read. Protégé assumes that the system s performance engine runs as a separate program, perhaps on a different platform. This separation is often advantageous because the development and runtime environments are different. Nevertheless, tight integration with the performance engine is sometimes essential. Currently, we can access Protégé knowledge bases using Java and an application-programming interface, but doing so is time consuming. I built a plug-in called JessTab ( ~her/jesstab), which integrates Protégé with Jess, a light, fast rule engine and scripting environment. (See the Background sidebar on page 46 for more detailed information on Jess, Protégé, and the Protégé Axiom Language.) By creating a declarative mapping between these tools knowledge representation schemes, JessTab lets us build knowledge bases in Protégé that work with Jess programs and rule bases. JessTab can also propagate modifications automatically to mapped Protégé instances on Jess. JessTab integration model A Jess engine running inside the Protégé framework is the basis for the JessTab integration model (see Figure 1a). Because Protégé and Jess are implemented in Java, we can run them together in a single Java virtual machine. This approach lets us use Jess as an interactive tool for manipulating Protégé ontologies and knowledge bases. Furthermore, we can propagate changes in Protégé to Jess (for example, by monitoring Protégé events). There are several alternative approaches to integrating systems such as Protégé and Jess. The main considerations are as follows: Information transfer. We can transfer information between systems in different ways. Loosely coupled systems use files to communicate asynchronously. Other systems communicate directly through network connections (such as TCP/IP streams, Corba, and remote method invocation). Tightly coupled systems try to integrate the software (for example, by merging source code). MARCH/APRIL /03/$ IEEE 43 Published by the IEEE Computer Society

2 Protégé (a) Jess (b) Protégé knowledge base Jess fact base JessTab functions Jess engine (c) Protégé knowledge base API Figure 1. Aspects of the JessTab integration model. (a) The Jess engine runs as a Protégé plug-in. (b) JessTab maps instances of the Protégé knowledge base to Jess facts. (c) JessTab provides functions for managing Protégé knowledge bases. Figure 2. A Jess console window as a Protégé tab. Integration modeling. There are different ways to reconcile the knowledge representation models that systems use. Changing or extending them might be necessary. The models employed by frame- and rulebased systems are fundamentally different and are sometimes difficult to bring together. Design considerations. There are several possible design philosophies for integrating systems. For example, a minimalist design tries to make as few changes and extensions as possible, whereas an ambitious approach might try to add functionality beyond the original system features. JessTab integrates the knowledge representation models by mapping Protégé instances to Jess facts (see Figure 1b). This representation of instances as facts in Jess lets us effectively write Jess rules that match instance patterns. In the Protégé frame model, classes, slots, and facets are themselves instances. So, it is sufficient to map Protégé instances to facts. This mapping approach fits well with both the Protégé and Jess models. It also provides limited backward compatibility with Clips, which is a predecessor of Jess implemented in C, because Jess rules can match resulting facts in the same manner Clips rules match objects (see the sidebar for more information). The design philosophy behind JessTab is to make the use of Protégé and Jess seamless that is, the systems should appear tightly integrated to users. However, our goal is not to integrate their source code, because that is impractical: the Protégé and Jess implementers are actively developing their systems and releasing major and minor revisions. The JessTab distribution is a plug-in (Java archive, jar, file) to both Protégé and Jess, which works with a range of Protégé and Jess versions. JessTab does not modify Protégé or Jess. In addition to the mapping between the representation models, JessTab provides a set of additional Jess functions for managing ontologies and knowledge bases (see Figure 1c). JessTab also adds graphical tools to make rapid editing of Jess programs in Protégé easy. JessTab implementation JessTab provides a Jess console window in the Protégé environment (see Figure 2). We can easily switch between the Jess readevaluate-print dialogue and the normal graphical interaction with Protégé. To make Jess development in the Protégé environment easier, JessTab implements graphical inspectors for Jess facts and definitions (rules, functions, defglobals, deftemplates, and deffacts). These inspectors facilitate Jess code navigation and definition editing. In addition to the graphical tools, JessTab extends Jess and Protégé functionality in five areas: It Provides the two functions mapclass and mapinstance that map Protégé knowledge bases consisting of instances to facts in the Jess fact list Adds several functions to Jess that let Jess programs query and manipulate Protégé knowledge bases Implements message handlers and methods for the Protégé frame system, with functionality similar to corresponding Clips features Adds functions that examine and modify the Protégé ontology Mirrors Jess definitions in Protégé knowledge bases; instances represent Jess definitions, such as rules and functions 44 computer.org/intelligent IEEE INTELLIGENT SYSTEMS

3 Mapping Protégé knowledge bases to Jess facts A core component of Protégé Jess integration is the mapping mechanism. This approach makes it possible to mark classes in the ontology for mapping to Jess facts. By using the expression (mapclass <class-name>),we can map all instances of the specified class to Jess facts. The mapclass expression applies to direct and indirect instances for example, instances of subclasses. An alternative to the class-mapping mechanism is to map a specific instance to a fact through the expression (mapinstance <instance>). An important design goal for the JessTab mapping mechanism is letting Jess rules patternmatch on mapped instances. We can then write rules that fire when the appropriate conditions in the Protégé knowledge base are met. For example, mapping the class Person, which has a single instance representing John, age 20, results in a Jess fact with the format (object (is-a Person) (name John ) (age 20)). This fact represents the instance with its slot values for name and age. (I simplified the fact in this example for clarity; the actual fact holds additional information about the instance.) JessTab asserts facts based on a certain pattern (template). The pattern starts with object and always contains the class name and a direct reference to the Protégé object. As the example shows, the instance s slot value pairs are also part of the fact. The mapping mechanism asserts a fact for every instance (of a mapped class). Creating a new instance of the class Person, for example, will result in the assertion of a new fact matching the instance. The motivation for designing this type of mapping to facts is that it lets us define Jess rules that pattern-match on mapped instances in many ways. For example, we can write rules that match instances regardless of their class by using a wild card for the is-a property. The pattern (object (is-a?) (name John )) matches every (mapped) instance that has a slot name with the value John. (The character? represents a wild card in patterns.) In addition to wild-card matching, it is often useful to define rules that match instances of several alternative classes. The mapping ensures that the is-a fact slot contains the unique class name for the instance (as a Jess atom). Fortunately, Jess provides a rich language for rule patterns, which lets us express classes that match in several ways. One approach is to match several alternative classes by enumerating them explicitly. For example, the pattern (object (is-a Person Customer Employee)) matches instances of the Person, Customer, and Employee classes. This type of pattern is especially useful if we want to identify classes in different parts of the ontology. An alternative approach to multiclass matching is to use an expression to define the matching classes. We can use the function superclassp to test if a class is indeed another class s superclass. We can then use rule patterns that match direct and indirect instances of a class for example, (object (is-a Person?c&:(superclassp Person?c)) (name John )). In this case, Jess binds?c to the class name and calls the superclassp function. The motivation for designing this type of mapping to facts is that it lets us define Jess rules that pattern-match on mapped instances in many ways. Mapping from instances to facts is unidirectional because changes to the Jess fact list, such as fact assertions, are not propagated back to the Protégé knowledge base. However, we can make changes to the knowledge base from Jess by calling functions that operate on knowledge base constructs. Knowledge base operations from Jess JessTab provides several functions for retrieving information from Protégé knowledge bases and for modifying them. Functions exist for getting slot values from instances, defining new classes, and instantiating classes. Whenever possible, these functions are compatible with their corresponding Clips counterparts (if any). How can we use JessTab to create Protégé classes and instances from Jess? Just as in Clips, we can use the defclass construct to create a new class and attach slots to it. (Jess also implements an alternative format for defclass. 2 Advanced developers can use this format to specify communication with native Java classes.) The make-instance function lets us create an instance of a specified class in the knowledge base and, optionally, provide initial slot values for it. Using defclass and make-instance, we can experiment with creating instances and then map them to facts. The following example illustrates how we create a Person class and a person instance named John: Jess> (defclass Person (is-a :THING) (slot name (type string)) (slot age (type integer))) TRUE Jess> (make-instance john of Person (name John ) (age 20)) <External-Address:SimpleInstance> Jess> (mapclass Person) Person The mapclass expression marks the Person class as mapped, and it will assert facts of the instances (direct and indirect) of Person. After the mapclass operation, we can check the resulting Jess fact: Jess> (facts) f-0 (object (is-a Person) (is-a-name Person ) (OBJECT <External-Address:SimpleInstance>) (age 20) (name John )) For a total of 1 facts. This fact represents the instance of the class Person we created. In addition to the class name and the slot value pairs, the fact contains a reference to the actual Protégé instance (the Java object representing it). This reference is useful when defining rules that perform operations on the object in the action part. The isa-name value is a string version of the class name, which is useful in some rule patterns. Because the class Person is marked as mapped, changing a Protégé slot value results in a change of the corresponding fact. We use the slot-set function to change the age to 21: Jess> (slot-set john age 21) Jess> (facts) f-1 (object (is-a Person) (is-a-name Person ) (OBJECT <External-Address:SimpleInstance>) (age 21) (name John )) For a total of 1 facts. When we change a fact property, Jess actually retracts the old fact and asserts a new version of it that is, the fact number changes. This behavior is normal Jess semantics. MARCH/APRIL 2003 computer.org/intelligent 45

4 Background Some background information on the current Protégé implementation ( the complementary Protégé Axiom Language extension, and the Jess language ( and its implementation should help users understand and use the JessTab implementation. Protégé The Protégé tool supports knowledge acquisition and knowledge base development. 1 It is a powerful development and knowledge-modeling tool with an open architecture. Protégé includes an ontology editor and a system for generating and custom-tailoring forms for data entry by domain specialists. The user interface consists of several tabs that provide different views of the knowledge base. For example, tabs exist for ontology editing, form layout, knowledge entry, and knowledge base search. Protégé is implemented as an open-source Java application. An important feature of Protégé is the possibility to extend its functionality through plug-in modules. By defining slotwidget plug-ins, we can extend the functionality of data entry widgets (for example, by implementing new interaction modes). The mechanism for tab-widget plug-ins lets us add new tabs to the Protégé user interface. Developers often use this plug-in application programming interface to implement projectspecific tabs that provide unique views of the knowledge base. The Protégé Java API lets us control the ontology s internal representation. For example, we can create new classes and instances programmatically. Although we can use this API to manage all aspects of the Protégé internal representation, doing so is complicated because of the API s flexible but lowlevel nature. The tool has no performance engine, so we must use procedural Java code to access the API. Protégé Axiom Language PAL is a language for expressing constraints in Protégé knowledge bases. It is based on first-order predicate logic. PAL lets us define constraints that the PAL interpreter can check. Once the knowledge base under development is in a reasonably coherent state, we can invoke the PAL engine to check consistency with respect to the constraints. PAL then reports any constraint violations. PAL is implemented as a tab-widget plug-in to Protégé. The main difference between JessTab and PAL is that JessTab lets us use Jess as a programming language and inference engine. PAL, however, is not a programming language because we cannot use it to define inferences and behaviors. We invoke PAL explicitly to perform constraint checking. The result of this process is a report (rather than a behavior). Unlike Jess, PAL is custom tailored for expressing constraints when checking knowledge bases. Jess and PAL are complementary languages; we can use PAL to test a knowledge base s integrity, whereas we can use Jess to implement operations on the knowledge base. Because Jess is Turing complete, we can use it to implement custom-tailored constraint checkers and programs that modify the knowledge base. Jess Jess 2 is a reimplementation of a subset of Clips 3 in Java. Jess implements some additional functionality not provided by Clips. Like Clips, reasoning in Jess is based on a list of known facts and a set of rules that try to match on these facts in its fact base. Facts are basically a list of known values, such as (temperature outdoor 25), which represents the value 25 for the temperature at the outdoor location. The rules preconditions are patterns with wild cards and conditional expressions, which match such facts. For example, the pattern (temperature??t&:(>?t 20)) matches temperatures greater than 20, while ignoring the location. Rules can assert new facts when they fire, which in turn could result in other rules firing. Jess uses the Rete algorithm to ensure efficient pattern matching and rule activation. Jess supports mainly forward chaining and, to some extent, backward chaining. Integrating Jess with other Java programs is easy because it has a well-defined API for controlling the reasoning engine from Java. For example, Java programs can send expressions to the Jess engine for evaluation. In addition, we can define new Jess functions in Java. The JessTab implementation takes advantage of the Jess API to map information in the Protégé knowledge base to Jess facts and to extend Jess with additional functions for communication with Protégé. References 1. J.H. Gennari et al., The Evolution of Protege: An Environment for Knowledge-Based Systems Development, Int l J. Human Computer Studies, vol. 58, no. 1, 2003, pp E.J. Friedman-Hill, Jess in Action: Java Rule-Based Systems, Manning, CLIPS Reference Manual, Software Technology Branch, Lyndon B. Johnson Space Center, NASA, Creating a second instance adds a new fact to the Jess list of facts: Jess> (make-instance sue of Person (name Sue ) (age 22)) <External-Address:SimpleInstance> Jess> (facts) f-1 (object (is-a Person) (is-a-name Person ) (OBJECT <External-Address:SimpleInstance>) (age 21) (name John )) f-4 (object (is-a Person) (is-a-name Person ) (OBJECT <External-Address:SimpleInstance>) (age 22) (name Sue )) For a total of 2 facts. Because the mapping of the class Person is reactive, JessTab asserts a new fact automatically when we create a new instance. We can now write a Jess rule that patternmatches on the facts. The following rule prints the name for every person age 21 or older: 46 computer.org/intelligent IEEE INTELLIGENT SYSTEMS

5 Jess> (defrule twentyone (object (is-a Person) (name?n) (age?a&: (>=?a 21))) => (printout t The person?n is 21 or older crlf)) TRUE Jess> (run) The person John is 21 or older The person Sue is 21 or older 2 Jess> This rule format lets us write rules that perform object matching in several different ways. For example, we can write rules with constraints or wildcards for the class name. The action part of the rules can perform reasoning tasks, such as asserting new facts and making changes to slot values. Note that the rules format is similar to the Clips rule format for pattern matching on objects. To actively modify the knowledge base, we need functions for accessing and modifying values in Protégé. The functions slot-get and slot-set let us retrieve and change slot values, respectively. For example, the expression (slot-get sue age) will return the age slot value for the instance sue. The expression (slot-set sue age 23) will set the slot value for age to 23. Continuing this example, we can define a generalized rule that changes the age from 22 to 23 for every person: Jess> (defrule changeage?o <- (object (is-a Person) (age 22)) => (slot-set?o age 23)) TRUE There are also functions for getting and setting facet values (or slot properties). We can use the expressions (facet-get <class-name> <slot-name> <facet-name>) and (facet-set <classname> <slot-name> <facet-name> <new-value>) to access the facets. Message handlers and methods Object-oriented programming is sometimes an alternative or supplement to the rule-based paradigm. JessTab adds support for message passing, message handlers, and generic methods to Jess. You can use the defmessage-handler and defmethod constructs to create object-oriented programs based on Protégé ontologies. Message handlers and methods in JessTab follow the same inheritance model and dispatch model as Clips. For example, the message handler (defmessage-handler Person incrementage (?i) (slot-set?self age (+ (slot-get?self age)?i))) lets us send messages to instances of the Protégé class Person. The expression (send john incrementage 1) sends the incrementage message to the john instance. In this case, the message handler then adds 1 to the value of the slot age of the instance john. Methods are similar to message handlers in that they let us define behavior for instances. However, the method dispatcher can consider several parameters, and the methods can overload existing functions. For example, the method (defmethod >= ((?p Person) (?q Person)) (>= (slot-get?p age) (slot-get?q age))) Although the Clips legacy facilitates the Protégé and Jess integration, it results in somewhat inconsistent functionality and syntax. overloads the built-in Jess function >= and lets us compare Person instances on the basis of their age. You can use expressions such as (>= john sue) to compare people s ages. Hence, the message handlers and methods complement the mapping of instances to facts by providing elements for object-oriented programming. Clips heritage An important consideration for JessTab design is the Clips heritage. JessTab tries to be compatible with Clips whenever possible. In some cases, compatibility is not possible because of differences between Clips and Jess and differences between the Clips and Protégé object models. Although the Clips legacy facilitates the Protégé and Jess integration, it results in somewhat inconsistent functionality and syntax. For example, the naming of certain functions, such as get-defclass-list and classsubclasses, is inconsistent. Complete source code compatibility was never JessTab s goal. The JessTab additions to Jess aim at close resemblance to make it easy for Clips developers to start using Protégé and JessTab and to facilitate porting Clips code. Ontology integration JessTab lets Jess programs integrate with Protégé ontologies. There are several ways in which Jess programs can examine and manipulate ontologies. Let us consider four aspects briefly: Ontology reflection. Jess programs can reflect on the makeup of Protégé ontologies. Built-in functions, such as class-subclasses, can discover an ontology s structure. These functions let us develop Jess programs that analyze ontologies. Metalevel objects. Protégé provides advanced support for metalevel objects. 3 For example, classes are instances of metaclasses. Slots and facets are instances as well. JessTab supports these metalevel objects by letting programs create new classes by instantiating a metaclass (for example, with the make-instance function). Mapping metaclasses. Because classes behave as instances (of a metaclass) in most aspects, we can map them to facts just as regular instances. Thus, by mapping classes to facts, we can apply Jess rules to Protégé classes. For example, we can write rules that pattern-match certain classes in a large ontology and modify them. Definition mirroring. JessTab mirrors Jess definitions in the Protégé ontology. For example, Jess defrules are mirrored as an instance of the system class :JESS-RULE in Protégé. These mirror instances contain a textual representation of the Jess definition (that is, the source code). Thus, Jess programs can examine their own structure by inspecting the mirror instances (for example, by mapping them to facts and applying rules). Furthermore, we can save these mirror instances together with the rest of the knowledge base and reinsert them during reload from files. Metalevel objects in Protégé fit well with Jess. (Note that Clips does not support metaclasses or other metalevel objects at all.) JessTab lets Jess programs inspect and modify ontologies just like instances, which result in a superior expressive power for rules operating on the ontology. Ontology reflection Jess programs can reflect the structure of MARCH/APRIL 2003 computer.org/intelligent 47

6 Protégé ontologies. Functions such as classsubclasses and class-slots return information about the ontology s structure. Programs that analyze ontologies can then use this information to discover ontology properties and to draw conclusions from the ontologies. Examples of such analysis tasks are searching for certain patterns, detecting inconsistencies, and generating reports. These basic reflection functions are similar to the ones Clips provides. In JessTab, however, programmers get direct access to the ontology as it evolves in the editor. In addition to the basic reflection functions, JessTab provides a means for advanced reflection. Metalevel objects Protégé provides advanced support for metalevel objects. 3 Every class has a metaclass, and every slot has a metaslot. Protégé users can create custom metaclasses by extending the standard metaclass (:STANDARD-CLASS). Custom metaclasses can contain additional slots, which result in new class properties and new fields on the class-editor form. The metalevel objects in Protégé are not only useful for extending the ontology editor, they are also the basis for ontology reflection and modification. Examining and manipulating such metalevel objects is a powerful tool for ontology management. We can handle classes as regular instances in Jess and apply functions for manipulating instances to classes. For example, instantiating a metaclass is equivalent to creating a regular class. The expression (make-instance A of :STANDARD-CLASS (:DIRECT-SUPERCLASSES :THING)) creates a new Protégé class A, which is a subclass of :THING. By setting the value of the :DIRECT-TEMPLATE-SLOT slot of the class, we can attach slots to the class. The expression (slot-set A :DIRECT-TEMPLATE-SLOTS (create$ (instance-address :NAME))) sets the slots for the class A. The slot list now consists of the (predefined) slot :NAME. Thus, we can view the defclass function as syntactical sugar for the standard metaclass instantiation. Jess can essentially perform all the ontology operations available from the Protégé GUI by manipulating metalevel objects. This functionality lets us use Jess as a scripting language for supporting ontology development. For example, such Jess scripts can create, modify, and move sets of classes in large ontologies. The major advantages of using Jess over Java are that we can develop and test programs quickly (through the interactive Jess console) and that we can use the Jess rule engine to write declarative programs for managing ontologies. As I mentioned previously, another way of using JessTab is to use it as the basis for a problem solver, which could then operate directly on metalevel objects. Mapping metaclasses The Protégé metaobject model and the Jess- Tab support for handling classes as instances apply to the JessTab mapping functions. Jess- The metalevel objects in Protégé are not only useful for extending the ontology editor, they are also the basis for ontology reflection and modification. Tab can map instances of Protégé metaclasses to facts just as it maps regular instances to facts. This functionality lets us map class definitions that is, instances of metaclasses to facts. The expression (mapclass :STANDARD-CLASS) maps all classes to facts. Now we can write Jess rules that patternmatch metaobject values. For example, the following Jess code prints out all abstract classes in the ontology: Jess> (mapclass :STANDARD-CLASS) :STANDARD-CLASS Jess> (defrule print-abstract (object (:NAME?n) (:ROLE Abstract)) => (printout t?n is abstract. crlf)) TRUE Jess> (run) The left-hand side of this rule matches classes (metaclass instances) where the value of the :ROLE slot is Abstract. In the same way, we can pattern-match other system classes, such as slots and facets, using the same approach. For example, we can print out all slots with a certain value type. Another application is to modify the ontology (or the instances) in rule conclusions. For example, the following rule changes the role to abstract for classes that have subclasses but do not have any instances: Jess> (defrule make-abstract?c <- (object (:NAME?n) (:ROLE Concrete) (:DIRECT-INSTANCES)) (not (object (:NAME?n) (:DIRECT-SUBCLASSES))) => (slot-set?c :ROLE Abstract)) The left-hand side of this rule matches classes where the value of the :ROLE slot is Concrete :DIRECT-INSTANCES slot is an empty list :DIRECT-SUBCLASSES slot is not an empty list Mapping system classes lets the Jess program examine the ontology declaratively through the list of facts rather than function calls such as class-abstractp, slot-get, and facet-get. Protégé s metaobject protocol is suitable for this task because we can view classes, slots, and facets as regular instances and firstclass citizens. Definition mirroring JessTab adds the mirroring of Jess definitions in Protégé ontologies and knowledge bases. This mirroring is a reflective mapping from Jess to Protégé. During initialization, JessTab adds Jess-related system classes to Protégé. Jess constructs such as defrule and deffunction have corresponding system classes (:JESS-RULE, :JESS-FUNCTION, and so on). Figure 3 shows the system classes added by JessTab. Instances of these classes represent actual definitions in Jess. For example, when we define a Jess rule, JessTab will automatically create a corresponding instance of the class :JESS-RULE. Several advantages exist for mirroring Jess definitions in Protégé. Because the instances representing Jess definitions are regular Protégé instances, we can edit them using forms. Figure 4 shows the form for an instance of a Jess rule in Protégé. Furthermore, we can map these instances to Jess facts in the same way we map other instances. Thus, this functionality lets us write Jess programs that examine themselves. 48 computer.org/intelligent IEEE INTELLIGENT SYSTEMS

7 Regular instances can refer to Jess definition instances. For example, a form for knowledge entry in Protégé can refer to a Jess rule or a list of Jess rules. By following the link to the rule instance, the user can edit the rule in the rule-definition field (see Figure 4). Clicking on the Parse! button in the rule editor results in redefinition of the construct in the Jess engine. Another advantage of mirroring definitions is that this approach lets Protégé save the Jess definition instances together with other instances in the knowledge base. Reloading the project will result in reloading these instances into Protégé. Once the Jess definition instances reload, defining them in the Jess engine is possible. Discussion During the course of development, both the user and developer communities broadened Protégé s scope from an environment that mainly supported knowledge acquisition from domain experts (by generating knowledge acquisition tools) to a general tool for ontology and knowledge base development with an open architecture. 1 The advantage of today s Protégé is the combined power of the plug-in components and the ability to tailor the environment by developing custom components. A practical goal is for JessTab to be a useful tool for projects originating from both the Protégé and Jess communities. For the Protégé user, the JessTab extension adds a performance engine to Protégé and support for a declarative mapping between Protégé and Jess. For the Jess developer, JessTab makes it possible to take advantage of Protégé as a graphical development environment and use third-party plug-ins (tabs) added to Protégé. A development tool and a performance system working together is a powerful combination, and one we can use in several ways. Combining graphical environments and reasoners is not a new approach. In the mid-1980s, hybrid tools such as KEE featured graphical development environments. These tools, however, did not have the richness and flexibility of current knowledge-modeling tools, and they lacked the suppleness of the Java-based Jess engine. JessTab lets us use the performance system for ontology and knowledge base development (for example, using Jess to query and modify ontologies). There are also recent tools that have performance counterparts, such as OntoEdit (which uses Ontobroker 4 ), Web- ODE, 5 WebOnto, 6 and Ontosaurus 7 (which uses Loom). Figure 3. Jess system classes in Protégé. Figure 4. A Jess rule as a Protégé instance. This instance represents the rule print-abstract. The instance form serves as a rule editor. Defining the requirements for JessTab is not an obvious task. A major technical challenge for designing, developing, and maintaining JessTab is that it combines two systems, both of which are under active and sometimes experimental development. They MARCH/APRIL 2003 computer.org/intelligent 49

8 are two separate moving targets. In addition to this dynamic software environment, there are emerging user communities. The Jess and Protégé user communities consist mainly of researchers and developers who are designing their own systems. Our goal is to make future JessTab requirement specification and development a community process as much as possible. We welcome requests for additional functionality, and we invite others to extend the system by encouraging source code development. Generalizing the JessTab approach beyond Jess is an interesting prospect. Currently, JessTab serves as an example of how you can integrate programming languages, expertsystem shells, and other performance engines with Protégé. Although the mapping from Protégé instances to facts is Jess-specific, we can mirror structures in Protégé to other systems. From a communication perspective, integrating systems implemented in Java, the same programming language that Protégé uses, is relatively straightforward. (Examples of such integrated Protégé plug-ins are JessTab, PrologTab, and the Algernon reasoner.) However, we can achieve integration with systems running in other environments through Corba or native interfaces. (Examples of Protégé tabs that take advantage of this approach are the OntoViz, OIL, and Flora tabs.) Although appealing, a generalized tab for any programming language beyond a simple console window is difficult to achieve because of the differences in communication and representation formats. One major advantage of the Protégé Jess combination is that we can use other Protégé plug-ins and other Jess extensions and interfaces. For example, Jess and JessTab let us use Protégé for development of software agents. The Java Agent Development Framework 8 (JADE) can communicate with Jess, which in turn communicates with Protégé using JessTab. Using this approach, you can get Protégé ontology support for JADE agents by using Jess rules. Jess rules can create Protégé instances based on messages from agents. Furthermore, Jess rules can create and send agent messages based on the content of Protégé knowledge bases. Another possibility is using Protégé and Jess to develop Semantic Web applications. 9 Protégé supports encoding ontologies in the resource description framework (RDF) format. Thus, Jess can operate on such ontologies through JessTab. Used in this fashion, the Protégé Jess combination is a building block for the Semantic Web. The current users of JessTab range from ontology maintainers to agent-based systems developers. For example, developers use JessTab for Web data mining, medical advisory systems, and implementation of problemsolving methods. Currently, there are several hundred JessTab users, most of whom are researchers and developers working on advanced projects with specific goals. They use Protégé and Jess as building blocks in their systems, and they often extend Protégé and Jess for instance, by developing custom-tailored plug-ins. Some developers use Protégé and Jess as rapid-prototyping tools; they prefer reimplementing their production systems in a different environment (for example, for interoperability and performance reasons). The JessTab project contributes to the understanding of how ontology editors and performance systems can work together. This understanding includes the mapping from the Protégé knowledge representation to the Jess representation and the use of Jess definitions as system classes in Protégé ontologies. In practice, JessTab contributes to the Protégé community by enabling the use of Jess under Protégé. JessTab also supports the Jess community by allowing the use of Protégé as an object-oriented extension to Jess and by providing a tool for using Protégé as a graphical front end to Jess. JessTab is a solid basis for further development of the Protégé Jess integration. Examples of such potential integration projects are the representation of Jess problem solvers in ontologies and detailed modeling of Jess definitions (such as rules) in knowledge bases. Furthermore, the JessTab approach is a road map for integrating Protégé and other performance systems. Acknowledgments The JessTab user community contributed to this article with testing, bug reports, and suggestions for further improvements. Ray Fergerson and Ernest Friedman-Hill provided Protégé and Jess support, respectively. Samson Tu provided valuable insights in the problem of transferring information from Protégé and Jess via Java. Vinnova supported this work in part under grant , project P A. T h e A u t h o r Henrik Eriksson is a professor of computer science at Linköping University. He has a PhD in computer science from Linköping University. His research interests include knowledge-based systems, knowledge acquisition, reusable problem-solving methods, the Semantic Web, medical informatics, and ubiquitous computing. Contact him at the Dept. of Computer and Information Science, Linköping Univ., S Linköping, Sweden; her@ida.liu.se. References 1. J.H. Gennari et al., The Evolution of Protege: An Environment for Knowledge-Based Systems Development, Int l J. Human Computer Studies, vol. 58, no. 1, 2003, pp E.J. Friedman-Hill, Jess in Action: Java Rule- Based Systems, Manning, H. Eriksson et al., Automatic Generation of Ontology Editors, Proc. 12th Workshop Knowledge Acquisition, Modeling, and Management, Univ. Calgary, 1999, pp S. Decker, Ontobroker: Ontology Based Access to Distributed and Semi-structured Information, Proc. DS-8: Semantic Issues in Multimedia Systems, Kluwer, 1999, pp J.C. Arpirez et al., WebODE: A Workbench for Ontological Engineering, Proc. 1st Int l Conf. Knowledge Capture (K-CAP 2001), ACM Press, 2001, pp E. Motta, S. Buckingham Shum, and J. Domingue, Ontology-Driven Document Enrichment: Principles, Tools and Applications, Int l J. Human Computer Studies, vol. 52, no. 6, 2000, pp W. Swartout et al., Toward Distributed Use of Large-Scale Ontologies, Proc. 10th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop, Univ. Calgary, 1996, pp ; KAW96/swartout/Banff_96_final_2.html. 8. F. Bellifemine, A. Poggi, and G. Rimassa, Developing Multi-Agent Systems with a FIPA-Compliant Agent Framework, Software: Practice and Experience, vol. 31, no. 2, 2001, pp T. Berners-Lee, J. Hendler, and O. Lassila, The Semantic Web, Scientific American, vol. 284, no. 5, May 2001, pp For more information on this or any other computing topic, visit our Digital Library at computer.org/publications/dlib. 50 computer.org/intelligent IEEE INTELLIGENT SYSTEMS