Ontology Based Model Transformation Infrastructure

Arda Goknil, N. Yasemin Topaloglu

Department of Computer Engineering, Ege University, Izmir, Turkey

Abstract. Using MDA in ontology development has been investigated in sev-

eral works recently. The mappings and transformations between the UML con-

structs and the OWL elements to develop ontologies are the main concern of

these research projects. We propose another approach in order to achieve the

collaboration between MDA and ontology technologies. We propose an ontol-

ogy based model transformation infrastructure to transform application models

by using query statements, transformation rules and models defined as ontolo-

gies in OWL. Using this approach in model transformation infrastructure will

enable us to use semantic web and ontology facilities in model driven architec-

ture. This paper will discuss how these two technologies come together to pro-

vide automatization in model transformations.

1 Introduction

Model Driven Architecture (MDA) is a recent approach that has been introduced by

OMG [10]. MDA considers model generation as the core activity of software devel-

opment and specifically, it aims to accomplish software development through gener-

ating Platform Independent Models (PIMs) and mappings these models to Platform

Specific Models (PSMs). The main idea behind this is to enable software developers

to work in a higher abstraction layer than the code level. As a consequence, models

become the primary artifacts of software development [8]. To define mappings be-

tween models, model transformation, which takes one or more source models as input

and produces one or more models as output, according to a set of transformation rules

is needed.

An ontology is a formal explicit description of concepts in a domain of discourse,

properties of each concept

describing various features and attributes of the concept,

and restrictions of slots [9]. Web Ontology Language (OWL) is a technology for

ontology development and knowledge representation in Semantic Web [2]. OWL

defines and instantiates Web ontologies. Recent works discuss that UML [12] could

be a key technology for the ontology development bottleneck [1] [5] [6]. A number of

partial solutions are currently available as a result of these works and Object Model-

ing Group (OMG) initialized a working group to create Ontology Definition Meta-

model (ODM) to define M2 level UML-ontology-OWL transformation [13]. Alterna-

tively to the established views, we propose another approach for the collaboration

between MDA and OWL. While recent works discuss the contributions of MDA to

Goknil A. and Yasemin Topaloglu N. (2005).

Ontology Based Model Transformation Infrastructure.

In Proceedings of the Joint Workshop on Web Services and Model-Driven Enterprise Information Systems, pages 77-86

DOI: 10.5220/0002564100770086

 SciTePress

ontology development, we discuss the possible contributions of ontologies to MDA.

We propose an ontology based model transformation infrastructure to transform ap-

plication models by using query statements, transformation rules and models defined

as ontologies in OWL.

In this paper, we discuss our ontology based m

odel transformation approach and

define the ontologies for model transformations within the context of MDA. We base

our proposal on the idea that the current technologies for model transformations are

not enough for interoperability of the model queries and transformation rules. The

recent popular technologies to identify transformation rules are XMI and XSLT [15].

The paper is organized as follows. In Section 2, we discuss the general characteris-

ics and underlying concepts of the ontology based model transformations. In Section

3, we introduce our approach and define the ontologies for model transformation

infrastructure. Section 4 includes the conclusions.

2 Overview of Ontology Based Model Transformations

2.1 Web Ontology Language (OWL)

Web Ontology Language (OWL) is a technology to provide a standard language for

he representation of ontologies on the web. OWL is a result of the ongoing process

of defining a standard ontology web language. It is an extension of Resource Descrip-

tion Framework (RDF) [17]. OWL provides a rich set of vocabulary to catch all the

relationships between classes and properties. An OWL document can include an

optional ontology header and any number of class, property, and individual descrip-

tions or axioms.

A Class identifier describes a named class in OWL ontology. For instance,

“<owl

:Class rdf:ID=”Student”>” defines a class “Student” which is an instance of

“owl:Class”. In the ontology, many individuals can be instantiated from the defined

classes. Individuals are instances of classes, and properties may be used to relate one

individual to another. These properties can be used to state relationships between

individuals or from individuals to data values. For instance, an individual named Olca

may be described as an instance of the class Student and the property hasStudent may

be used to relate the individual Olca to the individual EgeUniversity which is derived

from the class University. There are two kinds of properties defined in OWL: object

property which relates individuals to individuals, and datatype property which relates

individuals to data values. Similar to object-oriented programming, class hierarchies

may be created by using one or more statements which shows that a class is a

subclass of another class [2]. For instance, the class UniversityStudent is the subclass

of the class Student. OWL allows restrictions to be placed on how properties can be

used by instances of a class. This restriction mechanism in OWL provides to define

constraints, which can not be specified in UML or other modeling techniques.

2.2 General Concepts of the Model Transformation Ontology

Model transformation is the core activity in MDA to generate new models or to

change

the existing models. A model transformation takes one or more source models

as input and produces one or more models as output according to a set of transforma-

tion rules. The metamodeling technique is used to define these models and transfor-

mation rules [14]. A metamodel describes models by defining the meta entities and

the relationships among these entities together with the semantics of these relation-

ships. The meta class instances of the metamodel define the models and transforma-

tion rules generated from the metamodel. Extensible languages like XML Metadata

Interchange (XMI) and Extensible Stylesheet Language Transformations (XSLT) can

be used to encode models and transformation rules with meta class instances [3][15]

[16].

XMI allows us encoding models in sets of XM

L tags to make them tool independ-

ent and interoperable. XSLT is another technology that enables to work on XML

documents for model transformations. Though XMI and XSLT have reached wide

usage, the interoperability and extendibility they provide are not sufficient. XMI is

designed for interoperability among different case tools and it provides mechanisms

for the exchange of UML models but it is not suitable for more structural interopera-

bility.

The three main components of MOF 2.0 Query/Views/Transformations RFP [11]

should be considered in the definition of m

odel transformation ontology. The QVT

RFP is issued by the Object Management Group (OMG) and seeks a standard solu-

tion for model manipulation. The three main subjects of model transformation defined

by QVT [11]:

• Queri

es take a model as input, and selects specific elements from that model.

• Vi

ews are models that are derived from other models.

• Transform

ations take a model as input and update it or create a new model.

In our work, these three parts are defined as ontological. Defining queries and

tran

sformation in an ontology format will enable us to specify the structure of how

meta entities and the relations between them are kept. Also queries defined in differ-

ent transformation architectures will understand each other with the help of ontologi-

cal approaches. To define instances from classes in XMI, you must define the meta

classes in the same document. But in OWL, all instance queries reference a shared

query ontology for the definitions of meta classes to define instances. The ontologies

of these parts are defined as OWL documents. The definition in the OWL document

provides a meta model for model transformations. For every instance transformation,

instance ontologies can be derived from the meta ontologies.

3 Modeling the Transformation Components As Ontologies

As mentioned in QVT [11], the transformation infrastructure is constituted of three

main structures as query, view and transformation. In our approach, we propose to

model the meta entities and instances of these structures as ontologies.

3.1 Querying Application Models With Ontological Structures

Queries take a model as input, and select specific elements from that model. The aim

is to detect the specific source and target patterns in application models. For that

reason, different query languages have the same meta structures like selection and

condition. These main structures are the basis of the query ontology.

Two different ontology documents are needed to query an application model. The

first ontology document includes the meta classes of the query meta model. This meta

model defines the main entities and the possible associations of these entities. The

second document contains the instance query. The instance query selects the specific

elements in the application document, and it is derived from the meta entities which

are defined in the first query ontology. Figure-1 shows the relationship between the

instance query ontology, meta query ontology, application model and the engine that

process the query on the application model. Query.rdf includes the meta classes

which constitute the meta model of model queries. These meta classes are the main

selection elements like Select, Where, And, Or, Not. They associate the model ele-

ments to constitute the source and target patterns. InstanceQuery.rdf includes the

instances of the classes in Query.rdf to define an executable query for an application

model. Query.rdf is a kind of schema for query instances and defines the possible

queries with its constructs.

Fig. 1. Deriving Query Instances from Query.rdf

We propose a simple query language whose meta-model is shown in Figure-2

The elements of this meta model constitute the structures in Query.rdf. The Query

class in Figure-2 defines the query which is composed of two parts as Where and

Select. The Select class associates with model elements which are derived after query

processing. The Where class defines the condition in the query and is composed of

the Boolean terms (And, Or, Not), model elements and query references.

Instead of showing the OWL document, we model our ontology definition by using UML

class diagrams because of the space limitation in this paper.

Query.rdf

imports

InstanceQuery.rdf

input

transforms

ine

Application

Query

+ na m e

Where

Select

Model El ement

QueryRe

+ na m e

BooleanTer

And Or No t

0..1

1..*

0..*

0..1

0..20..2

0..1

0..*

0..1

0..2

0..1

Fig. 2. The Meta Classes in Query.rdf

The QueryRef denotes other queries that are referenced in the Where term of the

query. This enables us to use queries as recursive functions. The main difference

between the QueryRef and the Query classes is that the QueryRef class is only a refer-

ence and does not contain the selection and the condition terms in the ontology where

it is used. It defines the parameters which the Query it references uses in its own

ontology. The Boolean terms include the model definitions as the conditions on the

application model. The Where class may have these three classes in different combi-

nations. The query ontology can limit the possible combinations that can be obtained

from the meta model. The restrictions in the aggregation mechanism of the Where

class and its collaborators can be defined in OWL as shown below:

<owl:Restriction>

<owl:onProperty rdf:resource=”#hasDefiniton”>

<owl:allValuesFrom>

<owl:Class>

<owl:unionOf>

<owl:Class rdf:about=”#QueryRef”>

<owl:Class rdf:about=”#BooleanTerm”>

<owl:Class rdf:about=”#ModelElement”>

</owl:unionOf>

</owl:Class>

</owl:allValuesFrom>

</owl:onProperty>

</owl:Restriction>

<owl:Restriction>

<owl:onProperty rdf:resource="#hasDefinition"/>

<owl:cardinality

rdf:datatype=”http://www.w3.org/2001/XMLSchema#nonNegativeInt

eger”>1</owl:cardinality>

</owl:Restriction>

The property named h

asDefinition defines the aggregation between the Where

class and its collaborators, the BooleanTerm class, the ModelElement class and the

QueryRef class. The first restriction defines that the Where class may have the Que-

ryRef, the BooleanTerm and the ModelElement classes but with the second restriction

it may have only one of them at once. The restriction mechanism in OWL provides to

define constraints, which can not be specified in UML or other modeling techniques,

for meta classes of our query model.

In Figure-2, we show the main classes that the query ontology must have. We can

ext

end this ontology with additional structures for more complex model queries. For

instance, there may be a set of same elements after the query processing. The query

result set may have a model including a class associated with a set of same elements.

To handle the set of model elements with iterations, there may be a container class to

keep model elements as a set. A query which selects a class with a public attribute

may return more than one public attribute of the class. We can handle the set of pub-

lic attributes in the class in a set structure. Without a set structure, the query only

matches the class with one public attribute at once. This set structure enables us to

match one class with the set of its public attributes all at once.

Defining query models as ontologies allows u

s to extend this query meta model.

The InstanceQuery ontologies are derived from Query.rdf for every model query like

in Figure-1. In our work, InstanceQuery.rdf provides a query definition matching

UML classes and their attributes, both owned by the class, and all of its superclasses.

The query [4] shown below is an example of this.

QUERY hasAttr(C, A)

SELECT Class C, Attribute A, Class C2

WHERE A.owner=C OR (C.super=C2 AND hasAttr(C2, A))

It is possible for ontologies to be treated as reusable modules and imported into

fferent documents. An OWL document may contain an individual of class defined

in another ontology, which contains meta-data about that document itself. In our

example, the InstanceQuery defining the hasAttr query imports Query.rdf to create

individuals from the meta classes as shown below:

<owl:Ontology rdf:about="">

<owl:imports rdf:resource="Query.rdf"/>

</owl:Ontology>

Every individual created in the QueryInst

ance references the class defined in the

Query ontology. In our case, the Where individual has an Or individual. This Or

individual has two properties named the left-hand side and the right-hand side. The

left-hand side has a clause which defines (A.owner=C) and the right-hand side has an

And individual. The And individual has (C.super=C2) clause in the left-hand side and

a QueryRef referencing the hasAttr query with the parameters as Class C2, and At-

tribute A. Figure-3 shows this condition structure. In the ontology, we define

(A.owner=C) clause with Class C which has Attribute A. Every model element used

in the query is defined and is aggregated by the Query individual. We use their refer-

ences while defining the clauses in the conditions. It means that the reference of the

Class C has the reference of the Attribute A. The reference mechanism allows us to

define conditions on model elements by using temporary clauses. The model elements

defined inside the query are accessed through their references while the conditions

are defined.

Where

has

And (A.owner=C)

left hand-side

right hand-side left hand-side

right hand-side

(C.super=C2) hasAttr(C2,A)

Fig. 3. The Structure of the Condition Statement in the Instance Ontology

3.2 Transforming Application Models With Ontological Structures

Transformations take a model as input and update it or create a new model. The sub-

mission for MOF 2.0 QVT RFP [11] split queries, views and transformations into two

distinct groups. Queries and transformations may possibly create views, but views

themselves are passive [11]. In our work, we consider that a transformation includes

both queries and transformation operations. While queries select specific elements

from the application model, transformation operations are applied to these selected

model elements to transform the application model. The meta transformation ontol-

ogy includes both the meta classes of transformation operations and queries. It can be

considered that the transformation ontology is an extended query ontology to support

the transformation operations.

The relationship between transformation ontology and transformations is similar to

the relationship between meta ontology and instance ontology of queries that are

discussed in Section 3.1. Transformation.rdf includes the meta classes which consti-

tute the meta model of transformations and the instances in instance transformations

are derived from these meta classes. Transformation.rdf is a kind of schema for trans-

formation instances and defines the possible transformations with its constructs. Fig-

ure-4 shows the structures in our transformation ontology as a UML diagram.

ransformation

+ na me

Where

Select

ModelElem ent

ueryRe

+ na me

BooleanTer

And Or No t

0..1

1..*

0..*

0..1

0..20..2

0..1

0..*

0..1

Operation

Add Update Delete

Tr ansformationRe

+ na m e

- Extends

- Superceeds

0..2

0..1

Fig. 4. The Meta Classes in Transformation.rdf

The Transformation class in Figure-4 defines the transformation itself. It has the

Select and the Where classes like the Query class in Query.rdf because the transfor-

mation includes both model queries and transformation operations inside. The Where

class is associated with the QueryRef class because a query instance can be referenced

in the query condition of the transformation ontology. The query structures in Trans-

formation.rdf and Query.rdf are the same. Transformations may be related to other

transformations. [4] defines two ways for this relation: Extends and Supersedes. The

associations between the Transformation and the TransformationRef classes in our

ontology denote this relationship. Here, we have the OWL extensibility facilities to

support other possible transformation relations in our ontology. Other possible rela-

tions between transformations can also be added to the transformation ontology in

different approaches. The TOperation class and its sub-classes encapsulate the trans-

formation operations on application models. The sub-classes of the TOperation class

in our ontology are the Add, the Update and the Delete classes. We use them in our

ontology to define the simplest operations. They are also the atomic operations and

operate on meta class instances. In different and more complicated transformation

approaches, more abstract and high-level classes may be used to define transforma-

tion operations.

Below, we give an example for a transformation definition which converts a public

attribute from a given class to private and also creates the getter operation:

Transformation makingAttributePrivate(C, A)

SELECT Class C, Attribute A

WHERE (A.owner=C) AND (A.visibility=”Private”)

MAKE A.visibility=”Private”

Define getMet = new Operation()

getMet.name=”getAttr”

getMet.owner=C

The Make

part after model query in the transformation defines the transformation

operations on the application model. The first operation is making the visibility of

Attribute A private. It is an update operation denoted by the individual derived from

the Update class in the ontology. The second step in the transformation is creating a

get method in Class C. An individual derived from the Add class does the creation of

the get method named getAttr in Class C.

The third component of model transformations is views. Views are models that are

deri

ved from other models. Application models can also be defined in OWL instead

of XMI where Case tools export and import the application models.

4 Conclusion

In this paper, we proposed an ontology based model transformation infrastructure.

Ontologies provide a shared and common understanding of a domain. We consider

the domain as model transformation in the context of model transformation languages

and model the main constructs of model transformations. It enables us to extend our

ontologies for future constructs of model transformations and allows communication

of rules across applications. We used OWL in the definition of our ontologies be-

cause it is executable and is supported by tools. The restriction mechanism in OWL

allows defining constraints about the instance models derived from meta models.

OWL which provides to define assertions for UML has a precise semantics and is

compared with Object Constraint Language (OCL) [18]. Some programmatic envi-

ronments [7] include OWL APIs. These environments provide persistent storage,

reading and writing OWL documents. Using OWL in model transformation infra-

structure allows us to use the current semantic technologies to constitute the trans-

formation engines. Loading and compiling the parts of model transformation are

processed by the help of current ontology APIs.

Our aim is to investigate the possible contributions of ontologies to MDA and an

ntology based model transformation infrastructure. We think that ontologies will

play an important role in the development of MDA. In our future work, we will ex-

tend our transformation ontology with the constructs that support new transformation

domains.

References

1. Backlawski, K. et al: Extending the Unified Modeling Language for Ontology Develop-

ment. Int. J. Software and Systems Modeling, Vol.1, No.2 (2002) 142-156

2. Dean, M., Schreiber, G. (eds): OWL We

b Ontology Language Reference W3C Recom-

mendation, Feb 10, 2004, http://www.w3.org/TR/owl-ref/

3. Demuth, B., Obermaier, S.: Experiements with XMI Based Transformations of Software

Models. WITUML’01, Genova Italy, April (2001)

4. Duddy

, K., Gerber, A., Lawley, M., Raymond, K., Steel, J.: Model Transformation: A

declarative, reusable patterns approach. In Proceedings EDOC 2003, pp 174-185

5. Falkovy

ch, K., Sabou, M., Stuckenschmidth, H.: UML for The Semantic Web: Transfor-

mation-Based Approaches. In Knowledge Transformation in Semantic Web, IOS Press,

Vol.95 (2003), pp 92-106

6. Gasevic, D., Djuric, D., Devedzic, V., Damjanovic, V.: Approaching OWL to

MDA

Through Technological Spaces. WISME@UML’2004, Lisbon Portugal, 2004

7. Jena: A Sem

antic Web Framework For Java. http://jena.sourceforge.net/

8. J

udson, S., France, R., Carver, D.: Specifying Model Transformations at the Meta-model

Level. WISME@UML’2003, San Francisco USA, October (2003)

9. Noy

, N., McGuinnes, D.: Ontology Development 101: A Guide to Creating Your First

Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05, March

(2001).

10. OMG: MDA Guide Version 1.0.1. The Object

Management Group, Document Number:

omg/2003-06-01 (2003)

11. OMG: Submissions for MOF 2.0 Query

/Views/Transformations Request for Proposal.

The Object Management Group (2003)

12. OMG: OMG Unified Modeling Specification. Version 1.4. (2001)

13. OMG: Ontology

Definition Meta-Model, http://www.omg.org/cgi-bin/doc?ad/03-08-06

(Current Apr 3, 2004)

14. S

endall, S., Kozaczynski, W.: Model Transformation – the Heart and Soul of Model-

Driven Software Development. IEEE Software Sep/Oct. (2003), pp. 42-45

15. S

taron, M., Kuzniarz, L.: Implementing UML model transformations for MDA.

NWPER’2004, Turku Finland, August (2004)

16. Wagner, A.: A pragmatical approach to rule-based transform

ations within UML using

XMI.difference. WITUML 2002, Malaga Spain, June (2002)

17. W3C Resource Description Framework.

http://www.w3.org/RDF/

18. Zhao,

Y., Assman, U., Sandahl, K.: OWL and OCL for Semantic Integration. Technical

Report, Programming Environmental Lab (PELAB), Department of Computer and Infor-

mation Science, Linköping University, Sweden.