OntRel: An Optimized Relational Structure for

Storage of Dynamic OWL-DL Ontologies 1Adnan Khalid,

2Syed Adnan Hussain Shah,

3Muhammad Abdul Qadir

Center for Distributed and Semantic Computing

Mohammad Ali Jinnah University, Islamabad

{1adnankhalid,

2syedadnan,

3aqadir }@jinnah.edu.pk

Abstract - Ontology is one of the most important components of semantic based information systems which provides context to the document. Ontology enables us to define relationship between

different terminologies from diverse domains. To interpret this information and perform reasoning we require to store Ontologies in a way that retrieval becomes easy. Ontologies are defined using

OWL (Web Ontology Language) which is based on XML. All the OWL documents are stored in the form of specialized XML files. With the increase in the semantic websites number of Ontologies

describing different domains also grow and with their growth there comes a problem of storing these Ontologies. With the passage of time it has been established that RDBMS (Relational

Database Management Systems) is the most efficient and reliable Data Structure in terms of storage and retrieval. To store OWL documents in RDBMS multiple techniques have been proposed,

but they still lack the advantages of RDBMS. All the databases in RDBMS are closed in nature, but OWL documents are inherently dynamic and semi-structured. So, there is a need to preserve the

dynamic OWL documents in the Relational structure in such an way that no data or relationship is lost and advantages of RDBMS are also gained. This paper briefly presents the survey of existing

ontologies with comparative analysis on the basis of Load Time and Query Performance. Secondly, this paper makes a contribution by proposing a rule based approach to improve the

downside of earlier techniques.

I. INTRODUCTION

Semantic based systems are the future solution of info based

systems. To realize the concept of semantic based systems,

Ontologies were introduced. These ontology documents are

described using RDF, DAML, OWL [1] etc. OWL is a flexible

and expressive language and describes the relationships

between terms more accurately therefore, it is safe to assume

that OWL is going to be an integral part of future semantic

based systems.

As the size of internet is growing with a swift rate, so is the

number of semantic websites using OWL to express the

relationship between their terms. To organize and maintain

relation between these hugely growing data, Ontologies [1]

were introduced. As the data grows the size of the Ontologies

belonging to a particular domains also grow. To store

Ontologies we need an optimized and scalable solution so that

query results can be retrieved properly and quickly. For a long

time RDBMS has proven its worth in terms of persistence and

storage, so we store Ontologies is RDBMS which is the basic

purpose of this paper. Ontologies are written using OWL

language. So we need to store each and every construct of

Figure I: Meta Model of Relationships between ontology constructs

OWL in the database in such a way that no data is lost,

retrieval is easy and quick [2].

Ontology is composed of concepts, properties and

restrictions. The concepts can be enumerations. Properties can

be either data-type properties or object properties. The property

can also be single valued or a multi-valued property. On each

of the properties there are certain restrictions that apply.

Restrictions include All-Values-From, Some-Values-From,

Has-Value and Cardinality Restrictions etc. There are certain

axioms that apply on concepts and properties. They can be

relationships like sub-class-of, inverse-of, disjoint or

equivalent etc. Figure I shows the basic ontology structure

which we have to consider before indexing the OWL document

and at the end we have to assure that all the constructs of basic

ontology are preserved.

The reason for storing OWL Ontologies in Relational

database is that when Ontologies are stored in the form of

tables (Relational Schema) then the old application can easily

access, and interact with the data stored in Ontologies without

ever needing the knowledge of semantic query languages [2].

The Ontologies stored in RDBMS can also interact with non-

semantic data stored in other tables [2].

Before storing Ontologies in a database we need to apply

some rules which will show how the concepts, properties and

all the constructs are stored in the database. The procedure of

applying these rules is known as Transformation [3].

978-1-4244-4873-9/09/$25.00 ©2009 IEEE

Introduction being the first section, the rest of the paper is

divided in the following sections: Section 2 describes the state

of the art survey of existing techniques. Section 3 elaborates

the background of our research proposes OWL-DL indexer

Architecture. Section 4 compares the proposed technique with

the earlier techniques. Section 5 describes the prototype

implementation and section 6 concludes this paper.

II. PREVIOUS WORK

Previously multiple techniques have been proposed to store

Ontologies in RDBMS [2, 3, 4, 5, 6, 7, 8, 9, 10, 11 & 12] and

flat files as well. The important factors that we need to see

while looking at other techniques are that the indexing

technique should preserve the structure of the ontology; it

should be scalable in such a way that the number of tables

should be constant while the number of Ontologies being

indexed by the indexer grows. The last few factors are that

there should be well defined rules for the transformation and

there should be no or minimal data loss after transformation. In

the file based techniques the focus remained on the retrieval

instead of the better storage technique which in return

increased the complexity of retrieval algorithms. In many

papers retrieval techniques have been discussed like Swoogle

[13], sem search [14] etc, which try to provide new ways and

steps by which we can query from ontology documents. There

are other search engines like Hakia [15], Powerset [16] and

Cognition [17] etc which have the magic key word “semantic”

associated with them but even they do not discuss the

organization of the data on which they perform reasoning.

On the other hand the techniques used to store ontology in

RDBMS focused on the mapping / transformation techniques.

During mapping we require both the low level schema

constructs of ontology and RDBMS to define which ontology

component maps to which RDBMS component. As a result of

mapping we get set of rules. While during transformation we

only have transformation rules and ontology. As a result of

transformation we get a database schema.

After doing a comparison between ontology indexing

techniques we have concluded that only the technique

explained in [2] and Jena [5] preserve the ontology in the

optimized and fixed RDBMS schema but, the problem with

Jena is that the database layer is totally transparent from the

user. Jana automatically manages the database end. The

problem with [2] is that they are not completely preserving all

the constructs of the ontology although they have a

static/optimized structure for all the ontologies and any new

ontology can be stored in the same fixed RDBMS schema. The

problem with other techniques is that they create separate set of

tables in the database for each new ontology. The problem with

this methodology is that as the number of ontologies or the

number of concepts in the ontology grow, so do the number of

tables in the database. This makes it difficult for the

programmer to make an application for such dynamic schema.

Furthermore we have compared these techniques using

existing benchmarks provided by Lehigh University

Benchmark and University Ontology Benchmark to estimate

the correctness, completeness, scalability, load time and query

performance of earlier techniques. Correctness means the

degree to which each indexed ontology construct conforms to

its original semantics presented in OWL document.

Completeness means that indexing scheme should preserve all

the constructs of ontology document. Scalability means that the

indexing scheme has an ability to accommodate any extension

in the data and can handle large size ontologies without ever

changing the schema. Load time means the time taken by a

technique to index or preserve large ontology dataset. The time

taken to answer certain queries provided by Lehigh University

Benchmark under different loads is said to be the Load Time.

Table I shows the comparison between existing OWL

ontologies techniques based on the based discussed

benchmarks.

After doing a comparison presented in Table I based on few

benchmarks we have concluded that only the technique

explained in [3], [7] and [14] preserve the ontology in a

scalable way. The techniques discussed in [4], [5] and [6]

index all the constructs of ontology while keeping the

semantics intact. The storage mechanism and process of Jena

[5] is transparent from the user. Jena automatically manages

the database end. The problem with [3] is that they are not

completely preserving all the constructs of the ontology

although they have a static structure for all the ontologies. The

problem with rest of the techniques is that they create separate

set of tables in the database for new ontology. The issue with

this methodology is that as the number of ontologies or the

number of concepts in the ontology grow, so do the number of

tables in the database. This compromises the scalability of the

system. To address these issues we have proposed an Indexing

scheme which consistent, scalable, correctly stores ontologies

and retrieval is quick and efficient.

Technique\

Benchmarks

Co

rrec

tnes

s

Sca

lab

le

Co

nsi

sten

t

Co

mp

lete

nes

s

QUALGDB [2] No No No No

Persistent storage model [3] Yes Yes Yes No

A Tool for storing OWL... [4] Yes No No Yes

Jena [5] Yes No Yes Yes

DDL [6] Yes No No Yes

Minerva [7] Yes No No No

OntoMS [11] Yes No No No

DLDB-OWL [8] Yes No Yes No

DLDB2 [9] Yes Yes Yes No

Instance Store [14] Yes No yes No

Sesame-DB [10] Yes No Yes No

Table I: Comparison of Ontology indexing techniques

III. SEMANTIC WEB INDEXER (PROPOSED TECHNIQUE)

Semantic Web indexer is the integral part of semantic Search

engine as the quality of searched results and complexity of the

query posed, will highly depend on how the information is

organized. The indexer will get the semantic web pages from

the crawled repository and then it applies the rules on the OWL

document. After transformation, the ontology is stored in the

database. Figure II shows the architecture of the proposed

OWL-DL indexer.

In all the earlier techniques the structure of the database was

not fixed except [3] & [5]. Our technique improves this down

side and we have changed the structure in such a way that an

over-all schema remains the same even when the numbers of

Ontologies grow. By changing the structure of the techniques

described in [2, 3, 4, 8 & 14] we can store the Ontologies in

more effective way which will in return make the retrieval

process quick. To elaborate our technique we have defined

following rules which take all the constructs of ontology in

consideration and ensure the smooth conversion of ontology to

RDBMS.

Rule 1: (New Ontology / Parent Ontology Rule) For every

new domain ontology an entry is done in the Onto_tbl. This

table contains the ontology ID, its domain, URI, description,

version, label, comments and prior versionThere is also

importedontology_tbl table which contains the list of

Ontologies imported by certain ontology.

Rule 2: (New Concept Rule) For each known concept a

unique new concept ID is assigned and their entry is done in

the Concept_tbl with the ontology ID as a foreign key with

each concept. Concept_tbl also contains Concept Name, its

URI, label and comments.

Rule 3: (Property/ Property characteristics Rule) Entry

of every property that applies on certain concept is done in the

Property_tbl. That property can be data-type property or an

Object property. A unique property ID is allotted to each

property which acts as a primary key. Property_tbl contains

name of property, property type, Domain, Range and Range

value. Where property type represents Object property or Data

type property. If there are constraints like functional property,

inverse functional property, symmetric property or transitive

property that apply on the property then entry of the property

id is done in the propertyCharacteristics_tbl and against each

property ID a unique flag is set representing the type of

characteristics.

Rule 4: (Object Property Rule) If the property type

represents that it is a Object property in the Property_tbl then

concept ID entry is done under Domain Concept ID on which

property is applied. Similarly concept ID entry is done under

Range Concept ID which is defined as range in ontology.

Rule 5: (Data-type Property Rule) If property type

represents data-type property then domain still represents a

concept but, the range of this property represents ID of the

XSD datatype.

Rule 6: ({SubPropertyOf, InverseProperty,

EquivalentProperty} Rule) If the property is SubPropertyOf,

InverseOf or EquivalentOf some other property then the entry

of their relation is done in SubPropertyOfAxiom_tbl,

InverseProperty_tbl or EquivalentProperty_tbl respectively.

Rule 7: (Known {Sub Class Of, Complement Of,

Equivalent Of, Disjoint with} Rule) If there is a SubClassOf,

ComplementOf, EquivalentOf or Disjointwith relationship

between two concepts then to maintain the relationship an

entry of Parent Concept ID, Complement Concept ID,

Equivalent Concept ID or Disjoint Concept ID is done against

a Concept ID in SubClassOfAxiom_tbl,

ComplementOfAxiom_tbl, EquivalentOfAxiom_tbl or

DisjointWithAxiom_tbl respectively. Where all the concept

IDs act as foreign keys.

Rule 8: (Anonymous {Sub Class Of, Complement Of,

Equivalent Of, Disjoint with} Rule) If a class is a

SubClassOf, ComplementOf, EquivalentOf or Disjointwith an

Anonymous class then to maintain the relationship an entry of

Anonymous Parent Concept ID, Anonymous Complement

Concept ID, Anonymous Equivalent Concept ID or

Anonymous Disjoint Concept ID is done against a Concept ID

in SubClassOfAxiom_tbl, ComplementOfAxiom_tbl,

EquivalentOfAxiom_tbl or DisjointWithAxiom_tbl

respectively. Where all the concept IDs act as foreign keys.

Rule 9: (Anonymous Concept Intersection Rule) If there

is a Intersection relationship between Anonymous concepts to

make a new known concept then to preserve the relationship

multiple entries of Anonymous concept IDs are done against

a Concept in Intersection_tbl, where Anonymous concept IDs

are multiple Anonymous concepts defining the Intersection

relation. In this scenario, IsAnonymous field will be true in

Intersection_tbl.

Rule 10: (Anonymous Concept / Anonymous

Enumeration Rule) For each Anonymous concept a unique

new Anonymous concept ID is assigned and their entry is done

in the AnonymousConcept_tbl with the ontology ID as a

foreign key with each concept. Anonymous Concept can be

Anonymous {Union, Intersection, Complement, Enumeration

or Restriction} so, AnonymousConcept_tbl also contains an

ID and Flags for each type of Anonymous relationship it can

have. If the flag is true then ID will contain an ID which will

be a foreign key from Anonymous{Union, Intersection,

Complement, Restriction}_tbl. If a Anonymous concept is an

Enumeration of other individuals then unique Individual ID is

Figure II: Ontology Indexer Architecture

assigned to each individual and entry about their relationship is

done in AnonymousEnumeration_tbl where AEnumID acts as

a foreign key.

Rule 11: (Anonymous Concept {Union, Intersection,

Complement} Rule) If we have anonymous concept which is

created by Union, Intersection or Complement relationship

then every AUnionID, AIntersectionID or AComplementID

receives a concept ID which can be Anonymous or known

concept ID. IsAnonymous field represents if a concept is

Anonymous or not. All these relations are stored in

AnonymousUnion_tbl, AnonymousIntersection_tbl or

AnonymousComplement_tbl.

Rule 12: (Anonymous Restriction Rule) For all the

restrictions in OWL document that apply on know or

Anonymous Concepts an entry of restriction is done in

AnonymousRestriction_tbl. This table contains unique

ArestrictionID, Restriction Type, Property ID on which

restriction is applied, Object Concept ID and the restriction

Value.

Rule 13: (Individual / Anonymous Individual Rule) For

all the individuals that exist in the ontology a unique ID is

assigned to each individual and against each individual concept

ID is stored in the Individual_tbl. The combination of concept

ID and Individual ID represent that a certain individual belongs

to a particular concept. If an Individual is Anonymous then its

entry is done in the AnonymousIndividual_tbl where

individual id and concept ID are stored representing the

relationship. This is also isAnonymous field when true means

that a particular individual is Anonymous.

Rule 14: (Individual {SameAs, DifferentFrom,

AllDifferent} Rule) An individual can have sameAs,

differentFrom and AllDifferent relationship with other

individuals. If there is a sameAs relationship between two

concepts then there relationship is stored in the

IndividualSameAs_tbl, where two individual Ids stored against

each other represent the sameAs relationship. DifferentFrom

and AllDifferent relationship between two individuals are

stored in the DifferentFrom_tbl, where two individual Ids act

as a foreign key from individual_tbl.

Rule 15: (Individual Property Individual Relation Rule)

Two individuals can have property relationship between each

other. To index such scenario the entries of individual ids will

be made in indivisualproperty_tbl with individualID,

PropertyID and RangeIndividualID. Where PropertyID

represents the relation between IndividualID and

RangeIndividualID.

Rule 16: (Annotation Property Rule) Since OWL-DL

supports Annotation property therefore; we index all the

annotations in annotations_tbl where annotation id is a primary

key. identificationFlag can represent either a Concept, Property

or individual. AnnotationProp and Annotation Value represent

an annotation against ConstrustID which is a foreign key

identified by the field identificationID.

These rules apply on any valid OWL-DL ontology and as

preserve the ontology in the following fixed schema, where

underline filed shows a primary key and the field with * shows

that it is a foreign key.

TABLE 1: anonymousclass_tbl

FIELDS: AnonymousClassID, AnonymousType, AnonymousID*

TABLE 2: anonymouscomplement_tbl

FIELDS: AComplementID, IsAnonymous, ComplementConceptID*,

AnonymousClassID*

TABLE 3: anonymousenumeration_tbl

FIELDS: AEnumID*, EnumIndID*

TABLE 4: anonymousintersection_tbl

FIELDS: AIntersectionID, IsAnonymous, IntersectingConceptID,

AnonymousClassID

TABLE 5: anonymousrestriction_tbl

FIELDS: ARestrictionID, RestrictionTypeID, PropID*,

ObjectConceptID*, IsAnonymous, AnonymousClassID*, `Value`

TABLE 6: anonymousunion_tbl

FIELDS: AnonymousUnionID, IsAnonymous, UnionConceptID,

AnonymousClassID

TABLE 7: concept_tbl

FIELDS: ConceptID, ConceptName, ConceptURI, Label, Comments,

OntologyID*

TABLE 8: differentfrom_tbl

FIELDS: IndID*, DifferentFromIndID*

TABLE 9: disjointaxiom_tbl

FIELDS: ConceptID*, DisjointConceptID*

TABLE 10: enumeration_tbl

FIELDS: ConceptID*, EnumConceptID*

TABLE 11: equivalentaxiom_tbl

FIELDS: EquivalentAxiomID, ConceptID*, IsAnonymous,

EquivalentConceptID*, AnonymousClassID*

TABLE 12: equivalentprop_tbl

FIELDS: PropID*, EquivalentPropID*

TABLE 13: importedontology_tbl

FIELDS: OntologyID*, ImportedOntologyID*

TABLE 14: individual_tbl

FIELDS: IndID, ConceptID*, IndName

TABLE 15: intersection_tbl

FIELDS: IntersectionID, ConceptID*, IsAnonymous,

IntersectingConceptID*, AnonymousClassID*

TABLE 16: inverseofproperty_tbl

FIELDS: PropID*, InverseOfPropID*

TABLE 17: onto_tbl

FIELDS: OntologyID, OntologyName, OntologyURI, OntologyDesc,

Version, Label, Comments, PriorVersion, compatible_with, Domain

TABLE 18: parentproperty_tbl

FIELDS: PropID*, ParentPropID*

TABLE 19: property_tbl

FIELDS: PropID, PropName, PropTypeID, DomainConceptID*,

RangeConceptID*, OntologyID*

TABLE 20: proplogicalchar_tbl

FIELDS: PropID*, LogicalChar*

TABLE 21: sameas_tbl

FIELDS: IndID*, SameAsIndID*

TABLE 22: subclassofaxiom_tbl

FIELDS: SubClassOfAxiomID, ConceptID*, IsAnonymous,

ParentClassID*, AnonymousClassID*

TABLE 23: individualproperty_tbl

FIELDS: IndID*, PropID*, RangeIndID*

TABLE 24: annotations_tbl

FIELDS: AnnotationID, identificationFlag, ConstructID*,

AnnotationProp, AnnotationValue

IV. COMPARATIVE ANALYSIS

We have compared our technique with the existing

techniques on the basis of correctness, scalability, consistency,

completeness and most importantly on the basis of Load Time

and Query Performance. For Load time and Query

performance we have used the data provided by LUBM

(Lehigh University Benchmark) and UOBM (University

Ontology Benchmark). LUBM is considered as a defecto

standard to evaluate the performance of large scale ontology

storage systems.

Lehigh University Benchmark provides a set of 14 queries to

check the query performance and perform completeness test. If

all the queries are answered completely then we can say that

ontology storage technique satisfies the completeness test.

Table II shows the comparison of OntRel with other techniques

on the basis of completeness (percentage of query answered),

which shows that Sesame-DB and DLDB-OWL do not answer

the queries completely. On the other hand OntRel satisfies the

completeness test.

Table-II: Completeness test results using LUBM dataset

Q1&Q14 Q2 Q3-8 Q9 Q10-

12

Q13

DLDB-

OWL100% 82% 30% 0% 33% 67%

Sesame-

DB100% 100% 100% 100% 0% 100%

OntRel 100% 100% 100% 100% 100% 100%

UOBM [20] extends the LUBM by making ontologies more

expressive. Therefore, we have also evaluated OntRel using

UOBM benchmark. The Load Time of DLDB2 and Minerva is

published in [9] using UOBM benchmark. Table III presents

the completeness comparison of OntRel with Minerva and

DLDB2 using UOBM dataset, which shows that OntRel

answers all the queries thereby, satisfying the completeness

test. The problem with DLDB2 and Minerva is that they do not

answer all the queries completely.

Table-III: Completeness test results using UOBM dataset

Q1 Q2 Q3-8 Q9 Q10-12 Q13

DLDB2 100% 95% 100% 0% 100% 80%

Minerva 100% 100% 100% 100% 100% 61%

OntRel 100% 100% 100% 100% 100% 100%

We have computed average performance of all the

techniques and made a ratio table to compare OntRel with

other techniques. The comparison is done for both Lehigh

University Benchmark and University Ontology Benchmark.

The table-IV shows that DLDB2 takes 29% less time to index

the ontologies as compared to OntRel. Although DLDB2 is

scalable yet, it does not clear the completeness test because of

14% data loss on Lehigh University Benchmark. If we

compare OntRel with other techniques on UOBM standard

then DLDB-OWL takes 39% less time and DLDB2 takes 57%

less time to index the ontology but, both these techniques fail

the completeness test as for DLDB-OWL there is 62% data

loss and for DLDB2 there is 23% data loss while answering the

queries. According to our experiments OntRel passes all the

tests and except the Load Time comparison of OntRel with

DLDB2, it out performs all the other techniques by a

significant margin.

Table-IV: Ratio table comparison wrt OntRel

Ratio Table

Lehigh University

Benchmark

University Ontology

Benchmark

(LUBM) Avg. (UOBM- Lite) Avg.

Tec

hn

iqu

e\

Ben

chm

ark

Lo

ad

Tim

e

Qu

ery

Per

form

an

ce

Co

mp

lete

nes

s

Tes

t

Lo

ad

Tim

e

Qu

ery

Per

form

an

ce

Co

mp

lete

nes

s

Tes

t

Persistent

storage model [3]

1.16 NA 0.50 NA NA NA

Minerva [7] 6.83 NA 0.93 1.51 0.87 0.92 DLDB-OWL [8]

2.43 NA 0.36 0.61 1.45 0.38

DLDB2 [9] 0.71 NA 0.86 0.43 7.71 0.77 Sesame-DB

[10] 25.9 103.2 0.79 NA 1.02 0.92

OntRel 1.00 1.00 1.00 1.00 1.00 1.00

V. IMPLEMENTATION

To verify our technique and prove its worth, we have

implemented it using java (JDK1.6) and parsed the OWL file

using Jena API [5]. Figure III shows the main modules in the

OntRel system. At first the ontology document is sent to the

syntax analyser. After verifying the ontology syntax the OWL

document is sent to the OWL Element Identifier which

identifies the class, properties, restrictions and all the other

elements of ontology. Then it sends these elements to the

Element Transformer which transforms the element so that it

can be stored in the database. This transformation is done by

applying some set of rules proposed in this paper. Element

Transformer then sends the transformed elements to the

Storage Manager. The purpose of storage manager is to act as a

layer between database and the transformation process. The

storage manager dynamically stores all the constructs of

ontology in an optimized and scalable database.

Figure IV shows the interface of a tool which indexes the

Ontologies. It is a very simple application. You just have to

select the path where the Ontology is placed. When clicked on

the index files button it will transform the Ontology according

to the above mentioned rules and preserves them in the

database with all its semantics intact. The prototype version of

the OWL indexer is available for testing at [18]. It is deployed

on the Tomcat server. As this is an ongoing research therefore,

it is highly recommended to browse the website using Internet

explorer 6 or 7 only.

We have also implemented a prototype of a query engine

available for testing at [18]. Since this is just a prototype of

query wizard, therefore, it can only handle simple subject,

object and predicate scenarios. Since query engine is out of the

scope of this paper therefore, we have not discussed it any

further.

Figure III: OntRel Architecture

Figure IV: Screenshot of web based ontology Indexer [18]

VI. CONCLUSIONS AND FUTURE WORK

This paper presents a twofold contribution. In the first part

survey of existing ontology indexing techniques is done and all

the techniques are compared against certain benchmarks to find

out there pros and cons. In the second part of this paper

ontology indexing technique (OntRel) is proposed with well

defined rules to cover the drawbacks of earlier ontology

indexing techniques.

To conclude we can say that the technique presented in

this paper (OntRel) is much better than the previous techniques

to store/transform Ontologies in the RDBMS in terms of

storage, retrieval and optimization (static schema). As the

indexed ontology data is always available in RDBMS therefore,

most of the simple queries to find relationship between two

concepts can be answered from only the property table. To

further enhance and prove the worth of OntRel, a prototype

was developed and made public [18].

The future direction to work in this area would be to device

a way to rank the query results according to user’s preferences.

In this paper as a proof of concept, the discussed prototype of

query engine only covered five simple scenarios; another

direction to work on query engine can be finding ways to

introduce complex queries. The major benefit of semantic

search engine is that the user won’t have to go through each

page to get the desired result; the user agent will do this on

user’s behalf. To take the work done in this paper to the next

level would be to define intelligent user Agents. The next

challenging task of our research is to define criteria to map and

merge the same concepts that exist in different ontologies.

REFERENCES

[1] OWL Web Ontology Language Reference. W3C Working Draft, 10 February 2004. http://www.w3.org/TR/owl-ref/, 2004.Last visited in March, 2009.

[2] I. Astrova, N. Korda, and A. Kalja, “Storing OWL ontologies in SQL relational databases”, INTERNATIONAL JOURNAL OF ELECTRICAL, COMPUTER, AND SYSTEMS ENGINEERING VOLUME 1 NUMBER 4 2007 ISSN 1307-5179

[3] D. Jeong, M. Choi1, Y. Jeon, Y. Han,Laurence T. Yang, Y. Jeong, and S.K. Han. “Persistent Storage System for Efficient Management of OWL Web Ontology”, 2007.

[4] R. Garcia, M.M., A. Montes, J.F. “A Tool for Storing OWL Using Database Technology”, (November 2005)

[5] Jena, A.: Semantic Web Framework for Java, http://jena.sourceforge.net/ontology/index.html.Lastvisited:March, 2009.

[6] E. Vysniauskas, and L. Nemuraite, “Transforming ontology representation from OWL to relational database,” Information Technology and Control, vol. 35A, no. 3, 2006, pp. 333-343.

[7] J. Zhou, L. Ma, Q. Liu, L. Zhang, Y. Yu and Y. Pan “Minerva: A Scalable OWL Ontology Storage and Inference System”, Volume 4185/2006, ASWC 2006.

[8] Z. Pan & J. Heflin, “DLDB: Extending Relational Databases to Support Semantic Web Queries”. In Proceedings of Workshop on Practical and Scalable Semantic Web Systems. Florida, USA, 2003.

[9] Z. Pan, X. Zhang & J. Heflin, “DLDB2: A Scalable Multi-perspective Semantic Web Repository”. IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology. Sydney, NSW, 2008.

[10] J. Broekstra, A. Kampman & V. F. Harmelen, “Sesame: A generic Architecture for storing and querying RDF and RDF schema. In Proceedings of the Semantic Web Conference. ISWC. Berlin / Heidelberg.

[11] M.J. Park, J. Lee, C.H Lee, J. Lin, O. Serres and C.W. Chung, “An Efficient and Scalable Management of Ontology”, Advances in Databases: Concepts, Systems and Applications, Volume 4443/2008, 2007.

[12] I. Astrova, A. Kalja, and N. Korda, “Automatic transformation of OWL ontologies to SQL relational databases,” in Proc. IADIS European Conf. Data Mining (MCCSIS), Lisbon, Portugal, 2007, pp. 145-149.

[13] Lei, Y., Uren, S., V.,Motta, E.” SemSearch: A Search Engine for the Semantic Web”. In Staab, S., Studer, R. (Eds.): EKAW 2006. Springer-Verlag Berlin Heidelberg 2006, pp. 238-245.

[14] I. Horrocks, L. Li, D. Turi & S. Bechhofer, “The Instance Store: Description Logic Reasoning with Large Numbers of Individuals”. In International Workshop on Description Logics, DL 2004. Whistler, BC, Canada, 2004.

[15] Assali, A.A.; Lenne, D.; Debray, B. “KoMIS: An Ontology-Based Knowledge Management System for Industrial Safety”, 18th International Conference on Database and Expert Systems Applications, 2007. DEXA apos;07, Volume , Issue , 3-7 Sept. 2007 Page(s):475 - 479

[16] D. Tektonidis, A. Bokma, G. Oatley and M. Salampasis, “ONAR: An Ontologies-based Service Oriented Application Integration Framework”, published in Interoperability of Enterprise Software and Applications in 2006.

[17] B. Park, H. Han and I. Song, “PIES: A Web Information Extraction System Using Ontology and Tag Patterns”, published in LNCS in 2005.

[18] Prototype of OWL indexer and query interface, reference, http://www.starget.info.

[19] Y. Guo, Z. Pan, & J. Heflin. “LUBM: A Benchmark for OWL Knowledge Base Systems”. Journal of Web Semantics. 158-182, 2005.

[20] L.Ma, Y. Yang, Z. Qiu, G. Xie, Y. Pan, and S. Liu. “Towards a complete OWL ontology benchmark”. In ESWC, pages 125– 139, 2006.