A Survey of Tools for Mapping and Synchronization of Knowledge from

Legacy Systems

Helio H. L. C. Monte-Alto, Lucas O. Teixeira and Elisa H. M. Huzita

Informatics Department, State University of Maring

a, Av. Colombo 5790, Maring

a, Paran

a, Brazil

Keywords:

OWL Mapping, Knowledge Management, Semantic Web Programming.

Abstract:

Knowledge modeling and manipulation are great challenges in the current knowledge-based systems develop-

ment scenario. Recent development in the area of Semantic Web have arisen with solutions to build intelligent

information systems. However, adapting legacy systems to Semantic Web technologies and standards is not

trivial and demands too much effort from developers. This paper presents a survey to ﬁnd tools to ease cre-

ation, maintenance and persistence of knowledge by means of mapping between existing application or domain

models and OWL ontology concepts. Such tools are intended to be used in a context-aware Global Software

Development (GSD) environment using Semantic Web standards to represent context information.

1 INTRODUCTION

The increasing amount of available information and

the need for effective communication between het-

erogeneous information systems have led many appli-

cations to adopt formal semantics. Moreover, many

software engineers have been trying to improve the

interaction of the application with the user, as well as

ease knowledge-based systems development. This is

possible by taking advantage of the inference capabil-

ities using semantic representation of the application

data.

One of the main issues concerning the adoption

of formal semantics in legacy applications is the difﬁ-

culty to adapt the data to this new approach. There are

many companies which use legacy systems that are

important for them. Requiring such companies to ac-

quire new information systems comprising the needs

for knowledge management is not desirable. It would

incur in too much additional cost of implementing a

new system, implanting it, and adapting to it.

One point also to observe is that nowadays the

most used approach for data storage is still relational -

or object-relational - databases. However, such tech-

nologies do not support very well many capabilities

that are required by the current software development

scenario. Such requirements include: interoperabil-

ity, reasonability and availability (Berners-Lee et al.,

2001). Several technologies have been proposed to

address most of these requirements. They are sup-

ported by W3C (World Wide Web Consortium) and

adopt an approach often known as the Semantic Web

(Berners-Lee et al., 2001).

The main Semantic Web standards for semantic

representation are the following: RDF (Resource De-

scription Framework), RDFS (or RDF Schema) and

OWL (Web Ontology Language). RDF is a foun-

dation for processing metadata, providing interoper-

ability between applications that exchange machine-

understandable information on the Web (Swick and

Lassila, 1999). RDFS is an ontology language that

provides a simple vocabulary for knowledge represen-

tation using RDF (Guha and Brickley, 2004). OWL is

an extension of RDFS, which includes a more com-

plex vocabulary for knowledge representation with

formal semantics (W3C OWL Working Group, 2009).

The OWL vocabulary is based on Description Log-

ics (DL), which allows knowledge representation by

means of descriptions of the domain terminology

(Terminology Box, or TBox) and the information as-

serted based on the terminology (Assertion Box, or

ABox).

Although Semantic Web technologies offer sev-

eral features - mainly interoperability and reasonabil-

ity - there is still the issue of adapting legacy applica-

tions to them. There are many frameworks, such as

Jena (Carroll et al., 2004), Sesame (Broekstra et al.,

2002) and OWL API (Bechhofer et al., 2003), with

focus on manipulating RDF and OWL data. How-

ever, there are few mature tools that offer capabili-

ties to create and manipulate such knowledge repre-

sentation based on existing application and domain

157

H. L. C. Monte-Alto H., O. Teixeira L. and H. M. Huzita E..

A Survey of Tools for Mapping and Synchronization of Knowledge from Legacy Systems.

DOI: 10.5220/0004436001570164

In Proceedings of the 15th International Conference on Enterprise Information Systems (ICEIS-2013), pages 157-164

ISBN: 978-989-8565-60-0

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

models, such as POJOs, relational databases, ER dia-

grams, UML diagrams, etc.

Our main goal is to ﬁnd a solution to map an ex-

isting application or domain model to knowledge rep-

resentation in OWL notation, i.e. a knowledge base

(KB) speciﬁed by an OWL ontology. Furthermore,

we focus on tools that support automatic persistence

of entities in a KB, i.e. ABox synchronization and

TBox creation and synchronization in a KB. This pa-

per aims to explore some of these tools and ﬁnd out

if there are any of them that meet the most impor-

tant requirements of our application scenario which is

a context-aware Global / Distributed Software Devel-

opment (GSD/DSD) environment.

This paper is structured as follows. Section 2

presents our application scenario and its issues con-

cerning to knowledge management. Section 3 in-

troduces some of the tools and approaches we have

found. Section 4 presents some qualitative compar-

isons among the most suitable approaches for our ap-

plication. Section 5 presents a discussion about the

suitability of the analysed tools in the application sce-

nario, as well as our choice and some ideas to improve

it to better support OWL mapping. Finally, we present

the conclusions and future works.

2 APPLICATION SCENARIO:

DiSEN

The main goal of our research group is to develop

a software engineering environment (SEE) called

DiSEN (Distributed Software Engineering Environ-

ment). It focuses on supporting GSD/DSD, offering

features to support communication, persistence and

collaboration among geographically distributed teams

(Huzita et al., 2007).

Context-awareness and knowledge management

are appropriate approaches to support such environ-

ment. The ﬁrst one intends to improve communica-

tion and collaboration between individuals. It is nec-

essary that individuals who participate in a project

are aware of context information while interacting

(Chaves et al., 2008). Context is any information that

can be used to characterize the situation of entities

that are considered relevant to the interaction between

a user and an application, including the user and the

application themselves (Dey et al., 2001).

One of the main concerns about context-

awareness is the context representation itself. In

(Chaves et al., 2011) it is proposed an OWL ontology

called OntoDiSEN to specify the context information.

Such ontology also speciﬁes a KB for DiSEN since it

holds semantic information about the domain. A key

requirement for realizing context-aware systems is to

give computer systems the ability to understand their

situational conditions. To achieve this, it requires that

contextual information have been adequately repre-

sented for reasoning and machine processing. Ontolo-

gies allow to make inferences about the context, since

it allows explicit semantic representation (Chen et al.,

2004). Therefore, the main characteristic of semantic

information on which we are interested in DiSEN is

the reasonability.

It has also been proposed in (Monte-Alto et al.,

2012) a multi-agent mechanism to implement con-

text awareness, processing and dissemination called

ContextP-GSD (Context Processing on Global Soft-

ware Development). One of the main issues of the

examples implemented with this mechanism is the

difﬁculty to extract the various context information

mainly based on CRUD (Create, Read, Update and

Delete) operations. For example, when using the en-

vironment to allocate participants to projects, it is nec-

essary to take the following steps to capture the con-

text information: (i) detect the event generated by

the user; (ii) traverse the just created entities (cur-

rently implemented as JavaBeans) mapping the in-

formation to ontology assertions, according to On-

toDiSEN’s TBox; (iii) send the assertions to another

agent to store the context information in DiSEN’s KB.

In this case, the problem is the elevated program-

ming and maintainability effort in (ii). Traversing the

objects while mapping their contents into ontology as-

sertions requires several lines of code and too much

burden on the programmer. Furthermore it is neces-

sary to make it for every operation in the environment.

In the current implementation the entities are

mapped to a relational model using JPA (Java Per-

sistence API)

through Java Annotations. Based on

that, we realized that we could possibly use a simi-

lar approach to persist the entities in the ontology. It

would allow the environment to automatically update

the KB, ensuring its consistency with the application

data. Moreover, it would ensure the ontology com-

pleteness related to the application, because it would

grow together with the application model, becoming

more detailed as the mapping becomes more detailed.

Using this new approach, step (ii) would be au-

tomatized in cases where context information is re-

lated to operations that make changes over application

entities. There are context that do not involve such en-

tities, which requires specialized agents to map them

to OWL notation. For example, capturing and pro-

cessing context information about project artifacts -

which are managed by external tools like version con-

http://java.sun.com/developer/technicalArticles/J2EE/

jpa/

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

158

trol systems - or capturing ubiquitous context infor-

mation, like the presence of a speciﬁc user in its work-

place. In these cases, it is necessary speciﬁc handling

to represent the context as ontologies.

In summary, we are interested in a tool that would

allow us to use Java Annotations in order to: (i) auto-

matically persist semantic data (ABox synchroniza-

tion); (ii) automatically create part of the TBox spec-

iﬁcation based on Java Annotations (TBox genera-

tion); and (iii) continuously synchronize the appli-

cation domain model and the ontology TBox (TBox

synchronization).

3 RELATED WORKS

There are many related works focused on Seman-

tic Web application development and ontology-based

systems. Many of them are APIs that provide ways to

handle and persist knowledge, but lack of features to

map it to application code.

Many RDF APIs are available. Some provide ac-

cess to RDF stores, such as the Jena API (Carroll

et al., 2004), the Sesame API (Broekstra et al., 2002)

and RDF2Go

. Most of these APIs are generic and

triple-based, allowing handling RDF triples, although

some of them (e.g. Jena) provide different layers to

ease handling OWL ontologies. One exception is the

OWL API (Bechhofer et al., 2003), which is not based

on RDF graphs.

These APIs provide high-level methods for the

most common data access patterns. It can be observed

three such high-level methods: to read object values,

to write object values and to ﬁnd resources. These ac-

cess patterns correspond exactly to the main manipu-

lation patterns in relational and object-oriented data.

Most of the current works toward mapping existing

models of applications to ontologies apply some de-

sign patterns, such as Active Record and Data Map-

per (Fowler et al., 2002). Fundamentally, these data

access patterns are based on ﬁltering the dataset into

a set of relevant objects and then manipulating these

objects.

Anyway, the existent solutions may be split into

two categories: (i) RDB (relational database) map-

ping and (ii) application code mapping. Some exam-

ples of efforts towards the ﬁrst category are given be-

low:

• ER2OWL (Fahad, 2008) is a framework that

transforms extended entity-relationship diagram

(ERD) into OWL ontology by using a set of pre-

deﬁned rules.

http://rdf2go.ontoware.org

• D2R (Bizer and Cyganiak, 2006) is a system

which exports relational databases to RDF. This

is achieved by assigning URIs to the entries of the

database and automatically generating a schema

for them.

• R2RML (Das et al., 2011) is an ongoing project

of W3C RDB2RDF Working Group to deﬁne

a language for expressing customized mappings

from relational databases to RDF datasets.

Although these approaches are interesting, there

are some issues that make them rather inappropriate

for our application scenario. As we intend to main-

tain some synchronization between the current sys-

tem model and the ontology, there is a problem be-

cause such approach depends on converting data and

schema of the RDB continuously to RDF representa-

tion. It may generate some overhead because it will

be necessary to persist the data primarily in the RDB

and then later map this data to RDF. Moreover, the

current approaches, except for ER2OWL, are only ca-

pable to map from RDB to RDF, whereas we intend

to use OWL.

ER2OWL is an interesting approach, however it

is necessary to maintain a mapping from the ERD

model of the domain to the RDB model, implying in

an additional layer of data synchronization and redun-

dancy. There are some efforts concerning the mainte-

nance of such mapping, such as the framework pre-

sented in (An et al., 2008). It uses Round-Trip En-

gineering (RTE), a process for synchronizing models

by keeping them consistent, thus changes in the re-

lational model are synchronized with the conceptual

model (CM). Similarly, such approach may be used

to synchronize the CM (in this case, an ERD) with

the ontology model. Although this approach incurs

in additional overhead after the persistence operation,

the results show that the additional time is insigniﬁ-

cant (An et al., 2008).

Some solutions that ﬁt in the second category are

given below:

• Jenabean (Cowan, 2008) is a framework that

binds a Java Object speciﬁcally to Jena framework

to persist JavaBeans using RDFS. It uses Java An-

notations to map the objects and does not require

placing any interface or extension in the object-

oriented model, representing a little intrusive de-

sign.

• JASB (Java Architecture for Semantic Bind-

ing) (Calero, 2010) is a framework which uses

Java Annotations for semantic enforcing, which

consist of reclassifying Java objects at runtime by

means of predeﬁned OWL ontologies or SWRL

(Semantic Web Rule Language) rules. It also in-

ASurveyofToolsforMappingandSynchronizationofKnowledgefromLegacySystems

159

Table 1: Qualitative comparisons among Java2OWL, JAOB and JASB.

Feature / technology Java2OWL JAOB JASB

OWL features support Very good Satisfactory Regular

ABox synchronization Full Partial No

Creates TBox from domain model? Yes Yes Yes

TBox synchronization Partial Partial No

Supported APIs OWLAPI OWLAPI Jena

Semantic repositories support OWLDB OWLDB No

SPARQL support No No D/A

License GPL LGPL GPL

cludes a TBox compiler to map the annotated

classes to an ontology schema.

• JAOB (Java Architecture for OWL Binding)

(Malottki, 2008) is a framework, similar to Jen-

abean, that creates OWL ontologies from Java

classes and objects. It uses OWL API instead of

Jena, and it does not require any superclass exten-

sion or previously deﬁned ontology models. Al-

though it is not yet fully implemented, it provides

a good mapping to OWL.

• Java2OWL (Ohlbach, 2012) is another Java soft-

ware library for synchronizing Java class hierar-

chies with OWL concept hierarchies. It is also

based on OWL API. With a few extra annotations

in Java class ﬁles, the Java2OWL library can auto-

matically map Java class hierarchies to OWL on-

tologies. The instances of these Java classes are

automatically mapped to OWL individuals and

vice versa.

There are other approaches that were disconsid-

ered because of the lack of support to OWL, like

RDFBeans

, TRIOO (Fern

andez et al., 2010) and

Texai KB (Reed, 2007). There is also an architec-

ture, proposed in (Paulheim et al., 2011), which al-

lows arbitrary mapping between Java and RDF/OWL

in a non-intrusive way by means of using rules to map

each class. It was disconsidered because we were un-

able to ﬁnd its prototype implementation for testing.

4 ANALYSIS AND EVALUATION

OF THE CURRENT

TECHNOLOGIES

In Section 3 we discussed some possible existent so-

lutions. OntoDiSEN is modeled as an OWL ontology,

thus some of the tools are not appropriate since they

only support mapping to RDF triples.

http://rdfbeans.sourceforge.net/

Therefore we chose three frameworks, which are

those that promise to support OWL: Java2OWL,

JAOB and JASB. Table 1 presents some qualitative

comparisons among these technologies, focusing on

their appropriateness to DiSEN’s scenario.

For our comparison, we chose the following fea-

tures: (i) OWL features support; (ii) the ABox syn-

chronization issue as exposed in Section 2; (iii) the

functionality of creating TBox based on the existing

domain model; (iv) the TBox synchronization; (v) the

supported APIs; and (vi) the possibility of semantic

repositories support. Those features were chosen be-

cause they are basically requirements of our scenario.

It was also included the license for copying and modi-

fying. Fortunately, they are all free software and open

source.

4.1 OWL Features Support

We analysed the OWL features support by taking into

account the most important OWL constructions that

are implemented in the outlined technologies. A good

OWL support must include most of the following

items (W3C OWL Working Group, 2009):

• Property Axioms: property domain and range,

functional and inverse functional properties, ir-

reﬂexive properties, symmetric and asymmetric

properties, transitive properties and subproperties;

• Class Axioms: subclasses, equivalent classes and

disjoint classes;

• Property Expressions: inverse properties;

• Class Expressions: Boolean combinations (inter-

section, union, complement) and existential and

universal restrictions;

Supporting the mapping of all these features is a

great challenge since there are many semantic differ-

ences between the object-oriented approach and the

Description Logics implemented in OWL. Most of the

class axioms and expressions are possibly the most

difﬁcult to map from Java classes, as it is shown in

Table 2.

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

160

Table 2: Differences between object-oriented approach and the description logics.

Characteristic / approach Java Description logics

Class hierarchy Mono-inheritance Multi-inheritance

Class instances Each object is instance of exactly one

class

An individual can be instance of several

classes

Class equivalence No Yes

Property restrictions /anonymous

classes

Yes

Class union, intersection and com-

plement

No Yes

Runtime evolution class deﬁnitions typically cannot evolve

during runtime

data is integrated from heterogeneous

sources with varying structures where

both schema and data may evolve at

runtime

There are anonymous classes in Java, but not in the same sense as in DL. In DL, anonymous classes are property restrictions that describe a

class of all individuals that satisfy the restrictions. In Java, anonymous classes are inner classes that you can declare inside a method without

naming them.

Java2OWL is the tool that provides the best efforts

to address such problems. To deal with the classes

hierarchy and instances it is proposed in (Ohlbach,

2012) the individual wrappers, which encapsulate an

OWL individual together with several Java objects.

The main problem of this approach is that it is too

much intrusive for legacy systems, in the sense that

Java programs should not work with Java objects in

the usual way, but with individual wrappers.

Another approach, not related to Java2OWL, pro-

posed in (Kalyanpur et al., 2004) is to use Java inter-

faces instead of simple Java classes to be mapped to

OWL, since an interface can inherit from many oth-

ers. This way, each OWL class corresponds to a Java

interface and a JavaBean that implements the access

methods (get/set methods) declared in such interface.

Using this approach it is possible to address the is-

sue of hierarchy, equivalence, union, intersection and

complement. Although this is not as intrusive as the

individual wrappers, there is the need for creating in-

terfaces for every class, which may be done by using

an interface extractor like the one provided in Net-

Beans IDE

. Unfortunately, we have not found any

tools that support Java to OWL mapping using this

approach.

Although not complete, JAOB also provides a

good mapping from Java to OWL. It does not try to

deal with the class axioms and expressions as thor-

ough as (Ohlbach, 2012) and (Kalyanpur et al., 2004),

but provides concise ways to map Java classes to their

representation in OWL.

JASB is much more incomplete than the others.

Moreover, its goal is not to map Java to OWL, but

reclassify Java objects at runtime - which the authors

http://netbeans.org

call semantic enforcing - based on predeﬁned ontolo-

gies or rules.

4.2 ABox Synchronization

The ABox synchronization means that changes in

Java objects’ attributes are forwarded to the corre-

sponding OWL individuals. In other words, the appli-

cation data is continuously and automatically mapped

and persisted in the KB represented by the OWL on-

tology.

The Java2OWL library provides two ways to do it

(Ohlbach, 2012):

• Life Synchronization: in this approach all

changes to the attributes of Java objects are imme-

diately forwarded to the ontology. This is possible

if the annotated Java classes got a ”synchronizer

code” injected. Such code is automatically in-

jected by activating the J2OSynchronizerAgent

or by setting a speciﬁc ﬂag to true.

• Block Synchronization: in this approach the ap-

plication data is only synchronized when a spe-

ciﬁc method is called to commit the changes to

the ontology. It does not require any code to be

injected in the Java classes.

JAOB does not have a specialized synchronization

code. It has only a class called Marshaller which is

responsible for creating an OWL serialization of the

application data. Such serialization includes TBox

and ABox. The main problem of this implementa-

tion concerns the removal operations, because mar-

shalling consists of appending new data to the previ-

ous serialization. Therefore it still has to be improved

to support better synchronization between the appli-

cation data and the KB.

ASurveyofToolsforMappingandSynchronizationofKnowledgefromLegacySystems

161

As JASB does not aim to provide semantic persis-

tence for Java applications, it does not have any mech-

anism to do it.

4.3 TBox Generation and

Synchronization

This feature consists of generating the terminology of

the ontology based on the Java Annotations. It would

allow legacy systems developers to model the ontol-

ogy and map it to application model using only Java

annotations, which is much easier than doing both

things by hand separately. TBox synchronization is

also a desirable feature as it supports software evolu-

tion.

In DiSEN’s scenario we already have a fairly

advanced model of the domain ontology. How-

ever, TBox synchronization would be very convenient

since OntoDiSEN is still under development. It is

possible to use the TBox synchronization with the

Java Annotations to continuously construct the ontol-

ogy together with the application, thus making it eas-

ier to ﬁnd out semantic details that could be added to

the ontology model. Such details could improve the

reasoning capabilities for the KB, enabling smarter

context processing.

Java2OWL assumes the existence of a background

ontology with predeﬁned classes and properties. The

Java2OWL compiler then extend it with OWL classes

generated from Java classes, creating an extended on-

tology (Ohlbach, 2012). However, such background

ontology is optional, which means that it is possible to

create a new TBox from scratch only with the OWL

generated from Java classes. The synchronization is

partially supported by using the previous extended on-

tology as background ontology when it is necessary to

make changes in the Java code.

JAOB and its marshalling approach also generate

TBox based on the Java Annotations. The synchro-

nization can be partially guaranteed because the mar-

shalling operation creates both TBox and ABox. Al-

though JASB does not aim to synchronize application

data with ontologies, it provides a compiler to gener-

ate TBox based on the Java classes.

In every instance, it is necessary to recompile the

TBox if the class structure is changed (e.g. a class

is removed, or a hierarchy relation is changed). Such

changes may end up incurring inconsistencies or loss

of knowledge, depending on the affected structure.

Inconsistency can be resolved by using consistency

checking provided by inference engines, as well as

techniques like defeasible logic (Bao and Honavar,

2004).

4.4 Supported APIs and Semantic

Repositories

For legacy systems without any implementation of se-

mantic features there are not many issues concern-

ing the technologies and APIs which are going to be

used. As there are not many available frameworks and

toolkits for manipulating OWL and most of them are

still under development, the options are very strict.

All of the technologies in question, except JASB, use

OWL API, which is quite mature, although there are

some downsides related to other technologies, like

Jena. However, further comparison of such tools is

out of the scope of this paper.

Our main concern about the supported APIs is

mainly due to the fact that DiSEN already has some

implemented features that use ontologies. These are

currently implemented with Jena framework. Among

the analysed technologies, only JASB supports Jena,

but as it is seen in the previous sections, it is not ap-

propriate for our problem.

Another consideration is SPARQL

(Prud’hommeaux and Seaborne, 2008) and triple

store support. Different from Jena, OWL API

bypasses RDF graphs, i.e. it is not possible to deal

with lower level RDF triples. Therefore, currently

it is difﬁcult to support SPARQL queries and triple

stores - which are high performance solutions for

storing and accessing semantic data - in OWL API.

An alternative for SPARQL and triple stores is

OWLDB (Henss et al., 2009). It consists of an ex-

tension to OWL API which provides native map-

ping of OWL constructs to a database schema with-

out a complex transformation in triples. According

to performance tests reported in (Henss et al., 2009)

the system performs comparably to some triple-based

approaches and even outperforms those on several

queries.

5 DISCUSSION

In the previous section some important characteristics

of the selected solutions were enumerated, in order

to ﬁnd out what would be the most suitable for our

application scenario. Given the good evaluation of

Java2OWL, and considering it is a recent project with

plenty of documentation, it is reasonable to go deeper

into this library. JAOB is also a very interesting ini-

tiative, however it is a discontinued project lacking of

documentation and publications.

The most important issue about adopting

Java2OWL in our scenario is the incompatibility

with the API we are currently using for dealing

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

162

with ontologies. It is necessary to evaluate what

would be the best alternative: creating a new version

of Java2OWL which uses Jena or refactoring the

current code of ContextP-GSD and related projects

to use OWL API. Considering the contribution to

the Semantic Web community, we conclude that

creating a new version of Java2OWL is the best

alternative. It would also allow us to use SPARQL

queries and reasoning features and the various triple

store solutions.

There are still some complex issues related to

OWL, like dealing with multi-inheritance in a less in-

trusive way, dealing with inconsistencies in the ontol-

ogy, and considering open and closed world assump-

tions, that could be better explored as we advance in

working with the tool.

6 CONCLUSIONS AND FUTURE

WORKS

It was presented a qualitative comparison among

some solutions to map application data to OWL rep-

resentation by means of Java Annotations. This facil-

itates the incorporation of semantic features in legacy

systems in a little intrusive way. It also reduces the

programming effort since it eliminates the need to

write code responsible to map speciﬁc Java classes to

OWL concepts for every internal operation which in-

volves manipulating application entities. Another ad-

vantage is that such mapping approach allows any de-

veloper to cumulatively construct the ontology TBox

as the mapping becomes more detailed.

Among many researched approaches, there are

two outstanding technologies: Java2OWL and JAOB.

The ﬁrst one showed to be the most appropriate for

DiSEN’s application scenario, because of its wide

OWL features support and its focus on synchroniza-

tion between application data and OWL. Moreover,

Java2OWL is an ongoing project whereas JAOB is not

being supported.

Although many advantages were encountered in

these approaches, there are still some issues. First,

the mapping does not cover all of the OWL vocabu-

lary yet. Indeed such mapping is not trivial. There-

fore it still needs a lot of improvements. Second,

such approaches only support OWL API, which is not

suitable when it is intended to use SPARQL queries

and/or triple stores. In DiSEN’s case, it becomes

even more serious since there are already many imple-

mented semantic features using Jena instead of OWL

API.

For our case, it is necessary to make a choice:

migrating to OWL API or implementing an exten-

sion of Java2OWL or JAOB to support Jena. The

ﬁrst one is interesting, however it would be neces-

sary to discard the increasing progress of technolo-

gies based on RDF triples, such as SPARQL and triple

stores. Benchmarks like Berlin SPARQL Bench-

mark (BSBM) (Bizer and Schultz, 2009) are contin-

uously exposing the performance improvement made

on triple stores and SPARQL engines. Though there is

the OWLDB alternative for persistence and querying,

it may not be appropriate to ignore all of the current

work being done on triple stores.

Based on that we conclude that the best choice is

to implement an extension of Java2OWL which sup-

ports Jena. It would allow us to take advantage of

triple-based technologies without losing the possibil-

ity of using OWL API and OWLDB. Furthermore, we

intend to gradually improve such tool in order to ad-

just it for our needs.

REFERENCES

An, Y., Hu, X., and Song, I.-Y. (2008). Round-trip engineer-

ing for maintaining conceptual-relational mappings.

In CAiSE, volume 5074 of Lecture Notes in Computer

Science, pages 296–311. Springer.

Bao, J. and Honavar, V. (2004). Collaborative ontology

building with wiki@nt - a multi-agent based ontology

building environment. In Third International Work-

shop on Evaluation of Ontology Building Tools, Hi-

roshima.

Bechhofer, S., Volz, R., and Lord, P. W. (2003). Cooking

the semantic web with the OWL API. In The Seman-

tic Web – ISWC 2003: Second International Seman-

tic Web Conference, Sanibel Island, FL, USA, volume

2870 of Lecture Notes in Computer Science, pages

659–675. Springer, Berlin.

Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The

semantic web. Scientiﬁc American, 284(5):34–43.

Bizer, C. and Cyganiak, R. (2006). Dr2 server - publish-

ing relational databases on the semantic web. Poster

at the 5th International Semantic Web Conference

(ISWC2006).

Bizer, C. and Schultz, A. (2009). The Berlin SPARQL

benchmark. International Journal on Semantic Web

and Information Systems (IJSWIS), 5(2):1–24.

Broekstra, J., Kampman, A., and van Harmelen, F. (2002).

Sesame: A generic architecture for storing and query-

ing RDF and RDF Schema. In Proceedings of the ﬁrst

Int’l Semantic Web Conference (ISWC 2002), volume

2342 of Lecture Notes in Computer Science, pages

54–68, Sardinia, Italy. Springer Verlag.

Calero, J. M. A. (2010). Jasb project.

http://jasb.sourceforge.net/. Accessed May 2012.

Carroll, J. J., Dickinson, I., Dollin, C., Reynolds, D.,

Seaborne, A., and Wilkinson, K. (2004). Jena: im-

plementing the semantic web recommendations. In

Proceedings of the 13th international World Wide

ASurveyofToolsforMappingandSynchronizationofKnowledgefromLegacySystems

163

Web conference on Alternate track papers & posters,

WWW Alt. ’04, pages 74–83, New York, NY, USA.

ACM.

Chaves, A., Wiese, I., da Silva, C., and Huzita, E. (2008).

A model based on context-awareness for information

dissemination in a distributed software development

environment (in portuguese). In XXXIV Conferencia

Latinoamericana de Inform

aica (CLEI 2008), Santa

Fe, Argentina, pages 1365–374.

Chaves, A. P., Steinmacher, I., Leal, G. C. L., Huzita, E.

H. M., and Bias

ao, A. B. (2011). Ontodisenv1: an

ontology to support global software development (in

portuguese). CLEI Electron. J., 14(2).

Chen, H., Finin, T. W., and Joshi, A. (2004). Semantic web

in the context broker architecture. In PerCom, pages

277–286. IEEE Computer Society.

Cowan, T. (2008). Jenabean: Easily bind javabeans

to rdf. http://www.ibm.com/developerworks/java/

library/j-jenabean.html. Accessed May 2012.

Das, S., Sundara, S., and Cyganiak, R. (2011). R2rml: Rdb

to rdf mapping language (w3c working draft).

Dey, A., Abowd, G., and Salber, D. (2001). A concep-

tual framework and a toolkit for supporting the rapid

prototyping of context-aware applications. Human-

Computer Interaction, 16(2):97–166.

Fahad, M. (2008). Er2owl: Generating owl ontology from

er diagram. In Intelligent Information Processing, vol-

ume 288 of IFIP, pages 28–37. Springer.

Fern

andez, S., Berrueta, D., Rodr

ıguez, M. G., and Gayo, J.

E. L. (2010). Trioo - Keeping the Semantics of Data

Safe and Sound into Object-oriented Software. In In-

ternational Conference on Software and Data Tech-

nologies, pages 311–320.

Fowler, M., Rice, D., and Foemmel, M. (2002). Patterns of

Enterprise Application Architecture. Addison-Wesley

Professional.

Guha, R. V. and Brickley, D. (2004). RDF vocabulary de-

scription language 1.0: RDF schema. W3C recom-

mendation, W3C.

Henss, J., Kleb, J., Grimm, S., and Bock, J. (2009). A

database backend for owl. In Proceedings of the

5th International Workshop on OWL: Experiences

and Directions (OWLED 2009), Chantilly, VA, United

States, October 23-24, 2009, volume 529.

Huzita, E., Tait, T., Colanzi, T. E., and Quin

aia, M. (2007).

Disen - a distributed software development environ-

ment (in portuguese). In 1st Workshop de Desenvolvi-

mento Distribu

ıdo de Software.

Kalyanpur, A., Pastor, D. J., Battle, S., and Padget, J. A.

(2004). Automatic mapping of owl ontologies into

java. In SEKE, pages 98–103.

Malottki, J. (2008). Yoshtec kb: Jaob (java architecture for

owl binding). http://wiki.yoshtec.com/jaob. Accessed

May 2012.

Monte-Alto, H. H. L. C., Bias

ao, A. B., Teixeira, L. O., and

Huzita, E. H. M. (2012). Multi-agent applications in a

context-aware global software development environ-

ment. In Distributed Computing and Artiﬁcial Intelli-

gence, volume 151 of Advances in Intelligent and Soft

Computing, pages 265–272. Springer Berlin / Heidel-

berg.

Ohlbach, H. J. (2012). Java2owl - a system for synchronis-

ing java and owl version 1.1. Technical report, Insti-

tute for Informatics, University of Munich.

Paulheim, H., Plendl, R., Probst, F., and Oberle, D. (2011).

Mapping pragmatic class models to reference ontolo-

gies. In ICDE Workshops, pages 200–205. IEEE.

Prud’hommeaux, E. and Seaborne, A. (2008). SPARQL

query language for RDF. W3C recommendation,

W3C.

Reed, S. L. (2007). Semantic annotation for persistence.

In Proceedings of AAAI2007 Workshop on Semantic

e-Science.

Swick, R. R. and Lassila, O. (1999). Resource description

framework (RDF) model and syntax speciﬁcation. su-

persed work, W3C.

W3C OWL Working Group (2009). OWL 2 web ontology

language document overview. Technical report, W3C.

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

164