Towards an Expressivity Benchmark for Mappings based on a ... · tool-speci c metamodels. Thereby...

Towards an Expressivity Benchmark for Mappings basedon a Systematic Classification of Heterogeneities∗

M. WimmerTU Vienna

[email protected]

G. KappelTU Vienna

[email protected]

A. KuselJKU Linz

[email protected]. Retschitzegger

JKU [email protected]

J. SchoenboeckTU Vienna

[email protected]

W. SchwingerJKU Linz

[email protected]

ABSTRACTA crucial prerequisite for the success of Model Driven Engi-neering (MDE) is the seamless exchange of models betweendifferent modeling tools demanding for mappings betweentool-specific metamodels. Thereby the resolution of hetero-geneities between these tool-specific metamodels is a ubiqui-tous problem representing the key challenge. Nevertheless,there is no comprehensive classification of potential hetero-geneities available in the domain of MDE. This hinders thespecification of a comprehensive benchmark explicating re-quirements wrt. expressivity of mapping tools, which pro-vide reusable components for resolving these heterogeneities.

Therefore, we propose a feature-based classification of het-erogeneities, which accordingly adapts and extends existingclassifications. This feature-based classification builds thebasis for a mapping benchmark, thereby providing a compre-hensive set of requirements concerning expressivity of dedi-cated mapping tools. In this paper a first set of benchmarkexamples is presented by means of metamodels and conform-ing models acting as an evaluation suite for mapping tools.

Categories and Subject DescriptorsD.2.12 [Software Engineering]: Interoperability

General TermsMeasurement

KeywordsClassification of Heterogeneities, Mapping Benchmark

1. INTRODUCTIONWith the rise of MDE models become the main artifacts of

the software development process [3]. Hence, a multitude of

∗This work has been funded by the Austrian Science Fund(FWF) under grant P21374-N13.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.MDI2010, October 5, 2010, Oslo, Norway.Copyright 2010 ACM 978-1-4503-0292-0/10/10 ...$10.00.

modeling tools is available supporting different tasks, suchas model creation, model simulation, model checking, modeltransformation, and code generation. Seamless exchange ofmodels among different modeling tools increasingly becomesa crucial prerequisite for effective MDE. Due to the lack ofinteroperability, however, it is often difficult to use toolsin combination, thus the potential of MDE cannot be fullyexploited. For achieving interoperability in terms of trans-parent model exchange, current best practices comprise cre-ating model transformations between different tool meta-models (MMs) with the main drawback of having to dealwith all the intricacies of a certain transformation language.In contrast to that, first mapping tools [6, 18] have beenproposed, allowing to specify a transformation on a moreabstract level by means of reusable components. Out ofthe resulting mapping definitions corresponding executabletransformation code can be generated. In the definition ofa mapping between MMs the resolution of heterogeneitiesrepresents the key challenge. Thereby heterogeneities resultfrom the fact that semantically similar metamodeling con-cepts (M2) can be defined with different meta-metamodelingconcepts (M3) leading to differently structured metamod-els. As a simple example Fig. 1 shows two metamodels offictitious1 domain-specific tools administrating publications.Whereas the MM of Tool1 models the type of a publicationby the attribute Publication.kind (e.g., conference, work-shop or journal), the MM of Tool2 represents the same se-mantic using the class Publication which refers to a classKind to determine the kind of the publication.

KindPublicationname:String

Publication 1..1kind

name:Stringname:String

name:Stringkind:Integer

MM of Tool1 MM of Tool2

Figure 1: Two Heterogeneous Tool Metamodels

In order to resolve such heterogeneities mapping tools pro-vide certain reusable components. Nevertheless, it is stillunclear, which kinds of reusable components are requiredto provide the necessary expressivity. Therefore this paperprovides a systematic classification of heterogeneities occur-ring in the domain of MDE between object-oriented MMs,

1Due to reasons of comprehensibility examples comprisingontological concepts have been preferred over examples com-prising linguistic concepts.

thereby adapting and extending existing classifications [2, 4,10, 11, 12, 13, 15, 17]. Moreover, this classification is usedto derive an evaluation suite building an expressivity bench-mark for mapping tools. Thereby a first set of examples ispresented in this paper. Additional heterogeneity examplescan be downloaded from our homepage2 complementing theexpressivity benchmark.

The remainder of this paper is structured as follows. InSection 2 we present the design rationale behind our classifi-cation as well as the feature-based classification itself. In theSections 3-5 we exemplary discuss heterogeneities, therebypresenting six examples of our expressivity benchmark. Re-lated work is discussed in Section 6 and finally, Section 7 con-cludes the paper together with an outlook on future work.

2. TOWARDS A SYSTEMATIC CLASSIFI-CATION OF HETEROGENEITIES

This section presents the design rationale behind the pro-posed classification of heterogeneities as well as the classifi-cation itself. Since the classification targets at the domainof MDE, it bases on object-oriented MMs in contrast to ex-isting classifications from the domain of data engineeringbasing either on the relational or the XML data model. Toclearly make explicit the interconnections between hetero-geneities we build our classification on a feature model [5].

2.1 Deriving Heterogeneities from EcoreHeterogeneities result from the fact that semantically sim-

ilar concepts can be defined with different metamodelingconcepts (e.g., Ecore3) leading to differently structured toolmetamodels. To exemplify this, Fig. 2 depicts the MMs ofFig. 1 as Ecore instances. Thereby, several heterogeneitiesarise, e.g., the MM of Tool1 represents the publication kindby an EAttribute whereas the MM of Tool2 utilizes anEReference, an EClass and an EAttribute to represent thesemantically equivalent information.


Publication kind


te x Publicationname:String

Publicationname:String

1..1

ncret

yntax

gkind:Integer

Con Sy

EClasseStructuralFeatures

EClass

abstract = falsename = ‘Publication‘ EAttributeta

x) EAttributeabstract = false name = ‘nam

lowerBoundSynt name = ‘name‘

lowerBound = 1 EStringeStructuralFeatures eAttributeType

upperBound

tract upperBound = 1

EString

EReferencename = ‘kin(A

bst

EClassname = ‘Publication‘ name = kin

lowerBoundordered = fa

eStructuralFeaturescore

(

abstract = falsename = Publication

upperBoundcontainmen

eStructuralFeatures

ofEc EAttribute

‘ki d‘eAttributeType

eReferenceType

ance name = ‘kind‘

lowerBound = 1B d 1

EInteger

EClassname = ‘Kind‘ eStructuralFeaturesIn

sta upperBound = 1eStructuralFeatures

abstract = falsename Kind

22

Kindname:Stringg

me‘d = 1d = 1

eAttributeType

EStringed‘d

d = 1alse eAttributeType

d = 1t = false

EAttributeEAttributename = ‘name‘lowerBound = 1s lowerBound = 1upperBound = 1

Figure 2: Tool Metamodels as Instances of Ecore

To gain a systematic classification of different kinds ofsyntactic heterogeneities, we investigated potential variationpoints between two Ecore-based metamodels (cf. Fig. 3).Ecore has been used since it is the prevalent meta-metamodelin MDE and since it comprises the core concepts of seman-tic data models [9], being classes, attributes, references andinheritance. Therefore, the proposed classification can alsobe applied to other data models comprising these commoncore concepts, e.g., OWL4.2www.modeltransformation.net3http://www.eclipse.org/modeling/emf/4http://www.w3.org/TR/owl-features/

In this respect, Fig. 3 depicts the relevant extract of theEcore meta-metamodel for mappings. When comparing twoEcore-based metamodels, different cases can be distinguished,namely (i) that in the left-hand side (LHS) MM and in theright-hand side (RHS) MM the same Ecore concept is used.Thereby differences wrt. the owned attribute settings canarise, e.g., if two EClasses are used, one can be set abstractwhereas the other is not – leading to a concreteness differ-ence. Moreover, (ii) in the LHS MM and in the RHS MMdifferent Ecore concepts may be used, e.g., an EAttribute

in the LHS MM and an EReference, an EClass and an EAt-

tribute in the RHS MM (cf. example in Fig. 2). Finally,(iii) both cases mentioned get more complex, if the numberof Ecore concepts for modeling a certain MM concept dif-fers. A simple example in this respect is that in one MMtwo EAttributes firstName and lastName are used whereasin the other MM this information is contained in just oneEAttribute name.

ENamedElementENamedElementname : String

EClassifierETypedElementordered : boolean

Order Difference

…ordered : booleanlowerBound : intupperBound : int

MultiplicityDifferenceupperBound : int Difference

ConcretenessEClassabstract : boolean

eSu0..*

ConcretenessDifference

abstract : boolean

R f T1..1

Context Difference eReferenceTypeContext Difference

Dire

eStructuralFeatures0..*EStructuralFeature EReferenceEStructuralFeature

… containment: boolean

EAtt ib tConstraint Difference EAttribute…

Constraint Difference

Naming Difference

Inheritance Type Difference

Breadth Difference

Depth Difference

EDataTypeuperTypes*

eAttributeType1..1

…

yp

ection Difference

Datatype Difference

C iContainment Difference

Figure 3: Variation Points in Ecore-based MMs

Besides syntactic heterogeneities, comprising all hetero-geneities that can be derived from the syntactic definitionin Ecore, also semantic heterogeneities may arise [15]. Theyoccur when the valid instance set differs – either (i) in thenumber of valid instances or (ii) in the interpretation of theinstance values. An example for the first case is that one MMcomprises an EClass Publication whereas the other MMcomprises an EClass JournalPublication, allowing only forjournal instances - thus being a subset of the valid instancesof the EClass Publication. An example for the second caseis that one MM comprises an EAttribute amount encodingpricing information in Dollar, whereas the other MM alsoexhibits an EAttribute amount but encoding the pricing in-formation in Euro. Thus, semantic heterogeneities can notbe derived from the syntax (since in both cases the MMscan be represented syntactically equal) but only by incor-porating interpretation, i.e., an assignment of a meaning toeach piece of data [8].

2.2 Classification of HeterogeneitiesBased on this design rationale, we introduce a classifi-

cation of heterogeneities. It is expressed using the featuremodel formalism [5], which allows to clearly point out the in-terconnections between the different kinds of heterogeneities(e.g., xor features modeling mutual exclusive features ver-sus or features allowing to pick several features at once).Thereby heterogeneities are divided into the two main classesof (i) semantic heterogeneities, i.e., heterogeneities wrt. what

Heterogeneityg y

Syntactic HeterogeneitySemantic Heterogeneity

Naming Difference Structural DifferenceNumber ofInstances Difference

Interpretation ofInstance Values Difference

C C DiffDisjointIntersection Subset Superset

Core Concept Difference

Source-Target-ConceptCardinality

Same Meta-modeling Concept

Different Meta-modeling ConceptCardinality modeling Concept modeling Concept

1:1 n:1 1:n C2C A2A R2R C2A 2RR2C R2AA2Cm:n

Reference ReContext

Difference

O de

ContextDifference

O d

ReferenceSource

Re

OrderDifference

Multiplicity Multiplicty

OrderDifference

C A R

Datatypeiff

MultiplicityDifference

MultiplictyDifference

Directioniff

C A R

Difference Difference

ContainmentDifference

ConstraintDifference DifferenceDifference

ConstraDifferen

Required Feature

Optional Feature

XOR Features

OR Features

Legend

I h it DiffInheritance Difference

Same Meta-modeling Concept

Different Meta-modeling Conceptmodeling Concept modeling Concept

I2I I2C A2II2R C2II2A R2I

eference Concretenesseference Target

ConcretenessDifference

Breadth

C A R

BreadthDifference

Depth DiffC A R Difference

Inheritance TypeDifferenceDifference

intnce

Figure 4: Heterogeneity Feature Model

is represented by a MM and (ii) syntactic heterogeneities,i.e., heterogeneities wrt. how it is represented (cf. Fig. 4)whereby these two classes might occur jointly as modeled bythe or relationship in between.

Semantic Heterogeneities. Concerning semantic het-erogeneities – as mentioned above – two main cases can bedistinguished namely (i) differences in the number of validinstances and (ii) differences in the interpretation of the in-stance values. With respect to the first case all the set-theoretic relationships might occur as modeled by the cor-responding sub-features. Regarding the second case diversemodifications of the values might be necessary to translatethe values of one MM to correct values of the other MM suchthat it conforms to the interpretation of the other MM.

Syntactic Heterogeneities. With respect to syntacticheterogeneities we distinguish between simple naming differ-ences (i.e., a difference in the value of the name attribute ofENamedElement – cf. Fig. 3) and more challenging structuraldifferences. Although names play an important role whenderiving the semantics of a certain concept, names do notallow to automatically conclude on the semantics. Thereby,the two cases (i) same semantic and different naming, i.e.,synonyms and (ii) different semantic and same naming, i.e.,homonyms can be distinguished.

With respect to structural differences again two main casescan be distinguished – namely core concept differences andinheritance differences. Thereby, core concept differencesare differences that occur due to the different usage of classes,attributes and references between two MMs. In addition,these two main categories can be further distinguished intosame metamodeling concept heterogeneities and different meta-modeling concept heterogeneities, differentiating whether thesame Ecore concepts have been used in the LHS MM andin the RHS MM or not. In the context of core conceptdifferences additionally a different number of concepts mayhave been used in the two MMs leading to different source-target-concept cardinalities. In the following sections a firstset of benchmark examples is given divided into three main

packages, comprising (i) core concept heterogeneities withsame metamodeling concept heterogeneities, (ii) core con-cept heterogeneities with different metamodeling conceptheterogeneities and (iii) inheritance heterogeneities. Dueto space limitations only a subset of all potential hetero-geneities is explained in detail by means of concrete meta-models and according model instances but nevertheless ex-amples from each main category are given. In this respect,the benchmark examples are described uniformly comprising(i) a short description, (ii) the main challenges, (iii) the ex-ample description, and (iv) a discussion of resolution strate-gies. Complementary benchmark examples are presented onour collaborative homepage which invites the community toparticipate in adding and discussing benchmark examples.

3. CORE CONCEPT HETEROGENEITIES– SAME CONCEPTS

Same metamodeling concept heterogeneities are hetero-geneities, that occur although the same modeling concepthas been used in the LHS MM as well as in the RHS MMas mentioned above. In this respect, two main differencesmight emerge – either the concepts exhibit different attributesettings (cf. Fig 3) or a different number of concepts hasbeen used in the MMs to express the same semantic concept(cf. Source-Target-Concept Cardinality in Fig. 4). In thefollowing two examples of this category are given.

3.1 Benchmark Example 1This first example (cf. Fig. 5) only exhibits differences

wrt. different attribute settings (cf. optional features ofA(ttribute)2A(ttribute) and R(eference)2R(eference) in Fig-ure 4) as well as semantic heterogeneities. The main chal-lenges in this example can be summarized as follows:

1. EAttribute Professor.dateOfBirth –EAttribute Prof.bornIn:A2A, Multiplicity Difference, Datatype Difference

Professorte x0..*

publicationsname:StringdateOfBirth:Date [0..1]Currency =

D ll

Publicationname:Stringnc

ret

yntax

dateOfBirth:Date [0..1]salary:Integer

Dollar name:Stringtype:StringCo

n Sy

EClass 1:1 C2C Naming DifferenceEClass

b t t f lname = ‘Professor‘

EAttributeeStructuralFeatures

1:1, C2C, Naming Difference

abstract = false EAttributename = ‘name‘

eAttributeType1:1, A2A (no h1:1, A2A (no h

lowerBound = 1upperBound = 1

EString

eAttributeType

EString

EAttribute 1:1 A2A Naming Difference Multipltt butename = ‘dateOfBirth‘lowerBound = 0

eStructuralFeatures eAttributeType

1:1, A2A, Naming Difference, Multipl

lowerBound = 0upperBound = 1 EDataType

‘D t ‘C

EAttribute‘ l ‘

name = ‘Date‘1:1, A2A, Semant1:1, A2A, Semant

name = ‘salary‘lowerBound = 1

B d 1 EI teStructuralFeatures

eAttributeType

upperBound = 1 EInteger

ftax Cha

EReferencename = ‘publications‘ 1:1, R2R, Naming Differen1:1, R2R, Naming DifferenSy

nt

p

lowerBound = 01

ordered = falseeStructuralFeatures

tract

upperBound = -1containment = falseA

bst

Ch ll 4eReferenceType Challenge 4

EClassname = ‘Publication‘

1:1, C2C, Naming Difference, Semantic Heterogeneity

abstract = false

EAtt ib tEAttributename = ‘name‘ eAttributeType

1:1, A2A (no he


eStructuralFeatureseAttributeType

EAttributeeAttributeType

EAttributename = ‘type‘lowerBound = 1

1:0, Information Loss1:0, Information LosslowerBound = 1upperBound = 1eStructuralFeatures

P1:ProfessorP1:Professorname = ‘Prof1‘dateOfBirth = 12 04 1956nc

es

dateOfBirth = 12.04.1956salary = 5000 P2:Professor

‘P f2‘nstan

publications publicationsname = ‘Prof2‘dateOfBirth = ‘‘

l 3000pleIn

P10:Publicationname = ‘Paper1‘

P11:Publicationname = ‘Paper2‘

salary = 3000

xamp

name = Paper1type = ‘Conference‘

name = Paper2type = ‘Journal‘

Ex

ProfJournalname:String1..*

journalsname:StringbornIn:Integer [1 1]

Currency = Euro name:StringbornIn:Integer [1..1]

salary:IntegerEuro

EClass

abstract = falsename = ‘Prof‘


EAttributename = ‘name‘

eAttributeTypeeterogeneity)eterogeneity)


EString

eAttributeType

Challenge 1 EString

EAttributeicity Difference Datatype Differenceicity Difference Datatype Difference

Challenge 1

tt butename = ‘bornIn‘lowerBound = 1St t lF t

eAttributeType

icity Difference, Datatype Differenceicity Difference, Datatype Difference


eStructuralFeaturesChallenge 2

EAttribute‘ l ‘

tic Heterogeneitytic Heterogeneityname = ‘salary‘lowerBound = 1

B d 1 EI teStructuralFeatures

eAttributeType

upperBound = 1 EInteger

fllenge 3

EReferencename = ‘journals‘nce, Multiplicity Differencence, Multiplicity Difference j

lowerBound = 1ordered = falseeStructuralFeatures

upperBound = -1containment = false

eReferenceType

EClassname = ‘Journal‘abstract = false

EAtt ib t

eStructuralFeatures

EAttributename = ‘name‘ eAttributeType

eterogeneitiy)eterogeneitiy)


eAttributeType

P1:Prof P2:ProfP1:Profname = ‘Prof1‘

P2:Profname = ‘Prof2‘b I 2000

Autogeneratedor user-

interactionbornIn = 1956salary = 3970

bornIn= 2000salary = 2382

interactionnecessary

journals journalsAutogenerated

P11:Journal P0:Journal

Autogeneratedor user-

interactionname = ‘Paper2‘ name = ‘TODO‘ necessary

Figure 5: Benchmark Example 1 – Same Metamodeling Concept Heterogeneities

2. EAttribute Professor.salary –EAttribute Prof.salary: Semantic Heterogeneity (In-terpretation of Instance Values Difference), A2A

3. EReference Professor.publications –EReference Prof.journals:R2R, Multiplicity Difference

4. EClass Publication – EClass Journal: Semantic Het-erogeneity (Number of Instances Difference), C2C

Example Description. This first benchmark example(cf. Fig. 5) exhibits four main challenges. With respectto the first challenge, a multiplicity difference as well as adatatype difference between the EAttributes Professor.-

dateOfBirth and Prof.bornIn arise. Concerning the sec-ond challenge a semantic heterogeneity between the EAt-

tributes Professor.salary and Prof.salary emerges sinceProfessor.salary is encoded in Dollars whereas Prof.-

salary is encoded in Euros, i.e., difference in the interpreta-tion of the values. Regarding the third challenge a multiplic-ity difference between the EReferences Professor.publi-

cations and Prof.journals exists. Finally, the fourth chal-lenge incorporates again a semantic heterogeneity – but thistime a difference in the number of valid instances. For resolv-ing the differences of the first three challenges correspondingfunctions are required which either are able to generate val-ues or to transform values. In contrast to that, for resolving

the heterogeneity of the fourth challenge a correspondingcondition is needed, that filters those instances, that arestill valid in the context of the RHS EClass.

Discussion of Resolution Strategies. When taking alook at the example instances, one can see that a resolu-tion strategy has been chosen to minimize information lossand to achieve valid instances only. This is since instanceP2 has been kept in the RHS although it does not refer-ence any journal publication in the LHS model. Anotherpotential resolution strategy would be to keep only thoseProfessor instances that actually exhibit a journal publica-tion. If this is the case, also a semantic heterogeneity be-tween the EClasses Professor and Prof would exist, sincethe valid instance set would be potentially different. An-other interesting point in this example is that the RHS MMis more restrictive than the LHS MM since the EAttribute

Prof.bornIn always requires a value and since each instanceof Prof requires at least one link to a journal publication.Since these restrictions do not exist in the LHS MM, in-stances of the LHS MM may not fulfill them. Therefore someresolution strategy is needed – either by auto-generating val-ues or by incorporating user-interaction in order to producevalid instances of the RHS MM.

3.2 Benchmark Example 2In contrast to the first example which restricts itself to

source-target-concept cardinalities of 1:1, this example (cf.

N 1 I tN:1 Intra

Ki dPublication kindte x Kind

name:Stringtitle:Stringsubtitle:String

1..1ncre

yntax

gsubtitle:StringCo S y

EClass EAttributeeStructuralFeatures

EClass

abstract = falsename = ‘Publication‘ name = ‘title‘

lowerBound = 1 eAttributeTypeabstract = false upperBound = 1

EString


EAttributename = ‘subtitle‘ eAttributeTypelowerBound = 1upperBound = 1

yp

ntax

EReferencect Sy

name = ‘kind‘ordered = falseeStructuralFeaturesbs

trac n:1, C2


eStructuralFeatures

Ab

containment = falseeReferenceType

EClass

y

EClass

b t t f lname = ‘Kind‘ eStructuralFeatures Chaabstract = false

EAttribute 1:1, A2A, Naming D1:1, A2A, Naming Dname = ‘name‘lowerBound = 1

B d 1

eAttributeType

upperBound = 1

P1: Publicationtitle ‘P1‘ce

s P2: Publicationtitle ‘P2‘

P3: Publicationtitle ‘P3‘title = ‘P1‘

subtitle = ‘S1‘stan

title = ‘P2‘subtitle = ‘S2‘

title = ‘P3‘subtitle = ‘S3‘

kind

pleIn

kind kind

K1: Kind‘J l‘xa

mp

K2: Kind‘C f ‘name = ‘Journal‘Ex name = ‘Conference‘

C tConceptp

PublicationPublicationname:Stringki d St ikind:String

Challenge 1Challenge 1

EAttributename = ‘name‘eStructuralFeatures eAttributeType

n:1, A2A, NaminglowerBound = 1upperBound = 1

eStructuralFeatures eAttributeTypeDifference

pp

Challenge 2Challenge 2

EClassEString

abstract = falsename = ‘Publication‘

EString2C

eStructuralFeaturesallenge 3EAttributename = ‘kind‘ Att ib t T

Difference, Context DifferenceDifference, Context Difference


eAttributeType

pp

PK1:Publication‘P1 S1‘name = ‘P1 – S1‘

kind = ‘Journal‘ PK3:Publication

PK2:Publication

name = ‘P3 – S3‘kind = ‘Conference‘

PK2:Publicationname = ‘P2 – S2‘kind = ‘Journal‘


Fig. 6) additionally contains differences wrt. the number ofconcepts (cf. Source-Target-Concept Cardinality in Fig. 4).The main challenges in this example can be summarized asfollows:

1. EAttribute Publication.title,EAttribute Publication.subtitle –EAttribute Publication.name:Source-Target-Concept Cardinality: n:1, A2A

2. EClass Publication, EClass Kind –EClass Publication:Source-Target-Concept Cardinality: n:1, C2C

3. EAttribute Kind.name –EAttribute Publication.kind:A2A, Context Difference

Example Description. This benchmark example (cf.Fig. 6) possesses three challenges. Concerning the first chal-lenge, there is a n:1 source-target-concept cardinality be-tween the EAttributes title, subtitle and name. In or-der to resolve this heterogeneity, merging functionality isneeded, which is basically a concatenation function in thiscase. Concerning the second challenge, again a n:1 source-target-concept cardinality exists, but this time between theEClasses Publication, Kind and Publication. Therefore,again merging functionality is needed, allowing to merge ob-jects under a certain condition. Finally, the third challengeconsists in a context difference between the EAttributes

Kind.name and Publication.kind. For its resolution theassignment of values across object boundaries is needed.

Discussion of Resolution Strategies. When taking alook at the example instances in Fig. 6, one can see, thatfor each combination of a Publication object and the ref-erenced Kind object a Publication object should be gen-erated. Concerning the merge of the attributes different

strategies could be followed, whereby in this case a simpleconcatenation has been chosen. Other strategies compriseanother concatenation order. In case of other datatypes(e.g., numbers) arbitrary calculations could be incorporated.

4. CORE CONCEPT HETEROGENEITIES– DIFFERENT CONCEPTS

Different metamodeling concept heterogeneities result fromexpressing the same semantic concept with different mod-eling concepts in the LHS MM and in the RHS MM. Inour classification, potential heterogeneities were derived bysystematically combining the identified core concepts of se-mantic data models. To exemplify these heterogeneities twobenchmark examples are discussed in the following.

4.1 Benchmark Example 3The third example (cf. Fig. 7) deals with the fact that

a concept is modeled in the LHS MM by means of an EAt-

tribute whereas the RHS MM models this concept explic-itly by means of an EClass. Thus, the main challenges inthis example can be summarized as follows:

1. EAttribute Publication.kind – EClass Kind: A2C

2. EClass Publication, EAttribute Publication.kind

– EReference Publication.kind: CA2R

Example Description. The first challenge is that thekind of the publication is represented by means of the EAt-

tribute Publication.kind in the LHS MM whereas theRHS MM makes the type explicit by means of the EClass

Kind, which is therefore classified as A(ttribute)2C(lass)in Fig. 7. In order to link publications with the publica-tion kind, the RHS MM provides the EReference Publi-

cation.kind for which there is no according counterpart in

Inter‐ConcepInter Concep

Publicatione Publicationname:String

ncret

yntax

kind:StringCo

n Sy

EAttributeEAttributename = ‘name‘eStructuralFeatureslowerBound = 1upperBound = 1 1:1, A2A,1:1, A2A,

ax

EStringeAttributeType

eAttributeType

Synta eAttributeType

ract S

EClassname = ‘Publication‘

Abst


A

EAttributename = ‘kind‘lowerBound = 1upperBound = 1eStructuralFeatures 1:1, A2A, Naming D1:1, A2A, Naming D

es P1 P bli ti

ance P1:Publication

name = ‘P1‘

Insta

kind = ‘Journal‘ P3:Publicationname = ‘P3‘

mple P2:Publication

name = ‘P2‘

name P3kind = ‘Conference‘

Exam name = P2

kind = ‘Journal‘

pt A2C CA2Rpt, A2C, CA2R

kindKindname:String

Publicationtitle:String

1..1kind

uniquename:Stringtitle:String


EClass


EAttributename = ‘title‘abstract = false lowerBound = 1upperBound = 1, Naming Difference, Naming Difference pp

eAttributeTypeEString

EReferenceChallenge 2

EReferencename = ‘kind‘ordered = false

eAttributeType1:1, CA2R, NaminglowerBound = 1upperBound = 1

ordered = false, , gDifference

upperBound = 1containment = falseeStructuralFeatures

eReferenceType

C

eReferenceType

EClassname = ‘Kind‘ eStructuralFeaturesabstract = false

EAttributename = ‘name‘lowerBound = 1

Challenge 1o e ou dupperBound = 1Difference, Context DifferenceDifference, Context Difference

P1: Publicationtitle = ‘P1‘

P2: Publicationtitle = ‘P2‘

P3: Publicationtitle = ‘P3‘title P1

kind

title P2

kind

title P3

kind

K1: Kind

kind kind

K2: Kindname = ‘Journal‘ name = ‘Conference‘

Figure 7: Benchmark Example 3 – Different Metamodeling Concept Heterogeneities (A2C, CA2R)

the LHS MM, i.e., the RHS links have to be generated, rep-resenting the second challenge in the example. In order toestablish such additional links in the RHS, the informationis needed in which relation the to be linked concepts havebeen in the LHS MM. With respect to this example, thesource of the EReference Publication.kind is representedin the LHS MM by means of the EClass Publication andthe target of the EReference by means of the EAttribute

Publication.kind. Therefore, this heterogeneity is clas-sified as C(lass)A(ttribute)2R(eference), whereby the firstletter depicts the used LHS concept for the source of the tobe generated reference and the second letter the used LHSconcept for the target of the to be generated reference.

Discussion of Resolution Strategies. When taking alook at the example instances, one can see that the desiredintention of an A2C heterogeneity is that only for distinctPublication.kind attribute values an according Kind ob-ject should be generated. Therefore, the RHS model ex-hibits only a single object named Journal (cf. K1 in Fig. 7),which is referenced by the Publication objects P1 and P2.

4.2 Benchmark Example 4Whereas the previous example exhibited the heterogeneity

that a LHS concept is modeled by means of an EAttribute

and the RHS concept by means of an EClass, the followingexample (cf. Fig. 8) exhibits the heterogeneity that a LHSconcept is modeled by means of an EReference whereas theequivalent RHS concept is again represented by an EClass.The main challenges in this example are:

1. EReference Professor.publications –EClass DBLPEntry: R2C

2. EReference Professor.publications –EAttribute DBLPEntry.id: R2A

3. EClass Professor,EReference Professor.publications

– EReference Professor.entries: CR2R

4. EReference Professor.publications,EClass Publication

– EReference DBLPEntry.publication: RC2R

Example Description. Whereas the class Professor inthe LHS MM in Fig. 8 has a direct EReference Professor.-

publications, the LHS MM offers this information only in-directly by means of the EClass DBLPEntry and its ERefer-ence DBLPEntry.publication, representing the first chal-lenge in this example (cf.R(eference)2C(lass) feature valuein Fig. 4). Concerning the second challenge, values for theDBLP.id EAttribute have to be generated. Since the con-taining RHS EClass is generated on basis of the LHS ERef-

erence Professor.publications the according EAttribute

has also to be generated on basis of this EReference (cf.R(eference)2A(ttribute) feature value in Fig. 4). With re-spect to the third and fourth challenge, the according linkshave to be established. For this again the information isneeded in which relation the to be linked concepts have beenin the LHS MM, as described above. Concerning the Pro-

fessor.entries EReference, the source of the EReference

(Professor) is generated on basis of the LHS EClass Pro-

fessor and the target of the EReference (DBLPEntry) on ba-sis of the EReference Professor.publications – thus thisheterogeneity is classified as C(lass)R(eference)2R(eference).A similar situation occurs for the RHS EReference DBLPEn-

try.publication but in this case the source of the ERef-

erence bases on an EReference and the target bases on anEClass – a heterogeneity classified as R(eference)C(lass)2-R(eference).

Discussion of Resolution Strategies. The challengein this benchmark example is to obtain objects conform-ing to the RHS EClass DLBPEntry (cf. example instancesin Fig. 8). These RHS objects have to created on basisof the LHS links since these links encode the informationwhich publications belong to which professor which is alsothe task of DBLPEntry objects. Therefore, Fig. 8 depictsfour DLBPEntry objects which originate from the four LHSProfessor.publications links. To set the DBLPEntry.id

P fte x Professorname:String


0..*publications

ncret

yntax

g name:StringCo S y


1:1, C2C (no heterogeneity)

abstract = falsename = ‘Professor‘

( g y)

EAttribute 1:1, A2A (no

name = ‘name‘lowerBound = 1

, (

lowerBound = 1upperBound = 1 EString

eAttributeType

eAttributeType

Ch llyp Challe

x

EReference‘ bli ti ‘St t lF tyn

tax Challenge 1

name = ‘publications‘

lowerBound = 0ordered = false

eStructuralFeatures 1:1, R2C, Naming Difference

ct Sy

lowerBound = 0upperBound = -1containment = false

1:1, R2A, Nam

bstra

containment false

Ab

eReferenceType Challenge

EClassEClass

b t t f lname = ‘Publication‘

1:1 C2C (no heterogeneity)abstract = false 1:1, C2C (no heterogeneity)

EAttributename ‘name‘

eStructuralFeatures 1:1, A2A (noname = ‘name‘lowerBound = 1upperBound = 1

1:1, A2A (no

upperBound = 1

s

publicationspublicationsP1:Professor P2:Professor

publications bli tiances

publicationspublications name = ‘Prof1‘ name = ‘Prof2‘publications publications

Insta

P10:Publication P11:Publication P12:Publicationmple

P10:Publicationname = ‘P1‘

P11:Publicationname = ‘P2‘

P12:Publicationname = ‘P3‘Ex

amE

Professorname:String


DBLPEntryid:Integer

publication1..10.*

entries

name:String name:Stringid:Integer


abstract = falsename = ‘Professor‘

EAttributename = ‘name‘lowerBound = 1heterogeneity)heterogeneity) lowerBound = 1upperBound = 1

EStringAtt ib t T

eAttributeType

g y)g y)

g

EReferenceeAttributeType

1:1 CR2R Naming3 name = ‘entries‘

l B d 0ordered = falseeStructuralFeatures

1:1, CR2R, NamingDifference

enge 3

lowerBound = 0upperBound = -1containment = falsecontainment = false

eReferenceType

EClass‘DBLPE t ‘ Att ib t T

eStructuralFeatures1

abstract = falsename = ‘DBLPEntry‘ EAttribute

name = ‘id‘EInteger

eAttributeType

ffff name = idlowerBound = 1upperBound = 1

ming Differenceming Difference

upperBound = 1Challenge 2

EReferencename = ‘publication‘eStructuralFeatures p

lowerBound = 1ordered = false

eStructuralFeatures

1:1, RC2R, Naminge 4

eReferenceType

upperBound = 1containment = false

1:1, RC2R, NamingDifference

EClass

eReferenceType

EClass

b t t f lname = ‘Publication‘abstract = false

EAttributename ‘name‘heterogeneity)heterogeneity) name = ‘name‘lowerBound = 1upperBound = 1eStructuralFeatures

heterogeneity)heterogeneity)

upperBound = 1

P1:Professorentries

P2:Professorentries entries entriesname = ‘Prof1‘entries name = ‘Prof2‘entries entries entries

D1:DBLPEntry D2:DBLPEntry D3:DBLPEntry D4:DBLPEntryid = 1

publication

id = 2 id = 3 id = 4publication

P10:Publication

publication

P11:Publication P12:Publicationpublication publication

publication

name = ‘P1‘ name = ‘P2‘ name = ‘P3‘

Figure 8: Benchmark Example 4 – Different Metamodeling Concept Heterogeneities (R2C, R2A)

value a function is needed which generates an according idwhereby again for every LHS link an according RHS valueshould be created.

5. INHERITANCE HETEROGENEITIESIn the previous sections we discussed potential hetero-

geneities when considering the metamodeling concepts ofclasses, attributes and references. Finally, heterogeneitiesmight be caused by the concept of inheritance. In this re-spect we again divide into heterogeneities that might occuralthough both MMs use inheritance (cf. same metamod-eling concept inheritance differences in Fig. 4) and hetero-geneities that occur if only one MM makes use of inheri-tance (cf. different metamodeling concept inheritance differ-ences in Fig. 4). Similar to the afore mentioned same meta-modeling concept differences (cf. Section 3), same meta-metamodeling concept inheritance differences occur due todifferent attribute values or links in the Ecore MMs (cf.Fig. 3) whereas the latter heterogeneities occur if an inher-itance hierarchy in one MM is expressed by other concepts(i.e., classes, attributes, and references) in the other MM. Inthe following one example per category is given.

5.1 Benchmark Example 5This example (cf. Fig. 9) belongs to the same meta-

metamodeling concept category and therefore both MMs makeuse of inheritance. Nevertheless certain heterogeneities oc-cur, comprising breadth differences, depth differences and

concreteness differences. The main challenges in this exam-ple can be summarized as follows:

1. EClass FullProf, EClass AssistantProf –EClass FullProf: I2I, Breadth Difference

2. EClass Assistant – EClass Assistant:I2I, Concreteness Difference, Depth Difference

3. EClass PrePhd, EClass PostPhd –No corresponding EClass: I2I, Breadth Difference

Example Description. Concerning the first challenge,a breadth difference between the LHS EClasses FullProf,AssistantProf and the RHS EClass FullProf exists. Thisis since the number of sibling classes in the context of a cer-tain parent class differs. For resolving breadth differences,the strategy can be applied to map instances of some classonly existing in the LHS MM to a concrete parent classin the RHS MM. Nevertheless, since the parent classes ofthe EClass AssistantProf are abstract, instances of As-

sistantProf get lost. With respect to the second challenge,a concreteness difference as well as a depth difference occursbetween the two EClasses Assistant. This is since theEClass Assistant in the LHS MM is set abstract whereasthe corresponding EClass Assistant in the RHS MM isconcrete. Additionally, a depth difference exists, since thelongest path of subclasses in the context of the EClass As-

sistant in the LHS MM is 1 whereas it is 0 in the context ofthe corresponding class in the RHS MM. For resolving the

ResearchStaffResearchStaffname:String

tax

f

Synt

Professor Assistant

crete

Conc

PrePhdFullProf AssistantProf PostPhd

C

EClass‘R hS ff‘

1:1, C2C (no heterogeneity)1:1, C2C (no heterogeneity)

abstract = truename = ‘ResearchStaff‘

eSuperTypes

EAttributeEAttributename = ‘name‘l B d 1

eStructuralFeatures1:1, A2A (no hete1:1, A2A (no hete

eSuperTypes


eAttributeTypep yp

EClassname = ‘Professor‘

1:1, C2C (no heterogen1:1, C2C (no heterogen

abstract = truename = Professor

S T S T

EClass

eSuperTypes eSuperTypes

1:1, C2Ctax

abstract = falsename = ‘FullProf‘

Synt

abstract = false

tract

EClassname = ‘AssistantProf‘

1:0, breadth difference1:0, breadth differenceAbst

abstract = falsename = AssistantProf

Ch llEClass

Chall

abstract = truename = ‘Assistant‘ 1:1, C2C, concreteness difference, d

abstract trueeSuperTypes eSuperTypes

EClassname = ‘PrePhd‘

1:0, breadth difference1:0, breadth difference

abstract = falsename = PrePhd

EClass 1:0, breadth difference1:0, breadth difference

abstract = falsename = ‘PostPhd‘

P1:PrePhdF1:FullProfname = ‘Prof1‘ name = ‘PrePhd1‘pl

eces

A1:AssistantProf P2:PostPhd

name = Prof1 name PrePhd1

xamp

stanc

A1:AssistantProf P2:PostPhdname = ‘AssProf1‘ name = ‘PostPhd1‘Ex In

s

ResearchStaffResearchStaff

name:String

AssistantProfessor

FullProf

EClass‘R hSt ff‘

abstract = truename = ‘ResearchStaff‘

eSuperTypes

EAttributeEAttributename = ‘name‘l B d 1

erogeneity)erogeneity)



eSuperTypes

EClassname = ‘Professor‘

eity)eity)

abstract = truename Professor

S T

EClass

eSuperTypes

C, breadth differenceC, breadth difference


Challenge 1 abstract falseChallenge 1

2EClass

enge 2

abstract = falsename = ‘Assistant‘depth differencedepth difference

abstract false

Challenge 3

P1:AssistantF1:FullProf‘P f1‘ ‘P Phd1‘

P2:Assistant

name = ‘Prof1‘ name = ‘PrePhd1‘

P2:Assistantname = ‘PostPhd1‘


concreteness difference no strategy is needed in this exam-ple, since the LHS class is abstract and therefore no instancescan exist. The situation would be different, if it would beinverse. Then instances might be lost, if no concrete class inthe RHS MM for including those instances might be found.For resolving the depth difference, the strategy can be pur-sued to map instances of the classes only existing in the LHSMM to some concrete parent class in the RHS MM. There-fore, in this case the instances of the EClasses PrePhd andPostPhd result in instances of the parent EClass Assistant

in the RHS MM. Finally, regarding the third challenge, abreadth difference between the EClasses PrePhd and Post-

Phd and the non-existing RHS classes exists. Since in thiscase the breadth difference overlaps with the depth differ-ence of challenge 2 (being the case since the EClass As-

sistant in the RHS MM exhibits no subclasses at all), noadditional resolution strategy is needed here.

Discussion of Resolution Strategies. When taking alook at the chosen resolution strategies, one can see that astrategy has been chosen that tries to minimize instance lossand thus information loss. Therefore instances of a class thatonly exist in the LHS MM should be kept by mapping themto some concrete parent class due to the is-a relationshipbetween the classes. Nevertheless, the explicit type infor-mation and additional features only owned by the subclassare lost. Therefore sometimes also a strategy that omitsthese instances might be useful.

5.2 Benchmark Example 6This example (cf. Fig. 10) belongs to the different meta-

modeling concept category and therefore only one MM makesuse of inheritance. The main challenge in this example canbe summarized as follows:

1. EAttribute ResearchStaff.kind –EClasses ResearchStaff, Professor, Assistant

and FullProf in inheritance hierarchy: A2I

Example Description. With respect to the main chal-lenge in this example, an A(ttribute)2I(nheritance) hetero-geneity between the EAttribute ResearchStaff.kind andthe EClasses ResearchStaff, Professor, Assistant andFullProf occurs. For resolving this kind of heterogeneitya condition is needed to divide the instances of the EClass

ResearchStaff according to the values of the EAttribute

kind in order to instantiate instances of the correspondingRHS classes. Thereby the problem may arise, that the EAt-

tribute of the LHS MM comprises values that do not cor-respond to any (concrete) EClass in the RHS MM. This isthe case in the example with the instance R1, since the cor-responding EClass Professor in the RHS MM is abstractand can thus not be instantiated causing information loss.

Discussion of Resolution Strategies. Concerning theresolution strategy chosen in this example again informationloss should be prevented whenever possible. Nevertheless, asalready discussed above, this may not always be possible.

Inheritance Difference,

xR hSt ffyn

tax

ResearchStaff

name:StringeteSy

gkind:String

oncre

Co

EClassname = ‘ResearchStaff‘abstract = falsename = ResearchStaff

EAttribute 1:1 A2A (no hEAttributename = ‘name‘l B d 1

eStructuralFeatures

1:1, A2A (no h


eAttributeType

eAttrib teT pentax

EAttribute

eAttributeType

ct Syn

name = ‘kind‘lowerBound = 1

eStructuralFeaturesstrac

lowerBound 1upperBound = 1A

b

A2I

h llChallenge 1

R1:ResearchStaff R2:ResearchStaff R3:ResearchStaffle es

name = ‘staff1‘ki d ‘P f ‘

name = ‘staff2‘ki d ‘F llP f‘

name = ‘staff3‘ki d ‘A i t t‘xa

mp

stanc

kind = ‘Professor‘ kind = ‘FullProf‘ kind = ‘Assistant‘Ex Ins

, Non‐Overlapping, A2Ipp g

ResearchStaff

name:Stringname:String

AssistantProfessor

FullProf

EClEClassname = ‘ResearchStaff‘abstract = true

eSuperTypes

EAttributeheterogeneity)heterogeneity) EAttributename = ‘name‘l B d 1

heterogeneity)heterogeneity)



EClassname = ‘Professor‘abstract = true

S T

EClasseSuperTypes

eSuperTypes


EClassEClassname = ‘Assistant‘abstract = false

R3:AssistantR2:FullProf R3:Assistant

name = ‘staff3‘

R2:FullProf

name = ‘staff2‘

Figure 10: Benchmark Example 6 – Different Metamodeling Concept Heterogeneities (A2I)

6. RELATED WORKIn the following, two threads of related work are consid-

ered. First, our feature-based classification is compared toexisting classifications. Second, mapping benchmark is re-lated to existing mapping benchmarks. In this respect, atfirst the most closely related area of model engineering isexamined. Moreover, the more widely related areas of dataengineering and ontology engineering are investigated.

Existing Classifications.Model Engineering. Although model transformations and

thus the resolution of heterogeneities between MMs play avital role in MDE, to the best of our knowledge no dedicatedsurvey examining potential heterogeneities exists.

Data Engineering. In contrast to that, in the area ofdata engineering a plethora of literature exists for decadeshighlighting different aspects of heterogeneities in the con-text of database schemata. A first classification of semanticand structural heterogeneities when integrating two differentschemas was presented by Batini et al. in [2]. A systematicclassification of possible variations in a SQL statement waspresented by Kim et al. in [11], detailing Table-Table andAttribute-Attribute heterogeneities, e.g., wrt. cardinalities.The classification of Kashyap et al. presented in [10] pro-vides a broad overview on possible heterogeneities in a dataintegration scenario comprising semantic heterogeneities andconflicts occurring between same modeling concepts. Thework of Blaha et al. presented in [4] describes patternsresolving syntactic heterogeneities, comprising same meta-modeling concept heterogeneities as well as different meta-metamodeling concept heterogeneities. Finally, the classi-fication of Legler [13] presents a systematic approach forattribute mappings by combining possible attribute corre-spondences with cardinalities.

Ontology Engineering. Concerning the domain of ontologyengineering pattern collections as well as classifications exist.A pattern collection has been presented by Scharffe et al. in[14]. Thereby correspondence patterns for ontology align-

ments are presented, but on a rather coarse-grained level,e.g., conditional patterns dealing with attribute differencesand transformation patterns, vaguely dealing with differentmetamodeling concept heterogeneities. With respect to ex-isting classifications, Visser et al. [17] and Klein [12] providea comprehensive list of semantic heterogeneities. Neverthe-less, they have a strong focus on semantic heterogeneities,neglecting syntactic heterogeneities.

Summarizing, although there are several classificationsavailable, none explicitly focuses on the domain of MDE.Therefore we systematically analyzed variation points in theEcore meta-metamodel in order to extend and adapt exist-ing classifications. In this respect, we aligned on the onehand terms of existing classifications, e.g., most classifica-tions introduced terms for the heterogeneities summarizedin our classification by same metamodeling concept hetero-geneities. On the other hand, we introduced new hetero-geneities stemming from the explicit concepts of referencesand inheritance in object-oriented metamodels in contrastto existing classifications basing either on the relational orthe XML data model. Finally, current classifications miss toexplicate how different types of heterogeneities relate to eachother, which we formalized by means of a feature model.

Existing Benchmarks.Model Engineering. To the best of our knowledge no

benchmark for mapping systems in the area of MDE exists.Nevertheless, a benchmark for evaluating the performanceof graph transformations [16] has been proposed.

Data Engineering. In the area of data engineering Alexeet. al. propose in [1] a first benchmark for mapping sys-tems, thereby presenting a basic suite of mapping scenarioswhich should be readily supported by any mapping systemfocussing on information integration. In this respect, tenexamples are discussed for which the actual transformationfunctions are given in terms of XQuery5 expressions. Addi-

5http://www.w3.org/TR/xquery/

tional examples are presented on their homepage6. Althoughthe benchmark provides a first set of mapping scenarios itremains unclear how the scenarios have been obtained and ifthey provide full coverage in terms of expressivity. AlthoughXQuery expressions are given to define the semantics, someof the XQuery functions assume the availability of customfunctions which are not provided. Since there are also noRHS models given it is hard to get the actual outcome ofthe transformation. Finally, some scenarios are not clearlyspecified with the given query (cf. scenario 2 and 17 on theirhomepage). A further benchmark called THALIA is pre-sented by Hammer et. al in [7]. It provides researchers witha collection of twelve benchmark queries given in XQuery,focusing on the resolution of syntactic and semantic hetero-geneities in a data integration scenario. For every query a so-called reference schema (i.e., global schema) and a challengeschema is provided (i.e., the schema to be integrated) to-gether with instances. Although the paper claims a system-atic classification of semantic and syntactic heterogeneitiesleading to the presented queries, it is merely an enumerationof heterogeneities where the rationale behind is left unclear.

Ontology Engineering. With respect to the area of ontol-ogy engineering, no dedicated mapping benchmark exists.Nevertheless, efforts concerning the evaluation of matchingtools, i.e., tools for automatically discovering alignments be-tween ontologies have been spent, resulting in an ontologymatching benchmark7 whereby these examples could be ofinterest for a dedicated mapping benchmark as well.

Summarizing, although both benchmarks from the area ofdata engineering provide useful scenarios in the context ofXML they do not provide a systematic classification result-ing in a systematic set of benchmark examples to evaluatethe expressivity of a certain mapping system.

7. CONCLUSION AND FUTURE WORKIn this paper we presented a systematic classification of

heterogeneities occurring between Ecore-based MMs. Nev-ertheless, this classification of heterogeneities can also beapplied to other semantic data models, comprising the com-mon core concepts this classification bases on. Moreover, afirst set of benchmark examples has been proposed statingthe requirements a mapping tool should fulfill. Additionally,these benchmark examples can be used to compare solutionsrealized with ordinary transformation languages. Furtherwork comprise the completion of the benchmark examplesto fully cover the classification. However, the success of abenchmark heavily depends on the agreement of the com-munity – thus our collaborative homepage invites for discus-sions. Finally, a tool evaluation on basis of this benchmarkis envisioned comparing and evaluating mapping tools fromdiverse engineering domains wrt. their expressivity.

8. REFERENCES[1] B. Alexe, W.-C. Tan, and Y. Velegrakis.

STBenchmark: Towards a Benchmark for MappingSystems. VLDB Endow., 1(1):230–244, 2008.

[2] C. Batini, M. Lenzerini, and S. B. Navathe. AComparative Analysis of Methodologies for DatabaseSchema Integration. ACM Comp. Surv.,18(4):323–364, 1986.

6http://www.stbenchmark.org/7http://oaei.ontologymatching.org/2010/

[3] J. Bezivin. On the Unification Power of Models.Journal on SoSyM, 4(2):31, 2005.

[4] M. Blaha and W. Premerlani. A catalog of objectmodel transformations. In Proc. of the 3rd WorkingConference on Reverse Engineering, WCRE’96, pages87–96, 1996.

[5] K. Czarnecki, S. Helsen, and U. Eisenecker. StagedConfiguration Using Feature Models. In Proc. of ThirdSoftware Product Line Conf., pages 266–283, 2004.

[6] M. Del Fabro and P. Valduriez. Towards the efficientdevelopment of model transformations using modelweaving and matching transformations. Journal onSoSyM, 8(3):305–324, July 2009.

[7] J. Hammer, M. Stonebraker, and O. Topsakal.THALIA: Test harness for the assessment of legacyinformation integration approaches. In Proc. of theInt. Conf. on Data Engineering, ICDE, pages485–486, 2005.

[8] D. Harel and B. Rumpe. Meaningful modeling:What’s the semantics of ”semantics”? Computer,37:64–72, 2004.

[9] R. Hull and R. King. Semantic Database Modeling:Survey, Applications, and Research Issues. ACMComput. Surv., 19(3):201–260, 1987.

[10] V. Kashyap and A. Sheth. Semantic and schematicsimilarities between database objects: A context-basedapproach. The VLDB Journal, 5(4):276–304, 1996.

[11] W. Kim and J. Seo. Classifying Schematic and DataHeterogeneity in Multidatabase Systems. Computer,24(12):12–18, 1991.

[12] M. Klein. Combining and relating ontologies: ananalysis of problems and solutions. In Proc. ofWorkshop on Ontologies and Information Sharing,IJCAIS01, 2001.

[13] F. Legler and F. Naumann. A Classification of SchemaMappings and Analysis of Mapping Tools. In Proc. ofthe GI-Fachtagung fur Datenbanksysteme in Business,Technologie und Web (BTW’07), 2007.

[14] F. Scharffe and D. Fensel. Correspondence Patternsfor Ontology Alignment. In Proc. of the 16th Int.Conf. on Knowledge Engineering, EKAW ’08, pages83–92, 2008.

[15] A. P. Sheth and J. A. Larson. Federated DatabaseSystems for Managing Distributed, Heterogeneous,and Autonomous Databases. ACM Comput. Surv.,22(3):183–236, 1990.

[16] G. Varro, A. Schurr, and D. Varro. Benchmarking forgraph transformation. In Proc. of the 2005 IEEESymposium on Visual Languages and Human-CentricComputing, VLHCC ’05, pages 79–88, 2005.

[17] P. R. S. Visser, D. M. Jones, T. J. M. Bench-Capon,and M. J. R. Shave. An analysis of ontologicalmismatches: Heterogeneity versus interoperability. InProc. of AAAI 1997 Spring Symposium on OntologicalEngineering, 1997.

[18] M. Wimmer, G. Kappel, A. Kusel, W. Retschitzegger,J. Schonbock, and W. Schwinger. Surviving theHeterogeneity Jungle with Composite MappingOperators. In Proc. of the 3rd Int. Conf. on ModelTransformation, ICMT 2010, pages 260–275, 2010.

Towards an Expressivity Benchmark for Mappings based on a ... · tool-speci c metamodels. Thereby...

Documents

Transcript of Towards an Expressivity Benchmark for Mappings based on a ... · tool-speci c metamodels. Thereby...