PATTERN-BASED ONTOLOGY TRANSFORMATION SERVICE

Ond

rej

ab-Zamazal

1,2

, Vojt

ech Sv

atek

University of Economics, Prague, Czech Republic

Franc¸ois Scharffe

INRIA & LIG, Montbonnot, France

Keywords:

Ontology transformation, Ontology alignment, Pattern detection, Correspondence patterns.

Abstract:

Many use cases for semantic technologies (eg. reasoning, modularisation, matching) could beneﬁt from an

ontology transformation service. This service is supported with ontology transformation patterns consisting

of corresponding ontology patterns capturing alternative modelling choices, and an alignment between them.

In this paper we present the transformation process together with its two constituents: a pattern detection and

an ontology transformation process. The pattern detection process is based on SPARQL and the transfor-

mation process is based on an ontology alignment representation with speciﬁc extensions regarding detailed

information about the transformation.

1 INTRODUCTION

On-demand ontology transformation inside a formal-

ism such as OWL can be useful for semantic applica-

tions. The same conceptualization can be modeled in

diverse ways; (parts of) an ontology thus can be trans-

formed from one modeling choice to another, taking

advantage of ontology patterns for eg. n-ary relations,

speciﬁed values or naming variations. Although the

strictly formal semantics may change, the intended

meaning should be preserved.

In (Svab-Zamazal et al., 2009) are described three

use cases:

• Reasoning. Some features of ontologies cause

performance problems for certain reasoners. Hav-

ing information about these features, possibly

gathered via machine learning methods, we can

transform parts of ontologies with such problem-

atic entities.

• Modularization. Modular ontologies are a pre-

requisite for effective knowledge sharing. How-

ever, if the source and target ontology are mod-

eled using different styles (such as property- vs.

relation-centric), the user faces difﬁculties when

choosing fragments to be imported. modeling

style of the various modules.

• Matching. Most ontology matching (OM) tools

deliver simple entity-to-entity correspondences.

When applying lexical methods on names of enti-

ties, they ignore matching of complex structures.

Complex matching can be mediated by correspon-

dence patterns, which however most OM tools do

not support. Attempting to transform, prior to

matching, an ontology to its variant using trans-

formation patterns, could thus help the OM tools.

These use cases share an ontology transformation

service that makes use of ontology transformation

patterns. In this paper we present details about the

ontology transformation service, based on the detec-

tion and transformation of patterns in ontologies. We

clearly distinguish the modeling of ontology patterns,

used for the detection phase of the transformation ser-

vice, and the transformation itself. The link between

the ontology patterns and the transformation is real-

ized through the use of an alignment between the pat-

tern to be detected and the pattern resulting from the

transformation.

The rest of the paper is organized as follows:

Section 2 presents the overall work-ﬂow of ontology

transformation service. Section 3 details the ontol-

ogy pattern detection phase using an illustrative ex-

ample. Section 4 details the transformation phase us-

ing ontology transformation patterns, following the

same example. The paper is wrapped up with Related

work, Conclusions and Future Work.

Šváb-Zamazal O., Svátek V. and Scharffe F. (2009).

PATTERN-BASED ONTOLOGY TRANSFORMATION SERVICE.

In Proceedings of the International Conference on Knowledge Engineering and Ontology Development, pages 42-47

DOI: 10.5220/0002298300420047

 SciTePress

2 ONTOLOGY

TRANSFORMATION SERVICE

WORK-FLOW

This section presents the work-ﬂow (See Figure 1) of

the ontology transformation service. The transforma-

tion service takes as input an ontology O

and an on-

tology transformation pattern. It outputs a new on-

tology O

resulting from applying an ontology trans-

formation pattern on given ontology O

. An ontol-

ogy transformation pattern consists of an ontology

pattern A, its counterpart ontology pattern B, and an

alignment between them. The ontology pattern A and

the ontology pattern B represent the same conceptu-

alization, but modeled in two different ways. The

alignment between the two ontology patterns is rep-

resented using an ontology alignment language (Eu-

zenat et al., 2007), with several extensions detailed

in Section 4. In a ﬁrst step, an ontology pattern A is

detected in the ontology O

. This procedure is fur-

ther detailed in Section 3. If this ontology pattern

matches, the ontology O

is transformed into an on-

tology O

given the ontology transformation pattern

and generated transformation operations. Section 4

presents this second step in more details.

ontology

pattern A

alignment

ontology transformation pattern

ontology

pattern B

ontology pattern

detection

ontology transformation

Figure 1: Ontology transformation service workﬂow.

During the ontology transformation process, many

ontology transformation patterns from the input li-

brary may be detected and applied. Moreover, an on-

tology transformation pattern may be applied many

times if its ontology pattern A was detected a number

of time in the ontology.

Generally, we do not expect full automation of the

ontology transformation, as there often would be nu-

merous alternatives that only a human could evalu-

ate. We thus aim at semi-automatic transformation

(with appropriate user interface) only. In fact, the

user will be shielded from this transformation service

with the system where (s)he could opt diverse level of

automation of the whole process eg. (not)selecting

and/or (not)changing the ontology patterns applied,

(not)modifying the ontology transformation patterns

if the transformation results are not satisfactory etc. In

this paper we concentrate merely on the core transfor-

mation service while issues such as ontology patterns

ordering, checking the consistency of the newly cre-

ated ontology (a validation step) and user interaction

are future work.

3 PATTERN DETECTION

In this section we detail the ontology pattern detec-

tion phase. This phase takes as input the ontology

pattern A of an ontology transformation pattern and

tries to match this ontology pattern in the ontology

. Each ontology pattern A consists of three inter-

twined aspects: aspects related to the ontology struc-

ture, aspects related to the logical axioms such as dis-

jointness, and aspects related to entities names. For

detection we can use the SPARQL language

We illustrate an ontology pattern detection on a

simple example of ontology pattern A where a class

is deﬁned using an existential restriction

. Let us as-

sume the following conceptualization of “Presented-

Paper”:

: Document w Paper w PresentedPaper ≡ Paper u

∃hasStatus.{Accept}

“PresentedPaper” is restricted on the value “Ac-

cept” for the property “hasStatus”. This is a common

conceptualization (eg. man with married state, paper

with status poster). An alternative to this ontology

pattern is presented in Section 4. The SPARQL query

for detection of this ontology pattern is the following:

SELECT ?y ?p ?a

WHERE {

?y rdfs:subClassOf _:b.

_:b owl:onProperty ?p.

_:b owl:hasValue ?a.

FILTER ( !isBlank(?y) )}

There are several drawbacks using the SPARQL

language for such a detection, see Section 5. In our

current implementation, we use the SPARQL query

engine from the Jena framework

The following example of ontology pattern deals

with “speciﬁed values” representing speciﬁed collec-

tion of values expressing ‘qualities’, ‘attributes’, or

‘features’, see the left-hand side in Figure 3. The cor-

responding SPARQL query is:

SELECT distinct ?y ?c1 ?c2

WHERE {

?c1 rdfs:subClassOf ?y.

?c2 rdfs:subClassOf ?y.

?c1 owl:disjointWith ?c2.

http://www.w3.org/TR/rdf-sparql-query/

All examples come from the conference organization

domain.

http://jena.sourceforge.net/

PATTERN-BASED ONTOLOGY TRANSFORMATION SERVICE

FILTER (

!isBlank(?c1) &&

!isBlank(?c2) &&

!isBlank(?y))}

In order to better detect the “speciﬁed values”

ontology pattern, a lexical constraint on the entities

name is used. An average token-based similarity mea-

sure c is computed as the ratio of the number of mutu-

ally disjoint entities (?c1, .., ?cn) that are subclasses of

?y sharing a token with ?y over the number of all dis-

tinct such entities (?c1, ..., ?cn). If c is higher than cer-

tain threshold it is taken as an instance of the “speci-

ﬁed values” ontology pattern. As we can see in Fig-

ure 3 the token “topic” is present in the superclass as

well as in both subclasses “MultimediaTopic” (MT)

and “ComputerNetworkTopic” (CNT).

The next example of ontology pattern A deals with

“n-ary relations”. In OWL there is direct support for

representing a binary relation. However, it is some-

times more natural to link more than two individuals

in one relation. In order to detect this kind of ontology

pattern, we deﬁne a structural bunch (Svab-Zamazal

and Svatek, 2009) which can be found with the fol-

lowing SPARQL query:

SELECT ?x ?p ?y ?q ?r ?z ?w

WHERE {

?p rdfs:domain ?x.

?p rdfs:range ?y.

?q rdfs:domain ?y.

?q rdfs:range ?z.

?r rdfs:domain ?y.

?r rdfs:range ?w

FILTER (?q!=?r)}

Additionally, a lexical constraint similar to the

aforementioned one can be used to reﬁne the detec-

tion: an average token-based similarity measure c is

computed as the ratio of the number of entities from

a structural bunch that share a token with ?p over

the number of all distinct entities from the structural

bunch except ?y and ?p. If c is higher than a certain

threshold it is taken as an instance of ”n-ary relation”

ontology pattern.

The three ontology patterns presented in this sec-

tion can be classiﬁed as logical patterns. We have in-

cluded them into the ontology transformation pattern

library (ie. for each of them we have an ontology pat-

tern A, an ontology pattern B and an alignment). In

future work we will extend the ontology transforma-

tion library with other ontology patterns like eg. name

patterns (Svab-Zamazal and Svatek, 2008) capturing

awkward naming style.

Once an ontology pattern is detected, the corre-

sponding transformation can be applied as detailed in

Section 4.

4 ONTOLOGY

TRANSFORMATION

In this section we detail the transformation phase of

the ontology transformation service. This phase takes

as input the result of an ontology pattern detection, ie.

bound variable(s) from the corresponding SPARQL

query, and the ontology transformation pattern related

to the detected ontology pattern A. Initially, the entire

ontology O

is copied into a new ontology O

. After-

wards, a set of speciﬁc transformation operations are

generated according to an appropriate ontology trans-

formation pattern. The new ontology O

is then trans-

formed applying the operations. We will detail how

to generate those transformation operations below in

this section. We will also present at the end of this

section three examples illustrating various aspects of

the transformation process.

Note that a given ontology pattern A can be trans-

formed in more than one way, ie. more than one on-

tology pattern B and appropriate alignment for each

ontology pattern A are possible. This issue is our fu-

ture work. The result of the transformation step is a

new ontology O

. It can be useful to enable reverse

transformation from the ontology O

back to the on-

tology O

. This can be realized using OWL-2 annota-

tions materializing information that can be lost during

a transformation.

There are three general rules how to generate spe-

ciﬁc transformation operations:

1. if there is a correspondence between entities of

ontology patterns A and B (entity-to-entity) in the

alignment then REMOVE the old entity and ADD

the new entity with proper name and proper type

There is an instruction how to name new entity in

the alignment.

2. If there is no existing correspondence from an en-

tity in ontology pattern A to any entity of ontology

pattern B in the alignment then REMOVE this en-

tity.

3. If there is no existing correspondence from an en-

tity in ontology pattern B to any entity of ontology

pattern A in the alignment then ADD this entity.

As a result, several ADD/REMOVE operations

are generated to be applied on copied version of O

The REMOVE operation must be done carefully in

order to avoid removing an entity which is used in an-

other part of the original O

. Consistency checking

and user validation need to be performed each time as

Entities types can be different in case there is a corre-

spondence between heterogeneous entities, eg. between a

class and a relation.

KEOD 2009 - International Conference on Knowledge Engineering and Ontology Development

an ontology pattern is applied in order to avoid this

kind of problem.

Alignments between ontology patterns A and B

of the ontology transformation patterns are expressed

using an extension of the ontology alignment for-

mat (Euzenat et al., 2007). This format allows to

model complex correspondence arising when trying

to relate existing ontology patterns. This format also

has the advantage to be supported by many ontology

matching systems

ex:PresentedPaper

ex:Accept

ex:AcceptStatusPaper

ex:hasStatus

Figure 2: Ontology pattern: class using an existential re-

striction.

Next, we illustrate a transformation on the running

example. The ontology transformation pattern is de-

picted in Figure 2. The corresponding alignment is

represented below in the extended alignment format

<alignment:Cell rdf:about="class-by-attribute-value-cell">

<alignment:relation rdf:resource="&alignment;equivalence"/>

<alignment:entity1>

<alignment:Variable>

<rdf:type resource="&alignment;Class"/>

<alignment:var_id>?x</alignment:var_id>

<transf:resourceName>

<rdf:Seq>

<rdf:li>?a</rdf:li>

<rdf:li>patomat:head_noun(?p)</rdf:li>

<rdf:li>patomat:head_noun(?y)</rdf:li>

</rdf:Seq>

</transf:resourceName>

</alignment:Variable>

</alignment:entity1>

<alignment:entity2>

<alignment:Variable>

<rdf:type resource="&alignment;Class"/>

<alignment:var_id>?y</alignment:var_id>

<alignment:attributeValueCondition>

<alignment:Restriction>

<alignment:onProperty>

<alignment:Variable>

<rdf:type resource="&alignment;Relation"/>

<alignment:var_id>?p</alignment:var_id>

See the ontology alignment initiative:

http://oaei.ontologymatching.org

http://alignapi.gforge.inria.fr/language.html

</alignment:Variable>

</alignment:onProperty>

<alignment:value>

<alignment:Variable>

<rdf:type resource="&alignment;Instance"/>

<alignment:var_id>?a</alignment:var_id>

</alignment:Variable>

</alignment:value>

</alignment:Restriction>

</alignment:attributeValueCondition>

</alignment:Variable>

</alignment:entity2>

</alignment:Cell>

This example is a common pattern in on-

tology alignment (Scharffe, 2009) extended with

transformation-speciﬁc information. In order to bind

variables between ontology patterns and the align-

ment we introduce the class alignment:Variable. Vari-

ables in a correspondence of the alignment format are

bound to variables of an ontology pattern A or B us-

ing alignment:var_id. The alignment format extension

can be used to modify attribute values but not the re-

sources names themselves. We thus make use of an-

other extension transf:resourceName and external func-

tions enabling this transformation.

The transformation function transf:resourceName

contains information how to name a resource in on-

tology pattern B. This function concatenates the list

of entity names given in < rd f : Seq >. In the ex-

ample above, we use the speciﬁc lexical function

patomat:headnoun(?a) which returns the head noun of an

entity name on which all other tokens are depen-

dent. The head noun detection was introduced in

(Svab-Zamazal and Svatek, 2008). Regarding prop-

erty names, we can use several heuristics how to ﬁnd

a main term, eg. for “hasStatus” it would be “status”

where “has” is preﬁx.

In this case, the generation of the transformation

operations gives the following result: REMOVE the

class “PresentedPaper” and ADD the class with name

“AcceptStatusPaper”. These operations result from

applying rule #1. “Accept” is the name of instance ?a,

“Status” is the head noun of property ?p, and “Paper”

is the head noun of class ?y. Then, “hasStatus” and

“Accept” will be removed with REMOVE operations.

There are other alternatives regarding naming of the

new entity “PresentedPaper”. These alternatives can

be captured with the next transf:resourceName function:

<transf:resourceName>

<rdf:Seq>

<rdf:li>patomat:head_noun(?y)</rdf:li>

<rdf:li>"With"</rdf:li>

<rdf:li>patomat:head_noun(?p)</rdf:li>

<rdf:li>?a</rdf:li>

</rdf:Seq>

</transf:resourceName>

PATTERN-BASED ONTOLOGY TRANSFORMATION SERVICE

This will cause naming the entity as ”PaperWith-

StatusAccept”. These options can be offered to the

ﬁnal user for selecting the most appropriate one.

The “speciﬁed values” ontology transformation

pattern is depicted in Figure 3. According to the trans-

formation rules, the following transformation opera-

tions will be generated: REMOVE and ADD opera-

tions for each subclass. Because there are correspon-

dences between heterogeneous entities, classes will

be removed and instances will be added.

ex:Topic

?c1

ex:MT

?a2

?a1

ex:MT

?c2

ex:CNT

Figure 3: Pattern: speciﬁed values.

The “Nary relations” ontology transformation pat-

tern is depicted in Figure 4. According to the transfor-

mation rules, the following transformation operations

will be generated: REMOVE entity ?p, ?q, and ?v

because of rule #2 and REMOVE entity ?r, ?w, and

ADD new entity name according to original names of

?r and ?w in the following way:

<transf:resourceName>

<rdf:Seq>

<rdf:li>patomat:head_noun(?r)</rdf:li>

<rdf:li>patomat:head_noun(?w)</rdf:li>

</rdf:Seq>

</transf:resourceName>

ex:Reviewer

ex:reviewOfPaper

ex:Review

Submission

ex:reviewSubmitted

ex:reviewForPaper

ex:reviewOfPaper

ex:ReviewPaper

ex:Review

ex:Paper

Figure 4: Ontology pattern: speciﬁed values.

5 RELATED WORK

Regarding ontology pattern detection, there are two

related aspects: ontology patterns representation, and

patterns detection. Regarding patterns in ontologies,

here presented ontology patterns are based on re-

sults of Semantic Web Best Practices and Deploy-

ment Working Group

(SWBPD). There are further

activities in this respect like ontology design patterns

http://www.w3.org/2001/sw/BestPractices/

(ODP)

. The SWBPD concentrates on logical pat-

terns which are domain-independent, the ODP con-

siders many diverse kinds of ontology design patterns

(incl. logical patterns, content patterns, reasoning pat-

terns etc.). So far we did not directly reuse ODP pat-

terns but we plan to do so in the close future.

While the purpose of those two activities is to pro-

vide ontology designers with the best practices on

how to model certain situations, we are interested in

detecting these ontology patterns. On the one hand

ontology patterns can emerge by chance or they can

be used intentionally by the ontology designer. In the

latter case, detection of ontology patterns should be

easier. In both cases, since we have in mind an ontol-

ogy transformation we always take an ontology pat-

tern and its one or more alternative variants.

SPARQL enables us to match structural aspects of

ontology patterns by specifying a graph pattern with

variables. But SPARQL is a query language for RDF.

However ontology patterns are rather DL-like concep-

tualizations. Therefore we have to consider a transla-

tion step between DL-like conceptualizations and the

RDF representations which is not unique. In order

to overcome this kind of issue we could use some

an OWL-DL aware query language, eg. SPARQL-

DL(Sirin and Parsia, 2007). However this language

does not support some speciﬁc DL constructs e.g. re-

striction and it is not fully implemented yet. Next,

we should consider not only asserted axioms but also

hidden ones. This could be realized using a reasoner

which could materialize all hidden axioms. Further-

more the SPARQL language is not sufﬁcient for spe-

ciﬁc lexical constraints (such as synonymy or hyper-

onymy). We need to either make some additional

checking (post-processing), or alternatively to imple-

ment a speciﬁc SPARQL FILTER function. Such

FILTER functions could make the SPARQL language

quite expressive however they are also usually com-

putationally expensive (P

erez et al., 2006). It raises

a question of right balance between the expressiv-

ity of the query language (here it holds for work-

ing with synonyms/hyperonyms in SPARQL query)

and computational efﬁciency. By now, we use a two-

phase process for detection of ontology patterns: a

SPARQL query for the structural aspects and then a

post-processing of the results for lexical constraints.

In (Svab-Zamazal and Svatek, 2008), the authors

worked on the detection of ontology name patterns.

These name patterns will be included into the ontol-

ogy transformation pattern library as a speciﬁc kind of

negative patterns. Furthermore, we reuse several con-

cepts for detection and transformation (lexical pro-

cessing).

See e.g. http://ontologydesignpatterns.org

KEOD 2009 - International Conference on Knowledge Engineering and Ontology Development

Regarding the transformation part of our work, an

immediate solution would be to use XSLT. However,

XSLT transformations are not directly applicable to

RDF because of its alternative representations. XS-

PARQL (Akhtar et al., 2008) overcomes this limita-

tion by combining SPARQL with XSLT. XSPARQL

constitutes an alternative to detecting and transform-

ing ontology parts as we propose in this paper. It how-

ever mixes the detection and transformation parts. As

already mentioned in the introduction of this paper

we need to keep a clear distinction between the pat-

tern detection and the transformation process. For this

reason, we also do not directly base on other related

approach, the OPPL(Iannone et al., 2008), which is

a language for detecting and transforming ontology

patterns. Furthermore there is no support for lexical

aspect in this last approach.

Another related approach is GeRoMeSuite (Ken-

sche et al., 2007), a system for models management

(such as XML Schema, OWL, SQL) that implements

matching, merging and composing of models. It also

supports many kind of transformations such as trans-

formation of data, identiﬁers, dates, and transforma-

tion between different formalisms. This work how-

ever does not consider transformations between het-

erogeneous conceptualizations and detection of ontol-

ogy patterns. Furthermore, a lot of attention has been

paid to transformation between different modeling

languages, transformation based on meta-modeling

using UML, and speciﬁcally transformation of data-

models (Omelayenko and Klein, 2003).

6 CONCLUSIONS AND FUTURE

WORK

In this paper we have presented the details of an on-

tology transformation service with its two phases:

ontology pattern detection and ontology transforma-

tion using ontology transformation patterns. The pro-

posed service makes use of the existing formalisms

SPARQL and the alignment format, combined with

transformation rules in order to detect and transform

parts of ontologies. This approach allows to reuse

ontology patterns and correspondence/transformation

patterns developed by third parties.

An implementation of the core service is our im-

minent future work. Further we will consider on-

tology transformation from a system viewpoint, incl.

user interaction, incremental selection of patterns,

consistency checking of the newly created ontology

etc. Furthermore we will extend the ontology trans-

formation pattern library with other ontology patterns,

e.g. name patterns and other patterns based on the

ODP portal. We also plan to further experiment with

ontology pattern detection using diverse approaches

presented in the previous section.

ACKNOWLEDGEMENTS

The research was partially supported by the IGA VSE

grant no.20/08 ’Evaluation and matching ontologies

via patterns’. The authors would also like to thank

ome Euzenat for consultations during writing this

text.

REFERENCES

Akhtar, W., Kopecky, J., Krennwallner, T., and Polleres, A.

(2008). XSPARQL: Traveling between the XML and

RDF worlds and avoiding the XSLT Pilgrimage. In

ESWC-08.

Euzenat, J., Scharffe, F., and Zimmermann, A. (2007).

D2.2.10: Expressive alignment language and imple-

mentation. Project deliverable 2.2.10, Knowledge

Web NoE (FP6-507482).

Iannone, L., Egana, M., Rector, A., and Stevens, R. (2008).

Augmenting the Expressivity of the Ontology Pre-

Processor Language. In OWLED 2008.

Kensche, D., Quix, C., Chatti, M. A., and Jarke, M. (2007).

GeRoMe: A Generic Role Based Metamodel for

Model Management. In Journal on Data Semantics.

Omelayenko, B. and Klein, M., editors (2003). Knowledge

Transformation for the Semantic Web. IOS press, Am-

sterdam (NL).

erez, J., Arenas, M., and Gutierrez, C. (2006). Semantics

and Complexity of SPARQL. In International Seman-

tic Web Conference, pages 30–43.

Scharffe, F. (2009). Correspondence Patterns Representa-

tion. PhD thesis, University of Innsbruck.

Sirin, E. and Parsia, B. (2007). SPARQL-DL: SPARQL

Query for OWL-DL. In OWLED2007.

Svab-Zamazal, O. and Svatek, V. (2008). Analysing Onto-

logical Structures through Name Pattern Tracking. In

EKAW 2008.

Svab-Zamazal, O. and Svatek, V. (2009). Towards Ontol-

ogy Matching via Pattern-Based Detection of Seman-

tic Structures in OWL Ontologies. In Znalosti 2009.

Svab-Zamazal, O., Svatek, V., David, J., and Scharffe, F.

(2009). Towards Metamorphic Semantic Models. In

In Poster session at ESWC-09.

PATTERN-BASED ONTOLOGY TRANSFORMATION SERVICE