DOMAIN ONTOLOGIES: A DATABASE-ORIENTED ANALYSIS

ephane Jean, Guy Pierra, Yamine Ait-Ameur

Laboratory of Applied Computer Science (LISI)

National Engineering School for Mechanics and Aerotechnics (ENSMA) - Poitiers

86960 Futuroscope Cedex - FRANCE

Keywords:

Ontology, Semantic Web, Ontology Based Information Systems, Semantic Integration, Data Exchange,PLIB.

Abstract:

If the word ontology is more and more used in a number of domain, the capabilities and beneﬁts of ontology

for Information Systems management are still unclear. Therefore, the usage of ontology-based Information

Systems in industry and services is not widespread. This paper analyses the concept of a domain ontology

from a database perspective. As a result, ﬁrstly, we provide three criteria that distinguish domain ontology

from other existing domain modeling approach which lead us to propose a new deﬁnition of domain ontolo-

gies. Secondly, based on the various approaches of ontology modeling followed by different communities, we

propose a taxonomy of domain ontology. We show how they may be organized into a layered model, called the

onion model, allowing to design and to use the capabilities of each category of ontology in an integrated envi-

ronment. Finally, this paper presents several information systems based on ontology technologies and describe

the kinds of services that should be provided to allow a powerful usage of ontology in data management.

1 INTRODUCTION

Deﬁned by T. Gruber (Gruber, 1993) as an explicit

speciﬁcation of a conceptualization, an ontology may

be considered as a quite new and exciting artefact

in computer science allowing to represent explicitly

meaning. Nowadays, the word ontology is used in

a lot of diverse research ﬁelds including natural lan-

guage processing, information retrieval, electronic

commerce, Web Semantic, software component spec-

iﬁcation and information systems integration. In

this context, several proposals for ontology models

and languages and corresponding operational systems

have been developed in the last decade. The growth

of both the number and the diversity of such models

for ontologies leads to some difﬁculties encountered

by engineers when they need to identify the right on-

tology(ies) and the right ontology model(s) to use or

to apply in practical engineering areas.

Due to the wide domain of usage, the meaning

of the word ontology is of course context-dependent.

Borrowed from philosophy, where it stand for ”a sys-

tematic account of existence”

, the term ontology got

a quite new meaning in technical and computer sci-

ence ﬁelds. In this new context, one may distin-

FOLDOC: http://foldoc.org

guish upper-level or foundation ontologies, the goal

of which is to provide deﬁnition for general-purpose

concepts, such that process, object or event, and to

act as foundation for more speciﬁc domain ontolo-

gies (Niles and Pease, 2001; Gangemi et al., 2003),

and domain ontologies that are tied to a speciﬁc uni-

verse of discourse and model the corresponding do-

main knowledge.

The goal of this paper is to analyse the concept of

a domain ontology in a database perspective. Most

of the usual deﬁnitions, such that the one of the Free

On-line Dictionary of Computing ”an explicit formal

speciﬁcation of how to represent the objects, concepts

and other entities that are assumed to exist in some

area of interest and the relationships that hold among

them” are so broad that they covers most of the pre-

vious information modelling artefacts such that con-

ceptual models, knowledge model or speciﬁcation of

information exchange formats. As a result the high

potential of ontologies for semantic integration is hid-

den, and a number of engineers consider ontology as

a buzzword.

In this paper, we suggest that the above deﬁni-

tion should be reﬁned and we propose three criteria

to distinguish domain ontologies from other informa-

tion modelling artefacts. Such domain ontologies in-

341

Jean S., Pierra G. and Ait-Ameur Y. (2006).

DOMAIN ONTOLOGIES: A DATABASE-ORIENTED ANALYSIS.

In Proceedings of WEBIST 2006 - Second International Conference on Web Information Systems and Technologies - Inter net Technology / Web

Interface and Applications, pages 341-351

DOI: 10.5220/0001246203410351

 SciTePress

troduce a new modelling level in the database ﬁeld

and we propose a taxonomy of the various possible

domain ontologies together with integration scenar-

ios that show how this taxonomy may be helpful for

addressing various data management issues. Then

we discuss what kind of tools, called Ontology-based

Data Management System (OBDMS) would be use-

ful for promoting ontology usage in the data process-

ing community. It is expected that this analysis will

promote the development of new OBDMS and help

engineers and practitioners to choose relevant OB-

DMS in order to solve their business problems. Our

work is different from previous related work (Cullot

et al., 2003; Meersman, 2001) aiming at clarifying

the differences between ontology and database tech-

nologies. The main contribution of this paper are the

following :

• a proposal for criteria that distinguish domain on-

tologies from other domain modeling approaches;

• a new deﬁnition of domain ontology;

• a taxonomy of domain ontology and a layered

model (the onion model) that shows how these dif-

ferent kinds of ontology may cooperate for solving

data processing issues.

This paper is organized as follows. Next section

presents the concept of an ontology by focussing on

three criteria that distinguish ontology from other ex-

isting modeling approach. This suggest a new deﬁ-

nition of domain ontologies. Section 3 describes the

various possible usages of ontologies in data manage-

ment. A database-oriented taxonomy of ontologies is

proposed in section 4 and section 5 proposes an inte-

grated view of these different kinds of domain ontol-

ogy for addressing various data processing problems.

Finally, section 6 describes several OBDMS and com-

pares their capabilities.

2 SPECIFICITY OF DOMAIN

ONTOLOGY AS DOMAIN

MODELS

We propose in this section three criteria that charac-

terize domain ontologies. These criteria suggest a

new deﬁnition of domain ontology. Finally, we dis-

cuss the difference between domain ontologies and

conceptual models.

2.1 Ontology Criteria

From our point of view, a domain ontology is a do-

main conceptualization obeying to the three following

criteria.

1. formal. An ontology is a conceptualization based

on a formal theory which allows to check some

level of consistency and to perform some level

of automatic reasoning over the ontology-deﬁned

concepts and individuals. We note that this crite-

rion excludes most meta-models that do not pro-

vide automatic reasoning capabilities.

2. consensual. An ontology is a conceptualization

agreed upon by a community larger than the mem-

bers involved in one particular application devel-

opment. For instance, The Gene Ontology (GO)

project

is a collaborative effort between more than

10 organisms to address the need for consistent de-

scriptions of gene products. Moreover, users are in-

vited to submit suggestions for improving the GO

ontologies. ISO 13584-compliant (PLIB) product

ontologies follow a formal standardization process

and are published as ISO or IEC international stan-

dards. We note that this criterion excludes most

database, conceptual models which are just tailored

for a particular database application.

3. capability to be referenced. Each ontology-

deﬁned concept is associated with an identiﬁer al-

lowing to refer to this concept from any envi-

ronment, independently of the particular ontology

model where this concept was deﬁned. We note

that this criterion exclude, in particular, all spec-

iﬁcation of information exchange formats, such

that STEP (Standard for the Exchange of Prod-

uct Model Data) Application Protocols (ISO10303,

1994), where entities and attributes may only be

referenced from the speciﬁed exchange structure.

2.2 A Proposed Deﬁnition for

Domain Ontology

These three criteria lead us to propose a new deﬁni-

tion for domain ontology. For us, a domain ontology

is a formal and consensual dictionary of categories

and properties of entities of a domain and the rela-

tionships that hold among them. By entity we mean

being, i.e, anything that can be said to be in the do-

main. The term dictionary emphasizes that any entity

of the ontology and any kind of domain relationship

described in the domain ontology may be referenced

directly, for any purpose and from any context, inde-

pendently of other entities or relationships, by a sym-

bol. This identiﬁcation symbol may be either a lan-

guage independent identiﬁer, or a language-speciﬁc

set of words. But, whatever be the symbol, and un-

like in linguistic dictionary, this symbol denotes di-

rectly a domain entity or relationship, the description

of which is formally stated providing for automatic

reasoning and consistency checking.

http://www.geneontology.org/

WEBIST 2006 - WEB INTERFACES AND APPLICATIONS

342

We show in the next section that the criteria used

for characterizing domain ontologies allow to distin-

guish them with previous kind of concept modeling

like conceptual models and knowledge models.

2.3 Ontologies Vs Conceptual

Models

As both an ontology and a conceptual model deﬁne

a conceptualization of a part of the world, an ontol-

ogy seems similar to a conceptual model. Concep-

tual models respect the formal criterion. Indeed, a

conceptual model is based on a rigorously formal-

ized logical theory and reasoning is provided by view

mechanisms. However, a conceptual model is appli-

cation requirement driven: it prescribes and imposes

which information will be represented in a particu-

lar application (logical model). Two different appli-

cation systems having always at least slightly differ-

ent application requirements, conceptual models are

always different from systems to systems. Thus, con-

ceptual models do not fulﬁll the consensual criterion.

Moreover, an identiﬁer of a conceptual model deﬁned

concept is a name that can only be referenced unam-

biguously inside the context of an information system

based on this particular conceptual model. Thus, con-

ceptual models also do not fulﬁll the capability to be

referenced criterion.

In the same manner, a conceptualization deﬁned in

Knowledge Representation and Artiﬁcial Intelligence

using logic constructors are not, in general, an ontol-

ogy. Such conceptualizations satisfy the formal crite-

rion. Indeed, logic is equipped with formal semantics

that enables automatic reasoning. However, in such

knowledge models, the main goals are the inference

capabilities of the models. Before that the notion of an

ontology emerged, neither mechanisms for referenc-

ing each particular concept of a knowledge model, nor

processes for ensuring a consensus on the concepts

were considered. Therefore, like conceptual models,

such usual knowledge models do not fulﬁll the con-

sensual and the capability to be referenced criterion.

However, data model constructs issued from data-

base design and logic are suitable for ontology mod-

els deﬁnitions. Indeed, several ontology models, like

OWL (Bechhofer et al., 2004), RDFS (Brickley and

Guha, 2004) and KAON (Bozsak et al., 2002) for

description logic and PLIB (Pierra, 2003), DOGMA

(Jarrar and Meersman, 2002) and MADS (Parent

et al., 1999) for database design, are based on con-

structors provided either by database conceptual mod-

els or by artiﬁcial intelligence knowledge base mod-

els. These models add other constructors that enable

to satisfy the consensual criterion (context deﬁnition,

multi instantiation, separation between concept deﬁn-

ition and data structure prescription) and the capabil-

ity to be referenced criterion (URI, GUI).

On the basis of this distinction between ontology

and other concepts models, we study in next section

what ontologies are good for.

3 WHAT ARE ONTOLOGIES

GOOD FOR ?

As stated in the introduction, ontology technologies is

widespread in a lot of diverse application domains and

it may be used in various engineering steps like spec-

iﬁcation, data exchange, data integration and search.

3.1 Speciﬁcation

Two usages of ontologies as speciﬁcation are re-

ported.

The usage of a conceptualization as a speciﬁcation

is the basis of the Model-Driven Architecture (MDA).

A model of the application is ﬁrst deﬁned. This model

is then used to generate the code of the application.

The existing formal link between the speciﬁcation

and the software enables to evolve the code when the

speciﬁcation evolves. Currently, several softwares ad-

dressing similar problems on the same domain are de-

ﬁned using different conceptualizations. This makes

difﬁcult interoperation between these softwares. On-

tology usage is a solution to this problem. Because

ontologies satisfy the consensual criterion, the var-

ious conceptualization corresponding to various do-

main softwares may be connected to a domain ontol-

ogy. Then, softwares can interoperate using accessors

provided by this ontology. This approach is called

ontology-driven software engineering (Tetlow et al.,

2005).

The same approach can be followed in database de-

sign. The proposition of Ontology-Based Database

approach (Pierra et al., 2005) is to use an ontology as

a ﬁrst level of database concepts speciﬁcation. This

ontology is then specialized to deﬁne a conceptual

model. Because all particular systems have partic-

ular requirements, different conceptual models may

be built on the same consensual ontology. The link

between ontologies, conceptual and logical models is

kept inside a database. This architecture enables the

evolution of both the conceptual model and of the on-

tology and provides a common access to information

through the ontology. The advantage of this approach

is to make clear what is common between two sys-

tems, and what is different.

3.2 Data Exchange

A consensual domain conceptualization that can be

referenced may easily be used as an interchange for-

DOMAIN ONTOLOGIES: A DATABASE-ORIENTED ANALYSIS

343

mat for data over this domain (ISO13584-42, 1998;

Chawathe et al., 1994). Unlike usual exchange for-

mat that specify the complete structure of the ex-

changed data and where the meaning of each piece

of data results from its place in the global structure,

ontology-based exchange are very ﬂexible. In such an

exchange, the meaning of each piece of data may be

deﬁned locally, by referencing ontology identiﬁers.

This allow quite different exchange structures to be

soundly interpreted by the same receiving system.

3.3 Data Integration

Domain ontologies is the only artefact that allows to

reconcile, at the semantics level, heterogenous data

source models. When domain ontologies are explic-

itly represented in databases, the integration may be

fully automated even when each source specializes lo-

cally the shared ontology (Bellatreche et al., 2004).

In the Semantic Web approaches, the link between

source and ontology is usually supported by metadata.

The integration is often automatic because the ontolo-

gies used in this process capture and identify concepts

in a formal and unique way.

In natural language processing, the link between

sources and an ontology consists of the words con-

tained in the documents. Most of the words having

context-dependent meaning, the integration process is

often user-assisted to provide meaningful results.

3.4 Data Access and Search

An ontology provides an access to data that reference

the concepts it deﬁnes. Depending on the expressive

power of the ontology model, data may be browsed

using the is-a concept hierarchy, queried using key-

word or with more sophisticated query languages.

Ontologies are also used to query databases. The

approach consists in enriching the queries on the log-

ical model by expressions involving ontology-deﬁned

concepts and expressions (Das et al., 2004).

To sum up, ontology applications are widespread.

For a complete survey describing various usages of

ontology, the interested reader can refer to (Uschold

and Jasper, 1999). However all ontologies are not

similar. Next section proposes a taxonomy of on-

tologies to highlight their differences and the conse-

quences on their usage for the various application do-

mains seen previously.

4 A TAXONOMY OF DOMAIN

ONTOLOGIES

Several orthogonal criteria need to be used to clas-

sify ontologies. The ﬁrst major criterion is the man-

ner of conceptualizing a domain. Indeed, a domain

can be conceptualized as a set of words or as a set

of concepts. This conceptualization way leads to the

distinction between linguistic (taxonomic) ontologies

and conceptual (descriptive) ontologies (Cullot et al.,

2003; Pierra, 2003). Following (Pierra, 2003), we call

Linguistic Ontologies (LO) those ontologies whose

scope is the representation of the meaning of the

words used in a particular Universe of Discourse, in

a particular language. On the other hand, Conceptual

Ontologies (CO) are those whose goal is the represen-

tation of the categories of objects and of the properties

of objects available in some part of the world.

As these two kinds of ontology address quite dif-

ferent problems and ﬁelds, it is fundamental to clar-

ify which kind of ontology is suited in each particular

business context. Before presenting our taxonomy, let

us review some fundamentals of ontologies.

4.1 Fundamentals of Ontologies

Concepts deﬁned in a conceptual ontology can be

classiﬁed in two categories.

Primitive concepts are those concepts ”for which

we are not able to give a complete axiomatic de-

ﬁnition” (Gruber, 1993). Here, the deﬁnition re-

lies on a textual documentation and a knowledge

background shared between the readers. The set of

primitive concepts deﬁne the border of the domain

conceptualized by an ontology. Primitive concepts

are the ground on which all other ontology con-

cepts will be built. The deﬁnition of primitive con-

cepts being always, at least partially, informal, the

only quality criteria, one has for such deﬁnitions,

is that they represent a consensus over some com-

munity. Without such a consensus one cannot asset

the usability of an ontology.

Besides primitive concepts, a number of ontology

models focus on the capability to create conserv-

ative deﬁnitions (Gruber, 1993), i.e, to associate a

new term or a new concept to something that is al-

ready deﬁned by another mean in the ontology un-

der design. This characteristic is the basis of in-

ference mechanisms like automatic classiﬁcation.

Deﬁned concepts are those concepts for which the

ontology provides a complete axiomatic deﬁnition

by means of necessary and sufﬁcient conditions ex-

pressed in terms of other concepts (either primitive

concepts or other deﬁned concepts).

When deﬁned concepts are introduced, concept

equivalence relation needs to be deﬁned in order to

be able to compare, classify or relate deﬁned and/or

primitive concepts.

Concept equivalence can be deﬁned at the class

level. This is the approach followed by models based

on Description Logics (DL) like OWL (Bechhofer

WEBIST 2006 - WEB INTERFACES AND APPLICATIONS

344

et al., 2004) or on the Carin language used in the

PICSEL project (Rousset et al., 2002). For exam-

ple, in PICSEL the concept of Hotel is deﬁned as a

specialization of the primitive concept HousingPlace.

A HousingPlace is deﬁned as a place having associ-

ated buildings, rooms and meal services. A hotel is

then fully deﬁned as those Housing Places which have

more than ﬁve rooms and have only CollectiveBuild-

ing.

Concept equivalence can also be expressed at the

property level. This is the case in models where

derivation functions can be deﬁned. F-Logic (Kifer

et al., 1995) is one of the models supporting this ca-

pability. For example, the property ”boss” relating an

employee to another employee can be derived from

the properties ”belong to” and ”chair”.

Thanks to the distinction between primitive con-

cepts and deﬁned concepts, we are now able to pro-

pose our database-oriented taxonomy of ontologies.

4.2 Canonical Conceptual Ontology

(CCO)

In database design, when conceptual model is de-

ﬁned, ambiguity or possible multi-representation of

the same fact is forbidden. The same approach is

followed for performing exchanges between two dif-

ferent databases. It consists in deﬁning a canonical

vocabulary in which each information in the target

domain is captured in an unique way without deﬁn-

ing any synonymous constructs. For example, in the

STEP project, exchange models are deﬁned in the

EXPRESS language as a STEP Application Proto-

col (AP). These canonic exchange models are used

by industrial users to exchange product descriptions

between different organizations.

Ontologies whose deﬁnitions follow this approach

are called Canonical Conceptual Ontologies.In

CCOs, each domain concept is described in a single

way, using a single description that may include nec-

essary condition. As a consequence, CCOs include

primitive concepts only.

Deﬁning CCOs is the main goal of the ontology

model deﬁned in the PLIB (Part Library) standard

(ISO13584-42, 1998) with a ﬁrst focus on represent-

ing and exchanging formal ontologies of technical do-

mains. Such CCOs use a property-based characteriza-

tion of the involved concepts. This means that a class

is only created when it proves necessary for deﬁning

the domain of some properties. Therefore, in PLIB,

the generalization/specialization concept hierarchies

are rather ”ﬂat”. An example of such an ontology for

electronic components can be found in (IEC61360-4,

1999).

These examples show that usage of CCOs in the

context of data exchange is fruitful. More arguments

are given latter in this paper by studying an exchange

scenario.

4.3 Non Canonical Conceptual

Ontology (NCCO)

In database design, concept equivalence plays an im-

portant (but second-order) role. Each database ad-

dresses a particular domain and deﬁnes a canonic way

of representing any fact about this domain. Then, in

order to achieve a degree of independence with re-

spect to the choice of the concepts offered to users, a

database designer provides views. These deﬁned con-

cepts are speciﬁed using the CREATE VIEW operator

on the basis of the primitive concepts that constitute

the database schema. In deductive database this func-

tionality also exists, provided with derived entities.

So, whatever the construct offered to express con-

cept equivalence, we call Non Canonical Conceptual

Ontologies those ontologies which contain not only

primitives concepts but also deﬁned concepts.

NCCOs are particulary useful when they are used

as global query schemas. For example, in the PIC-

SEL project mentioned earlier, primitive concepts of

local CCOs are expressed as deﬁned concepts for the

primitive concepts of a global ontology used as global

query schema. In the global ontology, concept ex-

pressions and rules expressed on basic concepts of the

tourism domain (HousingPlace, Flight ...) deﬁne a

wide range of terms (Hotel, Bed&Breakfast ...) use-

ful for users to formulate a query on data referenced

by local CCOs.

NCCO constructors are also very useful to deﬁne

mappings between different ontologies. For example,

ﬁgure 1 presents two CCOs of the domain of wines.

The CCO (A) is property oriented while the CCO (B)

is entity oriented.

String

(A)

(B)

Figure 1: Local Wine CCO.

Applying some NCCO operators, issued from a DL

syntax, we can write that:

RED W INE ≡ A WINE  color : red

This axiom states that the concept of B

REDWINE

deﬁned in CCO (B) is equivalent to the concept

WINE deﬁned in CCO (A) restricted by the value

of the color attribute. These primitives have formal

semantics which enables a powerful reasoning mech-

anism implementation in tools named reasoners (e.g,

DOMAIN ONTOLOGIES: A DATABASE-ORIENTED ANALYSIS

345

RACER (Haarslev and M

oller, 2001)). These tools

support mechanisms for concepts and instances clas-

siﬁcation. As a result, the two local CCOs can be au-

tomatically merged into the NCCO of ﬁgure 2. This

NCCO provides a global access to data of the two

CCOs.

String

Figure 2: Integrated Wine NCCO.

In this example, the reasoner has inferred that

all instances of B

RED W INE are instances of

WINE having the value red for the property

color. When these facts are materialized, as it is pro-

posed in OntoMerge (Dou et al., 2003), it become

possible to split the merged ontology into the CCO

(A) and the CCO (B) with the new inferred instances.

This process shows that NCCO constructors are use-

ful for integration tasks.

4.4 Linguistic Ontologies

In other application domains like information re-

trieval or natural language processing, human lan-

guages play a key role. Even in database, natural

languages are used in various places. Indeed, table

and attribute names are chosen to reﬂect their mean-

ing. Moreover, conceptual model documentation is

largely, and in a number of cases completely, ex-

pressed in natural language.

We call Linguistic Ontology (LO) those ontologies

that deﬁne words or contextual usages of words. In

this kind of ontology only words relationships (syn-

onym, hyponym, ...) are available. Words relation-

ships being highly contextual, machine inference in

general needs expert supervision. Moreover, approxi-

mate relationships may be deﬁned.

Wordnet (http://www.cogsci.princeton.edu/wn) is

the most well-known representative of this category

of ontologies. It provides with textual deﬁnitions,

synonymous terms and representations for the vari-

ous concepts that can be denoted by a term. They are

intended to be used as a sophisticated thesauri.

LOs help to recognize conceptual similarities be-

tween sentences even if different terms are used.

Since word meanings are contextual and their rela-

tionships are approximative, wrong similarities may

be produced and results can never be considered as

reliable. An example of LOs usage is given in (Das

et al., 2004). A LO on types of cooking is used to

retrieve more meaningful results on the food served

in a restaurant. Thus, querying the ’latin ameri-

can’ served food retrieves tuples having ’american’ or

’mexican’ as value of type of cooking. A number of

semi-automatic database integration approaches, e.g.,

(Visser et al., 1999), use such linguistic ontologies.

4.5 Discipline Speciﬁc View of

Domain Ontology

Currently, the three categories of ontology mainly

correspond to three different disciplines of computer

science and have few connexions. Ontology models

focus either on CCO, NCCO or LO design.

CCO are mainly considered in the data processing

community. In CCOs, ontology descriptions focus

on primitives concepts characterization and identiﬁ-

cation.

They include precise and complex descriptions of

the primitive concepts. These descriptions are

provided using CCO oriented model constructs.

For example, the DOGMA formalism (Jarrar and

Meersman, 2002), a database inspired ontology

model, provides contextual identiﬁcation of con-

cepts. In the PLIB model, primitive concepts can

be associated with reference to real documents, pic-

tures, usage restrictions .... This model also dis-

tinguishes the rigid properties (Guarino and Welty,

2002), i.e., properties essential for any instance of

a class from those that may or not hold or exist ac-

cording to the role in which an entity is involved.

They don’t contain model mappings. Conse-

quently, the encoding of such conversions is

achieved in an application.

NCCO models were developed by artiﬁcial intelli-

gence community. Therefore, they focus on inference

and concept equivalence.

NCCOs contains conservative deﬁnition of deﬁned

concepts using useful operators like boolean oper-

ators (union of classes ...).

As a rule, they include less precise descriptions for

the primitive concepts. For example, in OWL, a

primitive concept description is limited to a label, a

comment and the properties (roles) that can apply

to its instances.

LOs were designed for computational linguistic. In

LOs (e.g Wordnet), each word is associated with sev-

eral synsets (sets of synonymous) that reﬂects its var-

ious meanings. The imprecision of the conceptualiza-

tion is due to the following facts:

words meaning depends upon a context;

words relationships (e.g synonymy) have no formal

deﬁnition whereas concepts relationships (e.g sub-

sumption) have.

WEBIST 2006 - WEB INTERFACES AND APPLICATIONS

346

5 RELATIONSHIP BETWEEN

ONTOLOGY CATEGORIES

AND PROPOSAL FOR A

LAYERED MODEL

The previous observations lead us to identify some

relationships between CCOs, NCCOs and LOs.

Mappings between CCO might also be deﬁned as

equivalence operators of some NCCO;

NCCO models can use powerful CCO-oriented

model constructs to deﬁne their own primitive con-

cepts;

LOs might deﬁne the various meaning of each word

of a particular language by reference to a NCCO.

This reference would provide a basis for formal

and exact reasoning and automatic translation of

context-speciﬁc terms.

As a further step towards this observation, we ﬁrst

propose a layered model for domain ontology design.

Then, we present an example of usage of this layered

model.

5.1 A Layered Model for Ontology

Design

An often used guide (Noy and McGuinness, 2001)

proposes a seven steps approach for NCCO develop-

ment.

1. Determine the domain and scope of the ontology to

be developed.

2. Consider reusing existing available ontologies that

someone else has developed.

3. List the important terms in the ontology without

considering the possible concepts overlaps they

may lead to.

4. Deﬁne the classes and the associated class hierar-

chy. From the list created in step 3, select the terms

that describe objects having independent existence.

These terms will be classes in the ontology and will

become anchors in the class hierarchy.

5. Deﬁne the properties associated to classes. Indeed,

most of the remaining terms are likely to be prop-

erties of these classes.

6. Deﬁne the constraints (cardinality, domain and

range restrictions) that hold on properties.

7. Create instances of classes in the hierarchy.

This approach exploits the NCCO capability to de-

ﬁne equivalent concepts and thus to integrate several

ontologies addressing the same domain. Since we

claim that NCCOs can beneﬁt from being articulated

with CCOs, we propose an alternative approach for

the development of a NCCO starting from a CCO.

1. The ﬁrst step of the design of an ontology should be

to agree within a community on a CCO. To reach

this agreement, it is required to:

deﬁne clearly what is the domain covered by the

ontology;

choose a powerful model to deﬁne precisely the

primitive concepts existing in the domain and al-

low to explicate the evaluation context of a prop-

erty value (Pierra, 2003);

provide a common understanding of a canonic

set of concepts covering the domain. This con-

ceptualization must accommodate a wide and di-

verse range of technical and business require-

ments shared by the members of the community.

It must reach a wide recognition and acceptance.

2. Within the community of users and/or developers,

on the basis of the deﬁned CCO, a NCCO may be

built for use by members of this community either

to build their own view of the domain or to model

formally all the concepts existing in the target do-

main that are associated with a usual linguistic de-

notation (word or sequence of words). Proceeding

this way ensures the preservation of the capabil-

ity to share and exchange information expressed in

terms of the CCO.

3. In order to allow the use of the deﬁned NCCO for

linguistic inference and/or to provide an end-user

friendly user interface in various languages, a list

of language-speciﬁc terms needs to be deﬁned and

associated to each concept in the NCCO.

According to this alternative approach, ﬁgure 3 il-

lustrates a layered model, called the onion model, of

the resulting domain ontology. A CCO provides a for-

mal basis to model and to exchange efﬁciently the

knowledge of a domain. A NCCO provides mecha-

nisms to relate different conceptualizations made on

this domain. Finally, LO provides natural language

representation of the concepts of this domain, possi-

bly in the various languages where these concepts are

meaningful.

5.2 An Exchange Scenario Based on

Layered Domain Ontology

In database universe, each database uses a canonical

vocabulary. Usually, each database uses a different

canonical vocabulary. Instead of deﬁning a NCCO

covering all the terms of all the sources (see ﬁg 4

(A) ), the onion model suggests that all exchanges are

performed using a consensual CCO. Each source just

contains the descriptions of its own concepts in terms

of the (primitive) concepts of the canonical concep-

tual ontology (see ﬁg 4 (B)). This approach has been

put into practice for databases integration in (Bella-

treche et al., 2004). Notice that if each concept is

DOMAIN ONTOLOGIES: A DATABASE-ORIENTED ANALYSIS

347

CCO

NCCO

Class Expression :

Description Logic

Property Expression :

Derivation function

Property

Expression

F-Logic

Other

…

Figure 3: The onion model of domain ontology.

represented differently in the n participating sources,

and if there exists in each source a mean value of

p concepts, solution (A) needs to implement n ∗ p

mappings in each source, when solution (B) requires

only p mappings in each source. Moreover, this ap-

proach also applies to virtual exchange, i.e, mediator

(Wiederhold, 1991).

(A)

(B)

CCO

CCO CCO

CCO

CCO CCO CCO

CCO

Figure 4: Use of ontologies for canonic data exchange.

This clause, and the above show the interest of ar-

ticulating the three categories of ontologies according

to our onion model across the whole life cycle of do-

main ontologies.

CCOs provide canonical and accurate descriptions

of each concept of a given domain. It pro-

vides sound basis for exchange between different

sources.

NCCO operators are used to interact with other ap-

plications or sources that have already their own

particular ontologies.

LOs provide linguistic capabilities over primitive

and deﬁned concepts.

Next section discusses the various tools that would

be useful to facilitate the use of ontologies in data

management activity and compare with those cur-

rently existing.

6 ONTOLOGY BASED DATA

MANAGEMENT SYSTEM

(OBDMS)

An OBDMS is a suite of tools providing support for

using ontologies and ontology instances data. In data

management, many different functionalities may be

expected from an OBDMS. In this section we list a

set of such functionalities and relate them to our tax-

onomy.

6.1 OBDMS Functionalities

An OBDMS may provide the following functionali-

ties.

F1. Respect of standard. If a formal semantics is

deﬁned for some supported ontology model stan-

dard, this semantics shall be respected by the de-

ﬁned OBDMS.

F2. Handling of exchange format. When an ex-

change format is provided with an ontology

model, import/export ontologies and ontologies

instance data in this format are needed.

F3. Data manipulation. An OBDMS should pro-

vide support to insert, update or delete ontology

concepts and instance data (support of CCO).

F4. Linguistic support. An OBDMS should support

and exploit linguistic-oriented naming and de-

scription of concepts in various languages (sup-

port of LO).

F5. Data querying. An efﬁcient way should be

available for querying both ontologies and on-

tologies data.

F6. Ontology Mapping. An OBDMS should pro-

vide mapping functionalities to integrate differ-

ent ontologies (support of NCCO operators).

F7. Ontology as a speciﬁcation. An OBDMS

should provide the possibility to extract from an

ontology a speciﬁcation of a software or of a

database schema.

6.2 Comparison of Some OBDMS

Implementations

The description of various useful capabilities needed

to facilitate the use of ontologies in data management

being completed, this section reviews three OBDMS

according to the functionalities they offer.

WEBIST 2006 - WEB INTERFACES AND APPLICATIONS

348

6.2.1 RDF Tools

RDF Suite and Sesame are two suites of tools for

RDFS storage and querying. A database is used for

the persistence of the data. These two tools add con-

straints on the RDFS standard. They propose import/-

export module to manage data described in an RDF

syntax. Third-party tools can be associated to this

suite by using this module. Thus, an ontology editor

(e.g. Protege) can be associated to these tools. How-

ever, this editor will not be synchronized with the stor-

age system. Querying data in Sesame and RDF Suite

is performed through the RQL language. There is no

support provided by these tools to integrate different

ontologies or to use them as a speciﬁcation.

6.2.2 PLIB Suite

PLIB Suite (http://www.plib.ensma.fr) is a set of tools

for PLIB ontologies storage, edition, querying and in-

tegration. The exchange format of PLIB ontologies is

EXPRESS physical ﬁle. PLIB Suite include full sup-

port of this format. Currently, ontologies storage rely

on the OntoDB prototype. This prototype is an im-

plementation of the notion of Ontology Based Data-

base presented in section 3. Thus, it stores ontologies,

data and logical models of data deﬁned by extraction

and/or specialization from ontologies. It respects full

deﬁnition of the PLIB standard and its architecture is

ﬂexible enough to manage the evolution of this stan-

dard. This prototype is directly linked to the PLIB Ed-

itor software that can be used to visualize and manage

ontologies and data. Each concept is associated to a

name in different natural languages with synonymous

names. PLIB Editor exploits this natural language

capability to provide a multilingual interface. How-

ever, there is no linguistic inference using synony-

mous names. PLIB Editor provides a query module

that enables to build visually a query on data from the

ontologies. This module relies on the OntoQL query

language allowing to manage and to query both on-

tologies and data. Integration of PLIB ontologies is

enabled when subsumption links are deﬁned between

different ontologies.

6.2.3 RacerPro

RacerPro is an in-memory OWL reasoning system.

RacerPro supports OWL DL almost completely and

includes a graphical user interface to manipulate on-

tologies and data. These data are directly persisted

in an OWL ﬁle. Querying these data is possible

through the query language nRQL. However, mem-

ory demands, concurrency control and scalability of

this implementation are still open issues. As a payoff,

RacerPro offers a full reasoning system that enables

automatic classiﬁcation of concepts and of data. As

we have seen in section 4.3, this functionality is very

useful for integration.

Table 1 summarizes the previous study.

Table 1: Fulﬁlled functionalities by existing OBDMS.

RDF Tools Racer Pro PLIB Suite

F1 partial yes yes

F2 yes yes yes

F3 partial yes CCO

F4 no no partial

F5 yes partial yes

F6 no NCCO partial

F7 no no yes

It appears that none of the existing tools covers the

complete set of functionalities required to implement

the scenario proposed in section 5.2. Therefore, next

section proposes an architecture using existing OB-

DMS to solve this problem.

6.3 An Integrated Architecture to

Implement our Data Exchange

Scenario

Our exchange scenario requires one consensual CCO

managed in an OBDMS providing the possibility to

map NCCOs (F6). Since Racer is the only existing

OBDMS providing this functionality we propose to

use it for this purpose.

Each source deﬁnes its own CCO and manages its

instances. We propose to use PLIB Suite for each par-

ticular source. The use of PLIB Suite for this pur-

pose ensure that a precise description of the concepts

will be available (F3). Moreover it provides a scal-

able repository to store all the data (F5). For linguis-

tic support (F4), it provides the necessary resources to

reference a LO such as Wordnet.

The exchange of data requires the following steps:

1. A source exports its primitive concepts to Racer

(F2). They become the consensual CCO. Notice

that this step requires that PLIB Suite can export

data in OWL format.

2. Other sources may use Racer editor to deﬁne map-

ping between their concepts and the deﬁned con-

sensual CCO.

3. Using the Racer reasoning system, a classiﬁcation

of all the concepts is done. Thus, the consensual

CCO become a NCCO.

4. Data instances to be exchanged between the de-

ﬁned sources are imported into Racer.

5. Using the Racer reasoning system, a classiﬁcation

of these instances is performed.

DOMAIN ONTOLOGIES: A DATABASE-ORIENTED ANALYSIS

349

6. For concepts of a given source under which in-

stances have been classiﬁed, an export of these in-

stances to this source is achieved. This step re-

quires to keep track of the origin of each concept.

Other propositions like (Pan and Heﬂin, 2003) are

made to associate a reasoner with a database. How-

ever the aims of these propositions is to provide a full

reasoning system using a database. Yet, OWL reason-

ing is not fully supported by these systems.

7 CONCLUSION

This paper has investigated the concept of domain on-

tology in a database perspective. Ontology becoming

a buzzword, often used as a new term for already ex-

isting models, we have ﬁrst proposed three criteria to

characterize ontology. A domain ontology must be

formal, i.e, allowing some automatic reasoning and

consistency checking capability, consensual in some

community and able to be referenced from any en-

vironment. These three criteria characterize domain

ontology as a new kind of model in computer science

and lead us to propose a new deﬁnition of domain on-

tology as a formal and consensual dictionary of cate-

gories and properties of entities of a domain and the

relationships that hold among them.

Domain ontology models being mainly developed

by three communities, we have proposed a taxonomy

of domain ontology into CCO, NCCO and LO. After

reviewing the partial domain coverage of these vari-

ous models, we have proposed a layered model, called

the onion model of domain ontology, allowing to de-

sign and to use the capabilities of each category of

ontology in an integrated environment. We have also

discussed under the name of OBDMS what kinds of

services should be provided to allow a powerful usage

of ontology in data management.

Currently there exist neither exchange format nor

OBDMS able to represent and to manage domain on-

tologies corresponding to the complete onion model.

First, we are developing an XML schema that will in-

tegrate both OWL and PLIB capabilities. Second, we

are extending the PLIB Suite to support OWL class

expression constructs using both a connexion with an

OWL reasoner and a representation by SQL views.

Finally, we are working on a query language, called

OntoQL, allowing to query the three layers of the

onion model.

ACKNOWLEDGMENTS

The authors would like to thank the anonymous refer-

ees of this paper. Their relevant comments and sug-

gestions were very helpful to improve the quality of

this paper.

REFERENCES

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

McGuinness, D. L., Patel-Schneider, P. F., and Stein,

L. A. (2004). OWL Web Ontology Language Refer-

ence. World Wide Web Consortium.

Bellatreche, L., Pierra, G., Xuan, D. N., Hondjack, D., and

Ait-Ameur, Y. (2004). An a priori approach for au-

tomatic integration of heterogeneous and autonomous

databases. In DEXA, pages 475–485.

Bozsak, E., Ehrig, M., Handschuh, S., Hotho, A., Maed-

che, A., Motik, B., Oberle, D., Schmitz, C., Staab, S.,

Stojanovic, L., Stojanovic, N., Studer, R., Stumme,

G., Sure, Y., Tane, J., Volz, R., and Zacharias, V.

(2002). Kaon - towards a large scale semantic web.

In EC-WEB ’02: Proceedings of the Third Interna-

tional Conference on E-Commerce and Web Technolo-

gies, pages 304–313, London, UK. Springer-Verlag.

Brickley, D. and Guha, R. (2004). RDF Vocabulary De-

scription Language 1.0: RDF Schema. World Wide

Web Consortium.

Chawathe, S. S., Garcia-Molina, H., Hammer, J., Ireland,

K., Papakonstantinou, Y., Ullman, J. D., and Widom,

J. (1994). The tsimmis project: Integration of hetero-

geneous information sources. In IPSJ, pages 7–18.

Cullot, N., Parent, C., Spaccapietra, S., and Vangenot, C.

(2003). Ontologies : A contribution to the dl/db de-

bate. In SWDB, pages 109–129.

Das, S., Chong, E. I., Eadon, G., and Srinivasan, J.

(2004). Supporting ontology-based semantic match-

ing in rdbms. In VLDB, pages 1054–1065.

Dou, D., McDermott, D., and Qi, P. (2003). Ontol-

ogy translation on the semantic web. In Proceed-

ing of the 2nd International Conference on On-

tologies, Databases and Applications of Semantics,

(ODBASE’2003), pages 952–969.

Gangemi, A., Guarino, N., Masolo, C., and Oltramari, A.

(2003). Sweetening wordnet with dolce. AI Magazine,

24(3):13–24.

Gruber, T. R. (1993). A translation approach to portable on-

tology speciﬁcations. Knowl. Acquis., 5(2):199–220.

Guarino, N. and Welty, C. (2002). Evaluating ontological

decisions with ontoclean. Commun. ACM, 45(2):61–

65.

Haarslev, V. and M

oller, R. (2001). Racer system descrip-

tion. In IJCAR ’01: Proceedings of the First Inter-

national Joint Conference on Automated Reasoning,

pages 701–706. Springer-Verlag.

IEC61360-4 (1999). Standard data element types with as-

sociated classiﬁcation scheme for electric components

- part 4 : Iec reference collection of standard data el-

ement types, component classes and terms. Technical

report, International Standards Organization.

WEBIST 2006 - WEB INTERFACES AND APPLICATIONS

350

ISO10303 (1994). Initial release of international stan-

dard(is) 10303. Technical report is 10303, Interna-

tional Standards Organization.

ISO13584-42 (1998). Industrial automation systems and

integration parts library part 42 : Description method-

ology : Methodology for structuring parts families.

Technical report, International Standards Organiza-

tion.

Jarrar, M. and Meersman, R. (2002). Formal ontology en-

gineering in the dogma approach. In On the Move

to Meaningful Internet Systems, 2002 - DOA/Coop-

IS/ODBASE 2002 Confederated International Confer-

ences DOA, CoopIS and ODBASE 2002, pages 1238–

1254. Springer-Verlag.

Kifer, M., Lausen, G., and Wu, J. (1995). Logical founda-

tions of object-oriented and frame-based languages. J.

ACM, 42(4):741–843.

Meersman, R. (2001). Ontologies and databases: More than

a ﬂeeting resemblance. In OES/SEO Workshop Rome.

(2001).

Niles, I. and Pease, A. (2001). Towards a standard upper on-

tology. In Proceedings of the 2nd International Con-

ference on Formal Ontology in Information Systems

(FOIS-2001), pages 2–9.

Noy, N. F. and McGuinness, D. L. (2001). Ontology de-

velopment 101: A guide to creating your ﬁrst ontol-

ogy. Technical report ksl-01-05 and stanford medical

informatics technical report smi-2001-0880, Stanford

Knowledge Systems Laboratory.

Pan, Z. and Heﬂin, J. (2003). Dldb: Extending relational

databases to support semantic web queries. In PSSS.

Parent, C., Spaccapietra, S., and Zimanyi, E. (1999).

Spatio-temporal conceptual models: data structures +

space + time. In GIS ’99: Proceedings of the 7th ACM

international symposium on Advances in geographic

information systems, pages 26–33. ACM Press.

Pierra, G. (2003). Context-explication in conceptual on-

tologies: The plib approach. In Jardim-Gonalves, R.,

Cha, J., and Steiger-Garao, A., editors, Proceedings

of the 10th ISPE International Conference on Concur-

rent Engineering (CE 2003), pages 243–254.

Pierra, G., Dehainsala, H., A

ıt-Ameur, Y., and Bellatreche,

L. (2005). Base de donn

ees

a base ontologique :

principes et mise en œuvre. Ing

enierie des Syst

emes

d’Information, 10(2):91–115.

Rousset, M.-C., Bidault, A., Froidevaux, C., Gagliardi,

H., Goasdou, F., Reynaud, C., and Safar, B. (2002).

Construction de m

ediateurs pour int

egrer des sources

d’information multiples et h

erog

enes: Picsel. revue

I3, 2(1):9–59.

Tetlow, P., Pan, J., Oberle, D., Wallace, E., Uschold, M., and

Kendall, E. (2005). Ontology Driven Architectures

and Potential Uses of the Semantic Web in Systems

and Software Engineering. World Wide Web Consor-

tium.

Uschold, M. and Jasper, R. (1999). A framework for

understanding and classifying ontology applications.

In Proceedings of the IJCAI99 Workshop on On-

tologies and Problem-Solving Methods(KRR5), Stock-

holm, Sweden, (August 1999).

Visser, P. R. S., Beer, M. D., Bench-Capon, T. J. M., Diaz,

B. M., and Shave, M. J. R. (1999). Resolving onto-

logical heterogeneity in the kraft project. In Database

and Expert Systems Applications, 10th International

Conference, DEXA ’99, pages 668–677.

Wiederhold, G. (1991). Obtaining information from het-

erogeneous systems. In Proceedings of the First

Workshop on Information Technologies and Systems

(WITS’91), pages 1–8. Cambridge MA, MIT Sloan

School of Management.

DOMAIN ONTOLOGIES: A DATABASE-ORIENTED ANALYSIS

351