Achieving knowledge interoperabi

Dr

Admi

and M

imon F

Surre

d un

d on a

of knowledge sharing between different systems or should

Expert Systems with Applicat

* Corresponding author. Address: School of Interactive Arts and

Technology, Simon Fraser University, Surrey 2400 Central City, 10153Tel.: C1 604 268 7520; fax: C1 604 268 7488.automation of knowledge sharing between different systems becomes increasingly important. One solution might be to extend a knowledge

modeling tool by implementing a set of new classes or functions for importing other knowledge formats (using, e.g. Java, CCC, etc.). But,

this can be a rather difficult and time consuming task. Since XML is now widely accepted as knowledge representation syntax, we believe

that a more suitable solution would be to use eXtensible Stylesheet Language Transformation (XSLT) a W3C standard for transforming

XML documents. A special advantage of this approach is that even though an XSLT is written independently of any programming language,

it can be executed by a program written in almost any up-to-date programming language. We experiment on an XSLT-based infrastructure

for sharing knowledge between three knowledge modeling and acquisition tools that use different conceptual models for knowledge

representation in order to evaluate cons and pros of the proposed XSLT approach. Two of these tools, JessGUI and JavaDON are ongoing

efforts of the GOOD OLD AI research group to develop interoperable development tools for building intelligent systems, while the third one

is Protege-2000, a broadly accepted ontology development tool.

q 2005 Elsevier Ltd. All rights reserved.

Keywords: Interoperability; Knowledge sharing; XML; XSLT

1. Introduction

Development of an intelligent system is rather a difficult

task since it requires not only profound understanding of the

domain problem under study, but also employment of

different knowledge representation techniques and tools.

Those techniques and tools are often based on a variety of

paradigms and technological platforms. There are many

reasons why one should use such a diversity of tools.

Sometimes there is a need to translate a knowledge base

implemented in a traditional intelligent system tool

(e.g. Lisp-like languages and inference engines like

CLIPS (2003) into an object oriented knowledge base

(e.g. OBject Oriented AbstractionOBOA (Devedzic &

Radovic, 1999)). Similarly, in some cases the knowledge

representation techniques (e.g. rules and frames) used in a

developed intelligent system are not expressive enough and

there is a need for some other representation techniques (e.g.

fuzzy rules (Sendelj & Devedzic, 2004)) that would give a

more appropriate solution. Furthermore, substituting older

technologies with the new ones is another important reason

why exchange of knowledge bases between different

systems should be seriously considered. In this context

one question raises naturally: Can we automate the processJelena Jovanovica,

aGOOD OLD AI Research Group, FONSchool of Business

11000 Belgrade, SerbiabSchool of Interactive Arts and Technology, S

10153 King George Hwy,

Abstract

Development of an intelligent system requires not only profoun

different knowledge representation techniques and tools often baselity: An XML/XSLT approach

agan Gasevicb,*,1

nistration, University of Belgrade, POB 52, Jove Ilica 154,

ontenegro, Yugoslavia

raser University, Surrey 2400 Central City,

y, BC, Canada V3T 2W1

derstanding of the problem under study, but also employment of

variety of paradigms and technological platforms. In this context

ions 29 (2005) 535553

www.elsevier.com/locate/eswaintelligent systems?

It is obvious that there is a need for sharing knowledge.

This issue was noted in the paper (Neches et al., 1991)

where the authors stressed the need for creating interoper-

able knowledge bases. The key unit for achieving such0957-4174/$ - see front matter q 2005 Elsevier Ltd. All rights reserved.

doi:10.1016/j.eswa.2005.04.024

E-mail addresses: Jelijov@fon.bg.ac.yu (J. Jovanovic), dgasevic@

acm.org (D. Gasevic).1we always develop a new knowledge base, starting from the

scratch, every time we change the tool we use for buildingKing George Hwy, Surrey, BC, Canada V3T 2W1. Tel.: C1 604 268 7520;

fax: C1 604 268 7488.

tems wa goal is a domain ontology, as a formal description of the

shared conceptualization of a certain domain (Gruber,

1993). Ontology encapsulates semantics of a certain domain

and can be interchanged between intelligent systems that

use different languages (i.e. syntax). For example, Gruber

(1993) proposed the Frame ontology, that can be regarded as

an ontology about ontologies (i.e. meta-ontology), or as an

ontology language. This language uses Lisp-like syntax

closely related to the Propositional and First Order Logics

(FOL). Note that Knowledge Interchange Format (KIF) uses

the similar syntax. The main problem with this kind of

syntax is that one needs to develop a tool (i.e. a converter)

for transforming a knowledge base from some of these

languages into a new knowledge representation.

eXtensible Markup Language (XML) is a suitable

solution for this problem as this language enables syntax

interoperability (Bergholz, 2000). XML provides a common

way for defining other markup languages through two

mechanisms: Document Type Definitions (DTD) and XML

Schema. A special advantage of XML is standard

Application Programming Interfaces (APIs) for parsing

XML documents, so XML users do not have to develop their

own parsers for the specific XML formats they use.

Currently, there are several approaches that propose XML

as the common syntax for sharing knowledge. For example,

Leff (2001) developed Jess User Functions that load XML

documents and convert their Document Object Model

(DOM) tree into series of facts that can be consumed by

Java Expert System Shell (Jess, see Section 2.2). We

developed an XML Schema for representing Jess knowl-

edge bases (Jovanovic, Gasevic, & Devedzic, 2004).

JessGUI (a graphical development tool for building Jess-

based knowledge bases, see Section 2.2) produces XML

documents written in accordance to that XML Schema.

Further, note that the Semantic Web initiative (Berners-Lee,

Hendler, & Lassila, 2001) employs XML for sharing

ontologies. For example, standard Semantic Web languages

Web Ontology Language (OWL) (Bechhofer et al., 2004)

and Resource Description Framework (Schema)RDF(S)

(Brickley & Guha, 2004) have their own XML bindings.

Whats more, there are two attempts to define an XML-

based Semantic Web language for sharing rules: The Rule

Markup Initiative (http://www.dfki.uni-kl.de/ruleml/)

whose mission is to define a shared Rule Markup Language

(RuleML); and The eXtensible Rule Markup Language, or

XRML, that enables identification of implicit rules

embedded within Web pages, their interchange with

structured-format rule-based systems, as well as accessing

these rules from different applications (Lee & Sohn, 2003).

Even with all these XML-based proposals we have not

yet managed to solve all problems of knowledge interoper-

ability. For example, a problem might arise if one wants to

import an XML-based knowledge base created by JessGUI

tool (see Section 2.2) into an ontology editor (e.g. Protege)

as the ontology editor does not recognize this XML format.

J. Jovanovic, D. Gasevic / Expert Sys536This issue can be overcome by extending the target tool(i.e. the ontology editor). A conventional approach would be

to implement the converter employing the programming

language that the tool was originally written in. That means,

programming either a set of new classes or functions for

importing the source format into the target tool (e.g. Java, C/

CCC, Perl, etc.). But, this can be a rather difficult taskespecially when the target tool is a complex software

platform (e.g. Jess, Protege, etc.). We believe that a more

suitable solution would be to develop a converter tool that

would transform the source format into the target one. In

that case we would not need to learn about implementation

details of the target tool (usually a time-consuming task),

instead we would only have to concentrate on the target

format.

However, the converter does not have to be implemented

using a conventional programming language, instead we can

use a language that supports transformations between

knowledge formats. As we are discussing XML-based

knowledge sharing it is reasonable to propose eXtensible

Stylesheet Language Transformation (XSLT) a W3C

standard for transforming XML documents into either

other XML documents or regular text documents (Clark,

1999). A special advantage of this approach is that even

though we write an XSLT independently of any program-

ming language, it can be executed by a program written in

almost any up-to-date programming language. As XSLT is

invented with the idea to be used for transforming XML

documents, it is a suitable solution in terms of the time

needed to develop a transformation.

In this paper we explore the use of XSLT for

transforming different XML-based knowledge bases.

Since there are a lot of different knowledge models (KMs)

we decided to limit our work on four of them: a KM

proposed in OBOAan object oriented framework for

building knowledge bases (Devedzic & Radovic, 1999); a

KM that Jessa popular Java-implemented rule-based

expert system shellis based on; and KMs of two ontology

languages: OWL and RDF(S). Accordingly, we discuss

interoperability in the context of three tools that use one of

the four chosen types of KMs: JavaDON based on OBOA

KM, JessGUI founded on Jess KM and Protege that supports

both RDF(S) and OWL KM. The first two tools and their

accompanying KMs were chosen because they are current

results of two parallel ongoing projects of our GOOD OLD

AI research group and we know their internal structure and

underlying models in detail. More precisely, the former one

resulted from our research effort to develop a knowledge

acquisition tool for building intelligent systems, while the

latter one resulted from the similar effort to enhance features

of Jess. Ontology languages RDF(S) and OWL were

selected as they are official W3C recommendation for the

Semantic Web languages and the concept of the Semantic

Web is becoming increasingly important for the further

development of todays Web. Our approach is based on

using several XSLTs to implement mappings between the

ith Applications 29 (2005) 535553XML formats of the KMs under study. The main goal is to

explore XSLTs capacity to implement mappings between

different KMs. If it proves capable of such a task on this

sample of KMs, it would be reasonable to continue research

in the same direction and consider this approach in context

of other KMs and tools. However, if it proves inappropriate,

we would have to explore reasons behind that inappropri-

ateness and search for an alternative approach.

The paper is organized as follows. In Section 2 we briefly

present KMs and tools that we chose to focus on: OBOA

KM and JavaDON tool, Jess KM and JessGUI tool as well

as OWL and RDF(S) KMs. Section 3 gives an overview of

XSLT as an XML-based technology solution for knowledge

sharing. Section 4 presents an XSLT-based infrastructure

that we propose for achieving interoperability of different

knowledge modeling and acquisition tools. In Section 5 we

deal with relevant implementation issues of the developed

XML Schemas and XSLTs. Section 6 discusses the

present OBOA model that served as the basis for JavaDON

Finally, we give an overview of two Semantic Web standard

ontology languages: RDF(S) and OWL.

2.1. OBOA

Devedzic & Radovic (1999) have proposed a framework

for building intelligent systemsOBject Oriented Abstrac-

tion (OBOA). The OBOA is a multi-layered framework that

incorporates a number of techniques for representing

knowledge in intelligent systems. It is in fact an object-

oriented knowledge base model for building intelligent

systems. According to this model, knowledge of an

intelligent system comprises of three interconnected

components: domain knowledge, control knowledge and

explanatory knowledge. OBOA is primarily concerned with

the domain knowledge component, and treats it from the

conceptual level, i.e. without commitment to any specific

k

Kn

R

J. Jovanovic, D. Gasevic / Expert Systems with Applications 29 (2005) 535553 537toolan ongoing effort of a few members of our research

group to develop a knowledge acquisition tool for building

intelligent systems. Next, we discuss JessJava Expert

System Shelland the conceptual model it uses for

modeling knowledge. We also briefly present JessGUIa

graphical development environment built on top of the Jess.

Chun

DomainKnowledge

KnowledgeElements

1..*1..*

0..*0..*

Frames

0..*

Rules0..*

0..*0..*proposed solutions whereas Section 7 stresses some related

work on transforming different knowledge representation

formats as well as identifies some related solutions in other

application domains (i.e. software engineering). Section 8

summarizes the paper and indicates further directions of our

research in this area.

2. A diversity of knowledge representation platforms

and tools

In this section we discuss four conceptual models for

representing knowledge in intelligent systems. First, weFig. 1. Organization of domaiimplementation. The original model uses Boochs (1994)

notation, but since this notation could make the model

difficult to comprehend, we decided to use UML (Booch,

Rumbaugh, & Jacobson, 1998) notation.

Organization of domain knowledge is represented with the

Class diagram shown in Fig. 1. Knowledge of an intelligent

system is organized into n homogeneous collections of

different knowledge elements (KnowledgeElements).

Elements of those collections are represented with appropriate

classes derived from the abstract KnowledgeElement class. A

KnowledgeElement represents an abstract knowledge element

type and acts as the root class for all concrete knowledge

elements types, both simple (Attribute, Relation, Slot, Value,

Chunk) and complex (Frame, Rule). That way, operations

common for all elements of a knowledge base can be accessed

through the interface of the KnowledgeElement class. It should

be noted that Chunk is another abstract class whose

subclasses (e.g. OARV (Object-Attribute-Relation-Value),

Action, Picture) are used as building blocks for composition

of complex knowledge elements.

Attribute

Relation

Slot

Value

owledgeElement

Frame

ulen knowledge in OBOA.

further inferential-transformational tasks (Boley,

2.2

(Fr

ha

ess

CL

a l

the

backward chaining is supported as well.

set

can

as

ele

or

ele

tems wJess is a simple, yet powerful enough tool to allow for

building a number of industry-strength ES applications

(Fikes, Hayes, & Horrocks, 2003). Its major advantage is its

capability to easily integrate with other Java programs

through its well-defined API for controlling the reasoning

engine from Java (Eriksson, 2003). Java programs can send

expressions to the Jess inference engine for evaluation, and

it is easy to extend Jess with new functions in Java because it

is an open-source freeware. In addition, Jess implements

some additional functionality not originally provided by

CLIPS.

However, Jess lacks a GUI. We have ventured into aninfR&del.

. Jess/JessGUI

In recent years, Java Expert System Shell, or Jess

iedman-Hill, 2003; Sandia National Laboratories, 2003)

s become a popular development tool for ES. Jess is

entially a reimplementation of a subset of the earlier

IPS shell (CLIPS, 2003) in Java. Its reasoning is based on

ist of known facts and a set of rules that try to match on

se facts in its fact base. Rule-based reasoning of Jess

erence engine is mostly Rete-based forward chaining, buttoo

mo2003).

2. Inference mechanism, in the form of both forward and

backward chaining.

It should be noted that the current version of JavaDON

l covers only a small fraction of the OBOA conceptualThe first intelligent system based on OBOA model

was DON (Radovic, 1996) implemented in CCC.Another implementation is JavaDONour ongoing

research effort to create an OBOA-based platform for

development of intelligent systems. Java was chosen as

implementation language due to its platform indepen-

dence as well as our intent to enable seamless integration

of JavaDON with other intelligent software tools, the

majority of which are Java-based. JavaDON has capacity

to build rule and frame-based intelligent systems. It even

extends functionalities of the original OBOA model by

introducing:

1. OBOA XML bindingknowledge base developed

using JavaDON is saved in XML format compliant

to the predefined XML Schema (see Section 5.2).

Furthermore, procedural knowledge, represented in the

form of rules, can be saved in Rule Markup Language

(RuleML) formatan ongoing effort of The Rule

Markup Initiative (http://www.dfki.uni-kl.de/ruleml/)

to define a shared language (RuleML), that would

permit both forward (bottomup) and backward (top

down) rules in XML for deduction, rewriting, and

J. Jovanovic, D. Gasevic / Expert Sys538D project of designing and developing a GUI for Jess,We also monitor recent efforts related to integrating Jess

with other development environments, as well as contri-

butions of other research groups to the evolution of Jess

itself. The most notable recent work in that direction is

presented by Eriksson (2003). He has developed a plug-in

called JessTab (www.ida.liu.se/~her/JessTab), which inte-

grates Jess with Protege-2000, a popular, modular ontology

development and knowledge acquisition tool developed at

Stanford University (http://protege.stanford.edu/). JessTab

enables a Jess engine to run inside the Protege-2000

framework and lets users build knowledge bases inknoProting and getting attribute values.

A knowledge base consists of one or more Moduls that

be regarded as logical units of knowledge elements such

Rules, Facts, Deffacts (a group of facts), etc. The Frame

ment serves as a template for facts and it consists of one

more Slots that hold appropriate Values. The Query

ment, as it name suggests, facilitates querying the

wledge base.clucalled JessGUI, suitable for all platforms that support Java

Virtual Machine. JessGUI v. 1.0 is now complete (http://iis.

fon.bg.ac.yu/JessGUI/home.html), and is already used in

practical projects and as a teaching tool (Bergholz, 2000).

The main idea of the JessGUI project was to develop a

GUI for Jess ES Shell that would make this ES development

environment more user-friendly and much easier to work

with, hence enlarging the number of its potential users.

Important advantages of the new user interface in

comparison with the existing one are the following:

1. Interaction and dialogs using familiar graphical elements

instead of plain command promptJessGUI enables

users to work with graphical objects (widgets), typical

for modern user interfaces (JessGUI design was based on

the layout of Protege-2000s GUI (Freedman-Noy et al.,

2001). It is much more convenient and less time-

consuming then typing complicated constructs at the

command prompt.

2. Users need only the knowledge of the basic Jess concepts

instead of the complete syntax of the CLIPS language

JessGUI offers an alternative to learning complex

structures that are part of CLIPS, which Jess has

inherited from its predecessor.

Another important advantage of JessGUI over Jess is

interoperability related. Specifically, having defined an

XML Schema for XML binding of Jess knowledge base, we

enabled other Web (or non-Web) applications to access it

and use it. This issue is elaborated in Section 5.3.3.

The class diagram shown in Fig. 2 depicts the knowledge

model employed in JessGUI. Each class implements one of

the basic Jess concepts, and through its attributes and

methods enable capturing of all data necessary for

constructing the concept it represent. In order to avoid

tter, the class diagram does not show the methods for

ith Applications 29 (2005) 535553tege-2000 that work with Jess programs and rule bases.

tems wJ. Jovanovic, D. Gasevic / Expert SysIt takes advantage of the Jess API to map information in the

Protege knowledge base to Jess facts and to extend Jess with

additional functions for communication with Protege-2000

(Eriksson, 2003).

2.3. Ontology languages

Rapid expansion of XML throughout the Internet

community is promising to enable syntactic interoperability

on the global level. XML (eXtensible Markup Language) is

a meta-language used to define other languages. It describes

a class of data objects called XML documents and partially

describes the behavior of computer programs which process

them (Bray, Paoli, Sperberg-McQueen, & Maler, 2000).

XML is mainly devised for markup of vaguely structured

documents. It defines neither tags nor grammar, so an

appropriate XML description could be defined to satisfy

needs of any application. It only requires that document

must be well-formed in a tree structure, so it could be parsed

by standard XML tools. The structure of an XML document,

i.e. a set of rules that defines which tags are allowed to be

used and in which sequence, can be specified either by

Document Type Definition (DTD) or XML Schema.

Although DTD and especially XML Schema are solid

solutions for defining grammar of XML documents, i.e.

their syntactic rules, both of them lack capacity to express

underlying semantics of those documents (Decker et al.,

Fig. 2. JessGUIDith Applications 29 (2005) 535553 5392000). A standard must be built on top of XML that will

describe semantics of data. The first step in that direction

was Resource Description Framework (RDF).

The RDF is a language for describing resources on

the World Wide Web (specifying metadata for Web

resources) (Manola & Miller, 2003). However, by

generalizing the concept of a Web resource, RDF can

also be used to represent information about anything that

can be identified on the Web (via Uniform Resource

IdentifierURI), even when it cannot be directly

retrieved from the Web (Manola & Miller, 2003). RDF

is based on the idea that things (resources) being

described have properties which have values, and that

resources can be described by making statements that

specify those properties and values. The RDF data model

consists of three main components: a resource named by

URI plus optional anchor ID; a property that defines

specific aspects, characteristics or relations of resources;

and value that is assigned to a property of a resource (this

value might be another RDF statement). Therefore, RDF

provides a way to express simple statements about

resources, using named properties and values. However,

RDF user communities also need the ability to define the

vocabularies (terms) they intend to use in those

statements, specifically, to indicate that they are describ-

ing specific kinds or classes of resources, and will use

specific properties in describing those resources. This can

ataModel.

another layer is needed on top of RDF(S). That (logical)

layer introduces ontology languages that provide a richer set

neither the same names for their constituent elements and

attributes, nor the same number of them.

Concluding this brief overview of XSLT technology, we

deem important to point out that XSLT is an appealing

tems with Applications 29 (2005) 535553of modeling primitives, which can be mapped to description

logics. Common examples of such languages are OIL

(http://www.ontoknowledge.org/oil) and DAML (http://

www.daml.org). The latest W3Cs release, Web Ontology

LanguageOWL (Bechhofer et al., 2004) was recently

accepted as standard ontology language. OWL is a semantic

markup language for publishing and sharing ontologies on

the World Wide Web. It is developed as a vocabulary

extension of RDF and is derived from the DAMLCOILWeb ontology language. Fig. 3 presents the position of

ontology languages RDF(S) and OWL in the Semantic Web

architecture. As it can be deduced from the figure, both

RDF(S) and OWL have XML syntax representation.

However, one should note that an ontology (specified either

in RDF(S) or OWL) does not have a unique XML binding,

instead each ontology can be serialized in XML in multiple

different ways (Decker et al., 2000).

3. A technology for bridging gaps

A growing number of intelligent systems building tools

need an ability to handle different knowledge formats. They

should not be restricted to use neither only one specific

XML format, nor XML format at all. For example, JessGUI

tool saves knowledge bases in an XML-based format, while

Jesss interpreter is able to recognize only Jess/CLIPS (abe achieved using RDF Schema (RDFS) that provides the

basic type system for RDF data models (Brickley & Guha,

2004). The combination of RDF and RDF Schema is

known as RDF(S), however, it is not very expressive,

since it just allows the representation of concepts, concept

taxonomies and binary relations (Gomez-Perez & Corcho,

2002).

To enable reasoning services for the Semantic Web,

Fig. 3. RDF(S) and OWL in the Semantic Web architecture.

J. Jovanovic, D. Gasevic / Expert Sys540Lisp-like) language. Therefore, this tool has to support, not

only XML but, also Jess/CLIPS native knowledge base

format in order to enable usage of Jess inference engine. On

the other hand, writing special parsers for each text-based

knowledge format or special procedures for traversing

different XML documents is not an ideal solution since it

can be very complex or time consuming or both (in case of

special parsers).

The eXtensible Stylesheet LanguageXSLTis an

elegant solution for the presented problem. XSLT is alanguage for transforming an XML document into another

XML document (Clark, 1999). An excerpt of an XSLT

stylesheet is presented in Fig. 13a. XSLT has already been

used for transforming XML document into HTML and SVG

(Scalable Vector Graphicsa W3C XML-based standard

for 2D vector graphics) documents as well as documents

expressed in other markup languages defined using DTD or

some Schema language. Furthermore, using XSLT principle

an XML document can be transformed into a simple text-

based document. However, the best result is achieved when

an XSLT is used to transform one XML document into

another XML document, regardless how different their

schemas are. This feature of XSLT should be used, not just

to enable simple support for different presentation formats

of the same data, but also to enable straightforward

interchange of knowledge between applications.

Although creation of an appropriate XSLT stylesheet is

necessary it is not sufficient for performing a desired

transformation. One would also need a piece of software

able to process both the XSLT stylesheet and the XML

document that needs to be transformed, and produce another

document in the desired format as a result. Fig. 4 illustrates

the main principle of document transformation using XSLT

technology.

An XSLT stylesheet consists of sequence of rules, in

XSLT terminology called templates, that matches certain

elements of the input XML document and transform them

into the target XML format. One should notice that the

source and the target XML documents do not have to have

XMLdocument

Input

XSLTprocessor

XSLT

XMLdocument

Targetformats

Fig. 4. XSL Transformation: An input XML document XSLT processor

transforms into an output XML document using an adequate XSLT

stylesheet.approach for performing transformations of XML docu-

ments, since one does not need to modify his/her program

(i.e. recompile the program), instead XSLTs are interpreted

during the program execution. If it happens that the XML

format (i.e. XML Schema or DTD) an application uses

should be changed, the application itself does not need to be

modified, it would be enough to develop an adequate XSLT

to support that change. This approach is both easier and less

time consuming.

infra

tems w4. Resulting infrastructure for knowledge sharing

Fig. 5 presents the XSLT-based infrastructure that we

propose for knowledge sharing. The proposed infrastructure

should enable knowledge exchange between different

knowledge modeling and acquisition tools. For the moment

we consider only three tools of this type (JessGUI, JavaDON

and Protege) but other Semantic Web and ontology devel-

opment tools could be included as well. The infrastructure is

based on XSLT stylesheets that we have developed in order

to enable conversion between different knowledge represen-

Fig. 5. The proposed XSLT-based

J. Jovanovic, D. Gasevic / Expert Systation formats of these tools. Our choice to use an approach

based on XSLT was grounded on the fact that relying on the

XSLT principle we did not need to change any of these tools,

instead we just needed to apply an XSLT on their output

documents.

As we already mentioned (see Section 2.2) Jess knowl-

edge base is normally represented in Jess/CLIPS format, but

we developed an XML format for it in order to enable its

interoperability (Bergholz, 2000). However, this format

cannot be used by the Jess interpreter, which interprets only

Jess/CLIPS code. Thus we developed an XSLT that

transforms JessGUI XML format into Jess/CLIPS format,

so that it can be parsed by Jess interpreter and executed by

Jess inference engine.

We have also implemented a pair of XSLTs in order to

enable interoperability between JavaDON and JessGUI. This

means that a user can export a knowledge base developed in

JavaDON into JessGUIs knowledge format and then import

it in JessGUI tool in order to further refine it (e.g. profit from

Jess greater expressivity of procedural knowledge). Further

more, as we have developed an XSLT for transforming

JessGUIs XML format into Jess native text-based format,

one can use not just JessGUI to develop a knowledge basethat will be processed by Jess inference engine, but also can

use JavaDON to develop a knowledge base that will be firstly

transformed into JessGUI XML format and then (using

another XSLT) into Jess native format.

Having developed similar XSLTs we provided interoper-

ability with Semantic Web tools. These XSLTs transform

JessGUIs and JavaDONs XML based knowledge formats

into corresponding RDF(S) and OWL models. For example,

one can import a JessGUIs or JavaDONs knowledge base

into Protege-2000 since it would be a way to produce an

ontology. However, the reverse transformations (i.e. those

that would convert RDF(S) and OWL ontologies into

structure for knowledge sharing.ith Applications 29 (2005) 535553 541JessGUI and JavaDON XML knowledge models) are not

yet developed as XSLT approach proved ineffective for such

kind of transformations. As it is stated in (Decker et al.,

2000) an ontology does not have a unique XML binding,

therefore an XSLT implemented to work with one XML

serialization of the ontology would not work with others

(more on this subject can be found in Discussion).

However, this approach has certain limitations that result

from different conceptual models these tools are based on.

Table 1 presents a summary of results obtained from a

comparative study of those conceptual models that we did

prior to setting ourselves on the task of XSLTs develop-

ment. The table should only provide an introductory

overview since details are covered in Section 5.

5. Implementation details

In this section we briefly present XML Schemas that

define XML formats of JessGUI and JavaDON knowledge

bases. Then we focus on some problems that we faced

when implementing XSLTs to support the proposed

infrastructure. These problems originate from different

knowledge formats of the analyzed tools. We explain our

solution for each implemented XSLT.

5.1. XML JessGUI

We developed an XML format for Jess knowledge bases

using W3Cs XML Schema for defining XML document

grammar, and made it available to Jess knowledge-based

builders through JessGUI (Bergholz, 2000). This XML

format can contain and represent all Jess concepts (e.g.

more precisely the complex type for representing Jess rules

(ruleType); other elements are defined in a similar manner.

Each rule consists of a conditional or IF part (LeftHandSide

in Jess terminology, hence lhs element in the schema), an

action or THEN part (RightHandSide as it is called in Jess,

hence rhs schema element) and an optional description

element. Each condition of a rule is made of patterns that

should be matched against the knowledge base in order to

fire the actions in the action part of the rule.

5.2. XML JavaDONOBOA XML binding

Table 1

A comparative overview of Jess, OBOA and ontology languages knowledge models

Knowledge model JessGUI (Jess) JavaDON (OBOA) Ontology languages

(RDF(S) and OWL)

Declarative knowledge support Yes Yes Yes

Class Template Frame Class

Property Slot Attribute Property

Property as a first-class concept No Yes Yes

Instance Ordered/unordered fact Fact Named tag

Procedural knowledge support Rules, functions Rules No

J. Jovanovic, D. Gasevic / Expert Systems with Applications 29 (2005) 535553542module, global variable, etc.). Speaking in terms of XML

Schema definition, for each of these concepts we defined a

proper complex type. We used XMLSpy tool (http://www.

altova.com) for modeling XML Schema in order to obtain a

better readability as well as a better documentation of the

JessGUIs XML format. The root element, named knowl-

edgeBase can contain an unbounded number of XML

elements: module, globalVar, deffact, fact, template, func-

tion, rule and query, where each one represents a real Jess

concept. Due to the complexity of the developed schema, in

Fig. 6 we show only a part of the XML Schema definition,Fig. 6. Complex type for description ofUsing XML Schema we have also developed an XML

binding for the OBOA model (introduced in Section 2.1)

and set it as the native format of knowledge bases built in

JavaDON tool. The initial idea was to use previously

developed JessGUIs XML Schema as the grammar for

XML binding of knowledge bases generated in JavaDON.

Our aim was to enable direct interchange of knowledge

models developed in these two tools. However, we have

realized that the divergences of the underlying models of

these two tools (OBOA and Jesss native model) wouldrules in JessGUIs XML Schema.

tems wmake that approach infeasible. The second best solution was

to develop a separate OBOA XML binding and a pair of

XSLTs that would enable interoperability of these tools. A

graphical representation partially depicting the developed

XML Schema is shown in Fig. 7. Comparing this figure with

Fig. 1, one can notice that the developed XMLSchema is a

simplified version of the OBOA model. A KnowledgeBase

contains one or more knowledge elements of type Attribute,

Fact, Frame (template for fact), or/and Rule. While the

Attribute element is of a simple type, containing only

attribute values (not shown in the figure), other elements are

of complex types comprising, besides attributes, also other

nested elements, e.g. each Frame embodies one or more Slot

elements.

5.3. Transformations

Fig. 7. XML Schema for OBOA XML Binding.

J. Jovanovic, D. Gasevic / Expert SysIn this section we will describe in greater details XSLT

stylesheets that we have developed in order to provide

support for the proposed infrastructure. We will not present

developed XSLTs due to their length, instead we will focus

on comparing source and resulting documents in order to

highlight interesting details of the applied transformations.

However, all the developed transformations as well as

several XML documents illustrating the applied principle

are publicly available at http://iis.fon.bg.ac.yu/XML-KBS/

5.3.1. Transformations between XML schemas

In order to enable interoperability between knowledge

bases developed in JessGUI and JavaDON, we developed a

pair of XSLTs that perform bidirectional transformations

between XML formats of these two tools.

The XSLTs we have implemented for mapping between

JessGUI and JavaDON (OBOA) XML descriptions contain

a set of rules (i.e. xsl:templates) that match constructs of

XML format of one tool and transform them into

equivalent primitives of the other tool. We were aware ofthe fact that development of these rules will not be that

straightforward due to the evident differences between

the source and the target format. Thus we decided to firstly

perform a comparative study of JavaDONs (i.e. OBOA)

and JessGUIs (i.e. Jess) knowledge models. Table 2

summarizes the results of this analysis.

Generally speaking, the main obstacle stemmed from the

fact that JessGUIs XML format is much more complex than

the XML format JavaDON uses, so many features specific

to the JessGUIs knowledge base are lost in the resulting

document. This is especially true for JessGUIs rules that

are frequently far more complicate than those that JavaDON

defines. To put it another way, JessGUIs knowledge base

format is directed towards supporting procedural knowledge

(as a consequence we have to deal with complex structure of

rules), while features of the OBOA model implemented in

JavaDON are more oriented towards expressing declarative

knowledge (emphasizes on Object-Attribute-Value

statements).

In order to better illustrate differences between represen-

tation of procedural knowledge in Jess/JessGUI and

JavaDON (OBOA) knowledge models we present the

XML binding for rules that these tools use. In Fig. 8a one

can notice a rule in JessGUI XML format, while in its

bottom part (Fig. 8b) we present the same rule in JavaDON

XML format. A rule, as an expression of procedural

knowledge is an if/then statement that defines the set of

Table 2

A comparative overview of the main concepts of JessGUIs and JavaDONs

knowledge base models

JessGUI (Jess)

knowledge model

JavaDON (OBOA)

knowledge model

Module

GlobalVar

Template, slot Frame, slot

Attribute

Ordered fact

Unordered fact Fact

Deffact

Function

Rule Rule

ith Applications 29 (2005) 535553 543facts that must be true (the if part) before a set of actions (the

then part) can be executed. One can easily notice that

JessGUIs and JavaDONs XML formats use differently

named tags to represent the same thing: a conditional part of

a rule is enclosed inside !IfClauseO tags in JavaDON,while JessGUI uses instead !lhsO tags (shorten form ofLeft-Hand Side, a synonym for If part in Jess terminology).

Similarly, JavaDON uses !ThenClauseO tags to encapsu-late action part of a rule, while JessGUI employs !rhsOtags (shorten form of Right-Hand Side, a synonym for then

part in Jess terminology) for the same purpose.

However, those are just syntactical differences that can

be easily overcome, real problems are caused by the

aforementioned considerable discrepancy in complexity of

Jess rules and those that JavaDON uses. This discrepancy is

focus=

ment=

="=" c

ype="

ticipat

ation=cer" r

ncer"

le: (a

tems w

"none">

onstraintValue="true"/>=" constraintValue="true"/>

ion)

"=" value="true" />elation="=" value="true"/>

re lation="=" value="partic ipation"/>

) JessGUI knowledge format; (b) JavaDON.

ith Applications 29 (2005) 535553knowledge, more precisely properties (attributes) of

knowledge objects. While in the OBOA model attribute

is a first-class concept, analogy to a property in ontological

languages, a slot, OBOAs attribute corresponding concept

in Jess knowledge base model, cannot exist alone, i.e.

outside the template (concept analogous to an ontology

class) within which it is defined. The consequence of this

discrepancy is that when transforming a class (i.e.

Template in Jess terminology) from Jess knowledge

base into the corresponding concept of the OBOAs

knowledge format (i.e. Frame) we had to simultaneously

generate attributes as stand-alone concepts that correspond

to slots of the source class, of course if those attributes did

not already exist in the knowledge base. In this context, we

had to be careful to avoid naming conflict that could result

when raising slots on a higher level in the conceptual

model. This potential problem was prevented by introdu-

cing a naming convention based on using complex names

for OBOAs Attributes resulting from transformation of

Jess slots. Names of those Attributes were generated by

prefixing slots names with the name of the Template they

belong to. Fig. 10 illustrates this approach. The upper part

of Fig. 10a presents a class Dancer as it is represented in

Jess knowledge base, while its middle part (Fig. 10b)

contains an excerpt of the resulting JavaDON knowledge

base after transformation of the Dancer class was done. In

the bottom part of Fig. 9c we have presented an excerpt of

the XSLT in order to illustrate our solution for mapping

e="Bteger"e="B type

ship "

alue =""/>alue =

" va

/>oolean"/>="Boolean"/> type="String"/>

""/>

""/>lue=""/>

" value=""/>(i.e. knowledge base compliant with the OBOA model) into

these languages using an XSLT will result in lost of all

procedural knowledge, i.e. knowledge expressed in the form

of OBOA models rules. On the other hand, declarative

knowledge of a knowledge base compliant with the OBOA

model can be relatively easily transformed into correspond-

ing RDF(S) and OWL ontologies.

We have conducted a comparative analysis of Java-

DONs knowledge model format and elements of both

RDF(S) and OWL ontology languages. Table 3 presents an

t ">

to OBOA model format using the developed XSLT (b) and an excerpt of the

(S) and OWL primitives

f Representation

of body of knowledge

Representation of

procedural knowledge

Fact Rule

A tag named by the class it

instantiates

perty

rty

A tag named by the class it

instantiates

ame,

">Typeype "

ttribu>rce "

l:valu

vaDO

tems woverview of the results we have obtained. These results

served us as a starting point when defining transformation

rules between these knowledge formats.

Transforming Frames from OBOA knowledge model

into the corresponding RDFS concept, rdfs:Class was

straightforward. However, transformation of OBOAs

Attribute concept into the corresponding rdf:property

concept in RDFS was not so simple. Each Attribute was

converted into an equivalently named property whose range

was easily derived from the Attributes specified datatype.

select="@type"/>

te = $attributeName] ">

>e -of select="translate(../@name, ' ', '_') "/>

N (OBOA) Attributes are transformed into RDF(S) properties.

ith Applications 29 (2005) 535553Fact OBOA concept constitute RDF document and docu-

ments compliant to the OWL ontology. Fig. 11 presents the

resulting format of OWL ontology after the developed XSLT

stylesheets were applied to the excerpt of the JavaDON

knowledge base presented in the bottom part of Fig. 9.

5.3.2.2. JessGUI XML to OWL and RDF(S). Jess

conceptual model greatly relies on rules as a form of

expressing knowledge, so we were aware that we will have

significant loss of knowledge after transforming a Jess

knowledge base into corresponding RDF(S) and OWL

format regarding that these ontological languages do not

provide support for procedural knowledge modeling. This

loss was expected to be even greater than in the case of

JavaDONs transformations, since JavaDONs (i.e.

OBOAs) model is not that heavily based on rules.

We used the same approach as when developing XSLTs

for transforming JavaDONs model. In other words we began

by a comparative study of JessGUIs knowledge model

format on the one hand and RDF(S) and OWL conceptual

models on the other. Our observations are given in Table 4.

While properties are first-class concepts in RDF(S) and

OWL, their corresponding concept in Jess knowledge base

5.3.3. Transformation from the XML binding of knowledge

model into Jess native format

natural solution for this problem. We developed an XSLT

that transforms JessGUI XML format into Jess/CLIPS

Dancer

(a)

< Dancer .C_category >true< Dancer .score>160< Dancer .B_category >true< Dancer. StateChampion >true< Dancer .WorldChampionship >participation

(b)

Fig. 12. Differences between fact representation formats: (a) a Jess/JessGUI fact, (b) the same fact in RDF/OWL format.

J. Jovanovic, D. Gasevic / Expert Systems with Applications 29 (2005) 535553548Having XML-based format for JessGUI is a good feature

for interoperability with other knowledge-based systems,

but this format cannot be used by the Jess interpreter. The

Jess interpreter in its basic distribution interprets only

Jess/CLIPS code. Thus, we need a way to transform the

JessGUI XML format into the Jess/CLIPS code. XSLT is a

(a)null

(defrule

""

(declare (salience ))

hampionship true))

ipation))))

o Jess native (text-based) format. (b) The rule from Fig. 7a in Jess native

JessGUIs XML format and here (Fig. 13b) we show that

same rule in Jess native format.

Since this XSLT transformation has a standard text

document as the target format, we had to explicitly specify

the structure and constituent parts of the resulting document.

For example, each Jess rule has an attribute named salience

that defines the rules priority. In JessGUIs XML format we

defined an attribute priority of the rule element that holds

the value for the rules priority (in our example rule from

Fig. 8a that value is 100). On the other hand, Jess native

syntax uses construct (declare (salience 100)) to express the

same information. The highlighted part of the XSLT

presented in Fig. 10a is responsible for performing the

necessary conversion.

It should be noted that the resulting document is not

pretty-printed as the excerpt from Fig. 13b might suggest.

On the contrary, in most cases it is rather unorderly written,

essentially because XSLT is primarily aimed to enable

transformations between different XML formats where

documents presentation format is of the minor importance

comparing to its content. Special XML editors (e.g. XML

Spy) or other tools (e.g. Web browsers) can be used to

pretty-print resulting documents.

Since we have developed an XSLT that performs

transformation from JavaDONs into JessGUIs XML

knowledge format, we can now use Jess inference engine

to reason over knowledge bases originally developed using

JavaDON tool. The first thing to be done is to transform

JavaDONs document format into JessGUIs XML format

and then to apply another XSLT that will convert that

resulting XML format into Jess native format comprehen-

sible to the Jess parser.

6. Discussion

In this section we discuss advantages and disadvantages

of the proposed XSLT-based approach as well as suggest

some potential solutions for identified problems.

First, in Table 5 we present an overview of the

recognized advantages and disadvantages of the proposed

solution. In fact, the table summarizes our remarks from

Sections 4 and 5.

Although the proposed XSLT approach can be error-

prone due to the fact that one has to implement XSLTs on

a very low level of abstraction (i.e. by hand-coding), our

experience, however, confirms that it is a light-way

approach of extending already available tools in order

to achieve knowledge exchange between them. The most

challenging part of an XSLT development process is

Table 5

Summary of experiences with XSLT-based knowledge models sharing

F(s)/O

ntation

-class

ses)

an be

e too

inst X

cture

, just

wledg

JessGUI-class dependent

dinality

se of

The target formats offer no The reversed transformation

prese

ains

n in Ja

DFS/

J. Jovanovic, D. Gasevic / Expert Systems with Applications 29 (2005) 535553 549The proposed XSLT based knowledge sharing

JessGUI4JavaDON JavaDON/RD

Advantages Both XML formats defined

using XML Schemas

Similar represe

properties (first

cepts in both ca

XSLT in both directions Target format c

dated using som

Protege) or aga

Schemas

Achieved translation of both

declarative and procedural

knowledge

The target format can be

validated against the target

XML Schema

Difficulties JessGUI to JavaDON trans-

formation susceptible to large

loss of knowledge due to

greater complexity of Jess-

GUI knowledge model

There is no stru

describing rules

declarative kno

Only one type of JessGUI

rules can be mapped into

JavaDON rules

Insertion of car

restriction in ca

Different treatment of the

property concept:in Java-

DON first-class concept, in

JessGUI class dependent

Difference in re

of property dom

a class definitio

vs. domain in ROWL structure for representing

rules and functions, just

declarative knowledge

(Jess to JessGUI) requires

building a special-purpose

parser; it is not possible to do

it using XSLT

ntation

(slots in

vaDON

OWL)

Insertion of cardinality

restriction in case of OWL

Difficult to validate the target

format (it cannot be validated

against an XML Schema) and

Jess parser does not perform

strong syntax checkingWL JessGUI/RDF(S)/OWL JessGUI/Jess

of

con-

Target format can be vali-

dated using some tools (e.g.

Protege) or against XML

Schemas

Public access to Jess knowl-

edge model format

vali-

ls (e.g.

ML

Clear structure of the target

document

for

e

Different treatment of the

property concept:RDF(S)/

OWL-first-class concept;

Text-based target format-not

an ideal situation for applying

XSLT principle

indubitably confirm that this approach is much easier

and less time consuming than the approach based on

tems wprogrammatically extending existing tools in order to

make them interoperable.

However, we have also recognized a few drawbacks of

this approach. The first one stems from the XSLT

technology itself, since it is very sensitive to the format of

the input document: a slight change of the input documents

structure would result in poor transformation performance.

Thus, this approach could be used only with well structured

XML documents, i.e. those that fully comply with some

Schema. However, the main hindrance of the proposed

approach cannot be attributed to XSLT principle itself, but

rather to the lack of standard procedural knowledge

representation language for the Semantic Web (something

analogous to OWL for declarative knowledge). If such a

language had existed we would have been able to map

JessGUI and JavaDON rules into their Semantic Web

equivalences. A possible solution might be Semantic Web

Rule LanguageSWRL (Jovanovic et al., 2004) that is an

ongoing Semantic Web community effort to define a

standard rule language for the Semantic Web.

So far we have not found a programming language

independent solution for transforming ontological infor-

mation expressed in RDF(S) or OWL into JessGUI and

JavaDON. The initial idea was to employ again an XSLT

based approach, but we realized that even if we were able to

define such a transformation, it would not be general

enough, since it would work only for one specific XML

presentation form of an ontology, and fail in other cases. In

other words, XSLT is syntax sensitive, if syntactical

representation of the ontology changes, it becomes

inapplicable, and it is well known fact that the same

ontology instance can have different XML bindings (i.e.

compliant to different XML Schemas). We are presently

considering alternative approaches in order to find a suitable

one to base our further work on.

7. Related work

In this section we briefly present some similar solutions

to knowledge sharing and transformation issues. First, we

present a few conceptually similar (i.e. XSLT based)

approaches and then focus on some alternative approaches.

The idea of XSLT-based transformations is widely

applied for mappings between software engineering tech-the one related to exploring similarities and differences

between two knowledge representation formats and

defining mappings between them on the conceptual

level. This task might last even a few days. Nevertheless,

the implementation part is much less time-consuming, and

for an experienced developer might present a task of an

hour or two (of course, assuming that the conceptual

model was previously well defined). Thus we can

J. Jovanovic, D. Gasevic / Expert Sys550niques and ontologies. Cranefield (2001) used an XSLT fortransforming UML classes into RDF(S) ontologies. It is

important to note that he recognized the difference between

a UML attribute (defined in the scope of the class it belongs

to) and an ontology property (a first-class concept that can

exist independently of a class). In this paper we have

recognized a similar problem related to the mapping of

JavaDON attributes to JessGUI slots (and vice-versa), as

well as to the mapping of JessGUI slots into OWL/RDF(S)

properties. The XML/XSLT approach is also applied for

transformations of extended UML models into DAMLCOIL ontologies (Falkovych, Sabou, & Stuckenschmidt,

2003), as well as for transforming an ontology UML Profile

into an OWL ontology (Gasevic, Djuric, Devedzic, &

Damjanovic, 2004a).

Further, it is worth mentioning that an experimental

RuleML-RDF translator for a subset of RuleML 0.7 is

available in XSLT (Boley, 2001). The RDF representation

of a RuleML knowledge base (i.e. rulebase) directly reflects

its tree structure defined by the RuleML DTD. The author

emphasizes the use of XSLT as a flexible approach for

defining the current RDF version of RuleML that will

enable easy adaptation of this translator to the future

changes of the RuleML DTD. This is another confirmation

of XSLTs usefulness for overcoming potential obstacles

resulting from releasing new versions of an XML based

knowledge format.

Since RuleML should help rule-based intelligent systems

interoperation, RuleML community has made a request to all

rule-based systems developers to develop and make publicly

available a translator from the rule representation format of

his/her system into RuleML format. It is worth noting that the

majority of the proposed solutions are implemented as XSLTs

(http://www.ruleml.org/#Translators).

An alternative to our XSLT-based proposal is an

approach that could be referred to as programmatic.

This type of approach is used in some knowledge

representation tools, such as Protege, and it is based on

making transformations to be a part of the tools

implementation. Protege is nowadays probably the most

important tool in knowledge engineering. It is the leading

ontological engineering tool (Fikes, Hayes, & Horrocks,

2003) that has complex software architecture, easily

extensible through plug-ins. Many components that provide

interfaces to other knowledge-based tools (Jess, Argenon,

OIL, PAL constraint, etc.) have been implemented in this

way, as well as support for different ontology languages and

formats like XML, DAMLCOIL, OIL (tab), OWL plugin,etc. Since Protege supports several knowledge represen-

tation formats it is possible to use Protege as a sort of

transformation tool with the capacity to import and export

different formats. For instance, we can open an RDF(S)

ontology in Protege and afterwards we can save this

ontology into OWL format. In many cases this Proteges

feature works very well, but there are some plugins that

have limited transformation capacities (e.g. DAML plugin

ith Applications 29 (2005) 535553is unable to export a DAML ontology in some other format

tems wdifferent from DAML). However, all these transformations

should be regarded as a consequence of Proteges support

for different formats, but not in a way that Protege has a

collection of transformations specially developed for each

possible transformation pair. That means, all these trans-

formations are a part of the Proteges (or its plugins)

implementation. In order to upgrade a current plugin (e.g.

RDF(S)) to support some modifications of its underlying

XML format we should firstly learn the Proteges procedure

for developing plugins. This can be a time consuming

process if we are not experienced in developing Proteges

plugins. If Protege had used the approach (XML/XSLT) we

advocate in this paper most of these issues would have been

resolved.

SweetJess (Grosof, Gandhe, & Finin, 2002) is another

interesting software system that employs programmatic

approach to achieving interoperability between hetero-

geneous rule-based intelligent systems. More precisely,

SweetJess performs bidirectional transformations between

Jess and RuleML knowledge representation formats as well

as bidirectional transformations, via RuleML as the

interlingua, between Jess and a variety of other rule systems

(e.g. Prolog and relational database systems) for which

translation into RuleML format are defined and necessary

translation tools are developed (MOF 2.0 Query/View-

s/Transformations, 2002). The translation preserves seman-

tic equivalence, i.e. for a given rulebase, the same

conclusions are entailed. The authors have also developed

a DAMLCOIL ontology for RuleMLin particular, for theSCLP (Situated Courteous Logic Programs) case of

RuleML. However, the resulting syntax for RuleML,

named DamlRuleML merely enables a DAMLCOILsyntactic encoding of RuleML.

Another approach alternative to the one we proposed

would be to use ontology languages transformation

language like TRIPLE (Sintek & Decker, 2002) or RDF

Query Language (RDQL) (Seaborne, 2004) for developing

transformations from ontology languages (OWL,

RDFS(S)). Since each ontology language has an appropriate

XML binding, the XML/XSLT-based approach might

sound as a quite suitable solution for performing transform-

ations. However, as we have already mentioned, the same

semantics can be described using different XML-based

syntactical constructions (Decker et al., 2000), and since

XSLT is very sensitive to the input format, in the XSLT-

based ontology transformation we would have to consider

all possible syntactic (XML) forms in which an ontology

can be represented. This can be time-consuming and error-

prone task. On the other hand, if we perceive ontologies as a

set of subject-predicate-object triples, it would be more

appropriate to develop transformation tools starting from

that triple representation format. In that case, current

ontology query languages could be used as the basis for

ontology transformation tools, since specifications of those

languages state that they are not only ontology query

J. Jovanovic, D. Gasevic / Expert Syslanguages (Sintek & Decker, 2002), but also ontologytransformation languages. Currently, there are several

solutions that use one of these languages to transform

different RDF-based ontologies (Dolog, Henze, & Nejdl,

2004; Miklos, Neumann, Zdun, & Sintek, 2003). The main

problem with those ontology transformation languages is

that there is not a general consent which language should be

accepted as the standard. A potential candidate is the recent

W3Cs initiative for the standard transformation and query

language based on OWLOWL Query language (OWL-

QL) (Fikes et al., 2003).

Additionally, we believe that it would be useful to

borrow some solutions that other research communities

came up with when solving similar, transformations related,

problems. A very useful experience is the one related to the

recent software engineering community effortModel

Driven Architecture (MDA (Miller & Mukerji, 2003)). In

fact, the idea of using experiences from software engineer-

ing in knowledge engineering was introduced much earlier

(Devedzic, 1999). An MDA based solution to the presented

problem of interoperability, would be to develop a common

metamodel (Platform Independent Model-PIM) that would

cover different representation techniques (Platform Specific

ModelPSM). In this case we would only have to build a

pair of transformations between each PSM and PIM. In the

current solution we developed a pair of XSLTs for

transformations between each pair of knowledge represen-

tation formats, and if we had N different representation

platforms we would have to build N(NK1) transformations(square dependency). However, with the MDA-based

approach we would only have 2N transformations (linear

dependency). For example, some other domains outside the

scope of software engineering (e.g. repurposing multimedia

content (Obrenovic, Starcevic, & Selic, 2004)) have already

employed this MDA-based transformation principle.

Finally, note a very important concept for bridging

different technologies-the concept of technological spaces

(Kurtev, Bezivin, & Aksit, 2002). A technological space is a

working context with a set of associated concepts, body of

knowledge, tools, required skills, and possibilities.

Although some technological spaces are difficult to define,

they can be easily recognized (e.g. XML, MDA, and

ontology technological spaces in the case of approaching

MDA and OWL). In order to get a synergy of different

technological spaces we should create bridges between

them, and some of these bridges are bi-directional. The

bridges can be created in a number of ways (e.g. in the XML

technological space by using XSLT, in ontological engin-

eering through transformations that can be mapped into

XSLT, etc.). Note that technological spaces can be classified

according to their layers of abstraction (e.g. MDA and

ontological engineering are high-level spaces, whereas

XML and databases are low-level spaces). The Semantic

Web integrates XML and ontological engineering techno-

logical spaces. This approach can be a good starting point

for the future research on exchanging knowledge bases and

ith Applications 29 (2005) 535553 551defining more abstract transformations between different

into a standard text document. These problems stems from

the fact that XSLT was not originally developed for those

html

Boley, H. (2003). The rule markup language: RDF-XML data model, XML

schema hierarchy, and XSL transformations. Presented at INAP2001.

tems with Applications 29 (2005) 535553purposes.

Our work should be useful primarily to the community of

knowledge base engineers since the proposed infrastructure

is intended to make knowledge easily sharable between

knowledge modeling and acquisition tools and that way

enable one to profit from specific features of each of these

tools. For example, one might start building a knowledge

base using one tool (say Protege) and then export it into

another tool for further refinement (say JessGUI for adding

procedural knowledge in the form of Jess rules). Further-

more, this work can be useful for students, since we are

already using JessGUI and JavaDON as teaching andknowledge base representations. One possible direction is to

define all these transformations in terms of MDA as well as

by employing other transformation techniques like Meta

Object Facility Query/Views/Transformations (MOF QVT)

(MOF 2.0 Query/Views/Transformations, 2002). MOF

OVT is a platform-neutral part of MDA aiming to define a

language for querying and transforming models as well as

viewing metamodels. Examples of approaching different

languages using technological spaces can be found in

(Bezivin, Dupe, Jouault, Pitette, & Rougui, 2003; Gasevic,

Djuric, Devedzic, & Damjanovic, 2004b; Kurtev & van den

Berg, 2003).

8. Conclusions

In this paper we have proposed an XSLT-based

infrastructure for sharing knowledge between different

knowledge modeling and acquisition tools. More precisely

we dealt with three tools that use different conceptual

models for knowledge representation. Two of these tools,

JessGUI and JavaDON are ongoing research efforts of our

group (GOOD OLD AI group, http://www.goodoldai.org.

yu) to develop interoperable development tools for building

intelligent systems. The third tool is Protege-2000, a widely

accepted ontology development tool. Our decision to base

the proposed infrastructure on XSLT was grounded on the

fact that relying on the XSLT principle we did not need to

change any of these tools, instead we just needed to apply an

XSLT on their output documents. We have also presented

some problems that stem from differences between knowl-

edge formats of the analyzed tools and we described the way

we dealt with those obstacles. Our experience in applying

XSLT for knowledge sharing is that XSLT can be useful,

but at the same time it is very sensible on the format of the

input document. It is a good solution for achieving

interoperability if formats of the source and the target

documents are well structured (explicitly defined by a DTD

or XML Schema). However, problems arise if one wants to

use an XSLT in order to enable interoperability with an

ontology language or tries to transform an XML document

J. Jovanovic, D. Gasevic / Expert Sys552learning tools in undergraduate and graduate courses on[Online]. Available at: http://www.dfki.uni-kl.de/ruleml/

Booch, G. (1994). Object oriented design with applications. Redwood City,

CA: The Benjamin/Cummings.

Booch, G., Rumbaugh, J., & Jacobson, I. (1998). The unified modeling

language user guide. Reading, MA: Addison-Wesley.

Bray, T., Paoli, J., Sperberg-McQueen, C. M., & Maler, E. (Eds.). (2000).

Extensible markup language (XML) 1.0 W3C recommendation (2nd

ed.). [Online]. Available at: http://www.w3.org/TR/2000/REC-xml-

20001006

Brickley, D., & Guha, R. V. (Eds.). (2004). Resource description

framework (RDF) schema specification 1.0. W3C recommendation.

[Online]. Available at: http://www.w3.org/TR/2004/REC-rdf-schema-

20040210/

Clark, J. (Ed.). (1999). XSL transformations (XSLT) version 1.0. W3C

recommendation. [Online]. Available at: http://www.w3.org/TR/1999/

REC-xslt-19991116/

CLIPS. (2003). CLIPS, a tool for building expert systems. [Online].

Available at: http://www.ghg.net/clips/CLIPS.html

Cranefield, S. (2001). Networked knowledge representation and exchange

using UML and RDF. [Online]. Available at: http://jodi.ecs.soton.ac.uk

Decker, S., Melnik, S., van Harmelen, F., Fensel, D., Klein, M., Broekstra,

J., et al. (2000). The semantic web: The roles of XML and RDF. IEEEexpert systems at our university. Now that we have enabled

transformations between knowledge bases of these tools,

students can gain practical experience in applying

the principle of interoperability that became the leitmotif

of contemporary courses on knowledge base systems.

Our plan is to enable importing RDF(S) and OWL

ontologies into JessGUI and JavaDON and that way realize

full interoperability between these and ontology develop-

ment tools. To achieve this we intend to use Jenaa Java

application programming interface available as an open-

source (www.hpl.hp.com/semweb/jena-top.html). In order

to enable support for procedural knowledge sharing we plan

to develop an XSLT that would transform rules from

JessGUI and JavaDONs knowledge models into Semantic

Web Rule LanguageSWRL (W3Cs proposal for the

standard Semantic Web language for rules based on a

combination of OWLs and RuleMLs sublanguages)

format [ref].

References

Bechhofer, S., van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D.

L., Patel-Schneider, P. F., et al. (2004). OWL web ontology language

reference. W3C recommendation. [Online]. Available at: http://www.

w3.org/TR/2004/REC-owl-ref-20040210

Bergholz, A. (2000). Extending your markup: An XML tutorial. IEEE

Internet Computing, 4(4), 7479.

Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The semantic web.

Scientific American, 284(5), 3443.

Bezivin, J., Dupe, G., Jouault, F., Pitette, G., & Rougui, J. E. (2003). First

experiments with the ATL model transformation language: Transform-

ing XSLT into Xquery. Proceedings of the second OOPSLA workshop

on generative techniques in the context of model driven architecture.

Boley, H. (2001). RuleML in RDFan experimental RDF translator for a

subset or RuleML. [Online]. Available at: http://www.ruleml.org/inrdf.Internet Computing, 4(5), 6374.

Devedzic, V. (1999). Ontologies: Borrowing from software patterns. ACM

Intelligence, 10(3), 1424.

Devedzic, V., & Radovic, D. (1999). A framework for building intelligent

manufacturing systems. IEEE Transactions on Systems, Man, and

Cybernetics, Part C-Applications and Reviews, 29(3), 402419.

Dolog, P., Henze, N., & Nejdl, W. (2004). Reasoning and ontologies for

personalized E-learning. Educational Technology & Society (Journal of

the IEEE Technical Committee on Learning Technologies) .

Eriksson, H. (2003). Using JessTab to integrate Protege and Jess. IEEE

Intelligent Systems, 18(2), 4350.

Falkovych, K., Sabou, M., & Stuckenschmidt, H. (2003). UML for the

semantic web: Transformation-based approaches. In B. Omelayenko, &

M. Klein, Knowledge transformation for the semantic web, frontiers in

artificial intelligence and applications (Vol. 95) (pp. 92106). IOS

Press.

Fikes, R., Hayes, P., & Horrocks, I. (2003). OWL-QLa language for

deductive query answering on the semantic web. KSL technical report

03-14. Stanford, CA: Knowledge Systems Laboratory, Stanford

University.

Jovanovic, J., Gasevic, D., & Devedzic, V. (2004). A GUI for Jess. Expert

Systems with Applications, 26(4), 625637.

Kurtev, I., Bezivin, J., & Aksit, M. (2002). Technological spaces: An initial

appraisal. Proceedings of the confederated international conferences

CoopIS, DOA, and ODBASE 2002, industrial track.

Kurtev, I., & van den Berg, K. (2003). Model driven architecture based

XML processing. Proceedings of the ACM symposium on document

engineering (pp. 246248).

Lee, J. K., & Sohn, M. M. (2003). The extensible rule markup language.

Communications of the ACMI, 46(5), 5964.

Leff, L. (2001). Automated reasoning with legal XML documents.

Proceedings of the eighth international conference on artificial

intelligence and law. ACM Press (pp. 215216).

Manola, F., & Miller, E. (Eds.). (2003). Resource description framework

(RDF) primer. W3C proposed recommendation. [Online]. Available at:

http://www.w3.org/TR/2003/PR-rdf-primer-20031215/

Miklos, Z., Neumann, G., Zdun, U., & Sintek, M. (2003). Querying

semantic web resources using TRIPLE views. Proceedings of the

second international semantic web conferenceISWC03, Sanibel

J. Jovanovic, D. Gasevic / Expert Systems with Applications 29 (2005) 535553 553Freedman-Noy, N., Sintek, M., Decker, S., Crubezy, M., Fergerson, R. W.,

& Musen, M. A. (2001). Creating semantic web contents with Protege-

2000. IEEE Intelligent Systems, 16(2), 6071.

Friedman-Hill, E. J. (2003). Jess, the expert system shell for the java

platform, v. 6.1a4 users manual. [Online]. Available at: http://

herzberg.ca.sandia.gov/jess/

Gasevic, D., Djuric, D., Devedzic, V., & Damjanovic, V. (2004a).

Converting UML to OWL ontologies. Proceedings of the 13th

international WWW conference (pp. 488489).

Gasevic, D., Djuric, D., Devedzic, V., & Damjanovic, V. (2004b).

Approaching OWL and MDA through technological spaces. Proceed-

ings of the third workshop on software model engineering

WiSME2004 (at seventh international conference on the unified

modeling language: Modeling languages and applications), Lisbon,

Portugal.

Gomez-Perez, A., & Corcho, O. (2002). Ontology languages for the

semantic web. IEEE Intelligent Systems and Their Applications, 17(4),

5460.

Grosof, B. N., Gandhe, M. D., & Finin, T. W. (2002). SweetJess:

Translating DamlRuleML to Jess. [Online]. Available at: http://

ebusiness.mit.edu/bgrosof/paps/sweetjess-wp-050203.pdf

Gruber, T. (1993). A translation approach to portable ontology specifica-

tions. Knowledge Acquisition, 5(2), 199220.

Horrocks, I., Patel-Schneider, P. F., Boley, H., Tabet, S., Grosof, B., &

Dean, M. (2004). SWRL: A semantic web rule language combining

OWL and RuleML, version 0.5 of 19 November 2003. [Online].

Available at: http://www.daml.org/2003/11/swrl/rules-all.htmlIsland, Florida (pp. 517532).

Miller, J., & Mukerji, J. (Eds.). (2003). MDA guide version 1.0. OMG

document: Omg/2003-05-01. [Online]. Available at: http://www.omg.

org/mda/mda_files/MDA_Guide_Version1-0.pdf

MOF 2.0 Query/Views/Transformations. OMG Document ad/2002-04-10.

(2002). [Online]. Available at: http://www.omg.org/docs/ad/02-04-10.

pdf

Neches, R., Fikes, R., Finin, T., Gruber, T., Senator, R. P., & Swartout,

W. R. (1991). Enabling technology for knowledge sharing. AI

Magazine, 12(3), 3656.

Obrenovic, Z., Starcevic, D., & Selic, B. (2004). A model driven approach

to content repurposing. IEEE Multimedia, 11(1), 6271.

Radovic, D. (1996). Objektno orijentisani model znanja ekspertnih sistema,

MS thesis. Belgrade: Department of Electrical Engineering, University

of Belgrade.

Sandia National Laboratories. (2003). Jess: The rule engine for the JavaTM

platform. [Online]. Available at: http://herzberg.ca.sandia.gov/jess/

Seaborne, A. (2004). RDQLa query language for RDF, W3C member

submission. [Online]. Available at: http://www.w3.org/Submission/

RDQL/

Sintek, M., & Decker, S. (2002). TRIPLEa query, inference, and

transformation language for the semantic web Proceedings of the first

international semantic web conference on the semantic web, Sardinia,

Italy (pp. 364378).

Sendelj, R., & Devedzic, V. (2004). Fuzzy systems based on component

software. Fuzzy Sets and Systems, 141(3), 487504.

Achieving knowledge interoperability: An XML/XSLT approachIntroductionA diversity of knowledge representation platforms and toolsOBOAJess/JessGUIOntology languages

A technology for bridging gapsResulting infrastructure for knowledge sharingImplementation detailsXML JessGUIXML JavaDON-OBOA XML bindingTransformations

DiscussionRelated workConclusionsReferences