MQL: A Mapping Management Language for Model-based Databases

Val´ery T´eguiak

, Yamine Ait-Ameur

, St´ephane Jean

and

Eric Sardet

LIAS, ISAE-ENSMA and Poitiers University, Futuroscope, Poitiers, France

IRIT-ENSEEIHT, INPT-ENSEEIHT, Toulouse, France

CRITT Informatique, Futuroscope, Poitiers, France

Keywords:

Mapping, Meta-modeling, Model Transformation, Ontology Engineering, Query Languages.

Abstract:

Nowadays model mapping plays a crucial role in applications manipulating various heterogeneous sources

(data integration and exchange, datawarehouse, etc.). Users need to query a given data source and still obtain

results from other mapped sources. If many model management systems have been proposed that support high-

level operators on model mappings, a more ﬂexible approach is needed supporting the querying of mapping

models and the propagation of queries through mappings. As a solution, we present, in this paper, a mapping-

based query language called MQL (Mapping Query Language). MQL extends the SQL language with new

operators to exploit mappings. We show the interest of this language for the multi-model ontology design

methodology proposed in the DaFOE4App (Differential and Formal Ontology Editor for Application) project.

1 INTRODUCTION

In order to deal with various heterogeneous models

used to represent the same real word domain, sev-

eral mapping languages (Bouquet et al., 2003; Hor-

rocks et al., 2004) or frameworks (Jouault et al., 2008;

Melnik et al., 2003; Moha et al., 2010) have been

proposed. These frameworks support either model

mappings or model transformations. (Bouquet et al.,

2003; Horrocks et al., 2004) allow users to express

correspondences between models and (Jouault et al.,

2008; Melnik et al., 2003; Moha et al., 2010) describe

model transformations. Both approaches aim at per-

forming instance migration. Most of these languages

run in central memory and do not address scalability

when dealing with huge amount of data.

Moreover, with the emergence of the Web, the

amount of models and instances is growing drasti-

cally. Managing mappings in such a context often

requires writing more and more undesirable complex

queries. Therefore, offering solutions for managing

such mappings and instances in a convenient way be-

comes a necessity if one wants to address real sized

problems.

Before year 2000, mappings were implemented by

programs, then (Bernstein, 2003) introduced the no-

tion of Model Management that aimed at reducing the

amount of programming needed for the development

of metadata-intensive applications. More precisely,

(Bernstein, 2003) has provided model management

operators (e.g, compose, diff, merge, match, etc) al-

lowing to manipulate and to manage models and map-

pings as objects. However, to understand and to use

mappings established between source models, design-

ers need to query and to exploit them in order to ex-

press a query on a data source and to obtain data re-

sults from other sources. Thus, a more ﬂexible ap-

proach is needed for supporting the querying of map-

ping model and the propagation of queries through

mappings. As a solution, we propose in this paper

a mapping-based query language named MQL (Map-

ping Query Language). This language is an extension

of traditional SQL query language with new operators

to exploit mappings such as crossing or ﬁltering map-

pings. The interest of this language is shown on a real

use case extracted from the DaFOE4App project.

This paper is organized as follows. Section 2 de-

scribes the use case set up to show the interest of

our proposition. This use case is an ontology design

methodology based on a multi-models approach. Sec-

tion 3 discusses related work. After presenting our

requirements for a new query language in Section 4,

we present, in Sections 5 and 5.1, our MQL language

proposal. Finally, Section 6 concludes this paper and

gives some perspectives of this work.

145

Téguiak V., Ait-Ameur Y., Jean S. and Sardet É..

MQL: A Mapping Management Language for Model-based Databases.

DOI: 10.5220/0003998601450150

In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 145-150

ISBN: 978-989-8565-10-5

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

2 CASE STUDY

In this section, we describe the ontologies de-

sign process led by the DaFOE platform (a

demonstration of this platform is available at

http://testcritt.ensma.fr/dafoe/demo/dafoeV1.zip),

where our MQL language proposal has been applied.

This platform proposes a stepwise approach for

building an ontology starting from text.

2.1 Ontology Design in the DaFOE

The DaFOE platform provides a stepwise methodol-

ogy for building ontologies from text analysis. The

ﬁrst step is dedicated to linguistic analysis (Termi-

nology step) in which users manage linguistic infor-

mation (terms and relations between terms) extracted

with natural language processing tools. Then, a step

for terms disambiguation (TerminoOntology step) is

performed. Finally, a formalization step (Ontology

step) allows users to create classes and

properties

the ontologies. Each step, that is autonomous, has its

own model respectively presented in Figure 1, 2 and

3 and mappings are used to establish correspondences

between these models.

Figure 1: A subset of the Terminology model.

Figure 2: A subset of the TerminoOntology model.

Figure 3: A subset of the Ontology model.

2.2 Persistence of Mappings

In (T´eguiak et al., 2012), we argued that model-

based databases (MBDB) are well adapted for han-

dling mappings in a database context. In that pro-

posal, we have extended MBDB with a repository for

mapping representations as illustrated in Figure 4. In

the resulting meta-model (named core meta-model)

where models are deﬁned by their entities and their

attributes, three main constructors for creating corre-

spondences are available. The ﬁrst one, called mLink,

is used to establish correspondences between models.

The second one, called eLink, allows the user to estab-

lish correspondences between entities of models and

ﬁnally, the aLink uses an expression to write the target

attribute in term of the sources attributes.

Figure 4: Core metamodel.

2.2.1 Terminology to TerminoOntology Step

Considering both Terminology and TerminoOntology

models, a simpliﬁed mapping between these models

consists in:

- Creating a mLink between the Terminology

model and the TerminoOntology model;

- Creating a eLink from the Term entity and the

TerminoConcept entity to express that instances of the

Term entity will be transformed into instances of the

TerminoConcept entity;

- Creating a aLink expressing that an instance of

the TerminoConcept entity has the same label as the

one of its corresponding instances of the Term entity,

preﬁxed by ’tc

’. Another aLink expresses that the

rate of an instance of TerminoConcept entity, equals

to the frequency of the corresponding instance in the

Term entity divided by 100.

2.2.2 TerminoOntology to Ontology Step

For TerminoOntology and Ontology models, a simpli-

ﬁed mapping consists in:

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

146

- Creation a mLink between the TerminoOntology

model and the Ontology model;

- In the context of the previous created mLink be-

tween models, a eLink is created between the Ter-

minoConcept entity and the Class entity to express

that instances of the TerminoConcept entity will be

transformed into instances of the Class entity;

- Creating of a aLink expressing that an instance

of the Class entity has the same label as the one of

its corresponding instance in the TerminoConcept en-

tity. Another aLink expresses that the relevance fac-

tor of an instance of Class entity, equals to the rate

of the corresponding instance in the TerminoConcept

divided by 10.

As an illustration, assume that instances of the

Ontology, TerminoOntology and Terminology mod-

els are represented by Tables 1, 2 and 3 respectively.

Thanks to mappings, a user who queries the Class en-

tity of the Ontology model could want to query both

TerminoConcept of the TerminoOntology model and

Term of Terminology model.

Table 1: Ontology model.

Class

oid c label relevance isAbtract

1000 tc car 0.01 true

1001 tc wheel 0.002 false

1003 electric motor 0.04 false

Table 2: TerminoOntology model.

TerminoConcept

oid tc label rate

600 tc car 0.1

602 motor 0.08

603 motorcycle 0.8

Table 3: Terminology model.

Term

oid t label frequency

300 car 1

301 wheel 2

302 bicycle 30

Putting these mappings all together results in the

MOF-like database repository (Cf. Figure 5) where

i+1

means that the M

level is represented as

instance of the M

i+1

level. The meta-schema part

is dedicated for managing the core metamodel while

schema and instance part a dedicated for managing

business models and data respectively.

3 RELATED WORK

Metadata repository systems manage metadata com-

monly represented as models or meta-models. Such a

repository is often equipped with a MOF-based query

language ((Lakshmanan et al., 2001), MSQL (Grant

et al., 1993), SQL/M (Kelley et al., 1995), OntoQL

(Jean et al., 2006), mSQL (Petrov and Nemes, 2008),

SparQL (Konstantinos et al., 2010)) that provides ca-

pabilities to manipulate both data and meta-data.

Another query language, called mapping oriented

query language ((Melnik et al., 2003), (Konstantinos

et al., 2010)) provide and explicit representation of

mappings between models and offer capabilities to

exploit these mappings when querying data. As lim-

itation, these languages do not allow a user to cus-

tomize the mapping exploitation process. In many

cases, the exploitation process is hidden to the user

and all the graph of interconnected database is used

even if the user wants to use only a sub-part of this

graph. Furthermore, in these languages or frame-

works, the representation of mappings is static and

can not be extended dynamically.

As illustrated in our case study, our proposed

database structure (Cf. Figure 5) is a MOF-like

database that also handles mappings between mod-

els. However, as we will see in the next section, this

database is a bit more complex to manage using clas-

sical SQL queries. This drawback brings us to de-

sign a query language bypassing limitations of lan-

guages presented above and that makes easier map-

pings exploitation using high level operators. So, re-

quirements for such a language are needed.

4 REQUIREMENTS

(Wakeman and Jowett, 1993; Petrov and Nemes,

2008) have investigated requirements for higher-level

query languages managing both data and metadata

(e.g, models). In this section we introduce new re-

quirements speciﬁc to mappings exploitation.

4.1 Handling Complex Queries

Considering the example of Section 2 and assume that

a user wants to retrieve, for the ontology model, all

classes of the ontology model whose relevance factor

is high than 0.01. To achieve this goal, the user can

write the following query:

) SELECT c

label, relevance FROM Class WHERE

relevance ≥ 0.01.

However, if the user also want to retrieve, for

each class, the corresponding object in other models

MQL:AMappingManagementLanguageforModel-basedDatabases

147

Figure 5: Mapping management in the DaFOEApp project.

mapped to the ontology model, two situations may

occur.

On the one hand, if the user knows the mappings

characteristics, so he/she can manually write the ap-

propriate following SQL queries:

) SELECT tc

label, rate FROM TerminoConcept

WHERE rate/10 ≥ 0.01

) SELECT t label, frequency FROM Term WHERE

(frequency/100)/10 ≥ 0.01

and R

queries are translation of the R

query

on the TerminoOntology and Terminology models re-

spectively according to the mappings between these

models.

On the other hand, because mappings character-

istics may be evolved dynamically (new mappings

may be created while existing one may be deleted

or updated, just as in a peer to peer system (Iraklis

and Joemon, 2003)), one needs ﬁrstly to query map-

pings repository for characteristics retrieval, and then

write the appropriate queries based on these charac-

teristics. Such a query requires to access a repository

which represented instances are model and mappings

between models. According to the transitivity capa-

bility of mappings, this access may raise a syntactic

complex query (Cf. Table 4). To simplify, we assume

that additional data should be retrieved from the Ter-

minoOntology model.

Table 5 represents the results of the Q

query.

These results are exploited to generate, for the Ter-

minoOntology model, the query for retrieving data.

As we can observe, the process of unfolding

queries on target models is not easy and may become

complex if one needs to integrate the complete net-

work of mappings. In this case, the user handles by

himself the transitivity capabilities of mappings. A

classical approach to deal with this situation consists

in writing a query translator. So, the user writes a

Table 4: Mapping level queries.

Goals Queries

) SELECT M.oid

Retrieve the FROM Entity E, Model M

Ontology model. WHERE E.label= “Class”

AND E.model= M.oid

) Retrieve mLink where SELECT mLink.oid

the Ontology model is FROM mLink

involved as target WHERE mLink.target in Q

) Retrieve the entities SELECT eLink.source

mapped to Class FROM eLink, Entity E

entity. WHERE eLink.mL in (Q

)

AND eLink.oid= E.oid

AND E.label= “Class”

) Retrieve correspondences SELECT eLink.oid

between entities where FROM eLink

the Class entity is WHERE eLink.mL in (Q

)

involved as target

) Retrieve mapped SELECT E.label,aLink.exp

entities and mapped FROM Entity E, Attribute A,

aLink

attributes (through WHERE E.oid in (Q

)

their expression). AND aLink.eL in (Q

)

AND aLink.target= A.oid

AND A.dom= E.oid

Table 5: Mapping level results.

E.label aLink.expression

TerminoConcept tc label

TerminoConcept rate/10

query (R

query for example) and the translator gen-

erates queries for target models. This queries genera-

tion process is hidden to the user and made implicit.

In other words, this approach assumes that the user

does not know any mappings characteristics usable to

customize the queries generation process.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

148

4.2 Handling Mapping Navigation

Considering more closely the second situation of the

requirement presented in Section 4.1 where users

need to query mappings repository in order to retrieve

mappings characteristics. One can ask itself how to

handle transitivity with query languages such as SQL

for example. This issue refers to the needs to dynam-

ically navigate through the mappings hiding the ex-

ploitation of these mappings. So, a policy for a tran-

sitive subqueries propagation through chains of arbi-

trarily huge mapped models is required because these

models may contain huge amount of data.

4.3 Providing Persistent Mappings

This requirement refers to the problem of memory

saturation, that means avoiding loading into cen-

tral memory big amount of data whose models are

mapped together. Indeed, the mappings repository

may become very huge and therefore expensive (in

response time and memory consumption) for naviga-

tion purposes because, new models (says news mod-

eling steps) could be created dynamically according

to the needs of a particular user. Thus, a persistent-

based approach is required.

5 OUR APPROACH

In this section, we present an overview of the

MQL (Mapping Query Language), our mapping-

based query language proposal for handling mappings

according to previous quoted requirements. This lan-

guage is highly coupled to the Model Based Database

(MBDB) persistence approach presented in (T´eguiak

et al., 2012). For each part (meta-schema, schema,

instance) of the MBDB, the MQL language provides

operators to deﬁne, manipulate and query its content.

Due to space limitation, we only present capibilities

for MQL to query instances and mappings together.

More details are available in a complete version of our

unpublished internal report (T´eguiak et al., 2011).

5.1 Instances and Mappings Together

To address the requirements mentioned in Section 4,

we propose to extend the classical ”SELECT ... FROM

... WHERE ... ” query. In other words, our approach is

and hybrid one that can be used even if a user knows

mappings characteristics or not. As the main purpose

of MQL is to facilitate navigation through mappings,

we introduced optional statements useful for query

propagation in order to get compact syntactic queries.

The following statements are exploited in the queries

translation process to customize this process.

MATCH. Specify the target models in which the

MQL query is propagated at runtime.

FILTER. When propagating a MQL query from a

model m

to another model m

, an entity of m

may

correspond to several entities of m

. In this case, one

may want to restrict the translation so that it applies

only to part of these entities. Such a restriction is de-

scribed using the FILTER clause.

CONFIDENCE. Conﬁdence degrees are often as-

signed to mappings in order to handle fuzzy map-

pings. This clause restricts the propagation of the

MQL query for the models that satisfy the speciﬁed

conﬁdence degree. When speciﬁed, this clause is used

as a threshold to be respected.

With closure. If speciﬁed, the propagation of the

query is achieved through the mappings repository us-

ing the transitive closure in the way that, instances

are retrieved according to the transitivity of available

mappings.

DEPTH. When a MQL query uses the With clo-

sure clause, it may result in a memory saturation or a

bad response time according to the size of the graph

of mappings. The DEPTH clause speciﬁes the depth

exploration of the graph of mappings. For example,

”DEPTH 4” means that the MQL query will be prop-

agated transitively on four consecutive mappings at

most .

mWHERE. Unlike the classical WHERE clause of

a SQL query, the mWHERE clause allows users to

specify predicates to ﬁlter correspondences. In other

words, the mWHERE clause is comparable to a SQL

WHERE clause, but it is dedicated to mapping level.

5.2 MQL in Action

Applied to the Ontology model, the mQ

query

returns data (Cf. Table 6) of the Ontology model

(no mapping statement is used). In other words,

this query is a classical SQL query. For readability

purpose, all the result records are preﬁxed by the

name of its entity.

Table 6: Results of the mQ

MQL query.

Results

SELECT c label, relevance Class(tc car, 0.01)

FROM Class Class(electric motor, 0.04)

WHERE relevance ≥ 0.01 ...

Applied to the Ontology model, the mQ

query

returns data (Cf. Table 7) extracted from both the

Ontology and the TerminoOntology models (the

MQL:AMappingManagementLanguageforModel-basedDatabases

149

MATCH statement has been set to TerminoOntology).

Table 7: Results of the mQ

MQL query.

Results

SELECT c label, relevance Class(tc car, 0.01)

FROM Class Class(electric motor, 0.04)

WHERE relevance ≥ 0.01 TC(motorcycle, 0.8)

MATCH TerminoOntology ...

Applied to the Ontology model, the mQ

query re-

turns data (Cf. Table 8) extracted from both Ontology

and TerminoOntology models (the MATCH statement

for this query has been set to all models using the *

symbol). However due to the DEPTH statement, the

results are limited to 1 transitive propagation. Only

the TerminoOntology model is reachable from the

Ontology model with 1 propagation.

Table 8: Results of the mQ

MQL query.

Results

SELECT c label, relevance Class(tc car, 0.01)

FROM Class Class(electric motor, 0.04)

WHERE relevance ≥ 0.01 TC(motorcycle, 0.8)

MATCH * ...

FILTER *

DEPTH 1

With closure

Applied to the Ontology model, the mQ

query

returns data (Cf. Table 9) extracted from both the

Ontology, TerminoOntology and Terminology mod-

els. Indeed, thanks to the * symbol of the MATCH

statement and with no DEPTH limitation, mQ

propagated to any model transitively reachable from

the Ontology model.

Table 9: Results of the mQ

MQL query.

Results

SELECT c label, relevance Class(tc car, 0.01)

FROM Class Class(electric motor, 0.04)

WHERE relevance ≥ 0.01 TC(motorcycle, 0.8)

MATCH * Term(bicycle, 30)

FILTER * ...

With closure

6 CONCLUSIONS

In this paper, we have presented a mapping-based

query language called MQL that makes easier query-

ing data thanks to available mappings between mod-

els. This language has a knowledge part based on

a core metamodel dedicated models and mappings

representation. One of the main features of our ap-

proach is that this knowledge part can be extended

by evolving the core metamodel. MQL has been im-

plemented for model-based databases, where both in-

stance, metamodel and metametamodel level are per-

sisted in a single database. As perspective of this

work, we are working on the deﬁnition of a bench-

marking scenario for improving performance of our

approach.

REFERENCES

Bernstein, P. A. (2003). Applying model management to

classical meta data problems. In CIDR.

Bouquet, P., Giunchiglia, F., Harmelen, F. V., Seraﬁni, L.,

and Stuckenschmidt, H. (2003). C-owl: Contextualiz-

ing ontologies. In ACM SIGIR’03, pages 164–179.

Grant, J., Litwin, W., Roussopoulos, N., and Sellis,

T. (1993). Query languages for relational multi-

databases. In VLDB.

Horrocks, I., Patel-Schneider, P., Boley, H., Tabet, S.,

Grosof, B., and Dean., M. (2004). Swrl: a semantic

web rule language combining owl and ruleml.

Iraklis, K. and Joemon, J. (2003). An architecture for

peer-to-peer information retrieval. In ACM SIGIR’03,

pages 401–402.

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

tology based database. the ontoql proposal. In SEKE,

pages 166–171.

Jouault, F., Allilaire, F., B´ezivin, J., and Kurtev, I. (2008).

Atl: a model transformation tool. In Science of Com-

puter Programming, pages 31–39.

Kelley, W., Gala, S., Kim, W., Reyes, T., and Graham, B.

(1995). Schema architecture of the unisql/m multi-

database system. In Modern Database Systems.

Konstantinos, M., Nektarios, G., Nikos, B., and Stavros, C.

(2010). Ontology mapping and sparql rewriting for

querying federated rdf data sources. In OnTheMove,

pages 1108–1117.

Lakshmanan, L., Sadri, F., and Subramanian, S. N. (2001).

Schemasql: An extension to sql for multidatabase in-

teroperability. In JTDS.

Melnik, S., Rahm, E., and Bernstein, P. A. (2003). Devel-

oping metadata-intensive applications with rondo. In

Journal of Semantic Web, pages 47–74.

Moha, N., Sen, S., Faucher, C., Barais, O., and J´ez´equel, J.-

M. (2010). Evaluation of kermeta for solving graph-

based problems. In JSTT.

Petrov, I. and Nemes, G. (2008). A query language for mof

repository systems. In OnTheMove, pages 354–373.

T´eguiak, V., Ait-Ameur, Y., and Sardet, E. (2012). Use of

persistent meta-modeling systems to handle mappings

for ontology design. In MOPAS, page To appear.

T´eguiak, V., Ait-Ameur, Y., Sardet, E., and Bellatreche, L.

(2011). MQL: an extension of SQL for mappings

manipulation. Technical report, LIAS.

Wakeman, L. and Jowett, J. (1993). PCTE: the standard for

open repositories. Prentice-Hall, Inc., Upper Saddle

River, NJ, USA.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

150