I n t e l l i g e n t I n f o r m a t i o n P r o c e s s i n g

Using JessTab to
Integrate Protégé
and Jess
Henrik Eriksson, Linköping University

D evelopment environments for ontology definition and knowledge modeling

require integration with other types of software—for example, to communicate

with and control external programs. External programs must sometimes control a devel-
Integration with
opment environment. For example, it is often useful to create programs that perform
external systems, such
operations on ontologies or modify a knowledge base
as problem solvers, is in certain ways. We might want to define rules that
trigger actions after matching knowledge base pat-
becoming increasingly terns, or run a problem-solving method and record
the results in a knowledge base. Integrating devel-
important for ontology opment environments with other software is a criti-
cal factor for using these systems in a range of orga-
development and nizations and a key to widespread acceptance of such
environments.
knowledge-modeling Protégé1 is a popular, modular ontology devel-
opment and knowledge acquisition tool. It produces
tools. The author’s output (that is, ontologies and knowledge bases) that
other programs can read. Protégé assumes that the
JessTab extension system’s performance engine runs as a separate pro-
gram, perhaps on a different platform. This separa-
lets you write Jess tion is often advantageous because the development
and runtime environments are different. Neverthe-
programs that manage less, tight integration with the performance engine
is sometimes essential. Currently, we can access
Protégé ontologies and Protégé knowledge bases using Java and an appli-
cation-programming interface, but doing so is time
knowledge bases. consuming.
I built a plug-in called JessTab (www.ida.liu.se/
~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 Pro-
tégé Axiom Language.) By creating a declarative
mapping between these tools’ knowledge represen-
tation 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é frame-
work is the basis for the JessTab integration model
(see Figure 1a). Because Protégé and Jess are imple-
mented 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 exam-
ple, by monitoring Protégé events).
There are several alternative approaches to inte-
grating 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 cou-
pled systems use files to communicate asynchro-
nously. Other systems communicate directly
through network connections (such as TCP/IP
streams, Corba, and remote method invocation).
Tightly coupled systems try to integrate the soft-
ware (for example, by merging source code).

MARCH/APRIL 2003 1094-7167/03/$17.00 © 2003 IEEE 43

Published by the IEEE Computer Society
I n t e l l i g e n t I n f o r m a t i o n
Protégé knowledge
base
Protégé Jess
Jess fact base
(a) (b)
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.
• Integration modeling. There are different
ways to reconcile the knowledge repre-
sentation models that systems use. Chang-
ing or extending them might be necessary.
The models employed by frame- and rule-
based systems are fundamentally different
and are sometimes difficult to bring
together.
• Design considerations. There are several
possible design philosophies for integrat-
ing systems. For example, a minimalist
design tries to make as few changes and
extensions as possible, whereas an ambi-
Figure 2. A Jess console window as a Protégé tab.
44
P r o c e s s i n g
Protégé
JessTab knowledge
functions
base API
Jess engine
(c)
tious approach might try to add function-
ality beyond the original system features.
JessTab integrates the knowledge rep-
resentation 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 them-
selves instances. So, it is sufficient to map
Protégé instances to facts. This mapping
approach fits well with both the Protégé and
computer.org/intelligent
Jess models. It also provides limited back-
ward 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 seam-
less—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 revi-
sions. 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 read-
evaluate-print dialogue and the normal
graphical interaction with Protégé. To make
Jess development in the Protégé environ-
ment 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 meth-
ods 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é knowl-
edge bases; instances represent Jess defi-
nitions, such as rules and functions
IEEE INTELLIGENT SYSTEMS
Mapping Protégé knowledge
bases to Jess facts
A core component of Protégé–Jess inte-
gration 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 exam-
ple, 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 impor-
tant design goal for the JessTab mapping
mechanism is letting Jess rules pattern-
match 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 repre-
senting 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 sim-
plified 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 prop-
erty. The pattern (object (is-a ?) (name “John”))
matches every (mapped) instance that has a
slot name with the value “John.” (The charac-
ter ? 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 con-
tains 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
MARCH/APRIL 2003
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 func-
tion 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 uni-
directional because changes to the Jess fact
list, such as fact assertions, are not propagated
back to the Protégé knowledge base. How-
ever, we can make changes to the knowledge
base from Jess by calling functions that oper-
ate on knowledge base constructs.
Knowledge base operations
from Jess
JessTab provides several functions for
retrieving information from Protégé knowl-
edge bases and for modifying them. Func-
tions exist for getting slot values from
instances, defining new classes, and instan-
tiating classes. Whenever possible, these
functions are compatible with their corre-
sponding 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 cre-
ate a new class and attach slots to it. (Jess
also implements an alternative format for
defclass.2 Advanced developers can use this
computer.org/intelligent
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 creat-
ing 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 oper-
ations on the object in the action part. The is-
a-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 actu-
ally retracts the old fact and asserts a new ver-
sion of it—that is, the fact number changes.
This behavior is normal Jess semantics.
45
I n t e l l i g e n t I n f o r m a t i o n P r o c e s s i n g
Background
Some background information on the current Protégé
implementation (http://protege.stanford.edu), the comple-
mentary Protégé Axiom Language extension, and the Jess
language (http://herzberg.ca.sandia.gov/jess) and its imple-
mentation should help users understand and use the JessTab
implementation.
Protégé
The Protégé tool supports knowledge acquisition and knowl-
edge 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 differ-
ent 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 slot-
widget 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 project-
specific 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 low-
level nature.
The tool has no performance engine, so we must use proce-
dural 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 reason-
ably 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
Creating a second instance adds a new fact f-1 (object (is-a Person) (is-a-name “Person”)
to the Jess list of facts: (OBJECT <External-Address:SimpleInstance>)
(age 21) (name “John”))
Jess> (make-instance sue of Person (name “Sue”) f-4 (object (is-a Person) (is-a-name “Person”)
(age 22)) (OBJECT <External-Address:SimpleInstance>)
<External-Address:SimpleInstance> (age 22) (name “Sue”))
Jess> (facts) For a total of 2 facts.
46 computer.org/intelligent
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
Jess2 is a reimplementation of a subset of Clips3 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 advan-
tage of the Jess API to map information in the Protégé knowl-
edge base to Jess facts and to extend Jess with additional func-
tions 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. 89–123.
2. E.J. Friedman-Hill, Jess in Action: Java Rule-Based Systems,
Manning, 2003.
3. CLIPS Reference Manual, Software Technology Branch, Lyndon B.
Johnson Space Center, NASA, 1991.
Because the mapping of the class Person is
reactive, JessTab asserts a new fact automat-
ically when we create a new instance.
We can now write a Jess rule that pattern-
matches on the facts. The following rule
prints the name for every person age 21 or
older:
IEEE INTELLIGENT SYSTEMS
 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 that they let us define behavior for instances.
Jess>
This rule format lets us write rules that per-
form 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 rea-
soning tasks, such as asserting new facts and
making changes to slot values. Note that the
rules’ format is similar to the Clips rule for-
mat for pattern matching on objects.
To actively modify the knowledge base, we
need functions for accessing and modifying val-
ues in Protégé. The functions slot-get and slot-set
let us retrieve and change slot values, respec-
tively. 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 <class-
name> <slot-name> <facet-name> <new-value>) to
access the facets.
Message handlers and methods
Object-oriented programming is some-
times 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 inheri-
tance model and dispatch model as Clips. For
example, the message handler
MARCH/APRIL 2003
(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
However, the method dispatcher can consider
several parameters, and the methods can over-
load 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 Pro-
tégé object models. Although the Clips legacy
facilitates the Protégé and Jess integration, it
results in somewhat inconsistent functional-
ity and syntax. For example, the naming of
certain functions, such as get-defclass-list and class-
subclasses, is inconsistent. Complete source
code compatibility was never JessTab’s goal.
The JessTab additions to Jess aim at close
computer.org/intelligent
resemblance to make it easy for Clips devel-
opers 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 ad-
vanced support for metalevel objects.3 For
example, classes are instances of meta-
classes. 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 defin-
ition (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 meta-
classes or other metalevel objects at all.)
JessTab lets Jess programs inspect and mod-
ify ontologies just like instances, which result
in a superior expressive power for rules oper-
ating on the ontology.
Ontology reflection
Jess programs can reflect the structure of
47
I n t e l l i g e n t I n f o r m a t i o n
Protégé ontologies. Functions such as class-
subclasses and class-slots return information about
the ontology’s structure. Programs that ana-
lyze 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 cer-
tain patterns, detecting inconsistencies, and
generating reports.
These basic reflection functions are simi-
lar 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 meta-
class, and every slot has a metaslot. Protégé
users can create custom metaclasses by extend-
ing 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 met-
alevel 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 meta-
level objects is a powerful tool for ontology
management. We can handle classes as reg-
ular instances in Jess and apply functions for
manipulating instances to classes. For exam-
ple, 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 sub-
class 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 “syn-
tactical sugar” for the standard metaclass
instantiation.
Jess can essentially perform all the ontol-
ogy operations available from the Protégé
GUI by manipulating metalevel objects. This
functionality lets us use Jess as a scripting
language for supporting ontology develop-
48
P r o c e s s i n g
ment. For example, such Jess scripts can cre-
ate, 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 interac-
tive 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 defini-
tions—that is, instances of metaclasses—to
facts. The expression (mapclass :STANDARD-CLASS)
maps all classes to facts.
Now we can write Jess rules that pattern-
match 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
computer.org/intelligent
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 ontol-
ogy (or the instances) in rule conclusions.
For example, the following rule changes the
role to abstract for classes that have sub-
classes 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 pro-
gram 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 first-
class citizens.
Definition mirroring
JessTab adds the mirroring of Jess defini-
tions 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 def-
function 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 def-
initions 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 Pro-
té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 func-
tionality lets us write Jess programs that
examine themselves.
IEEE INTELLIGENT SYSTEMS
 Regular instances can refer to Jess defin-
ition 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 defini-
tions 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 reload-
ing 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 Figure 3. Jess system classes in Protégé.
domain experts (by generating knowledge
acquisition tools) to a general tool for ontol-
ogy 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 envi-
ronment by developing custom components.
A practical goal is for JessTab to be a use-
ful tool for projects originating from both the
Protégé and Jess communities. For the Pro-
tégé user, the JessTab extension adds a per-
formance 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 sys-
tem working together is a powerful combina-
tion, and one we can use in several ways. Com-
bining graphical environments and reasoners
is not a new approach. In the mid-1980s,
hybrid tools such as KEE featured graphical
development environments. These tools, how-
ever, 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
Figure 4. A Jess rule as a Protégé instance. This instance represents the rule
development (for example, using Jess to query print-abstract. The instance form serves as a rule editor.
and modify ontologies). There are also recent
tools that have performance counterparts, such
as OntoEdit (which uses Ontobroker4), Web- Defining the requirements for JessTab is taining JessTab is that it combines two sys-
ODE,5 WebOnto,6 and Ontosaurus7 (which not an obvious task. A major technical chal- tems, both of which are under active and
uses Loom). lenge for designing, developing, and main- sometimes experimental development. They

MARCH/APRIL 2003 computer.org/intelligent 49

I n t e l l i g e n t I n f o r m a t i o n
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 design-
ing 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 addi-
tional 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, expert-
system 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 sys-
tems. 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 rea-
soner.) However, we can achieve integration
with systems running in other environments
through Corba or native interfaces. (Exam-
ples of Protégé tabs that take advantage of
this approach are the OntoViz, OIL, and
Flora tabs.) Although appealing, a general-
ized tab for any programming language
beyond a simple console window is difficult
to achieve because of the differences in com-
munication 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 inter-
faces. For example, Jess and JessTab let us use
Protégé for development of software agents.
The Java Agent Development Framework8
(JADE) can communicate with Jess, which in
turn communicates with Protégé using
JessTab. Using this approach, you can get Pro-
tégé ontology support for JADE agents by
using Jess rules. Jess rules can create Protégé
instances based on messages from agents. Fur-
thermore, 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 frame-
work (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.
50
P r o c e s s i n g
The current users of JessTab range from
ontology maintainers to agent-based systems
developers. For example, developers use
JessTab for Web data mining, medical advi-
sory systems, and implementation of problem-
solving 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-tai-
lored plug-ins. Some developers use Protégé
and Jess as rapid-prototyping tools; they pre-
fer reimplementing their production systems
in a different environment (for example, for
interoperability and performance reasons).
T he 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 develop-
ment of the Protégé–Jess integration. Exam-
ples of such potential integration projects are
the representation of Jess problem solvers in
ontologies and detailed modeling of Jess def-
initions (such as rules) in knowledge bases.
Furthermore, the JessTab approach is a road
map for integrating Protégé and other perfor-
mance 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 valu-
able insights in the problem of transferring infor-
mation from Protégé and Jess via Java. Vinnova
supported this work in part under grant 2002-
00907, project P22454-1A.
References
1. J.H. Gennari et al., “The Evolution of Protege:
An Environment for Knowledge-Based Sys-
computer.org/intelligent
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 sci-
ence from Linköping
University. His research
interests include knowl-
edge-based systems,
knowledge acquisition, reusable problem-solv-
ing methods, the Semantic Web, medical infor-
matics, and ubiquitous computing. Contact him
at the Dept. of Computer and Information Sci-
ence, Linköping Univ., S-581 83 Linköping,
Sweden; her@ida.liu.se.
tems Development,” Int’l J. Human–Computer
Studies, vol. 58, no. 1, 2003, pp. 89–123.
2. E.J. Friedman-Hill, Jess in Action: Java Rule-
Based Systems, Manning, 2003.
3. H. Eriksson et al., “Automatic Generation of
Ontology Editors,” Proc. 12th Workshop
Knowledge Acquisition, Modeling, and Man-
agement, Univ. Calgary, 1999, pp. 4.6.1–4.6.20.
4. S. Decker, “Ontobroker: Ontology Based
Access to Distributed and Semi-structured Infor-
mation,” Proc. DS-8: Semantic Issues in Multi-
media Systems, Kluwer, 1999, pp. 351–369.
5. 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. 6–13.
6. E. Motta, S. Buckingham Shum, and J.
Domingue, “Ontology-Driven Document
Enrichment: Principles, Tools and Applica-
tions, Int’l J. Human–Computer Studies, vol.
52, no. 6, 2000, pp. 1071–1109.
7. 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.
32.1–32.19; http://ksi.cpsc.ucalgary.ca/KAW/
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,” Soft-
ware: Practice and Experience, vol. 31, no.
2, 2001, pp. 103–128.
9. T. Berners-Lee, J. Hendler, and O. Lassila,
“The Semantic Web,” Scientific American,
vol. 284, no. 5, May 2001, pp. 34–44.
For more information on this or any other com-
puting topic, visit our Digital Library at http://
computer.org/publications/dlib.
IEEE INTELLIGENT SYSTEMS