Bok:978 3 642 24574 9 PDF

Lecture Notes in Computer Science 6999
Commenced Publication in 1973

Founding and Former Series Editors:
Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen
Editorial Board
David Hutchison
Lancaster University, UK
Takeo Kanade
Carnegie Mellon University, Pittsburgh, PA, USA
Josef Kittler
University of Surrey, Guildford, UK
Jon M. Kleinberg
Cornell University, Ithaca, NY, USA
Alfred Kobsa
University of California, Irvine, CA, USA
Friedemann Mattern
ETH Zurich, Switzerland
John C. Mitchell
Stanford University, CA, USA
Moni Naor
Weizmann Institute of Science, Rehovot, Israel
Oscar Nierstrasz
University of Bern, Switzerland
C. Pandu Rangan
Indian Institute of Technology, Madras, India
Bernhard Steffen
TU Dortmund University, Germany
Madhu Sudan
Microsoft Research, Cambridge, MA, USA
Demetri Terzopoulos
University of California, Los Angeles, CA, USA
Doug Tygar
University of California, Berkeley, CA, USA
Gerhard Weikum
Max Planck Institute for Informatics, Saarbruecken, Germany
Olga De Troyer Claudia Bauzer Medeiros
Roland Billen Pierre Hallot
Alkis Simitsis Hans Van Mingroot (Eds.)
Advances in
Conceptual Modeling
Recent Developments and New Directions
ER 2011 Workshops FP-UML, MoRE-BI,

Onto-CoM, SeCoGIS, Variability@ER, WISM
Brussels, Belgium, October 31 - November 3, 2011
Proceedings
13
Volume Editors
Olga De Troyer
Vrije Universiteit Brussel, Department of Computer Science, Brussel, Belgium
E-mail: olga.detroyer@vub.ac.be
Claudia Bauzer Medeiros

University of Campinas, Institute of Computing, Campinas, SP, Brazil
E-mail: cmbm@ic.unicamp.br
Roland Billen
Pierre Hallot
Universit de Lige, Geomatics Unit, Lige, Belgium
E-mail: {rbillen; p.hallot}@ulg.ac.be
Alkis Simitsis
Hewlett-Packard Laboratories, Palo Alto, CA, USA
E-mail: alkis@hp.com
Hans Van Mingroot

Business Development and Academic Relations Belgium-Luxembourg
Brussel, Belgium
E-mail: vanmingroot@be.ibm.com
ISSN 0302-9743 e-ISSN 1611-3349

ISBN 978-3-642-24573-2 e-ISBN 978-3-642-24574-9
DOI 10.1007/978-3-642-24574-9
Springer Heidelberg Dordrecht London New York
Library of Congress Control Number: 2011937539
CR Subject Classication (1998): H.4, H.3, I.2, D.2, C.2, H.5
LNCS Sublibrary: SL 3 Information Systems and Application, incl. Internet/Web

and HCI
Springer-Verlag Berlin Heidelberg 2011
This work is subject to copyright. All rights are reserved, whether the whole or part of the material is
concerned, specically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting,
reproduction on microlms or in any other way, and storage in data banks. Duplication of this publication
or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965,
in its current version, and permission for use must always be obtained from Springer. Violations are liable
to prosecution under the German Copyright Law.
The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply,
even in the absence of a specic statement, that such names are exempt from the relevant protective laws
and regulations and therefore free for general use.
Typesetting: Camera-ready by author, data conversion by Scientic Publishing Services, Chennai, India
Printed on acid-free paper
Springer is part of Springer Science+Business Media (www.springer.com)
Preface to ER 2011 Workshops, Posters,
Demonstrations, and Industrial Papers
This book contains the proceedings of the workshops associated with the 30th
International Conference on Conceptual Modeling (ER 2011), as well as the pa-
pers associated with the Posters and Demonstrations Session, and the Industrial
Track of ER 2011.
As always, the aim of the workshops was to give researchers and participants
a forum to present and discuss cutting edge research in conceptual modeling, and
to pose some of the challenges that arise when applying conceptual modeling in
less traditional areas. The workshops deal with theories, techniques, languages,
methods, and tools for conceptual modeling and span a wide range of domains
including web information systems, geographical information systems, business
intelligence, software variability management, and ontologies. Some of the work-
shops were organized for the rst time but others have a longer tradition. Six
workshops were selected and organized after a call for workshop proposals:
WISM: Web Information Systems Modeling

MORE-BI: Modeling and Reasoning for Business Intelligence
Variability@ER: Software Variability Management
Onto.Com: Ontologies and Conceptual Modeling
SeCoGIS: Semantic and Conceptual Issues in GIS
FP-UML: Foundations and Practices of UML
In all, 31 workshop papers were accepted from a total of 88 submitted, making

an overall acceptance rate of 35%.
For the posters and demonstrations session, nine contributions were selected.
The aim of this session was to give researchers a highly interactive forum to show
research work in progress and to demonstrate new and innovative applications.
The industrial track is the forum for presentations on innovative commercial
software, systems, and services for all facets of conceptual modeling method-
ologies and technologies. For the 2011 edition, 6 papers were accepted from a
total of 11 submitted. The papers present emerging industrial applications of
conceptual modeling, as well as business intelligence applications.
Setting up workshops, a poster and demonstration session, and an industrial
track requires a lot of eort and involves many people. We would like to thank
the dierent Workshop Chairs and their Program Committees, the Program
Committee of the posters and demonstrations, and the Program Committee
of the industrial track for their diligence in selecting the papers in this volume.
VI Preface
We would also like to thank the main ER 2011 conference committees, particu-
larly the Conference Co-chairs, Esteban Zim
anyi and Jean-Luc Hainaut, the Con-
ference Program Co-chairs, Manfred Jeusfeld, Lois Delcambre, and Tok Wang
Ling, and the Webmaster, Boris Verhaegen, for their support and for putting
the program together.
July 2011 Olga De Troyer

Claudia Bauzer Medeiros
Roland Billen
Pierre Hallot
Alkis Simitsis
Hans Van Mingroot
ER 2011 Workshops, Posters, Demonstrations,
and Industrial Track Organization
Workshop Co-chairs
Olga De Troyer Vrije Universiteit Brussel, Belgium
Claudia Bauzer Medeiros University of Campinas, Brazil
WISM 2011
WISM 2011 was organized by the Econometric Institute, Erasmus University
Rotterdam, Netherlands; the Department of Computer Science, Delft University
of Technology, Netherlands; and the Department of Computer Science, Namur
University, Belgium.
Program Committee
Workshop Co-chairs
Flavius Frasincar Erasmus University Rotterdam,
The Netherlands
Geert-Jan Houben Delft University of Technology,
The Netherlands
Philippe Thiran Namur University, Belgium
Program Committee
Djamal Benslimane University of Lyon 1, France
Sven Casteleyn Polytechnic University of Valencia, Spain
Richard Chbeir Bourgogne University, France
Roberto De Virgilio Universit`
a di Roma Tre, Italy
Oscar Diaz University of the Basque Country, Spain
Flavius Frasincar Erasmus University Rotterdam,
The Netherlands
Martin Gaedke Chemnitz University of Technology, Germany
Irene Garrigos Universidad de Alicante, Spain
Hyoil Han LeMoyne-Owen College, USA
Geert-Jan Houben Delft University of Technology,
The Netherlands
Zakaria Maamar Zayed University, UAE
Michael Mrissa University of Lyon 1, France
Moira Norrie ETH Zurich, Switzerland
VIII Organization
Oscar Pastor Polytechnic University of Valencia, Spain

Dimitris Plexousakis University of Crete, Greece
Jose Palazzo Moreira
de Oliveira UFRGS, Brazil
Azzurra Ragone Technical University of Bari, Italy
Hajo Reijers Eindhoven University of Technology,
The Netherlands
Davide Rossi University of Bologna, Italy
Philippe Thiran Namur University, Belgium
A Min Tjoa Technical University of Vienna, Austria
Riccardo Torlone Università di Roma Tre, Italy
Lorna Uden Staordshire University, UK
Erik Wilde UC Berkeley, USA
External Reviewers
J.A. Aguilar
A. Bikakis
F. Valverde
MORE-BI 2011
Program Committee
Workshop Co-chairs
Ivan Jureta FNRS and Louvain School of Management,
University of Namur, Belgium
Stephane Faulkner Louvain School of Management, University of
Namur, Belgium
Esteban Zim
anyi Universite Libre de Bruxelles, Belgium
Steering Committee
Ivan Jureta FNRS and Louvain School of Management,
Stephane Faulkner Louvain School of Management,
Esteban Zim
any Universite Libre de Bruxelles, Belgium
Marie-Aude Aufaure Ecole Centrale Paris, France
Carson Woo Sauder School of Business, Canada
Program Committee
Alberto Abello Universitat Politècnica de Catalunya, Spain
Daniele Barone University of Toronto, Canada
Ladjel Bellatreche Ecole Nationale Superieure de Mecanique
et dAerotechnique, France
Organization IX
Sandro Bimonte Cemagref, France

Farid Cerbah Dassault Aviation, France
Dalila Chiadmi Ecole Mohammadia dIngenieurs, Morocco
Alfredo Cuzzocrea University of Calabria, Italy
Olivier Corby INRIA, France
Marin Dimitrov Ontotext, Bulgaria
Jerome Euzenat INRIA Grenoble Rhone-Alpes, France
Cecile Favre Universite Lyon 2, France
Xavier Franch Universitat Politècnica de Catalunya, Spain
Octavio Glorio University of Alicante, Spain
Matteo Golfarelli University of Bologna, Italy
Gregor Hackenbroich SAP, Germany
Dimitris Karagiannis University of Vienna, Austria
Vijay Khatri Indiana University, USA
Isabelle Linden University of Namur, Belgium
Patrick Marcel Universite Francois Rabelais de Tours, France
Maryvonne Miquel Institut National des Sciences Appliquees
de Lyon, France
Jose-Norberto Maz on University of Alicante, Spain
John Mylopoulos University of Trento, Italy
Carlos Ordonez University of Houston, USA
Jerey Parsons Memorial University of Newfoundland, Canada
Anna Perini Fondazione Bruno Kessler, Italy
Stefano Rizzi University of Bologna, Italy
Catherine Roussey Universite de Lyon, France
Anne Tchounikine Institut National des Sciences Appliquees
de Lyon, France
Maguelonne Teisseire UMR TETIS, France
Juan-Carlos Trujillo Mondejar University of Alicante, Spain
Robert Wrembel Poznan University of Technology, Poland
Variability@ER 2011
Program Committee
Workshop Co-chairs
Iris Reinhartz-Berger University of Haifa, Israel
Arnon Sturm Ben Gurion University of the Negev, Israel
Kim Mens Universite catholique de Louvain, Belgium
Program Committee
Felix Bachmann SEI, USA
David Benavides University of Seville, Spain
Jan Bosch Intuit, Mountain View, USA
Paul Clements SEI, USA
X Organization
Anthony Cleve University of Namur FUNDP, Belgium

Ulrich Eisenecker Leipzig University, Germany
ystein Haugen University of Oslo, Norway
Brice Morin University of Oslo, Norway
Linda Northrop SEI, USA
Gilles Perrouin University of Namur FUNDP, Belgium
Frank van der Linden Philips, The Netherlands
Onto.Com 2011
Program Committee
Workshop Co-chairs
Giancarlo Guizzardi Federal University of Espirito Santo, Brazil
Yair Wand University of British Columbia, Canada
Program Committee
Alessandro Artale Free University of Bolzano, Italy
Alex Borgida Rutgers University, USA
Andreas Opdahl University of Bergen, Norway
Bert Bredeweg University of Amsterdam, The Netherlands
Brian Henderson-Sellers University of Technology Sydney, Australia
Carson Woo University of British Columbia, Canada
Chris Partridge BORO Solutions, UK
Claudio Masolo Laboratory for Applied Ontology (ISTC-CNR),
Italy
Colin Atkinson University of Mannheim, Germany
David Embley Brigham Young University, USA
Dragan Gasevic Athabasca University, Canada
Fred Fonseca Penn State University, USA
Gerd Wagner Brandenburg University of Technology,
Germany
Giancarlo Guizzardi Federal University of Espirito Santo, Brazil
Heinrich Herre University of Leipzig, Germany
Heinrich Mayr University of Klagenfuhrt, Austria
Jean-Marie Favre University of Grenoble, France
Jerey Parsons Memorial University of Newfoundland, Canada
Joerg Evermann Memorial University of Newfoundland, Canada
John Mylopoulos University of Trento, Italy
Jose Palazzo M. de Oliveira Federal University of Rio Grande do Sul, Brazil
Leo Orbst MITRE Corporation, USA
Matthew West Information Junction, UK
Michael Rosemann University of Queensland, Australia
Organization XI
Nicola Guarino Laboratory for Applied Ontology (ISTC-CNR),

Italy
Palash Bera Texas A&M International University, USA
Peter Green University of Queensland, Australia
Peter Rittgen University College Boras, Sweden
Pnina Soer University of Haifa, Israel
Richard Dapoigny University of Savoie, France
Simon Milton University of Melbourne, Australia
Stephen Liddle Brigham Young University, USA
Vadim Ermolayev Zaporozhye National University, Ukraine
Veda Storey Georgia State University, USA
Vijay Khatri Indiana University, USA
Yair Wand University of British Columbia, Canada
Wolfgang Hesse University of Marburg, Germany
SeCoGIS 2011
Program Committee
Workshop Co-chairs
Roland Billen Universite de Liège, Belgium
Esteban Zim anyi Universite Libre de Bruxelles, Belgium
Pierre Hallot Universite de Liège, Belgium
Steering Committee
Claudia Bauzer Medeiros University of Campinas, Brazil
Michela Bertolotto University College Dublin, Ireland
Jean Brodeur Natural Resources Canada
Christophe Claramunt Naval Academy Research Institute, France
Christelle Vangenot Universite de Genève, Switzerland
Program Committee
Alia Abdelmoty Cardi University, UK
Gennady Andrienko Fraunhofer Institute IAIS, Germany
Natalia Andrienko IAIS Fraunhofer, Germany
David Bennett The University of Iowa, USA
Michela Bertolotto University College Dublin, Ireland
Patrice Boursier University of La Rochelle, France
Jean Brodeur National Resources Canada
Benedicte Bucher Institut Geographique National, France
Yvan Bedard Laval University, Canada
XII Organization
Ricardo Rodrigues Ciferri UFSCar, Brazil

Christophe Claramunt Naval Academy Reseach Institute, France
Eliseo Clementini University of LAquila, Italy
Maria Luisa Damiani University of Milan, Italy
Clodoveu Davis Federal University of Minas Gerais, Brazil
Fernando Ferri IRPPS-CNR, Italy
Jugurta Lisboa Filho Universidade Federal de Vicosa, Brazil
Anders Friis-Christensen Denmark
Bo Huang The Chinese University of Hong Kong,
Hong Kong, China
Marinos Kavouras NTUA, Greece
Ki-Joune Li Pusan National University, South Korea
Therèse Libourel Universite Montpellier II, France
Miguel Luaces University of A Coru na, Spain
Jose Macedo Federal University of Ceara, Brazil
Antonio Miguel Vieira
Monteiro INPE - National Institute for Space Research,
Brazil
Pedro Rafael Muro Medrano University of Zaragoza, Spain
Dimitris Papadias HKUST, Hong Kong, China
Dieter Pfoser IMIS/ATHENA, Greece
Markus Schneider University of Florida, USA
Sylvie Servigne-Martin LIRIS, INSA-Lyon, France
Emmanuel Stefanakis Harokopio University of Athens, Greece
Kathleen Stewart-Hornsby University of Iowa, USA
Andrea Rodriguez Tastets University of Concepcion, Chile
Kerry Taylor CSIRO ICT Centre, Australia
Peter Van Oosterom Delft University of Technology, OTB,
GIS Technology, The Netherlands
Christelle Vangenot University of Geneva, Switzerland
Nancy Wiegand University of Wisconsin, USA
Stephan Winter The University of Melbourne, Australia
FP-UML 2011
Program Committee
Workshop Co-chairs
Guido Geerts University of Delaware, USA
Matti Rossi Aalto University, Finland
Steering Committee
Juan Trujillo University of Alicante, Spain
Il-Yeol Song Drexel University, USA
Organization XIII
Je Parsons Memorial University of Newfoundland, Canada

Andreas L. Opdahl University of Bergen, Norway
Program Committee
Doo-Hwan Bae EECS Dept. KAIST, South Korea
Michael Blaha OMT Associates Inc., USA
Cristina Cachero University of Alicante, Spain
Gill Dobbie University of Auckland, New Zealand
Dirk Draheim Inst. of Computer Science, Freie Univ. Berlin,
Germany
Eduardo Fernandez University of Castilla La Mancha, Spain
Frederik Gailly Vrije Universiteit Brussel, Belgium
Paolo Giorgini University of Trento, Italy
Jaime Gomez University of Alicante, Spain
Peter Green University of Queensland, Australia
Manfred Jeusfeld Tilburg University, The Netherlands
Ludwik Kuzniarz Blekinge Institute of Technology, Sweden
Jens Lechtenborger University of Munster, Germany
Pericles Loucopoulos University of Manchester, UK
Kalle Lyytinen Case Western Reserve University, USA
Hui Ma Massey University, New Zealand
Antoni Olive Polytechnic University of Catalonia, Spain
Witold Pedrycz Univerisity of Alberta, Canada
Mario Piattini University of Castilla La Mancha, Spain
Colette Rolland Universite de Paris, France
Manuel Serrano University of Castilla La Mancha, Spain
Keng Siau University of Nebraska-Lincoln, USA
Bernhard Thalheim Universitaet zu Kiel, Germany
A Min Tjoa Technical University of Vienna, Austria
Ambrosio Toval University of Murcia, Spain
Panos Vassiliadis University of Ioannina, Greece
Harry (Jiannan) Wang University of Delaware, USA
Posters and Demonstrations
Program Committee
Co-chairs
XIV Organization
Program Committee
Renata Ara
ujo Universidade Federal do Estado do
Rio de Janeiro, Brazil
Michael Blaha OMT Associates, USA
Irene Garrigos University of Alicante, Spain
Pierre Geurts Universite de Liège, Belgium
Sergio Lifschitz Pontifcia Universidade Catolica do
Rio de Janeiro, Brazil
Jose-Norberto Mazon Universidad de Alicante, Spain
Sergio Lujan Mora Universidad de Alicante, Spain
German Shegalov Oracle, USA
Alkis Simitsis HP Labs, USA
David Taniar Monash University, Australia
Industrial Track
Program Committee
Co-chairs
Alkis Simitsis HP Labs, USA
Hans Van Mingroot IBM, Belgium
Program Committee
Phil Bernstein Microsoft Research, USA
Umeshwar Dayal HP Labs, USA
Howard Ho IBM Research, USA
Neoklis Polizotis UCSC, USA
Erik Proper Public Research Centre - Henri Tudor,
Luxembourg
Sabri Skhiri Euranova, Belgium
Jan Verelst University of Antwerp, Belgium)
Table of Contents
WISM 2011 - The Eighth International Workshop

on Web Information Systems Modeling
Preface to WISM 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Flavius Frasincar, Geert-Jan Houben, and Philippe Thiran
Social Networks and Data Interoperability in Web

Information Systems
Academic Social Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Jose Palazzo Moreira de Oliveira, Giseli Rabello Lopes, and
Mirella Moura Moro
Conceptual Modelling for Web Information Systems: What Semantics

Can Be Shared? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Simon McGinnes
Requirements Analysis, User Interaction, and

Service Composition in Web Information Systems
A Goal-Oriented Approach for Optimizing Non-functional Requirements
in Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Jose Alfonso Aguilar, Irene Garrig os, and Jose-Norberto Maz on
Yet Another BPEL Extension for User Interactions . . . . . . . . . . . . . . . . . . . 24

Mohamed Boukhebouze, Waldemar Pires Ferreira Neto, and
Lim Erbin
Semantics-Enabled Web API Organization and Recommendation . . . . . . . 34

Devis Bianchini, Valeria De Antonellis, and Michele Melchiori
MORE-BI 2011 - The First International Workshop

on Modeling and Reasoning for Business Intelligence
Preface to MORE-BI 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Ivan J. Jureta, Stephane Faulkner, and Esteban Zim anyi
Formal Concept Analysis for Qualitative Data Analysis over Triple

Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Frithjof Dau and Baris Sertkaya
XVI Table of Contents
Semantic Cockpit: An Ontology-Driven, Interactive Business

Intelligence Tool for Comparative Data Analysis . . . . . . . . . . . . . . . . . . . . . 55
Bernd Neumayr, Michael Schre, and Konrad Linner
A Model-Driven Approach for Enforcing Summarizability in

Multidimensional Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Jose-Norberto Mazon, Jens Lechtenb orger, and Juan Trujillo
Repairing Dimension Hierarchies under Inconsistent Reclassication . . . . 75

Monica Caniupan and Alejandro Vaisman
GrHyMM: A Graph-Oriented Hybrid Multidimensional Model . . . . . . . . . 86

Francesco Di Tria, Ezio Lefons, and Filippo Tangorra
Ontologies and Functional Dependencies for Data Integration and

Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Abdelghani Bakhtouchi, Ladjel Bellatreche, and Yamine Ait-Ameur
A Comprehensive Framework on Multidimensional Modeling . . . . . . . . . . 108

Oscar Romero and Alberto Abell
o
Variability@ER11 - Workshop on Software

Variability Management
Preface to Variability@ER11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Iris Reinhartz-Berger, Arnon Sturm, and Kim Mens
ISO Initiatives on Software Product Line Engineering: Vision and

Current Status: Invited Talk for Variability@ER2011 . . . . . . . . . . . . . . . . . 119
Timo K. K ak
ol
a
Feature Modeling Tools: Evaluation and Lessons Learned . . . . . . . . . . . . . 120

Mohammed El Dammagh and Olga De Troyer
Service Variability Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Ateeq Khan, Christian K astner, Veit K oppen, and Gunter Saake
An Overview of Techniques for Detecting Software Variability Concepts

in Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Angela Lozano
Variability in Multi-tenant Environments: Architectural Design

Patterns from Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Jaap Kabbedijk and Slinger Jansen
Table of Contents XVII
Onto.Com 2011 - International Workshop on

Ontologies and Conceptual Modeling
Preface to Onto.Com 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Giancarlo Guizzardi, Oscar Pastor, and Yair Wand
Experimental Evaluation of an Ontology-Driven Enterprise Modeling

Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Frederik Gailly and Geert Poels
Levels for Conceptual Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Claudio Masolo
Principled Pragmatism: A Guide to the Adaptation of Ideas from

Philosophical Disciplines to Conceptual Modeling . . . . . . . . . . . . . . . . . . . . 183
David W. Embley, Stephen W. Liddle, and Deryle W. Lonsdale
Ontological Usage Schemes: A Working Proposal for the Ontological

Foundation of Language Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Frank Loebe
Gene Ontology Based Automated Annotation: Why It Isnt Working . . . 203

Matthijs van der Kroon and Ana M. Levin
Formal Ontologies, Exemplars, Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Marcello Frixione and Antonio Lieto
Unintended Consequences of Class-Based Ontological Commitment . . . . . 220

Roman Lukyanenko and Jerey Parsons
SeCoGIS 2011 - The Fifth International Workshop

on Semantic and Conceptual Issues in GIS
Preface to SeCoGIS 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Esteban Zimanyi, Roland Billen, and Pierre Hallot
Referring Expressions in Location Based Services: The Case of the

Opposite Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Phil Bartie, Femke Reitsma, Eliseo Clementini, and Simon Kingham
Cognitive Adequacy of Topological Consistency Measures . . . . . . . . . . . . . 241

Nieves R. Brisaboa, Miguel R. Luaces, and M. Andrea Rodrguez
The Neighborhood Conguration Model: A Framework to Distinguish

Topological Relationships between Complex Volumes . . . . . . . . . . . . . . . . . 251
Tao Chen and Markus Schneider
Reasoning with Complements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Max J. Egenhofer
XVIII Table of Contents
Towards Modeling Dynamic Behavior with Integrated Qualitative

Spatial Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Stefan Mitsch, Werner Retschitzegger, and Wieland Schwinger
Transforming Conceptual Spatiotemporal Model into Object Model

with Semantic Keeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Chamseddine Zaki, Myriam Servières, and Guillaume Moreau
FP-UML - The Seventh International Workshop on

Foundations and Practices of UML
Preface to FP-UML 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Guido L. Geerts and Matti Rossi
On Automated Generation of Associations in Conceptual Database

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Drazen Brdjanin and Slavko Maric
Specication and Utilization of Core Assets: Feature-Oriented vs.

UML-Based Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Iris Reinhartz-Berger and Arava Tsoury
Actor-eUML for Concurrent Programming . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Kevin Marth and Shangping Ren
Posters and Demonstrations
Preface to the Posters and Demonstrations . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Roland Billen and Pierre Hallot
An Eclipse Plugin for Validating Names in UML Conceptual

Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
David Aguilera, Ra ul Garca-Ranea, Cristina G omez, and
Antoni Olive
KEYRY: A Keyword-Based Search Engine over Relational Databases

Based on a Hidden Markov Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Sonia Bergamaschi, Francesco Guerra, Silvia Rota, and
Yannis Velegrakis
VirtualEMF: A Model Virtualization Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Caue Clasen, Frederic Jouault, and Jordi Cabot
Table of Contents XIX
Towards a Model-Driven Framework for Web Usage Warehouse

Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Paul Hernandez, Octavio Glorio, Irene Garrig os, and
Jose-Norberto Maz on
CRESCO: Construction of Evidence Repositories for Managing

Standards Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Rajwinder Kaur Panesar-Walawege, Torbjrn Skyberg Knutsen,
Mehrdad Sabetzadeh, and Lionel Briand
Modeling Approach for Business Networks with an Integration and

Business Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Daniel Ritter and Ankur Bhatt
Mosto: Generating SPARQL Executable Mappings between

Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Carlos R. Rivero, Inma Hern andez, David Ruiz, and
Rafael Corchuelo
The CSTL Processor: A Tool for Automated Conceptual Schema

Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Albert Tort, Antoni Olive, and Maria-Ribera Sancho
A Tool for Filtering Large Conceptual Schemas . . . . . . . . . . . . . . . . . . . . . . 353

Antonio Villegas, Maria-Ribera Sancho, and Antoni Olive
Industrial Track
Preface to the Industrial Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Alkis Simitsis and Hans Van Mingroot
Business Intelligence
QBX: A CASE Tool for Data Mart Design . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Antonino Battaglia, Matteo Golfarelli, and Stefano Rizzi
The Meta-Morphing Model Used in TARGIT BI Suite . . . . . . . . . . . . . . . . 364

Morten Middelfart and Torben Bach Pedersen
Tool Support for Technology Scouting Using Online Sources . . . . . . . . . . . 371

Elena Tsiporkova and Tom Tourwe
Industrial Applications of Conceptual Modeling

Governance Issues on Heavy Models in an Industrial Context . . . . . . . . . . 377
Sabri Skhiri, Marc Delbaere, Yves Bontemps,
Gregoire de Hemptinne, and Nam-Luc Tran
XX Table of Contents
High Quality Technical Documentation for Large Industrial Plants

Using an Enterprise Engineering and Conceptual Modeling Based
Software Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Steven J.H. van Kervel
Publishing Open Data and Services for the Flemish Research

Information Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Christophe Debruyne, Pieter De Leenheer, Peter Spyns,
Geert van Grootel, and Stijn Christiaens
Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

Preface to WISM 2011
The international workshop on Web Information Systems Modeling (WISM) aims to

uncover the most recent developments in the field of model-driven design of Web In-
formation Systems (WIS). This is the eighth edition of the workshop, after seven suc-
cessful editions organized in Vancouver (2010), Amsterdam (2009), Barcelona (2008),
Trondheim (2007), Luxembourg (2006), Sydney (2005), and Riga (2004).
The extended abstract of the invited talk by de Oliveira et al. proposes concepts
for Social Network Analysis to be applied for online Academic Social Networks. More
specifically, it investigates the network analysis, work dissemination, and partner rec-
ommendation in an academic context. The social network based on co-author relation-
ships among researchers is used as an example.
The first paper by McGinnes proposes research directions for handling data ex-
change between heterogeneous WIS. These research directions are developed around
the idea of building a basic ontology containing a simple set of shared concepts. The
author argues that knowing the types of the shared concepts is not enough to ensure
WIS interoperability, as WIS need be able to programmatically handle these types.
The second paper by Aguilar et al. suggests a solution for selecting the appropriate
WIS requirements in order to maximize the user satisfaction with respect to a prioritized
list of non-functional requirements. The approach is based on detecting the Pareto front
of candidate solutions and selecting the ones that ensure the fulfillment of the highly
ranked non-functional requirements. For demonstration purposes the authors use the
requirements of an online Conference Management System represented using the i
framework.
The third paper by Boukhebouze et al. proposes UI-BPEL, an extension of BPEL
that allows the modeling of user interaction (providing, selecting, and getting data by
the user) in Web service composition. The main of goal of UI-BPEL is to allow the
generation of user interfaces based on the described user interactions. This process is
composed of two steps: the generation of an abstract user interface independent of any
interaction modality and computing platform, and the generation of a concrete user
interface based on the abstract user interface that is adapted to the user specific context.
The fourth paper by Bianchini et al. describes an approach for rapid WIS develop-
ment by composing existing Web APIs. The composition is based on selection patterns
that exploit functional similarities and coupling criteria. For this purpose Web APIs
are annotated using existing lightweight semantic models extended with semantically
annotated events.
We do hope that the previous synopsis has triggered the readers interest to have
a closer look at the workshop proceedings. Last, we would also like to thank all the
authors, reviewers, and participants for their input and support for the workshop.
July 2011 Flavius Frasincar

Geert-Jan Houben
Philippe Thiran
O. De Troyer et al. (Eds.): ER 2011 Workshops, LNCS 6999, p. 1, 2011.

c Springer-Verlag Berlin Heidelberg 2011
Academic Social Networks
Jose Palazzo Moreira de Oliveira1, Giseli Rabello Lopes1 ,

and Mirella Moura Moro2,
1
Universidade Federal do Rio Grande do Sul - UFRGS
Porto Alegre, Brazil
{palazzo,grlopes}@inf.ufrgs.br
2
Universidade Federal de Minas Gerais - UFMG
Belo Horizonte, Brazil
mirella@dcc.ufmg.br
Abstract. The growth of Web 2.0 encouraged the consideration not

only of technological and content aspects but also the social interactions
and its relational aspects. Researches in the academic context also have
followed this trend. Methods and applications have been proposed and
adapted to consider social aspects by dierent modes. In this paper,
we present an overview of our publications focusing on Academic Social
Networks including proposals of analysis, dissemination and recommen-
dation for this context.
Keywords: Social Networks, Research, Collaboration.
1 Challenges and Research

In the Web 2.0 perspective not only the technological and content aspects but
also the social interactions and its relational aspects must be considered. In this
scenario, emerged applications with social aspects including Web-based commu-
nities and Social Networks. The Social Network Analysis (SNA) is based on the
assumption that the relationships importance between interaction elements is a
central point for analysis. The increasing interest in SNA research is encouraged
by the popularization of online social networks. Our example of SNA concepts
application is to model an Academic Social Network representing collaboration
among researchers by the use of co-author relationships. Following, we present
an overview of our publications focusing on Academic Social Networks including
models for analysis, dissemination and recommendation in this context.
In a rst paper [2] we introduced a set of challenges for developing a dissem-
ination service over a Web collaborative network. Specic metrics were dened
for working on a co-authorship network. As a case study, we build such a network
using those metrics and compare it to a manually built one. Specically, once we
build a collaborative network and verify its quality, the overall eectiveness of
the dissemination services will also be improved. A dissemination service is es-
tablished by data producers and consumers. Specically, consumers subscribe to

This research is partially supported by CNPq (Brazil) and is part of the InWeb
project.
O. De Troyer et al. (Eds.): ER 2011 Workshops, LNCS 6999, pp. 23, 2011.

Academic Social Networks 3
the service by dening a prole, which is usually composed of dierent queries.

As the producers introduce new data, usually through messages, the dissemina-
tion service evaluates each message against the proles. Once there is a match
between a prole and a message, the service sends that message to the proles
consumer. The results are evaluated by the access patterns and users accordance
with the quality of disseminated papers and, more important, by the increase in
the cooperation pattern among inter-institutional researchers.
In a second paper [1] we presented a Collaboration Recommendation on Aca-
demic Social Networks. In the academic context, scientic research works are
often performed through collaboration and cooperation between researchers and
research groups. Researchers work in various subjects and in several research ar-
eas. Identifying new partners to execute joint research and analyzing the level of
cooperation of the current partners can be very complex tasks. Recommendation
of new collaborations may be a valuable tool for reinforcing and discovering such
partners. In this work, we have presented the details of an innovative approach
to recommend scientic collaborations on the context of Social Networks. Specif-
ically, we introduce the architecture for such approach and the metrics involved
in recommending collaborations. A case study to validate the approach, using
researchers associated to the InWeb project, is also presented.
Finally we developed an analysis [3] including a new relationship weighted
approach. These weights aim to measure the importance of the relational ties
between actors and are important to be considered in an Academic Social Net-
work. In our case study, we demonstrated the possibility of uses of the Gini
coecient to analyze weighted Social Networks. Gini coecient is applied to
measure the homogeneity level of the collaboration, i.e., if only a few researchers
keep a good level of collaboration or if all researchers of the network, indeed, are
contributing for the group.
The developed researches demonstrate the importance of applying the con-
cepts of Social Networks to the analysis and quality improvement of academic
groups. Additionally, we proposed new measures to adequately quantify the
groups quality for generating ranks.
References
1. Lopes, G.R., Moro, M.M., Wives, L.K., de Oliveira, J.P.M.: Collaboration recom-
mendation on academic social networks. In: Trujillo, J., Dobbie, G., Kangassalo, H.,
Hartmann, S., Kirchberg, M., Rossi, M., Reinhartz-Berger, I., Zim anyi, E., Frasin-
car, F. (eds.) ER 2010. LNCS, vol. 6413, pp. 190199. Springer, Heidelberg (2010)
2. Lopes, G.R., Moro, M.M., Wives, L.K., de Oliveira, J.P.M.: Cooperative authorship
social network. In: Proceedings of the 4th Alberto Mendelzon International Work-
shop on Foundations of Data Management, Buenos Aires, Argentina, May 17-20.
CEUR Workshop Proceedings, vol. 619 (2010), CEUR-WS.org
3. Lopes, G.R., da Silva, R., de Oliveira, J.P.M.: Applying gini coecient to quan-
tify scientic collaboration in researchers network. In: Proceedings of the Interna-
tional Conference on Web Intelligence, Mining and Semantics, WIMS 2011, pp. 168.
ACM, New York (2011)
Conceptual Modelling for Web Information Systems:
What Semantics Can Be Shared?
Simon McGinnes
School of Computer Science and Statistics, Trinity College Dublin, Ireland

Simon.McGinnes@tcd.ie
Abstract. There is an increasing need to allow software applications to

exchange data, which usually requires the negotiation of meanings between
incompatible conceptual models. Theoretically, the concepts in one application
can be mapped to those in another, but this can be challenging in practice. The
problem is more fundamental than information plumbing; it requires
reconciliation between alternative and possibly conflicting ways of viewing the
world. Ontologies and the Semantic Web have been proposed as potential
solutions to the information exchange problem. This research investigates from
first principles what kinds of data exchange are possible, with the aim of
analyzing the issue in a useful way for the developers and users of web-based
information systems. The analysis suggests particular means of facilitating data
exchange involving the use of a simple set of shared basic-level categories.
Keywords: web information systems, ontologies, data models, conceptual

modelling, Semantic Web.
1 Introduction
Now is an important moment in human development. Thanks to the internet, for the
first time in history we have the capacity to share data on a massive scale, to move
information in digital form more or less anywhere we want at the press of a button.
But with this new ability comes the need to think in new ways about information
exchange. Our conventional view of sharing information developed in the low
bandwidth world of conversation, storytelling, books and newspapers. Trying to apply
the same ideas to the internet may risk creating the potential for confusion. Recently,
efforts have been made to automate the sharing of information using technologies
such as the Semantic Web, microformats and web services. As we begin to use these
technologies it is important to be clear about what we mean when we talk about
sharing information and what kinds of information can feasibly be shared.
This position paper aims to clarify these questions in a useful way for the
developers and users of web-based information systems. The discussion is necessarily
rather philosophical, but it is made as practical as possible because sharing data is
inherently a practical issue. In fact, the sole reason for sharing data is to facilitate
action. Viewing shared data as passive information is to miss the point; the
significance of sharing data is in the potential it creates for action.
Conceptual Modelling for Web Information Systems: What Semantics Can Be Shared? 5
1.1 The Need for Data Sharing
There is a greater need for data sharing within and particularly between organizations
than ever before. Historically, most organizations have used a portfolio of information
systems for different purposes, so corporate data has been locked into a number of
separate, mutually-incompatible data structures. Organizations need their systems to
work together, but sharing data between heterogeneous applications is rarely
straightforward. In an attempt to achieve integration, many organizations use
enterprise software applications, which address requirements across a range of
business processes. However, the adoption of enterprise software products tends to
lock organizations into a single supplier and prevents the selection of best-of-breed
solutions. Both approachesthe application portfolio approach, and the adoption of
enterprise softwarecan be expensive, and neither is ideal.
The situation is exacerbated when it comes to sharing data between organizations,
or between organizations and individuals. There is at present no universal inter-
organizational equivalent to the enterprise software solution. Therefore organizations
have little choice but to make their mutually-incompatible applications work together.
Historically, two factors have presented a barrier to interoperation. One is physical
incompatibility: if two systems are physically disconnected then they cannot
communicate. The Internet and related technologies have largely solved that problem.
However, as soon as applications can physically exchange data then the need for
semantic compatibility becomes paramount. This problem is less easily solved.
For example, consider two information systems which need to interoperate: (a) a
sales order processing system containing data about product types, suppliers,
customers, orders and employees, and (b) an accounting system with data on
transactions, debtors, creditors and accounts. Although the two sets of concepts
describe the same real-world phenomena (people, organizations and business
transactions), the systems conceptualize the data very differently. The systems are
conceptually incompatible, even though they store data about the same things. The
incompatibility presents a barrier to data exchange between the applications. Unless a
programmer crafts a suitable custom interface between the two applications, which
translates between the two ways of conceptualizing the underlying business entities, it
will be difficult to share data between them; the applications are built around concepts
that do not map to one another in any straightforward way.
Of course, the problem is not confined to this trivial example of sales and
accounting systems. It is rife, because most application software is structured around
idiosyncratic, domain-specific concepts. This seemingly-benign design practice,
which has long been the norm in information systems engineering, guarantees that
different programs will tend to be semantically incompatible. But, regardless of the
pros and cons of using ad hoc concepts in application design, we need to find ways of
integrating conceptually-incompatible systems. This is where technologies such as
ontologies and the Semantic Web offer some hope.
1.2 Structure and Terminology
The paper is structured as follows. Section 2 explores from first principles the ways in
which data exchange between semantically-incompatible systems can and cannot be
6 S. McGinnes
achieved. Section 3 discusses ontologies, the Semantic Web and related technologies
in the light of this analysis. Section 4 outlines some possible changes to design
practice suggested by this analysis, which might facilitate semantic interoperability.
Section 5 concludes with a summary of findings and limitations, and suggests
directions for further work.
Two commonly-used terms are avoided in this paper, because their ambiguity
could contribute to confusion. The first is information; this is a term from everyday
language which has been co-opted in IS/IT with a variety of meanings. It can refer to
essentially the same thing as data, or to any digital signal, or to text, or to facts that
have particular significance. The second term is semantics; this term has been adopted
by particular academic communities, with the result that its meaning is rather blurred.
Because the meanings of both terms are central to the arguments in this paper, we
avoid using them altogether and will use other, less ambiguous terms as appropriate.
2 Shared Meanings
When talking about data and information systems it is important to distinguish clearly
between real-world things (non-information resources in linked data terminology),
the signs that represent them, and mental states which corresponding to signs and
real-world things. For example, the term IBM is a sign, which corresponds to a
particular organization known as IBM (a real-world thing). An observer may have an
idea of the organization known as IBM, and this is a mental state. This three-way
relationship is sometimes encapsulated in the semiotic triangle [1].
Information systems store signs (bits, bytes, images, text, etc.) which represent
real-world things and mental states. When people communicate, they do so using
signs such as words and gestures. In all of these cases, signs are manipulated in the
hope of evoking mental states. This much is uncontroversial; in the following
discussion, we consider how mental states can be evoked through the use of signs by
people and machines. We are interested in knowing how software applications can
exchange data despite conceptual incompatibility. In order to understand that, we
need to understand how meaning is transmitted. Since humans often try to transmit
meaning to one another, it is helpful first to consider how this works.
2.1 How Do People Share Meanings?
Figure 1 illustrates two views of the communication of meaning between individuals.

In view (a) meanings are shared between individuals, and the purpose of language is
merely to evoke these shared meanings. This view is reminiscent of Jungs collective
unconscious or the concept of the platonic ideal. In view (b) meaning is transmitted
directly by language and so there is no particular need for meanings to be shared.
We argue that, at best, both of these views are unhelpful. There is no evidence for
view (a); despite centuries of philosophical theorizing, no scientific research has
uncovered any mechanism by which meanings might exist out there and be shared
between individuals. As for view (b), meaning is not something which can flow; it is
an experience. When we talk of conveying meaning, this is a figure of speech and not
Shared
meanings Meanings
embedded in
language
Language
(a) (b)
Fig. 1. Models for the communication of meaning between people
to be taken literally. Language cannot literally carry meaning since it consists only of
signs: sounds and gestures. The medium in this case is not the message. Meaning
arises only as an experience in each observer when he or she hears the sounds and
observes the gestures. The mental states that are evoked by these perceptions give rise
to mental states which we experience as meaning (Figure 2). According to this view,
no meanings can be shared; experience and memory are private mental states of each
individual. Language, which consists of signs, flows between individuals and evokes
the experience of meaning separately in each individual.
Subjective Subjective
meanings meanings
Language
Fig. 2. Improved model for the communication of meaning between people
However, this raises the question of how humans communicate at all, if there are
no shared meanings. The answer is that all meaning is subjective, yet we can assume
that much of our experience is similar. Humans communicate imperfectly and
misunderstanding is common. But we can proceed for much of the time as if we share
common meanings, because we are physiologically similar to one another and have
similar formative experiences. To give a trivial example, it is a reasonable working
assumption that we all mean the same thing by red. This assumption is in fact
incorrect, because evidence tells us that many people are colorblind and cannot
experience red in the same way as non-colorblind individuals. It is also likely that
individual variations in the perception of colors exist quite apart from colorblindness.
Nevertheless, it is more helpful to assume common meanings than to assume we have
no shared experience. The same argument can be extended to many concepts; while
there may be disagreement between individuals on the interpretation of particular
signals, it is more beneficial to attempt communication than not to.
Unlike computers, people can rely on having a common set of concepts, because
we all share the experience of living in the same world (roughly), are members of the
same species, and share elements of brain function. Hence our most fundamental
8 S. McGinnes
concepts (whether innate or learned) tend to be similar; most people would agree on
what a person is, for example. These ideas provide the context for thought and tell us
generally how to behave in relation to any given thing or situation that we encounter.
2.2 How Is Meaning Experienced?
A related question is how each individuals subjective meanings are stored and what
form they take when consciously experienced. This is an area of academic debate, but
one broad trend in our understanding of meaning can be identified. Early theories of
cognition postulated that meaning stems from conceptual structures in the mind. In
psychology, the spreading activation model is an example of such a theory; nodes
representing distinct concepts are connected explicitly, reflecting associative links
between ideas [2]. Similar thinking in computer science gave rise to conceptual
graphs and the ideas of schemata and frames [3]. There have even been suggestions
that the unconscious mind performs computations using symbolic logic [4].
However, despite a great deal of looking, neuroscience has not found evidence for
conceptual structures in the mind. It is becoming apparent that meaning arises in a
rather different way. Rather than activating concepts, perceptions appear instead to
elicit the recall of prior experience in a holistic manner. When we observe a situation
or hear language we recall a complex of memories with associated emotional states.
To recall is to re-experience, and it is this conscious re-experiencing of prior
experiences which we know as meaning.
Recall occurs on the basis of similarity using perceptual feature-matching
processes, which operate on multiple levels. This allows us to recall memories
because of literal as well as abstract (analogical) similaritiesone situation may be
quite unlike another in detail and yet we still are reminded, because of more abstract
similarities [5]. This suggests that, as a general principle, thinking about a concept
does not depend on definitions or on analytical thinking; it involves the retrieval of
prior experience on the basis of perceptual similarity. The definition of a concept
emerges and becomes crisp only when we try to define it consciously.
Although neuroscience has not found evidence for the existence of conceptual
structures, the results of studies (some of which use brain imaging) suggest that the
primate brain possesses hardwired semantic regions which process information
about particular subjects such as people, animals, tools, places and activities [6].
There is debate about the interpretation of these results, but the implication is that the
brain automatically segregates (on the basis of feature matching) cognitive processing
into certain broad categories. Categorization occurs unconsciously and the categories
appear to be innate, not learned. They correspond to concrete, everyday ideas rather
than abstractions. We can hypothesize that other conceptsmore specialized ideas
like customer and account, for exampleare learned, and become associated with the
corresponding basic-level innate categories.
2.3 How Do Computers Share Meaning?
To reiterate, we are interested in knowing how software applications can exchange

data despite conceptual incompatibility. Software applications cannot be said to
experience, at least in the sense meant above, and so they cannot be considered
capable of experiencing meaning in the way that a human does. The closest
equivalent to meaning for a software application is when it has been programmed to
act on specific types of data; we may then say (figuratively) that the application
understands that type of data. This figurative understanding consists of two
elements: (a) being programmed to accept data with a particular structure, and (b)
being programmed to deal with that type of data appropriately. However, we must be
clear that the ability to handle each specific type of data requires explicit
programming.
So, if two applications understand different types of data (and so are
conceptually incompatible) how can they exchange their own equivalent of meaning?
As before, we consider different models of communication. In Figure 3, view (a)
suggests that it is sufficient merely to exchange data. View (b) suggests that metadata
should also be included with the data; its function is to explain the structure and
purpose of the data, so that the receiving application can process it properly.
Data +
Data metadata
App A App B App A App B
(a) (b)
Fig. 3. Models for the communication of meaning between applications
View (a) is clearly insufficient since (to use our earlier example) the accounting
system will not recognize data about customers, orders and so on, and will therefore
be unable to do anything useful with them. Therefore some explanation of these
concepts is needed. However, view (b) is also incomplete, because any metadata must
be expressed in terms of concepts that the receiving application understands. The
accounting system will understand what to do with data about customers and orders
only if the metadata explains the concepts customer and order in terms of the
concepts account and transaction, or in terms of other constructs which the
accounting system understands. That would require the sending application to have
knowledge (e.g. of accounts and transactions) which it does not have.
For two conceptually-incompatible applications to exchange meanings, they must
both understand how to process particular types of data (Figure 4). This requires
that both be programmed with the ability to handle those types of data. For that to be
the case, both applications must share particular conceptual structures and must
contain program code which can deal with the corresponding data. But that would
mean that the applications would no longer be conceptually incompatible. Of course,
this is a contradiction. It means that the only way for conceptually-incompatible
applications to exchange data is by becoming conceptually compatible.
This analysis tells us that conceptually-incompatible applications can never
exchange data unless they become conceptually compatible first. It makes no
difference how complicated the data exchange method is or how much markup is
included. When data is exchanged it can be processed meaningfully only if the
sending and receiving applications are conceptually compatible and this situation can
be achieved only in advance of the exchange, through programming. In the next
section, we consider the implications of this finding for data exchange technologies.
10 S. McGinnes
Shared schema,
ontology or
conceptual model
Data +
App A metadata App B
Code to handle Code to handle

shared concepts shared concepts
Fig. 4. Improved model for communication of meaning between applications
3 Implications for Data Exchange Technologies

3.1 Ontologies and the Semantic Web
Ontologies have been proposed as a solution to data transfer problems. An ontology is

a formal description of concepts and their relationships. Unlike conceptual models,
ontologies are generally prepared independently of particular applications. Upper
ontologies such as SUMO contain hundreds of thousands of interconnected concepts;
they aim to encapsulate broad areas of knowledge in model form. They contain both
highly-generic and highly-specific abstractions; for example, SUMO contains the
hierarchy sentient agent cognitive agent human internet user (the symbol
can be read as may be a). Domain ontologies address more limited subject areas.
Some researchers are trying to reconcile upper ontologies with domain ontologies;
others are developing intermediate, industry-specific reference ontologies. Rather
than converging on a single, universal ontology, the field is producing many distinct
ontologies, each with particular strengths and scope [7].
The Semantic Web is partially based on ontologies. It envisions an alternative or
addition to the conventional web which will carry data using ontology-like structures.
According to this vision, programs will be able to interoperate and share data freely,
using ontologies to mediate data exchange. The goals for the Semantic Web are
ambitious: it will enable machines to comprehend semantic documents and data [8].
While a full theoretical treatment of the Semantic Web has yet to be elucidated, the
idea is that, if conceptual structures can be defined in sufficient detail and expressed
in machine-readable metadata, then software applications will be able to share and use
data intelligently and seamlessly.
The implicit assumption is that more detailed and rigorous definition of conceptual
structures can create machine comprehension; the computer will understand what
the data means sufficiently well to be able to process it appropriately. But how
machine comprehension can arise from more detailed definition of concepts has yet to
be explained. This appears to be a rather grand challenge similar to those previously
addressed in artificial intelligence research.
Setting aside the claims about machine comprehension, can ontologies provide a
basis for data sharing? In theory if two applications conform to the concepts defined
in a particular ontology then exchange of data becomes easy, because the applications
are conceptually compatible. However, it requires that applications be designed from
the ground up to conform to the particular ontology, which is an expensive
proposition. Also, no standard ontology has emerged. Multiple competing ontologies
and microformats exist, each with its own peculiar take on the relevant domains, and
it is not particularly easy to use them in combination. If applications are built to match
a variety of different ontologies, the risk is that this lack of standardization will
perpetuate the present problem of ad hoc conceptual structures and legacy
information islands.
An alternative approach is to use ontologies as a basis for mapping the conceptual
models of applications to one another. Defining conceptual structures in more detail
does not in itself convey significance or create machine comprehension. But richer
definition of concepts (such as customer and account, in our example) might help link
them to terms in a common ontology. This would allow programs to read the data, but
it would not tell programs how to process the data appropriatelyunless specific
programming were to be done for each concept or term in the ontology. That is also
an expensive proposition and probably less likely because ontologies contain many
thousands of terms, most of which are irrelevant to any particular application.
To summarize, the development of ontologies may assist in reconciling mutually-
incompatible conceptual structures and so allow applications to exchange data. But
ontologies are in effect better information plumbing; they cannot tell applications
how to process any given type of data. Each distinct ontology defines a set of
concepts which must be programmed into a software application before the
application can process the corresponding data meaningfully. The metadata (in RDF,
for example) is useful because it signifies the type of data, but this is useful only
inasmuch as the receiving application already understands how to deal with data of
that type.
3.2 Potential for Basic-Level Categories to Facilitate Interoperability
Because of the fundamental limitation that applications must already share concepts
in order to exchange corresponding data, the use of ontologies does not substantially
improve our ability to link applications on a large scale or more rapidly. We are still
held back by the need to program into each application the methods that it must use to
handle data corresponding to each concept. There is no such thing as common sense
or general knowledge for a computer application which would tell it how to handle
specific types of data.
However, the discussion in Section 2.1 alluded to some results from neuroscience
which may be helpful in thinking about this problem. The results suggest that a small
number of categories are hardwired in the brain and perhaps innate. These correspond
to concepts that people seem to understand intuitively: other people, food, tools,
actions and so on. They are neither particularly generic nor particularly abstract but
instead couched at a basic or everyday level [9]. One hypothesis is that these common
basic-level concepts, together with other common experiences such as emotions and
sensations, allow us to think and communicate about more complex ideas.
Applying the same idea to software applications, we could envisage a simple set of
shared innate categories for software applications to adhere to, providing a basis for
12 S. McGinnes
at least some limited data exchange and interoperability, without the need for
programming. It is generally a straightforward matter to map an existing conceptual
model to a simple set of basic-level categories [10]. For example, data about people
could be tagged as such, as could data about places, documents, organizations, and so
on. Once an item of data had been tagged according to this set of simple basic-level
categories, certain default programming would be applicable. For example, places can
be represented as maps; documents can be downloaded and opened. Other possible
basic-level categories include systems, physical objects, conceptual objects and
categories [11].
Recall that the purchase order processing and accounting systems in our example
contained the concepts supplier and creditor. If both of these concepts were identified
with the innate category organization, then the two applications could exchange data
meaningfully, identifying data in the categories supplier and creditor as data about
organizations. The applications could then treat the data in a way deemed appropriate
for processing data about organizations. Similarly, the concepts purchase and
transaction could be identified with the innate category activity, allowing exchange
and treatment appropriate for activities, and so on. By providing a generic level of
programming to suit each shared basic-level category, at least some basic level of
default operation would be possible on exchanged data without the two applications
possessing complex shared conceptual schemas.
4 Conclusion
Today, each software application is structured around its own set of unique, ad hoc,
concepts. This design practice guarantees conceptual incompatibility. There is a need
to find alternative design approaches that will allow applications to work with
different types of data more flexibly and share data more readily. Yet it is important
to respect the uniqueness of each applications conceptual model; a one-size-fits-all
conceptual model cannot easily be imposed.
It will become increasingly important for applications to be able to share data
automatically, despite the problem of conceptual incompatibility. A way is needed of
imbuing applications with the equivalent of common sense or general knowledge,
which will allow them to offer a sensible response to new types of data. In ontology
research, it is hoped that this will be achieved through more rigorous and more
detailed definition of concepts, to ultimately enable a form of machine
comprehension. But it is unclear how machine comprehension will be produced by
more detailed definition of concepts. As for the less ambitious goal of using
ontologies to map between conceptual models, even if ontology use in information
systems were to become widespread, a critical mass of organizations would need to
adopt a particular ontology before the benefits of standardization could be realized.
Overall, there is a tendency to think in rather non-specific ways about how
ontologies and the Semantic Web might permit free exchange of data. Any exchange
of data is constrained by the problem of conceptual incompatibility, and this cannot
be overcome solely by the inclusion of more complex markup. It requires advance
programming so that applications are able to handle the types of data to be exchanged.
This cardinal rule constitutes a fundamental limit on conceptual interoperability and
can be stated thus: applications can meaningfully interoperate with respect to data of
a specific type only if they have been programmed in advance to handle data of that
type. When data containing particular concepts is exchanged, applications have to be
specifically programmed to handle the relevant concepts, regardless of what
mechanism is used to transfer the data or construct the programs, and irrespective of
what markup or metadata is included.
In conclusion, this work remains theoretical. However, the relatively limited
progress to date on the Semantic Web (in comparison with the worldwide web, for
example) may represent evidence of the inherent limitation discussed in this paper.
Research is needed into ways of genuinely allowing heterogeneous applications to
exchange data in the face of conceptual incompatibility. Whether or not ontologies are
involved, the idea of using a simple set of innate categories should be tested
because it may offer a more practicable approach than attempting to implement large
and unwieldy ontologies in software applications.
References
1. Liebenau, J., Backhouse, J.: Understanding Information: An Introduction. Macmillan,
Basingstoke (1990)
2. Crestani, F.: Application of Spreading Activation Techniques in Information Retrieval.
Artificial Intelligence Review 11, 453482 (1997)
3. Sowa, J.F.: Conceptual Structures. Addison-Wesley, Reading (1984)
4. Modell, A.H.: Imagination and the Meaningful Brain. The MIT Press, Cambridge (2003)
5. Eysenck, M.W., Keane, M.: Cognitive Psychology: A Students Handbook. Psychology
Press, UK (2005)
6. Mason, M.F., Banfield, J.F., Macrae, C.N.: Thinking About Actions: The Neural
Substrates of Person Knowledge. Cerebral Cortex 14, 209214 (2004)
7. Kalfoglou, Y., Hu, B.: Issues with Evaluating and Using Publicly Available Ontologies
(2006)
8. Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American 284, 28
37 (2001)
9. Pansky, A., Koriat, A.: The Basic-Level Convergence Effect in Memory Distortions.
Psychological Science 15, 5259 (2004)
10. McGinnes, S.: Conceptual Modelling: A Psychological Perspective. Ph.D Thesis,
Department of Information Systems, London School of Economics, University of London
(2000)
11. McGinnes, S., Amos, J.: Accelerated Business Concept Modeling: Combining User
Interface Design with Object Modeling. In: Harmelen, M.V., Wilson, S. (eds.) Object
Modeling and User Interface Design: Designing Interactive Systems, pp. 336. Addison-
Wesley, Boston (2001)
A Goal-Oriented Approach for Optimizing
Non-functional Requirements in Web
Applications
Jose Alfonso Aguilar, Irene Garrig

os, and Jose-Norberto Maz
on
Lucentia-DLSI
University of Alicante, E-03080, San Vicente del Raspeig, Alicante, Spain
{ja.aguilar,igarrigos,jnmazon}@dlsi.ua.es
Abstract. Web design methodologies should be able to provide a re-

quirements analysis stage to consider the large and heterogeneous au-
dience of Web applications. In this stage, non-functional requirements
(NFRs) should be addressed in order to improve the quality of the Web
application perceived by users. To this aim, dierent congurations of re-
quirements could be implemented depending on the NFRs preferred by
the Web user. Furthermore, prioritizing and making tradeos between
NFRs is crucial for satisfying the audience of Web applications. There-
fore, this work presents an algorithm based on the Pareto optimal ap-
proach to evaluate and select the optimal conguration of requirements
for a Web application. To do this, the NFRs are maximized according to
a priority list provided by the audience. Our approach is illustrated with
a running example.
Keywords: non-functional requirements, Web engineering, goal-oriented

requirements engineering.
1 Introduction
Unlike traditional stand-alone software, the audience of Web applications is both
open and large. Therefore, users may have dierent goals and preferences and
stakeholders (in this context, stakeholders are individuals or organizations who
aect or are aected directly or indirectly by the development project in a posi-
tive or negative form [9]) should be able to cope with these heterogeneous needs
by means of an explicit requirements analysis stage in which functional and
non-functional requirements are considered [2].
Functional requirements (FRs) describe the system services, behavior or func-
tions, whereas non-functional requirements (NFRs), also known as quality re-
quirements, specify a constraint in the application to build or in the development
process [7]. An eective denition of requirements improves the quality of the
nal product. Unfortunately, in most of the Web engineering approaches, a com-
plete analysis of requirements is performed considering only FRs, thus leaving
aside the NFRs until the implementation stage. We totally agree with [3] the
argument that NFRs are a very important issue and must be considered from

A Goal-Oriented Approach for Optimizing Non-functional Requirements 15
the very beginning of the development process, to be analyzed in depth, in order

to improve the quality of the Web application perceived by users.
Interestingly, the recent inclusion of goal-oriented techniques in Web require-
ments engineering [4] oers a better analysis in the requirements stage since
requirements are explicity specied in goal-oriented models in order to support
reasoning about organizational objectives, alternatives and implications, thus
having a deep understanding about the domain. This has allowed the stakehold-
ers to choose among the design decisions that can be taken to satisfy the goals
and evaluate the implementation of certain requirements in particular (including
NFRs). However, this is not enough to ensure that the Web application satises
the real user needs because they do not oer mechanisms to maximize NFRs,
i.e., to nd a tradeo between the FRs and NFRs.
Therefore, not paying attention to eliciting, documenting and tracking NFRs
makes harder for the stakeholders to take design choices. Consequently, the qual-
ity of the Web application perceived by users will be aected negatively. Thus,
NFRs need to be addressed to enable the stakeholder to choose among multiple
congurations maximizing the NFRs, helping them to take design choices which
positively aects the quality of the Web application, i.e., maximizing the NFRs
navigability and accessibility, improves the browsing user experience.
Bearing these considerations in mind, this paper presents an algorithm that
allows the stakeholder to evaluate the implementation of certain requirements
considering the NFRs maximization. The algorithm is based on the Pareto op-
timal approach [10] , which is useful when there are multiple competing and
conicting objectives that need to be balanced. The algorithm thus constructs
a group of congurations (called Pareto front) optimizing the NFRs. A cong-
uration only can be considered on the Pareto front, if and only if, it maximizes
a NFR and the other ones remain the same, or they are maximized too. From
these balanced congurations, the stakeholder can select the nal conguration
taking into account the dierent NFRs from the beginning of the development
process. The proposal presented in this paper is dened upon our Web engineer-
ing method A-OOH (Adaptive Object Oriented Hypermedia method) [1] although
it can be applied to any other Web engineering approach.
The remainder of this paper is structured as follows: Section 2, presents related
work relevant to the context of this work. Section 3, describes the proposal
for goal-oriented requirements analysis where is found the contribution of this
work and introduces a running example for demonstration purposes. The Pareto
algorithm for softgoals maximization and its application (described step by step)
is presented in Section 4. Finally, the conclusion and future work is presented in
Section 5.
2 Related Work
In our previous work [2], a systematic literature review has been conducted for
studying requirement engineering techniques in the development of Web applica-
tions. Our ndings showed that most of the Web engineering approaches focus on
16 J.A. Aguilar, I. Garrig
os, and J.-N. Maz
on
the analysis and design phases and do not give a comprehensive support to the
requirements phase. Furthermore, the NFRs are considered in a isolated form,
leaving them out of the analysis stage. In addition, we can also conclude that
the most used requirement analysis technique is UML use cases and proles. On
the other side, with regard to approaches that consider NFRs from early stages
of the development process, in [8] the authors propose a metamodel for repre-
senting usability requirements for Web applications. Moreover, in [3] the authors
present the state-of-the-art for NFRs in a MDD (Model-Driven Development),
as well as an approach for a MDD process (outside the eld of Web engineering).
Unfortunately, these works overlook how to maximize the NFRs.
To sum up, there have been many attempts to provide techniques and meth-
ods to deal with some aspects of the requirements engineering process for Web
applications. Nevertheless, there is still a need for solutions that considers NFRs
from beginning of the Web application development process, in order to assure
that they will be satised at the same time that the functional requirements are
met, improving the quality of the Web application perceived by users.
3 Specifying Requirements in Web Engineering

This section briey describes our proposal to specify requirements in the con-
text of a Web modeling method by using i* models [6], [1]. As a goal-oriented
analysis technique, the i* framework focuses on the description and evalua-
tion of alternatives and their relationships to the organizational objectives. This
proposal supports an automatic derivation of Web conceptual models from a
requirements model by means of a set of transformation rules.
Following, we shortly describe an excerpt of the i* framework which is rel-
evant for the present work. For a further explanation, we refer the reader to
[11]. The i* framework consists of two models: the strategic dependency (SD)
model to describe the dependency relationships (represented as ) among var-
ious actors in an organizational context, and the strategic rationale (SR) model,
used to describe actor interests and concerns and how they might be addressed.
The SR model (represented as ) provides a detailed way of modeling internal
intentional elements and relationships of each actor ( ). Intentional elements
are goals ( ), tasks ( ), resources ( ) and softgoals ( ). Intentional rela-
tionships are means-end links ( ) representing alternative ways for fullling
goals; task-decomposition links ( ) representing the necessary elements for a
help
task to be performed; or contribution links ( ) in order to model how an

hurt
intentional element contributes to the satisfaction or fulllment of a softgoal.

Possible labels for a contribution link are Make, Some+, Help, Hurt,
Some-, Break, Unknown, indicating the (positive, negative or unknown)
strength of the contribution.
To adapt i* framework to the Web engineering domain we use the taxonomy of
Web requirements presented in [5]. Next, we have used the extension mechanisms
of UML to dene a prole for using i* to specic Web domain terminology.
Therefore, new stereotypes have been added according to the dierent kind of
Web requirements (NFRs are modeled directly using the i* softgoal element).
A sample application of the i* modeling framework for Web domain is shown

in Figure 1, which represents the SR model of our running example for the Con-
ference Management System (CMS), the complete specication of the case study
can be found at: http://users.dsic.upv.es/~west/iwwost01. The purpose of
the system is to support the process of submission, evaluation and selection of
papers for a conference. It is important to highlight that each element from
Figure 1 corresponds to a requirement type from the taxonomy previously men-
tioned, i.e., the content requirement (Content) from the taxonomy is displayed
with the notation Resource from i* and the navigational (Navigational) and
service (Service) requirements with the symbol Task from i*, both with their
respective associations (decomposition-links). The extract of the CMS example
is focused on the selection of the review process. Four actors participate in the
CMS, but due to space limitations, for this example only the author, reviewer
and system actors were considered. In this case, three actors are detected that
depend on each other, namely Reviewer, Author and Conference Man-
agement System. The reviewer needs to use the CMS to Review paper. The
author depends on the CMS in order to Paper be reviewed. These dependencies
and the CMS actor are modeled by a SD and SR models in Figure 1.
The goal of the CMS actor is Process of review of papers be selected. To
fullll this goal, the SR model indicates that one of the two navigational re-
quirements: Blind review process or Normal review process should be per-
formed. In this running example, the path to achieve the goal of the CMS actor
is by means of the navigational requirement Blind review process. We can
observe in the SR model that some navigational and service requirements are
decomposed in other requirements, some of them aects positively or negatively
some NFRs (sofgoals hereinafter), i.e., the service requirement Download paper
without authors name needs the content requirement Papers, also, aects
positively the softgoal Privacy be maximized and in some negatively form the
softgoal Obtain more complete info. This fact is very important to see how to
satisfy the goal Process of review of papers be selected considering the Web
application softgoals.
4 Optimizing NFRs in Web Applications

In this section, we present a proposal (see Figure 2) which provides support
for the stakeholder in order to evaluate and decide which functional require-
ments have to be implemented to improve the Web application functionality
while NFRs are maximizing. To do this, we extend the goal-oriented require-
ment approach for Web engineering, described in Section 3, with the Pareto
front algorithm, in order to achieve the optimal conguration based on the soft-
goals maximization. Also, a set of steps in order to fully satisfy the stakeholder
goals have been dened. Therefore, the eect of the implementation of a set of
FR can be assessed and the best among several implementation options can be
selected by prioritizing the softgoals while still satisfying the goals.
The Pareto front algorithm is useful when there are multiple competing and
conicting objectives [10] that need to be balanced. The Pareto front is a notion
os, and J.-N. Maz
on
Fig. 1. Part of the Conference Management System requirements expressed in a SR

and SD Models
from economics widely applied to engineering, which is described as follows:

given a set of alternative allocations and a set of individuals, allocation A is an
improvement over allocation B only if A can make at least one individual better
than B, without making any other worse. In this sense, a set of individuals refers
to the set of requirements, also, a set of alternative allocations corresponds to
the state of the requirement (implemented or not implemented), and make an
individual better by means of maximizing softgoals, and the opposite, means
weakening softgoals. Therefore, a Pareto front, is one that no other conguration
better satises a single softgoal, while satisfying the others equally. The set
of Pareto congurations can be used to make a well-informed decision about
which requirements conguration is the optimal to balance the tradeo between
softgoals.
Finding the set of Pareto optimal conguration can be dened as the prob-
lem of nding a (decision) vector of decision variables X (i.e., a valid imple-
mented/not implemented requirements conguration), which maximizes a vector
of M objective functions fi (X) (i.e., the satisfaction of softgoal i in conguration
X) where i = 1..M (with M the amount of softgoals). To do so, the concept
of domination between vectors is dened as follows: a decision vector X is said
to dominate a decision vector Y (also written X Y ) if and only if their cor-
responding objective vectors of objective functions fi (X) and fj (X) satises:
i {1...M }fi (X) fi (Y ) and i {1...M }fi (X) > fi (Y ), it is then said that
all decision vectors that are not dominated by any other decision vectors form
the Pareto optimal set, while the corresponding objective vectors are said to
form the Pareto front. Our approach as a running example is described next.
4.1 The Pareto Algorithm as a Running Example

Following the Pareto eciency, we have dened the following steps to determine
the Pareto optimal conguration for requirements implementation while the soft-
goals are balanced and maximized (see Figure 2). At the same time, these steps
are applied in our running example presented in Section 3.
Fig. 2. Overview of the Pareto approach
Step 1. Create the Initial Requirements Model. The stakeholder creates

an initial requirements model (IRM) using the i* framework with which species
the goals, softgoals and functional requirements (Navigational, Service, Person-
alization, Layout and Content ) that the Web application must satisfy. This IRM
species the requirements that must be implemented as a rst prototype of the
nal Web application. At the same time, the stakeholder denes a list of softgoals
sorted by priority, with which species the softgoals that the Web application
must accomplish. For this running example, the requirements model is the one
described in Section 3.
Step 2. Create a Requirements List. The second step consists of developing
a list of the requirements (implemented or not) that contribute to any softgoal
in the i* requirements model (see Table 1). This table shows a requirements
list and their type of contributions to the softgoals, where S1 corresponds to
softgoal Be fair in review from requirements model, S2 to Review process
easier, S3 represents Accurate review process, S4 conforms to Privacy
be maximized, S5 Avoid possible conicts of interest and S6 it is the
Obtain more complete info.
Step 3. Store Each Possible Requirements Configuration. In this step,
each possible implementation (conguration) of N requirements is stored in a
decision vector Xv : v0 v < 2N , i {1...N }Xvi = Ti , where Xvi is the ith
element of Xv , Ti = I if the requirement is implemented and Ti = N if the
requirement is not implemented.
os, and J.-N. Maz
on
Table 1. The requirements contributions to softgoals

Requirements S1 S2 S3 S4 S5 S6
R1.- Blind review process Help Break Hurt - Help -
R2.- Download papers without authors name - - - Help - Some -
R3.- Normal review process Some - Make Help - - -
R4.- Download paper with authors name - - - Some - Hurt Help
R5.- View review process status - - - - - Help
Step 4. Assign a Weight to Each Contribution from Requirements to

Softgoals. The contribution of each requirement (implemented or not) must be
quantied. To this aim, the stakeholder creates a matrix by using the following
weights to each kind of contribution: w= 0 if the requirement does not contribute
to any softgoal, w= +1 if there is a Help contribution link, w= -1 if there is a
Hurt contribution, w= +2 if there is a Some + link, w= -2 if the contribution
is Some -, w= +4 if there is a Make and w= -4 if there is a Break contribution
link.
Therefore, the matrix is dened, so that each entry Wikj corresponds to the
contribution of the ith requirement to the jth softgoal on the k status (imple-
mented or not): i {1...N }, j {1...M }, k {I, N } Wikj = w, where N is
the number of requirements and M is the number of softgoals, and w is dened
as previously described.
For computing the objective functions in this running example, the following
matrix (1) is dened containing the quantication of each requirement to soft-
goals, as explained in the previous section. As an example, row 3, (requirement
Normal review process), column 2 (softgoal Review process easier), shows
+4 in the matrix, indicating a Make contribution if the requirement is im-
plemented, and on the other side, if the requirement Blind review process (row
1) is implemented, column 2 will be indicating -4 in the matrix, this means a
Break contribution.

+1 4 1 0 +1 0
0 0 0 +1 0 2

k 2 +4 +1 0 0 0
Mi = (1)
j 0 0 0 2 1 +1

0 0 0 0 0 +1
Step 5. The Objective Function. For each softgoal j the corresponding ob-
jective function Fj with respect to a decision vector Xv is calculated by sum-
ming the contributions of all requirements to each softgoal j taking into account
the requirements conguration dened in xv : j {1...M }, v0 v < 2N
M
Fj (Xv ) = j=1 Wikj , where N is the number of requirements, M is the number
of softgoals.
Finally, the sum of all objective functions with respect to a decision vector Xv
is computed to obtain the overall tness of the decision vector Xv : j {1...N },
v0 v < 2N j=1 M
Fj (Xv ), where N is the number of requirements and M is
the number of softgoals.
Table 2 shows all possible decision vectors (column 2 to 6, all rows), in other
words, all possible requirements congurations, where I represents the sta-
tus Implemented and N represents Not implemented. The results of the
corresponding objective functions are shown in columns 7 to 12, and the overall
Table 2. The posible requirements to implement or not for the softgoal tradeo
Configuration R1 R2 R3 R4 R5 F(S1) F(S2) F(S3) F(S4) F(S5) F(S6) Pareto front
X1 I I I I I -1 0 0 -1 0 0 No
X2 I I I I N -1 0 0 -1 0 -1 No
X3 I I I N I -1 0 0 1 1 -1 Yes
X4 I I I N N -1 0 0 1 1 -2 No
X5 I I N I I 1 -4 -1 -1 0 0 Yes
X6 I I N I N 1 -4 -1 -1 0 -1 No
X7 I I N N I 1 -4 -1 1 1 -1 Yes
X8 I I N N N 1 -4 -1 1 1 -2 No
X9 I N I I I -1 0 0 -2 0 2 Yes
X10 I N I I N -1 0 0 -2 0 1 No
X11 I N I N I -1 0 0 0 1 1 Yes
X12 I N I N N -1 0 0 0 1 0 No
X13 I N N I I 1 -4 -1 -2 0 2 Yes
X14 I N N I N 1 -4 -1 -2 0 1 No
X15 I N N N I 1 -4 -1 0 1 1 Yes
X16 I N N N N 1 -4 -1 0 1 0 No
X17 N I I I I -2 4 1 -1 -1 0 Yes
X18 N I I I N -2 4 1 -1 -1 -1 No
X19 N I I N I -2 4 1 1 0 -1 Yes
X20 N I I N N -2 4 1 1 0 -2 No
X21 N I N I I 0 0 0 -1 -1 0 No
X22 N I N I N 0 0 0 -1 -1 -1 No
X23 N I N N I 0 0 0 1 0 -1 Yes
X24 N I N N N 0 0 0 1 0 -2 No
X25 N N I I I -2 4 1 -2 -1 2 Yes
X26 N N I I N -2 4 1 -2 -1 1 No
X27 N N I N I -2 4 1 0 0 1 Yes
X28 N N I N N -2 4 1 0 0 0 No
X29 N N N I I 0 0 0 -2 -1 2 Yes
X30 N N N I N 0 0 0 -2 -1 1 No
X31 N N N N I 0 0 0 0 0 1 Yes
X32 N N N N N 0 0 0 0 0 0 No
tness for each decision vector is shown in column 13. Finally, in the last column,
we indicate if the corresponding decision vector is in the Pareto front. Grey rows
are the Pareto front.
Step 6. Maximize the Softgoals and Still Satisfaying the Goals. In this
step the stakeholder creates a list of softgoals sorted by priority (the softgoals
priority was stablished in the list from Step 1 by the stakeholder) and a list
of goals that the Web application has to achieve. For this case, the softgoals
priority list is shown in Table 3.
Table 3. Softgoals priority list for achieve the goal Process of review of papers be
selected
Order Softgoal
1 S4.- Privacy be maximized
2 S2.- Review process easier
3 S3.- Accurate review process
4 S1.- Be fair in review
5 S5.- Avoid possible conflicts os interest
6 S6.- Obtain more complete info
Step 7. Select the Pareto Optimal Configuration. Finally, according to

Table 3, the two most important softgoals to maximize are S4 and S2.
Therefore, it is necessary to select the nal solution according to the priorities
established over the softgoals.
First of all, it is necessary to select the congurations that besides being
Pareto front satisfy the goal Process of review of papers be selected, for this
running example, the congurations X3, X7, X17 and X25 are the only
ones that satisfy the goal from all the 14 congurations that are Pareto front
(see Table 2). Importantly, this step could be done in Step 5, i.e., calculating the
os, and J.-N. Maz
on
objective function for those congurations that satisfy the goals, but not doing
it in this form allows us to select between dierent congurations considering
only the softgoals maximization, leaving aside the goals, this gives a wider scope
to the stakeholder for the nal implementation.
The next step consists in selecting from the congurations that are Pareto
front and satisfy the goal, the ones that maximize the softgoals according with
the list from Table 3. To do this, it is necessary to check all the congurations
with the requirements model to select the congurations that allow to achieve
the goal (in this case there are two paths, i.e., two means-ends links), these are
X3, X7, X17 and X25 . Then, it is necessary to select the best option
according to the softgoals to maximize. For the softgoal S4, X3 and X7
are the congurations which its overall is maximized and, for the softgoal S2
are X17 and X25.
For this running example, the conguration X3 is the best option, because
according with the priority list, S4 and S2 are the softgoals to prioritize.
The congurations X17 and X25 maximize S2, however the contributions
of both to softgoal S4 (which is the number one from the priority list) are
1 and 2 (see Table 2). Furthermore, besides that the conguration X3
has an overall tness of +1 for S4 as same as the conguration X7, the
conguration X3 has an overall tness of 0 for S2 and, X7 has an overall
tness of 4 for S2, resulting more aected that the conguration X3 (see
Table 2), with which indicating that optimizing security comes at a high cost
with respect to other softgoals (usability). The rest of solutions of the Pareto
front are intermediate congurations that lead us to dierent tradeos.
Finally, the nal requirements model (FRM) is the conguration X3 (see Ta-
ble 2). Therefore, the requirements R1.- Blind review process, R2.- Download
papers without authors name, R3.- Normal review process and R5.- View
review process status must be implemented in order to maximize the softgoals
S4.- Privacy be maximized and S2.- Review process easier. In X3 only
R4 is not implemented. These requirements enable alternative paths (means-
ends links) to satisfy the goal.
5 Conclusion and Future Work

In this work, we have presented an extension to our goal-oriented requirements
analysis approach for the development of Web applications. Our approach al-
lows the stakeholder to evaluate and decide which requirements conguration
to implement. To do so, we devised an algorithm based on the Pareto optimal
approach that is particularly suited to balance and maximize the conicting
softgoals. Furthermore, it facilitates the evaluation of the obtained (Pareto) op-
timal solutions and the selection of the nal solution taking into account the
priorities of softgoals. To do this, it includes weighted contributions according to
the importance of softgoals, in order to further help the stakeholder to balance
and optimize the dierent softgoals. Future work consists in the integration of
our goal-oriented approach for requirements analysis and the Pareto algorithm
in a MDD solution for the development of Web applications, within the A-OOH
approach.
Acknowledgments. This work has been partially supported by the MANTRA

project (GV/2011/035) from the University of Alicante, and by the MESOLAP
(TIN2010-14860) from the Spanish Ministry of Education and Science. Jose Al-
fonso Aguilar is subventioned by CONACYT (Consejo Nacional de Ciencia y
Tecnologa) Mexico and University of Sinaloa, Mexico.
References
1. Aguilar, J.A., Garrigos, I., Mazon, J.N., Trujillo, J.: An MDA Approach for Goal-
Oriented Requirement Analysis in Web Engineering. J. Univ. Comp. Sc. 16(17),
24752494 (2010)
2. Aguilar, J.A., Garrigos, I., Mazon, J.N., Trujillo, J.: Web Engineering Approaches
for Requirement Analysis- A Systematic Literature Review. In: 6th Web Informa-
tion Systems and Technologies (WEBIST), vol. 2, pp. 187190. SciTePress Digital
Library, Valencia (2010)
3. Ameller, D., Gutierrez, F., Cabot, J.: Dealing with Non-Functional Requirements
in Model-Driven Development. In: 18th IEEE International Requirements Engi-
neering Conference (RE), pp. 189198. IEEE, Los Alamitos (2010)
4. Bolchini, D., Paolini, P.: Goal-Driven Requirements Analysis for Hypermedia-
Intensive Web Applications. J. Req. Eng. 9(2), 85103 (2004)
5. Escalona, M.J., Koch, N.: Requirements Engineering for Web Applications - A
Comparative Study. J. Web Eng. 2(3), 193212 (2004)
6. Garrigos, I., Maz
on, J.N., Trujillo, J.: A requirement analysis approach for using i*
in web engineering. In: Gaedke, M., Grossniklaus, M., Daz, O. (eds.) ICWE 2009.
LNCS, vol. 5648, pp. 151165. Springer, Heidelberg (2009)
7. Gupta, C., Singh, Y., Chauhan, D.S.: Dependency Based Process Model for Im-
pact Analysis: A Requirement Engineering Perspective. J. Comp. App. 6(6), 2830
(2010)
8. Molina, F., Toval, A.: Integrating Usability Requirements that can be Evaluated in
Design Time into Model-Driven Engineering of Web Information Systems. J. Adv.
Eng. Softw. 40, 13061317 (2009)
9. Sommerville, I.: Software Engineering, 6th edn. Addison-Wesley, Reading (2001)
10. Szidarovszky, F., Gershon, M., Duckstein, L.: Techniques for Multiobjective Deci-
sion Making in Systems Management. Elsevier, Amsterdam (1986)
11. Yu, E.S.K.: Towards Modeling and Reasoning Support for Early-Phase Require-
ments Engineering. In: 3rd IEEE International Symposium on Requirements En-
gineering (RE), p. 226. IEEE, Washington, DC, USA (1997)
Yet Another BPEL Extension for User
Interactions
Mohamed Boukhebouze, Waldemar Pires Ferreira Neto, and Lim Erbin
PReCISE Research Center, University of Namur, 5000, Belgium

{mohamed.boukhebouze,waldemar.neto,lim.erbin}@fundp.ac.be
Abstract. In this paper, we propose a BPEL extension that deals with

the user interactions expression in a Web service composition. This ex-
tension denes new data interaction activities to allow user providing,
selecting or getting data. Moreover, the extension proposes a new type
of interaction events that allow processing of the user interaction. The
user interaction specication helps to generate a user interface for the
Web service composition which is made by transforming the described
user interactions to user interface components.
Keywords: BPEL extension, User Interaction, User Interface.
1 Introduction
A Web service is an autonomous software application that can be described,
published, discovered, and invoked across the Web [6] by using a set of XML
based standards such as UDDI, WSDL, and SOAP. Web services can be com-
bined together in order to fulll the user request that a single Web service cannot
satisfy [10]. This mechanism is known as Web service composition. A Web ser-
vice composition consists of several Web services orchestration or Web services
choreography processes that deal with a functional need which is unsatised by
a single Web service [10].
Several initiatives have been conducted to provide languages such as WS-
BPEL (Web Services Business Process Execution Language) [5] that allow the
description of Web service composition execution. WS-BPEL (BPEL for short)
is an XML based standard that provides a syntax to dene the Web service com-
position behavior (control ow) and mechanisms that enable data manipulation
(data ow).
This language expresses the Web service composition process in a fully auto-
mated way. Users are not able to interact with the Web services until the end of
the process execution. For example, users are not able to provide the input to a
Web service at runtime, they are not able to cancel the process execution, or they
are not able to have some intermediary output from a Web service. However,
many Web service composition scenarios require user interactions [3]. These user
interactions can be classied into four types [8]:

Research supported by la Wallonie.

Yet Another BPEL Extension for User Interactions 25
Data input interaction represents the fact that the user provides data to a
Web service at runtime. For example, a user provides a licence Number to a
car renting Web service;
Data output interaction represents the fact that a Web service composition
makes data available to the user. For example, the trip scheduling Web
service composition presents the car renting price to the user;
Data selection represents the fact that the user can select a data from a set
of data. For example, a user can make a choice between ight or driving as
a means of transportation;
Interaction event represents an indicator that a user interaction has been
carried out. For example, a cancellation is done by a user during the Web
service composition execution (by pressing a button for example).
The dierence between the data interaction types (input, output and selection)
and the interaction event is that the data interaction types allow changing the
data ow of the composition, while an interaction event changes only the control
ow of the composition regardless of the data (e.g. the cancelling process is done
regardless of the data).
Unfortunately, the BPEL language does not support such types of user inter-
action. For this reason, BPEL meta-model needs to be extended to express user
interactions in a Web service composition. In addition, a user interface for the
composition needs to be developed in order to help the user to interact with the
Web services at runtime.
In this work, we propose a BPEL extension for the user interactions expres-
sion. This extension is called UI-BPEL (User Interaction Business Process Ex-
ecution Language). UI-BPEL supports the expression of the four types of the
user interactions explained above by introducing new BPEL elements: (1) a new
BPEL activities (DataInputUI, DataOutputUI, DataSelectionUI ) to express the
user data interactions; (2) a new type of BPEL event (InteractionEventUI ) to
express the interaction event; (3) an extension of the BPELs Pick and Scope
activities that support the new InteractionEventUI. The main objective of this
extension is to allow the generation of a user interface for the Web service compo-
sition based on the described user interactions. This generation is performed by
transforming the UI-BPEL user interactions elements to specic user interface
components. For example, transforming a DataInputUI to a text box, trans-
forming a DataOutputUI to a label, and transforming a DataSelectionUI to a
combo box.
UI-BPEL is part of the several initiative eorts of BPEL extension to address
the user interaction expression in a Web service composition. An example of
such extensions is BPEL4People [3], which introduces user actors into a Web
service composition by dening a new type of BPEL activities to specify user
tasks. However, this extension focuses only on the user task and does not deal
with the design of a user interface for the Web service composition. Another
example of BPEL extensions that addresses the user interaction is BPEL4UI
(Business Process Execution Language for User Interface) [1]. BPEL4UI extends
the Partner Link part of BPEL in order to allow the denition of a binding
26 M. Boukhebouze, W.P.F. Neto, and L. Erbin
Fig. 1. UI-BPEL Vs. BPEL4UI
between BPEL activities and an existing user interface. This user interface is
developed separately from the composition instead to be generated.
Figure 1 shows the dierence between our approach (UI-BPEL) and BPEL4UI
approach. The top side of the gure depicts our approach that proposes to ex-
tend BPEL with user interactions so that a user interface for the Web service
composition can be generated. The generated user interface is described in two
abstraction levels: rst, we propose to generate, from a UI-BPEL process, an
abstract user interface, which is independent to any interaction modality (e.g.
graphical input, vocal output) and computing platform (e.g. PC, smart phone)
[4]. We then generate a concrete user interface based on the user context and by
taking into account a set of user interface usability criterions [7]. This approach
is compliant with the existing user interface description languages (like UsiXML
[4]), which describe a user interface at dierent abstraction levels. The bottom
side of Figure 1 shows the BPEL4UI approach that proposes to extend the Part-
ner Link of BPEL in order to link the composition with an existing concrete user
interface (HTML/JavaScript). This approach does not allow the generation of
a user interface adapted to the user context (user preference, user environment,
and user platform) and the usability criteria (e.g the interface should respect the
size of the device screen).
In the remainder of this paper, we focus on the description of the UI-BPEL.
In section 2, we show a Web service composition scenario that requires user
interactions. We present, in Section 3, an overview of the UI-BPEL meta-model
with an illustrative example. Next, in Section 4, we present an extension of the
Eclipse BPEL editor that supports the UI-BPEL. Finally, we conclude this paper
with a discussion about the generation of the user interface from the proposed
extension and our future works.
2 Scenario
In this section we introduce the scenario of the purchase order process, which
requires user interactions. A customer requests a purchase order by providing
the necessary data such as the item, and the customer address (user interaction:
data input interaction). Upon receiving a request from the customer, the initial
price of the order, initial price of the order is calculated and a shipper is selected
simultaneously. The shipper selection needs to be made by the customer who
selects a shipper from a list of available shippers (user interaction: data selec-
tion). When the two activities are completed, the nal price is calculated and
a purchase order needs to be presented to the customer (user interaction: data
output interaction). If the customer accepts his purchase order, she/he selects
a payment method either by cash or by credit card (user interaction: data se-
lection). There is a discount if the customer pays by cash. Next, a bill is shown
to the customer (user interaction: data output interaction). Finally, the user the
customer could cancel her/his request for an purchase order before receiving the
receipt of the payment (user interaction: interaction event).
Fig. 2. Purchase Order Process expressed in BPEL
Figure 2 illustrates the purchase order process expressed using the graphical
representation of Eclipse BPEL Designer graphical notations [2]. BPEL does not
support any type of user interaction required by the scenario. For example, BPEL
cannot express the fact that the customer needs data interaction to provide
the order. Moreover, BPEL cannot express the fact that the process can make
the purchase order available to the customer using data output interaction. In
addition, BPEL cannot describe the data interaction that allows the customer
to choose a shipper and a payment method. Finally, BPEL does not support the
fact that the customer has the ability to cancel the process before the payment
is received.
In the next section, we propose an extension of BPEL that deals with user
interactions required by the purchase order process scenario. The user interaction
specication helps to generate a user interface for the purchase order process.
3 UI-BPEL
In this section, we present our BPEL extension (called UI-BPEL) that addresses
the BPEL user interaction expression issue.
3.1 UI-BPEL Meta-Model

UI-BPEL extends the BPEL [5] by adding new data interaction activities and a
new type of interaction events. Figure 3 presents an overview of the UI-BPEL
meta-model. It shows the classes that model the user interactions and their
connections with some relevant classes of the BPEL meta-model.
Fig. 3. Overview of the UI-BPEL Meta-model
In the following, we present the main classes of the UI-BPEL meta-model.

DataInteraction is a generalization class that represents the new UI-BPEL
activities.
DataInputUI is a class that represents the data input activity. This activity
is similar to the BPEL Receive activity, since it suspends the composition
precess execution while waiting for an input from the user. However, unlike
the BPEL Receive activity, the process waits for an event where data is
provided, instead of a message from another Web service. This type of event
will be explained afterwards.
DataOutputUI is a class that represents the data output activity. This
activity species which variable contains data to be presented to the user.
DataSelectionUI is a class that represents the data selection activity. This
activity allows the user to select one value (or a subset of values) from a set of
values of a specic variable. The number of selectable values can be dened
by using the minCardinality property (how many values must be selected
at least) and/or the maxCardinality property (the maximum number of el-
ements have to be selected). Like DataInputUI , the DataSelectionUI
activity suspends the execution of the process until receiving an event of
selecting data as we will explain afterwards.
UI-BPEL proposes a new type of event to process the user interaction. These
events help to indicate when a user interaction is carried out, so that a specic
action can be launched. UI-BPEL denes the user interaction events as following:
OnInteractionEvent is a generalization class that represents a new type of

BPEL event. Such an event denes the occurrence of a user interaction. An
interaction event can be either an atomic event that designates a predened
eventOnAtomicInteractionEvent or a composite event that combines atomic
and/or composite events OncompositeInteractionEvent.
OnAtomicInteractionEvent is a generalization class that represents the
occurrence of a data interaction or an interaction action done by user.
OnDataInteractionEvent is a class that indicates the fact that a Data
interaction has been done. An OnDataInteractionEvent can be:
onDataInput indicates that new data has been entered by the user. This
event allows the process to resume its execution when it was being sus-
pended by a DataInputUI activity.
onDataSelection indicates that some data has been selected by the user.
This event allows to resume the process execution when it was being
blocked by a DataSelectionUI activity.
onDataOutput indicates that new data has been presented through the
user interface. This event is used to notify that the user validates a data
output. For example, an onDataOutput event can be the conrmation
that the user accepts the copyright licence of a Web service.
OnActionInteractionEvent is a class that represents the notication of
the occurrence of a predened interaction action. These predened interac-
tion actions are:
OnCancel indicates that a cancellation action has been performed by
the user.
OnException indicates that an exception has occurred in the user inter-

face (e.g. the User Interface Failure). This event is used by the BPEL
Fault handler part.
OnActionInteractionEvent is used to handle the cancellation or the exception
that can happen within a scope of the Web service composition.
OnCompositeInteractionEvent: is a class that expresses a combination
of atomic and/or composite events. According to [9], a composite event can
be:
Disjunction(e1, e2): species that at least one of the two interaction
events is detected;
Conjunction (e1, e2): species that interaction events take place without
taking into account of their occurrence order;
Occurrence (e1, number of occurrence): species multiple occurrences of
the same interaction event;
Sequence (e1, e2): species the sequence of interaction events
Not (e1, t): characterizes the fact that an interaction event has not
happened at time t.
OnCompositeInteractionEvent can be used to process the user interactions
aspect in the Web service composition. For example, if a user does not pro-
vide an input data during time t (Not (onDataInput, t)), the process should
be canceled. OnCompositeInteractionEvent can also be used to process the
grouping of a set of data interactions on the same User interface container.
For example, if we group the data input of the customer information, and
the data selection of a shipper on a same user interface component, the event
Conjunction (on customer information Input, on Shipper Selection) models
the fact that the customer information is provided and a shipper Selected.
This could resume the execution of a suspended process by the data input
and the data selection activities. Note that, grouping the data interaction on
a same user interface component is handled by the user interface generation
method. The data interaction grouping is not in the scope of this paper.
UI-BPEL denes also denes some useful new classes, for example:
UserRole: is a class that represents which user is responsible of DataInter-

action. UserRole is an important element for the user interface generation
process since a user interface should be generated for each dierent role.
PickUI: is a class that extends the BPEL Pick activity in order to take
into account onInteractionEvent listening.
ScopeUI: is a class that extends the BPEL Scope activity in order to add
on its EventHandler the onUserEvent listening.
3.2 UI-BPEL Example
We now illustrate the UI-BPEL of the purchase order scenario presented in

Section 2.
Fig. 4. Purchase Order Process expressed in UI-BPEL
Figure 4 depicts the purchase order process expressed using both graphical
representation (extended Eclipse BPEL Designer graphical notations [2]) and
XML representation of UI-BPEL. The gure shows that UI-BPEL supports the
user interaction types required by the scenario. For example:
UI-BPEL expresses the fact that customer needs data input interaction to
provide the data order by using the DataInputUI activity (Figure 4, line 4).
This activity launches the process execution when the input is provided;
UI-BPEL expresses the fact that the customer can select one shipper by using
DataSelectionUI (Figure 4, line 14). In order to process this data interaction,
the composed event Not (onShipperSelection, 5 min) is listened. So that, if
no shipper is selected in 5 minutes, then the process is cancelled (Figure 4,
line 18);
UI-BPEL expresses the fact that the customer can cancel the request for an
purchase order by using a ScopeUI with an OnCancelEvent (Figure 4, line
5-11);
The DataOutputUI presenting an order and The DataSelectionUI Pay-
mentMethod can be gathered on the same user interface component so that
the event Conjunction (OnDataOutput, on OnDataSelection) will be raised.
This event noties that user has conrmed the order (OnDataOutput ) and
leads to unblock the process that waits for a payment method selection (On-
DataSelection).
4 UI-BPEL Designer Tool

This section describes the UI-BPEL Designer Tool that is dedicated to edit a UI-
BPEL process that conforms to the UI-BPEL Meta-model. The tool is an Eclipse
plug-in based on the Eclipse BPEL Designer [2]. The Eclipse BPEL Designer is
chosen since it has an extensible framework that allows not only the WS-BPEL
2.0 specication, but also the deployment and the execution of BPEL processes
from the tool into a BPEL engine. Figure 5 shows a screenshot of the UI-BPEL
Designer Tool.
Fig. 5. UI-BPEL Designer Tool
The tool is available at the following address: http://webapps.fundp.ac.be/wse
5 Conclusion and Discussions

In this paper, we presented a BPEL extension, called the UI-BPEL. This ex-
tension addresses the user interaction in a Web service composition by dening
new data interaction activities to allow user providing, selecting or getting data.
The extension also proposes new types of interaction events to react when user
interaction is carried out. The main goal of UI-BPEL is to allow the generation
of a user interface for the Web service composition based on the described user
interactions. This generation can be done in two steps:
Step1 : an abstract user interface [7] is generated from a UI-BPEL model.
This user interface is described independent of any interaction modality
(e.g. graphical modal, vocal modal) and computing platform (e.g. PC, smart
phone). For this reason, each specied user interaction will be transformed
into an abstract component, which can be an input abstract component, a
selection abstract component, an output abstract component or a control
abstract component. A control abstract component allows to process one or
a set of data interactions. It also allows to model action interaction (e.g. can-
cel action). In addition, the control abstract component is also responsible
of triggering the interaction events.
Step2 : a concrete user interface [7] is generated from the abstract user inter-
face. The concrete user interface is adapted to a specic user context (user
preference, user environment, and user platform). For example, for a visually
handicapped person, the output abstract component will be transformed to
vocal output. The concrete user interface takes also into account a set of
user interface usability criterions. For example, the interface should respect
the size of the device screen.
Our future work includes the development of two transformation methods for
the two steps of the user interface generation described above.
References
1. Daniel, F., Soi, S., Tranquillini, S., Casati, F., Heng, C., Yan, L.: From people to
services to ui: Distributed orchestration of user interfaces. In: Hull, R., Mendling,
J., Tai, S. (eds.) BPM 2010. LNCS, vol. 6336, pp. 310326. Springer, Heidelberg
(2010)
2. Eclipse, B.: Project. Eclipse BPEL Designer (2011),
http://www.eclipse.org/bpel/
3. Kloppmann, M., Koenig, D., Leymann, F., Pfau, G., Rickayzen, A., von Riegen, C.,
Schmidt, P., Trickovic, I.: Ws-bpel extension for peoplebpel4people. Joint White
Paper, IBM and SAP (2005)
4. Limbourg, Q., Vanderdonckt, J., Michotte, B., Bouillon, L., L opez-Jaquero, V.:
USIXML: A language supporting multi-path development of user interfaces. In:
Bastide, R., Palanque, P.A., Roth, J. (eds.) DSV-IS 2004 and EHCI 2004. LNCS,
vol. 3425, pp. 200220. Springer, Heidelberg (2005)
5. OASIS, B.: Web Services Business Process Execution Language (2007)
6. Rao, J., Su, X.: A survey of automated web service composition methods. In:
Cardoso, J., Sheth, A. (eds.) SWSWPC 2004. LNCS, vol. 3387, pp. 4354. Springer,
Heidelberg (2005)
7. Seah, A., Gulliksen, J., Desmarais, C.M. (eds.): Human-Centered Software Engi-
neering - Integrating Usability in the Software Development Lifecycle. HCI Series,
vol. 8 ch. 6, pp. 109140. Springer, Heidelberg (2005)
8. Tofan, S., Pradais, A., Buraga, S.: A study regarding the abstract specication of
the user interface by using USIXML and UIML languages. Romanian Journal of
Human-Computer Interaction (RoCHI 2009), 3134 (2009)
9. Wu, E., Diao, Y., Rizvi, S.: High-performance complex event processing over
streams. In: Proceedings of the 2006 ACM SIGMOD 2006, pp. 407418 (2006)
10. Zeng, L., Benatallah, B., Ngu, A.H.H., Dumas, M., Kalagnanam, J., Chang,
H.: QoS-aware middleware for web services composition. IEEE Trans. Software
Eng. 30(5), 311327 (2004)
Semantics-Enabled Web API Organization and
Recommendation
Devis Bianchini, Valeria De Antonellis, and Michele Melchiori
Dipartimento di Ingegneria dellInformazione

Universita degli Studi di Brescia, Via Branze, 38, 25123 Brescia
{bianchin,deantone,melchior}@ing.unibs.it
Abstract. The design of Web applications from third-party Web APIs

can be shortened by providing a conceptual model that abstracts from
implementation aspects of each Web API and supports their selection.
In this paper we propose a framework to support easy Web application
development. The framework provides Web API organization based on
automated matching techniques apt to establish semantic links between
them according to properly dened similarity and coupling criteria and
Web API selection patterns to support interactive and proactive Web
application development according to an exploratory perspective.
1 Introduction
Recently, research attention is being progressively shifting from the develop-
ment of Web applications from scratch to their composition starting from a
huge amount of components independently developed by third parties [7]. These
components are made available through their APIs, to serve the development
of situational applications. However, integration of Web APIs often means in-
tegration of UIs (consider, for instance, the wide use of Google maps in Pro-
grammableWeb.com, an on-line registry of about 3000 Web APIs). UIs can gen-
erate/react to events, that require synchronization with the other Web APIs in
the same application. Moreover, Web application development is hampered by
the semantic heterogeneity of Web API descriptions (in terms of I/O variables,
operations, events) and by their increasing number.
The development of Web applications from third-party Web APIs can be
shortened by providing a model that abstracts from implementation aspects of
each Web API and supports their selection. While some eorts such as WADL
(Web Application Description Language) are being developed for RESTful ser-
vices, whose aim is to be the counterpart of the WSDL standard for SOAP Web
services, there are some tools such as SWEET [9] which guides the providers to
give a structured representation of their Web APIs (by using the hRESTS for-
malism) and add semantics by referencing concepts in publicly available domain
ontologies through the MicroWSMO language [8]. This still does not avoid prob-
lems during Web application development due to the huge availability of Web
APIs. In this paper we propose a framework to support easy Web application de-
velopment. The framework provides Web API organization based on automated

Semantics-Enabled Web API Organization and Recommendation 35
matching techniques apt to establish semantic links between them according to

properly dened similarity and coupling criteria and Web API selection patterns
to support interactive and proactive Web application development according to
an exploratory perspective.
The relevance of models of components/Web APIs which abstract from imple-
mentation details and thus make the composition of the Web application easier
has been highlighted in [1,4,5]. In [1] a formal model based on Datalog rules is
proposed to capture all the aspects of a mashup component. Mashups are com-
bined into patterns and a notion of inheritance relationship between components
is introduced. This model has been used in the MatchUp system [6], which sug-
gests components to be connected on the basis of recurrent patterns. In [4] an
abstract component model and a composition model are proposed, expressed
by means of an XML-based language, where components are coupled according
to a publish/subscribe mechanism, where events raised from a component are
associated to operations of other components. No particular selection strategies
are suggested. In [5] a faceted classication of unstructured Web APIs and a
ranking algorithm to improve their retrieval are proposed. The classication and
searching solution are based on IR techniques. The use of semantics in Web
application development has been introduced in [10], where authors propose a
novel application of semantic annotation together with a matching algorithm
for nding sets of functionally equivalent components. With respect to these
approaches, our approach considers dierent kinds of semantic links between
Web APIs, providing a richer organization of available APIs and easy browsing
of them during Web application development. Based on this organization, ner
selection strategies have been designed and implemented.
The paper is organized as follows: Section 2 introduces a motivating scenario
and the proposed framework, whose elements are detailed in Section 3 (Web
API semantic descriptor), Section 4 (semantic links) and Section 5, where the
selection patterns are presented; Section 6 presents a preliminary implementation
and validation of the framework; nally, Section 7 closes the paper and points
out future work.
2 Motivating Scenario
Let consider Dante, a Web designer who works for an Italian multimedia and
entertainment publishing company and must quickly design a Web application
to allow users to nd the company shops for promoting coming soon books/D-
VDs. This is an example of situational application, targeted on the companys
specic requirements and potentially useful for short periods of time, that is,
until the sales promotion will last. Main tasks of Dante concern the selection
and combination of suitable Web APIs which already implement some of the re-
quired functionalities, such as Web APIs to obtain information about company
shops or Web APIs to visualize on a map the location of the shops which have
been found. Dante proceeds step by step by selecting Web APIs and wiring them
to obtain the nal Web application as quickly as possible. Dante species the
36 D. Bianchini, V.D. Antonellis, and M. Melchiori
Web API hes looking for, for instance in terms of desired categories, operations
and inputs/outputs. A list of available API descriptions should be proposed,
ranked with respect to the degree of match with categories, operations and I/O
names specied by Dante. Less relevant APIs must be ltered out, to properly
reduce the search space. When Dante has already selected a Web API, other
APIs that could be coupled with the selected one should be proactively sug-
gested to him. The suggested APIs should be ranked with respect to the degree
of coupling with the selected one. Coupling can be evaluated on the basis of
correspondences between events and operations of Web API descriptions. Let
suppose that Dante chooses a Web API that, given the book/DVD title, returns
the addresses of company shops where the book/DVD is available. Other Web
APIs that can be wired with the selected one, for example Web APIs that visu-
alize points on a map by specifying the addresses to display, can be suggested to
Dante. If Dante wants to substitute one of the selected Web APIs, the system
should suggest a list of candidate APIs as alternatives, ranked with respect to
their similarity with the API to be substituted. API similarity can be evaluated
on the basis of similarity between operation names, inputs and outputs of Web
API descriptions.
The framework we propose has been designed to support Dante in the de-
scribed motivating scenario. The framework is based on semantic annotation of
Web APIs provided through available tools (e.g., SWEET [9]) and is composed
of three main elements.
Semantics-enabled Web API model. A collection of Web API semantic de-
scriptors are extracted from semantically Web APIs. Descriptors abstract
from underlying concrete implementations of the Web APIs. Each semantic
descriptor has a reference to the URI of the original API.
Web API registry model. Web API semantic descriptors are organized in a
semantics-enabled registry through semantic links established by applying
automated matching techniques.
Selection patterns. Semantic links are exploited for supporting: (i) proactive
suggestion of Web API descriptors ranked with respect to their similarity
with the Web application designers requirements; (ii) interactive support
to the designer for the composition of the Web application, according to an
exploratory perspective.
3 Semantics-Enabled Web API Model

Basic elements of the semantics-enabled Web API model are shown in Figure 1.
The description of Web APIs as found on the Web typically relies on non struc-
tured HTML documentation that makes dicult machine processing. Therefore
techniques, formats and tools for semantic annotation of Web APIs based on
lightweight semantic models have been proposed in [9], where the SWEET tool
have been described. The SWEET tool provides support in the identication
of elements that characterize a Web API to produce a description according to
the hREST language. A set of common elements can be identied in Web API
Fig. 1. The semantics-enabled Web API model
descriptions: (i) inputs and outputs; (ii) operations, usually associated with but-
tons or links on the Web API graphical interface; (iii) events, to model users
interactions with the Web API interface. Therefore, SWEET enables the se-
mantic annotation of the hRESTS structure: (i) APIs are classied with respect
to categories, that are taken from standard taxonomies available on the Web
(identied by a taxonomy URI); (ii) operation names, inputs and outputs and
event outputs are annotated with concepts, extracted from domain ontologies
and identied by a concept URI. Domain ontologies are built by domain experts
and can be designed ad-hoc for a particular application or can be made available
on the Web for general purposes. If a suitable ontology is not available, it must
be created rst, for example using common editors (such as Protege OWL). No
commitment is made on a particular ontology formalism. Annotation and classi-
cation of the Web APIs is performed according to the MicroWSMO [8] notation
extended with semantically annotated events.
From each semantically annotated Web API, the following semantic descriptor
SDi is extracted:
SDi = CATi , OPi , EVi (1)
where: CATi is a set of categories, OPi is a set of operations, EVi is a set
of events. Each operation opk OPi is described by the operation name opk ,
the operation inputs IN (opk ) and the operation outputs OU T (opk ), that are
annotated with concepts taken from the domain ontologies. Each event evh
EVi is described by the set of ontological concepts which annotate the event
outputs OU Tev (evh ) as well. An event of a Web API can be connected to an
operation of another Web API in a publish/subscribe-like mechanism. An event-
operation pair is represented in the model through an activation relationship,
that is equipped with the set of correspondences between event outputs, changed
when the event is raised, and inputs of operations triggered by event occurrence
(see Figure 1). An activation relationship from an event evih of a descriptor SDi
and an operation opkj of another descriptor SDj , is dened as follows:
acthk = evih , opkj , Mhk (2)

where evih EVi , opkj OPi , Mhk is the set of correspondences between evih
k
outputs and opj inputs. IO correspondences are suggested comparing concepts
used to annotate outputs and inputs and evaluating a concept anity CAf f be-
tween them. The coecient CAf f [0..1] evaluates the similarity between two
concepts. To this purpose, we rely on techniques such as those extensively de-
ned in [3]. Here we simply state that CAf f is based on WordNet terminological
(domain-independent) relationships (e.g., synonymy, hypernymy) between terms
used as concept names and on semantic relationships (e.g., equivalence, sub-
sumption) between concepts dened in domain ontologies. The proposed model
abstracts from implementation details in Web API description (in fact, Web
APIs can be implemented through dierent technologies and can be accessed
according to dierent messaging formats, such as XML, JSON, RSS items) and
enables the design of common selection patterns to support Web application
development.
4 Web API Registry Model
We propose a semantics-enabled Web registry model where descriptors are or-

ganized according to two kinds of semantic links: (i) functional similarity links,
set between descriptors that provide similar functionalities, and (ii) functional
coupling links, set between descriptors that can be included in the same Web
application.
A functional similarity link between two semantic descriptors SDi and SDj
is set if their categories are compatible (that is, at least one SDj category is the
same or less specic than one SDi category) and is formally dened as:
SDi , SDj , SimIO (SDi , SDj ) (3)
where SimIO (SDi , SDj ) is the functional similarity degree and [0, 1] is
a threshold experimentally set. The functional similarity degree is computed to
quantify how much SDj provides at least the operations and I/Os required in
SDi ; no matter if SDj provides additional operations and I/Os. The expression
is reported in Table 1. The building block of this expression is the Dice coecent
used in Information Retrieval [11] and the computation of the concept anity
CAf f () between pairs of, respectively, (i) operations, (ii) I/Os parameters.
Functional coupling links between events EVi raised by a semantic descriptor
SDi and operations OPj executed by a semantic descriptor SDj is formally
dened as
SDi , SDj , CouplIO (SDi , SDj ) (4)
where CouplIO (SDi , SDj ) is the coupling degree and [0, 1] is a thresh-
old experimentally set. Each functional coupling link is associated to a set Mijc
of candidate IO correspondences between ouputs of EVi and inputs of OPj .
CouplIO () is obtained by computing values of event-operation coupling coe-
cients, CouplEvOp(evi , opj ), evaluated as the total CAf f () between the outputs
Table 1. Coupling and functional similarity coecients
Functional similarity degree

CAf f (ins ,int )
s,t h,k CAf f (outh ,outk )
SimIO (SDi , SDj ) = |IN(SD )|
+ |OU T (SDi )|
+
i
l,m CAf f (opl ,opm )
|OP (SDi )|
[0, 3]
Coupling degree
CAf f (outh ,ink )
CouplEvOp(evi , opj ) = h,k
|OU Tev (evi )|
[0,1]

CouplEvOp (evi ,opj )
CouplIO (SDi , SDj ) = i,j
|EV (SDi )|
[0,1]
of evi EVi and the inputs of opj OPj (see Table 1). Functional similarity and
coupling have been detailed in [2].
Let be SD the set of semantic descriptors, OP (SD) (resp., EV (SD)) the over-
all set of operations (resp., events) for all the semantic descriptors in SD, M c the
set of candidate correspondences between annotated event outputs and operation
inputs detected during the functional coupling evaluation. The Web API registry
is dened as a 4-uple SD, SL, CL, M c , where SLSDSD[0, 1] is the set of
similarity links between descriptors and CL EV (SD)OP (SD)[0, 1] is the
set of coupling links between event/operation pairs.
5 Web API Selection Patterns
In this section, we propose the selection patterns we identied to support the

designer during the Web application development by exploiting semantic links
in the Web API registry. We identied two possible patterns:
Completion Pattern, to suggest a ranked list of descriptors that are function-

ally coupled to a selected descriptor SDc and belongs to a given category
catj ;
Substitution Pattern, to suggest a ranked list of descriptors that are func-
tionally similar to a selected descriptor SDs and are functionally coupled
with descriptors that are connected to SDs through activation relationships
in the Web application.
A Selection Pattern is dened as a 4-uple = SD , m , cond , , where

is the goal of the selection pattern (completion or substitution). The metric
m is used to evaluate candidate descriptors to suggest. The condition cond is
used to lter out not relevant descriptors. Finally, is a ranking function to
present the suggested descriptors.
According to this general denition, the Completion Pattern, denoted with
c , is dened as follows:
c = SDc , CouplIO (SDc , SDi ), Condc , c (5)

where SDc is the selected descriptor, Condc is dened as catj CAT (SDi )
CouplIO (..), catj the category which suggested descriptors must belong to.
Note that this implies the presence of a coupling link from SD c to SD i in the
Web API registry. The function c : SDSD denes a ranking over the set
SD of descriptors in the registry such that SD i c SDj if CouplIO (SD c , SDi )
CouplIO (SD c , SD j ). For a coupled descriptor that has been selected to be added
to the Web application, semantic correspondences among I/Os are suggested to
the designer. With reference to the motivating scenario, the completion pattern
is used to suggest to Dante Web API descriptors that can be coupled with the
Web API descriptor that, given the book/DVD title, returns the addresses of
company shops where the book/DVD is available, for instance, Web APIs that
visualize addresses on a map.
Similarly, the Substitution Pattern, denoted with s , is formally dened as
follows:
s = SDs , (SDs , SD i ), Conds , s (6)

where SD s is the selected descriptor, Conds is SimIO (..) CAT (SD s )
CAT (SDi ) = . The function (SDs , SDi ) is made up of three parts:
the functional similarity between SD s and SD i , that is SimIO (SD s , SD i );
the sum of the functional coupling degree between SD i and each SD k in
the Web application under development such that there exists an activation
relationship from SD s and SD k ;
the sum of the functional coupling degree between SD h and SDi , where
SD h are descriptors in the Web application under development such that
there exists an activation relationship from SD h and SDs .
That is,

(SDs , SDi ) = SimIO (SDs , SDi ) + CouplIO (SDi , SDk ) + CouplIO (SDh , SDi ) (7)
k h
The function s : SDSD denes a ranking over the set SD of descriptors in

the registry such that SD i s SD j if (SDs , SDi )(SD s , SD j ).
The condition SimIO (SD s , SD i ) gives priority to the presence of a similar-
ity link from SD s to SD i in the registry. This is because the goal of this selection
pattern is to nd an alternative to SDs (for example, dierent map viewer Web
APIs). Low eorts to connect the candidate alternatives to the other descriptors
is evaluated only for ranking purposes.
6 Preliminary Implementation and Evaluation

A prototype implementation of the framework to support easy Web application
development, based on the discussed model, is presented in this section. The
Web-based Graphical User Interface of the tool is shown in Figure 2. The in-
terface has been implemented using the ZK open source framework, providing a
library of AJAX components to implement dierent selection patterns.
Fig. 2. Graphical User Interface of the design framework
In the upper part, the Web interface enables to search for available Web APIs
by specifying their category or their name (Search By category and Search
By Name). On the left, panels to browse the semantics-enabled Web API registry
are shown. The selected descriptor SDi is highlighted as a circle in the center of
the Similarity links panel (e.g., the FindShops descriptor in Figure 2); all the
descriptors SDj related to SDi through a similarity link are displayed as circles
around SDi ; dimension of each circle is proportional to the SimIO (SDi , SDj )
value. The selected descriptor SDi is also highlighted as a pentagon in the center
of the Coupling links panel; other descriptors SDj coupled with SDi are shown
as hexagons around the pentagon; dimension of each hexagon is proportional to
the CouplIO (SDi , SDj ) value (see, for example, the MapViewer descriptor). In
the canvas on the right, the Web interface enables the designer to drag Web API
descriptors and wire them to design the Web application. Each descriptor is rep-
resented as a rectangle containing the descriptor events (e.g., the selectedShop
event for the FindShops descriptor) and operations (e.g., the find operation
for the FindShops descriptor). By pushing the Self connections button, the
system suggests activation relationships among descriptors which present IO
correspondences. By clicking on the connection in the canvas, the designer can
visualize the set of possible IO correspondences, which he/she can set or re-
set. The designer can also introduce his/her own activation relationships (Add
activations facility).
Preliminary experiments have been performed to validate the eectiveness of
the selection patterns. We used a 32 bit Windows machine with a 2.10 GHz
AMD Athlon X2 Dual-Core CPU, 1 MB L2 Cache and 4GB RAM memory
using a set of annotated descriptors inspired by the motivating scenario (map

visualization APIs, search APIs, etc.) and other descriptors randomly generated
for testing the registry performances, obtaining a total of 150 descriptors. We
started from a dataset of ten manually dened Web applications, each of them
made up of a Web API descriptor SDi coupled with other descriptors {SDj }
from the registry. We searched for coupled descriptors for SDi in the registry
(Completion Pattern) and for descriptors which can substitute SDi (Substitution
Pattern). We considered a hit for the completion pattern evaluation for each
Web API descriptor SDj that is eectively suggested in the Coupling link
panel. We evaluated the average precision and recall over the Web applications
as the number of hits with respect to the total number of APIs returned by the
registry (precision) and the total number of relevant APIs manually identied in
the dataset (recall). Experiments have been performed by varying the coupling
threshold in the range [0, 1]. The results are shown in Figure 3. Substitution
pattern evaluation has been performed in a similar way.
(b) completion selection pattern (a) substitution selection pattern

0.9 1
0.85 0.95
0.8
0.9
0.75
0.85
Precision
Precision
0.7
0.8
0.65
0.75
0.6
0.7
0.55
0.5 0.65
0.45
0.3 0.4 0.5 0.6 0.7 0.8 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Recall Recall
Completion Substitution
Fig. 3. Precision-Recall Curve for the two selection patterns
7 Conclusions and Future Work

In this paper we presented a support framework for easy Web application devel-
opment, which includes organization of Web APIs based on automated matching
techniques apt to establish semantic links between them according to properly
dened similarity and coupling criteria and selection patterns to support inter-
active and proactive Web application development according to an exploratory
perspective. A preliminary implementation and validation of the framework have
also been presented. The framework is intended to be used in an integrated way
with tools and frameworks for easy creation of Web applications starting from
available Web APIs, to automate the generation of programming code to actually
glue the selected Web APIs into the nal application. An extensive experimen-
tation in a real case scenario, including usability issues, is being performed.
References
1. Abiteboul, S., Greenshpan, O., Milo, T.: Modeling the Mashup Space. In: Proc. of
the Workshop on Web Information and Data Management, pp. 8794 (2008)
2. Bianchini, D., Antonellis, V.D., Melchiori, M.: A Semantic Framework for collab-
orative Enterprise Knowledge Mashup. In: DAtri, A., Ferrara, M., George, J.F.,
Spagnoletti, P. (eds.) Information Technology and Innovation Trends in Organiza-
tions, pp. 117124. Physica Verlag, Heidelberg (2011)
3. Bianchini, D., Antonellis, V.D., Melchiori, M.: Flexible Semantic-based Service
Matchmaking and Discovery. World Wide Web Journal 11(2), 227251 (2008)
4. Daniel, F., Casati, F., Benatallah, B., Shan, M.: Hosted universal composition:
Models, languages and infrastructure in mashArt. In: Laender, A.H.F., Castano,
S., Dayal, U., Casati, F., de Oliveira, J.P.M. (eds.) ER 2009. LNCS, vol. 5829, pp.
428443. Springer, Heidelberg (2009)
5. Gomadam, K., Ranabahu, A., Nagarajan, M., Sheth, A.P., Verma, K.: A Faceted
Classication Based Approach to Search and Rank Web APIs. In: ICWS, pp. 177
184 (2008)
6. Greenshpan, O., Milo, T., Polyzotis, N.: Autocompletion for Mashups. In: Proc. of
the 35th Int. Conference on Very Large DataBases (VLDB 2009), Lyon, France,
pp. 538549 (2009)
7. Hoyer, V., Fischer, M.: Market overview of enterprise mashup tools. In: Bouguet-
taya, A., Krueger, I., Margaria, T. (eds.) ICSOC 2008. LNCS, vol. 5364, pp. 708
8. Kopecky, J., Vitvar, T., Fensel, D.: hRESTS & MicroWSMO. Tech. rep., SOA4ALL
Project, Deliverable D3.4.3 (2009)
9. Maleshkova, M., Pedrinaci, C., Domingue, J.: Semantic annotation of Web APIs
with SWEET. In: Proc. of the 6th Workshop on Scripting and Development for
the Semantic Web (2010)
10. Ngu, A.H.H., Carlson, M.P., Sheng, Q.Z., Young Paik, H.: Semantic-based mashup
of composite applications. IEEE T. Services Computing 3(1), 215 (2010)
11. van Rijsbergen, C.J.: Information Retrieval. Butterworth (1979)
Preface to MORE-BI 2011
Business intelligence (BI) systems gather, store, and process data to turn it into informa-
tion that is meaningful and relevant for decision-making in businesses and organizations.
Successful engineering, use, and evolution of BI systems require a deep understanding
of the requirements of decision-making processes in organizations, of the kinds of infor-
mation used and produced in these processes, of the ways in which information can be
obtained through acquisition and reasoning on data, of the transformations and analyses
of that information, of how the necessary data can be acquired, stored, cleaned, how its
quality can be improved, and of how heterogeneous data can be used together.
The first International Workshop on Modeling and Reasoning for Business Intelli-
gence (MORE-BI 2011) was organized and collocated with the 30th International Con-
ference on Conceptual Modeling (ER 2011), held in Brussels, Belgium, to stimulate
discussions and contribute to the research on the concepts and relations relevant for the
various steps in the engineering of BI systems, the conceptual modeling of requirements
for BI systems, of the data used and produced by them, of the transformations and anal-
yses of data, and associated topics to which researchers and practitioners of conceptual
modeling can contribute, in the aim of constructing theoretically sound and practically
relevant models and reasoning facilities to support the engineering of BI systems.
The call for papers attracted 23 abstracts, of which 22 resulted in full submissions.
The submissions came from 64 authors from 14 countries and 4 continents. The pro-
gram committee consisting of 31 researchers conducted three reviews of each submis-
sion and selected 7 submissions for presentation and discussion at the workshop, an
acceptance rate of 32%.
We wish to thank all authors who have submitted their research to MORE-BI 2011.
We are grateful to our colleagues in the steering committee for helping us define the
topics and scope of the workshop, our colleagues in the program committee for the
time invested in carefully reviewing the submissions under a very tight schedule, the
participants who have helped make this an interesting event, and the local organizers
and workshop chairs of ER 2011.
We hope that you find the workshop program and presentations of interest to research
and practice of business intelligence, and that the workshop has allowed you to meet
colleagues and practitioners focusing on modeling and reasoning for business intelli-
gence. We look forward to receive your submissions and meet you at the next edition
of the International Workshop on Modeling and Reasoning for Business Intelligence.
July 2011 Ivan J. Jureta

Stephane Faulkner
Esteban Zimanyi

Formal Concept Analysis for Qualitative Data
Analysis over Triple Stores
Frithjof Dau and Baris Sertkaya
SAP Research Center Dresden, Germany

(frithjof.dau,baris.sertkaya)@sap.com
Abstract. Business Intelligence solutions provide dierent means like

OLAP, data mining or case based reasoning to explore data. Standard BI
means are usually based on mathematical statistics and provide a quanti-
tative analysis of the data. In this paper, a qualitative approach based on
a mathematical theory called Formal Concept Analysis (FCA) is used
instead. FCA allows clustering a given set of objects along attributes
acting on the objects, hierarchically ordering those clusters, and nally
visualizing the cluster hierarchy in so-called Hasse-diagrams. The ap-
proach in this paper is exemplied on a dataset of documents crawled
from the SAP community network, which are persisted in a semantic
triple store and evaluated with an existing FCA tool called ToscanaJ
which has been modied in order to retrieve its data from a triple store.
1 Introduction
Business Intelligence (BI) solutions provide dierent means like OLAP, data
mining or case based reasoning to explore data. Standard BI means are usually
designed to work with numerical data, thus they provide a quantitative analy-
sis of the data (aka number crunching) based on mathematical statistics. In
fact, classical BI examples show accounting, nance, or some other calculation-
heavy subject [10]. To some extent, though arguably oversimplied, one can
understand BI as acting on lists or tables lled with numbers.
Compared to number crunching, Formal Concept Analysis (FCA) [3] provides
a complementing approach. The starting point of FCA are crosstables (called
formal contexts), where the rows stand for some objects, the columns for some
attributes, and the cells (intersections of rows and columns) carry the binary
information whether an attribute applies to an object (usually indicated by a
cross) or not. Based on this crosstable, the objects are clustered to meaningful
sets. These clusters form a hierarchy, which can be visually displayed, e.g. by
a so-called Hasse-diagram. A short introduction into FCA, as needed for this
paper, is provided in the next section.
A general overview over the benets of FCA in information science is provided
by Priss in [8]. Relevant for this paper are the relationships between FCA and
both Business Intelligence (BI) and Semantic Technologies (ST).
With respect to BI, FCA can be for example considered as a data mining tech-
nology, particularly for mining association rules [7]. More relevant to this paper

46 F. Dau and B. Sertkaya
is the approach to explore data in relational databases with FCA. As described

in the next section, a method called conceptual scaling allows transforming
columns in a database, lled with arbitrary values, into formal contexts. Such
scales can be compared to dimensions in BI applications. The exploration of data
in databases with FCA is for example described in [4,6,13,12]. A number of tools
for FCA have been developed. Most important for this paper is Toscana [14,9] ,
developed in C, and its Java-based successor ToscanaJ [1]1 . Moreover, it should
be mentioned that FCA has been used for exploring data warehouses as well [5].
FCA targets a formalization of the human understanding of concepts with
their extensions and intensions, thus FCA indeed is a semantic technology.
Though it does not belong to the core of Semantic Web technologies, FCA
provides decent means to dene and analyze concept hierarchies, so it comes
as no surprise that FCA has been used in the realm of querying, browsing, com-
pleting and visualizing ontologies (e.g. OWLFCAViewTab and OntoComP2 [11]
plugins for the Protege ontology editor, and OntoViz), ontology alignment (e.g.
FCA-Merge and OntEx), ontology engineering (e.g. relational exploration or role
exploration) and ontology learning (e.g., Text2Onto). In this paper, we exem-
plify the benets of FCA for (semantically enabled) BI by analyzing data in a
triple store with FCA methods. In order to do so, the existing ToscanaJ tool
has been modied such that it can retrieve data from triple stores instead of
relational databases. A short introduction into ToscanaJ and its modications
are provided in Sec. 3. An often named benet of ST compared to relational
databases are the ST capabilities to better deal with unstructured data like
text-documents. FCA has already been employed to create concept hierarchies
out of the content of text documents. In this paper, we apply FCA on a dataset
of documents crawled from the SAP community network3 (SCN), but do not
target to investigate the contents of the documents, but utilize meta-data of the
documents (which have been created in the crawling process) for FCA-purposes.
This use case is described in Sec. 4.
2 Formal Concept Analysis
Formal Concept Analysis (FCA) is a eld of applied mathematics that is based

on a lattice-theoretic formalization of the notions of concepts and conceptual
hierarchies. FCA provides ecient algorithms for analyzing data and discovering
hidden dependencies in the data. It also allows the user to visualize the data in
an easily understandable way. In FCA, data is represented in the form of a formal
context, which in its simplest form is a way of specifying which attributes are
satised by which objects.
Example 1. Consider the formal context in Fig. 1. It shows information about
the gender of four customers and the product groups they are interested in. For
1
http://toscanaj.sourceforge.net
2
http://ontocomp.googlecode.com
3
http://www.sdn.sap.com/irj/scn/index
Formal Concept Analysis for Qualitative Data Analysis over Triple Stores 47
modelCars
PCgames
makeUp
female
books
male
mary
john
erika
max
Fig. 1. Formal context of customers (left) and its concept lattice (right)
instance the last row states that Max is a male, he is interested in model cars,
books and PC games but he is not interested in make-up items.
Given such a formal context, the rst step for analyzing this context is usually
computing the formal concepts of this context, which are natural clusterings
of the data in the context. A formal concept is a pair consisting of an object set
A and an attribute set B such that the objects in A share the attributes in B,
and B consists of exactly those attributes that the objects in A have in common.
The object set A is called the extent, and the attribute set B is called the intent
of the formal concept (A, B).
Example 2. Consider the formal context given in Ex. 1. It has nine formal con-
cepts. One of them is ({max}, {male, modelCars, P Cgames, books}) with the
extent {max} and the intent {male, modelCars, P Cgames, books}. Note that
max is male and has exactly the interests in modelCars, PCgames, books. On
the other hand, max is the only male person with these interests. Another (less
trivial) formal concept is ({john, max}, {male, modelCars, P Cgames}). Both
john and max are male and have modelCars and PCgames as (common) inter-
ests, and they are indeed the only male persons with (at least) these interests.
Once all formal concepts of a context are obtained, one orders them w.r.t.
the inclusion of their extents (equivalently, inverse inclusion of their intents).
For example, the two formal concepts of the above given example are ordered
that way. This ordering gives a complete lattice (e.g. a hierarchy where any
two elements have -like in trees- a least upper bound and -unlike in trees- a
greatest lower bound), called the concept lattice of the context. A concept lattice
contains all information represented in a formal context, i.e., we can easily read
o the attributes, objects and the incidence relation of the underlying context.
Moreover, concept lattice can be visualized, which makes it easier to see formal
concepts of a context and interrelations among them. Thus it helps to understand
the structure of the data in the formal context, and to query the knowledge
represented in the formal context.
The nodes of a concept lattice represent the formal concepts of the underlying
context. In order to improve readability of the lattice, we avoid writing down
the extent and intent of every single node. Instead, we label the nodes with
attribute and object names in such a way that every name appears only once
in the lattice. In this labelling, the intent of the formal concept corresponding
to a node can be determined by the attribute names that can be reached by
the ascending lines, and its extent can be determined by the object names that
can be reached by the descending lines. For instance consider the concept lattice
in Figure 1 that results from the formal context in Example 1. The attribute
names are written in boxes with gray background and object names are written
in boxes with white background. The intent of the formal concept marked with
the attribute name books is {books} since there is no other attribute name that
can be reached by an ascending line, and its extent is {max, erika} since these
are the only two object names that can be reached by a descending line from it.
Similarly, the concept marked with the attribute names modelCars and male,
and the object name john has the intent {modelCars, male, P Cgames} and the
extent {john, max}.
FCA, as it has been described so far, can only deal with binary attributes.
For real data, the situation is usually dierent: Attributes assign specic values
(which might be strings, numbers, etc) to data. For example, RDF-triples (s, p, o)
are exactly of this form: The attribute p - from now on we will use the RDF-term
property instead- assigns the value o to the entity s. In FCA, a process called
conceptual scaling is used to deal with this issue.
Let a specic property be given with a set of possible val-
ues. A conceptual scale is a specic context with the values sex age
of the property as formal objects. The choice of the formal Adam m 21
attributes of the scale is a question of the design of the Betty f 50
scale: The formal attributes are meaningful attributes to Chris 66
describe the values; they might be dierent entities or they Dora f 88
might even be the values of the property again. To exem- Eva f 17
plify conceptual scaling, we reuse a toy example from [15], Fred m
which is the following table provided on the right with two George m 90
many-valued properties sex and age. Note that empty Harry m 50
cells are possible as well.
Next, two conceptual scales for the properties sex and age and their line
diagrams are provided.
S2 < 18 < 40 65 > 65 80
17
S1 m f 21
m 50
f 66
88
90
With conceptual scales, the initial many-valued context can be transformed

into a standard context, so that the corresponding concept lattice can be dis-
played.
For conceptual scales, the following two points should be noted:
1. There is no standard or even neccessary interpretation of an attribute: It has

to be decided by the eld expert which scale is appropriate. As discussed in
[2], this is indeed not a drawback, but an advantage of FCA.
2. Conceptual scales do not depend on the real data, but only on the properties
(and their values, of course) used in the data set. As one can see in the
example, a realized context is derived from the scales and the real data in a
later step after the scales have been created.
Both points are important for ToscanaJ, which is discussed in the next section.
3 ToscanaJ
There is a variety of software for FCA available. Most of them support the cre-
ation of contexts from scratch and the subsequent computation and display of the
corresponding concept lattices. Contrasting this approach, Elba and ToscanaJ
are a suite of mature FCA-tools which allow to query and navigate through
data in databases. They are intended to be a Conceptual Information System
(CIS). CISs are systems that store, process, and present information using
concept-oriented representations supporting tasks like data analysis, informa-
tion retrieval, or theory building in a human centered way. Here, a CIS is an
FCA-based system used to analyze data stored in one table of an RDBMS.
Similar to other BI-systems, in CIS we have to distinguish between a design
phase and a run-time-phase (aka usage phase), with appropiate roles attached
to the phases. In the design phase, a CIS engineer (being an expert for the CIS)
together with a domain expert who has limited knowledge of a CIS) develops
the CIS schema, i.e. those structures which will be later on used to access the
system. This schema consists of manually created conceptual scales. Developping
the scales is done with a CIS editor (Elba) and usually a highly iterative process.
In the run-time phase, a CIS browser (ToscanaJ) allows a user to explore and
analyze the real data in the database with the CIS schema.
The original Elba/ToscanaJ-suite has been developped to analyze data in a
relational table, i.e. a table in a RDBMS or an excel-le. We have extended the
suite in order to be able to access data in a triple store. This extended version of
the suite uses the Sesame framework4 for accessing a triple store and querying
the RDF data therein. It provides two ways of connecting to a triple store over
Sesame. One of them is over HTTP via Apache Tomcat5 , the other one is over
the SAIL API6 . Tomcat is an open source software implementation of the Java
4
See http://www.openrdf.org/doc/sesame2/system
5
See http://tomcat.apache.org/
6
See http://www.openrdf.org/doc/sesame2/system/ch05.html
Servlet and JavaServer Pages technologies by the Apache Software Foundation.

The SAIL API (Storage And Inference Layer) is a low level system API for
RDF stores and inferencers. It is used for abstracting from the storage details,
allowing various types of storage and inference to be used.
In a triple store we do not directly have the notions of tables and columns
like in databases. As table information we use the type information in the triple
store: we treat the objects of triples with the predicate rdf:type as tables. As
column information, we use the predicates relating the subjects of the selected
type to any object. More precisely, in order to detect the columns we get those
subjects of the selected type and retrieve all distinct predicates that relate these
subjects to an object.
The Elba/ToscanaJ-suite provides dierent kinds of conceptual scales. We
have extended three of them namely nominal scales, attribute scales and context
tables in order to act on triple stores.
Nominal scales are the simplest type of scales one can automatically create
in Elba. They are used for properties with mutually exclusive values. For a given
property, the formal attributes of the nominal scale are selected values of that
property. As each object is assigned at most one of these values, the attribute
concepts form an anti-chain, and by denition, the scale cannot reveal any insight
into attribute dependencies. In the example provided in the next section, we
consider a predicate threadStatus for messages, which has the values Answered
and Unanswered. This predicate is modelled as conceptual scale.
Attributes scales oer an attribute centered view which is very close to
classical formal contexts and which allows to create complex scales in an intu-
itive manner. In an attribute list scale, each attribute is a property-value pair,
which is manually selected from the triple store. Moreover, the CIS engineer can
choose between a) ?use only combinations existing in the database? and b) ?use
all possible combination?. If option a) is selected, then the diagram will only
consist of concepts that could be derived from the data in the triple store, thus
the diagram will reveal insights into dependencies between property-value pairs.
If b) is chosen, a diagram of a Boolean lattice of all listed property-value pairs
will be created independent of whether there exists objects in the triple store for
each property-value combination or not.
Context table scales oer the most freedom and power to the CIS engineer.
In context tables, arbitrary labels act as formal attributes. As now, in contrast
to the last two types of scales, no property-value pairs are chosen as attributes, it
has now explicitely to be specied which objects of the data set fulll the formal
attributes. This is done by entering SPARQL expressions, which act as formal
objects, and by entering the incidence relation as well, i.e. the relation which
here relates the formal objects (the SPARQL expressions) to the attributes (the
labels).
4 Use Case
In order to evaluate our approach, we have used a dataset crawled from the
SAP Community Network (SCN). SCN contains a number of forums for SAP
users and experts to share knowledge, or get help on SAP topics and products.
The dataset we have used is taken from the forum Service-Oriented Architecture
(SOA), which contains 2600 threads and 10076 messages. The dataset is anno-
tated by the crawler using ontologies from the NEPOMUK project. The used
ontologies and their meanings are provided below along with short descriptions
taken from the project website7 .
NEPOMUK Information Element Ontology (NIE): The NIE Framework is
an attempt to provide unied vocabulary for describing native resources
available on the desktop.
NEPOMUK le ontology (NFO): The NFO intends to provide vocabulary
to express information extracted from various sources. They include les,
pieces of software and remote hosts.
NEPOMUK Message Ontology (NMO): The NMO extends the NIE frame-
work into the domain of messages. Kinds of messages covered by NMO in-
clude Emails and instant messages.
NEPOMUK Contact Ontology (NCO): The NCO describes contact infor-
mation, common in many places on the desktop.
From these ontologies, our dataset uses the following classes as types:
nie#DataObject: A unit of data that is created, annotated and processed on
the user desktop. It represents a native structure the user works with. This
may be a le, a set of les or a part of a le.
nfo#RemoteDataObject: A le data object stored at a remote location.
nie#InformationElement: A unit of content the user works with. This is a
superclass for all interpretations of a DataObject.
nco#Contact: A Contact. A piece of data that can provide means to identify
or communicate with an entity.
nmo#Message: A message. Could be an email, instant messanging message,
SMS message etc.
For analyzing experience levels of the users of the SOA forum, we used the
Contact type above and created a scale based on the number of posts, number
of questions, number of resolved questions information provided in the data.
We have named users that have less than 50 posts as newbie, users that have
more than 300 posts as frequent, users that have more than 1000 posts as pro,
users that have asked more than 310 questions as curious and people that have
resolved more than 230 questions as problem solver. Note that this scale uses
dierent measures (number of posts, number of questions, numbers of answers).
The concept lattice in Figure 2 shows number of users with the mentioned ex-
perience levels. The diagram clearly displays the sub/super-concept-relationships
between the experience levels, which is one of the main distinguishing features
of visualizing data using concept lattices. E.g. we can read from the lattice that
7
http://www.semanticdesktop.org/ontologies
Fig. 2. Diagram of the scale based on num- Fig. 3. Diagram of the scale based
ber of posts, questions, resolved questions on number of points
curious and professional users are both also frequent users, whereas problem
solvers and newbies are not.
Next, for analyzing experience levels based on the number of points infor-
mation in our dataset we created another scale. This time, as labels we took
contributor types that are ocially dened by SCN as bronze, silver, gold and
platinium contributors, which have more than 250, 500, 1500 and 2500 points
respectively. The concept lattice of this scale is shown in Figure 3. This scale is
a so-called ordinal scale, which means that the formal concepts are ordered as
a chain. This is also easily seen in the concept lattice of this scale. Obviously, a
user that has more than 2500 points also has more than 1500 points, and so on.
The above displayed concept lattices are separately informative about the
properties of forum users, i.e., the rst one about experience levels based on
number of posts, questions and resolved questions, and the second one about
number of points. One of the most powerful techniques of FCA is to com-
bine such lattices to give a combined view of several lattices together, which
is called a nested line diagram. In its simplest form, a nested line diagram is a
concept lattice whose concepts are themselves also concept lattices. Nested line
diagrams allow the user to select a concept and zoom into it to see the lattice
nested in that concept. Figure 4 shows the nested line diagram of the diagrams
in the Figures 2 and 3. Note that the outer diagram is actually the one in Fig-
ure 3. The four bigger circles correspond to the four types of contributors in
that gure. The inner diagrams are the diagram in Figure 2. Figure 5 shows an
excerpt of the nested diagram that corresponds to the node golden contributor,
and Figure 6 shows the inner diagram of this node. Note that the number of
users corresponding to dierent levels of experience in this diagram diers from
that of diagram in Figure 2. The reason is that, now we zoomed into the node
gold contributor so the information in the inner diagram is restricted to the
gold contributors only. For instance, as seen in this diagram there are no new-
bies that are gold contributors, which is quite natural. On the other hand 79 of
the gold contributors are pro users. In ToscanaJ, and thus in our extension of it
Fig. 5. Detail of Figure 4
Fig. 4. Nesting the above two scales Fig. 6. Inner diagram of Fig. 5
to triple stores, one can nest an arbitrary number of diagrams and can browse
nested diagrams easily by zooming in and out.
5 Conclusion and Further Research

We have discussed how FCA can be used as a methodology for analyzing data in
triple stores by extending the Toscanaj suite. As scales in the ToscanaJ workow
are manually crafted in the design phase of a CIS, this workow is feasible for
stable schemata. For ST, this is usually not the case: here the paradigm of agile
schema development is prevalent. As future work we plan to implement auto-
matic or at least semi-automatic generation of scales based both on the schema
information and the actual data in the triple store. existing BI approaches. An-
other future research direction is the development of hybrid solutions, combining
classical BI with FCA. This covers combinations of scales and their diagrams
with BI diagrams for numerical data, like pie charts or sun-burst diagrams, and
compared to nesting of scales, dierent approaches for using simultaneously sev-
eral scales. In our work we have considered RDF models only as simple object-
attribute-value models, ignoring the subclass relationships. As future work we
are also going to work on integrating such knowledge into FCA as background
knowledge for concept lattice computation.
Disclaimer: Parts of this work have been carried out in the CUBIST project,
which is funded by the European Commission under the 7th Framework Pro-
gramme of ICT, topic 4.3: Intelligent Information Management.
References
1. Becker, P., Hereth, J., Stumme, G.: ToscanaJ: An open source tool for quali-
tative data analysis. In: Duquenne, V., Ganter, B., Liquiere, M., Nguifo, E.M.,
Stumme, G. (eds.) Advances in Formal Concept Analysis for Knowledge Discovery
in Databases, FCAKDD 2002 (2002)
2. Dau, F., Klinger, J.: From Formal Concept Analysis to Contextual Logic. In:
Ganter, B., Stumme, G., Wille, R. (eds.) Formal Concept Analysis. LNCS (LNAI),
3. Ganter, B., Wille, R.: Formal Concept Analysis: Mathematical Foundations.
Springer, Berlin (1999)
4. Hereth, J.: Formale begrisanalyse und data warehousing. Masters thesis, TU
Darmstadt, Germany (2000)
5. Hereth, J.: Relational Scaling and Databases. In: Priss, U., Corbett, D., Angelova,
G. (eds.) ICCS 2002. LNCS (LNAI), vol. 2393, pp. 6276. Springer, Heidelberg
(2002)
6. Hereth, J., Stumme, G., Wille, R., Wille, U.: Conceptual knowledge discovery - a
human-centered approach. Journal of Applied Articial Intelligence (AAI) 17(3),
281301 (2003)
7. Lakhal, L., Stumme, G.: Ecient Mining of Association Rules Based on Formal
Concept Analysis. In: Ganter, B., Stumme, G., Wille, R. (eds.) Formal Concept
Analysis. LNCS (LNAI), vol. 3626, pp. 180195. Springer, Heidelberg (2005)
8. Priss, U.: Formal concept analysis in information science. Annual Review of Infor-
mation Science and Technology 40 (2005)
9. Roth-Hintz, M., Mieth, M., Wetter, T., Strahringer, S., Groh, B., Wille, R.: In-
vestigating snomed by formal concept analysis. In: Proceedings of ACM SIGMOD
Workshop on Research Issues in Data Mining and Knowledge Discovery (2000)
10. Scheps, S.: Business Intelligence for Dummmies. John Wiley and Sons Ltd., Chich-
ester (2008)
11. Sertkaya, B.: OntoComP: A Prot e Plugin for Completing OWL Ontologies. In:
e g
Aroyo, L., Traverso, P. (eds.) ESWC 2009. LNCS, vol. 5554, pp. 898902. Springer,
Heidelberg (2009)
12. Stumme, G.: Conceptual on-line analytical processing. In: Tanaka, K., Ghande-
harizadeh, S., Kambayashi, Y. (eds.) Information Organization and Databases. ch.
14. Kluwer, Boston (2000)
13. Stumme, G., Wille, R., Wille, U.: Conceptual knowledge discovery in databases us-
ing formal concept analysis methods. In: Zytkow, J.M., Quafofou, M. (eds.) PKDD
1998. LNCS (LNAI), vol. 1510, pp. 450458. Springer, Heidelberg (1998)
14. Vogt, F., Wille, R.: Toscana a graphical tool for analyzing and exploring data. In:
Tamassia, R., Tollis, I.G. (eds.) GD 1995. LNCS, vol. 1027, pp. 226233. Springer,
Heidelberg (1996)
15. Wol, K.E.: A rst course in formal concept analysis. In: Faulbaum, F. (ed.) Pro-
ceedings of Advances in Statistical Software, vol. 4, pp. 429438 (1993)
Semantic Cockpit: An Ontology-Driven,
Interactive Business Intelligence Tool for
Comparative Data Analysis
Bernd Neumayr1 , Michael Schre1 , and Konrad Linner2

1
Department of Business Informatics - Data & Knowledge Engineering
Johannes Kepler University Linz, Altenberger Strae 69, 4040 Linz, Austria
2
solvistas GmbH, R omerstrae 18/1, 4020 Linz
Abstract. Business analysts frequently use Cockpits or Dashboards

as front ends to data warehouses for inspecting and comparing multi-
dimensional data at various levels of detail. These tools, however, per-
form badly in supporting a business analyst in his or her business
intelligence task of understanding and evaluating a business within its
environmental context through comparative data analysis. With impor-
tant business knowledge either unrepresented or represented in a form
not processable by automatic reasoning, the analyst is limited in the
analyses that can be formulated and she or he heavily suers from in-
formation overload with the need to re-judge similar situations again
and again, and to re-discriminate between already explained and novel
relationships between data. In an ongoing research project we try to over-
come these limitations by applying and extending semantic technologies,
such as ontologies and business rules, for comparative data analysis. The
resulting Semantic Cockpit assists and guides the business analyst due
to reasoning about various kinds of knowledge, explicitly represented
by machine-processable ontologies, such as organisation-internal knowl-
edge, organisation external domain knowledge, the semantics of measures
and scores, knowledge about insights gained from previous analysis, and
knowledge about how to act upon unusually low or high comparison
scores. This paper outlines the architecture of the Semantic Cockpit and
introduces its core ideas by a sample use case.
1 Introduction
Comparative analysis of data gathered about past business activities is one of the
critical initial steps by a business analyst in her or his business intelligence task of
understanding and evaluating a business within its environmental context. Data
warehouse (DWH) technology for collecting and processing relevant data and ac-
companying On-Line-Analytical-Processing (OLAP)-Tools support the business
analyst to analyze and compare data aggregated over various dimensions (such
as time, location, product group). Dashboards and cockpits have been developed

SemCockpit is a collaborative research project funded by the Austrian Ministry of
Transport, Innovation, and Technology in program FIT-IT Semantic Systems and
Services. The project started in March 2011 and will end in August 2013.

56 B. Neumayr, M. Schre, and K. Linner
recently as front end tools for data warehouses that allow the business analyst to
predene and interactively select analysis reports and to build alert mechanisms
into user interfaces. These tools assist him through dierent kinds of graphs to
interactively inspect aggregated measures (e.g., average number of prescriptions
per patient) related to group of entities of interest (e.g., general practitioners)
and to compare these against corresponding measures of one or multiple peer (or
comparison) groups, potentially also through a normalized score, visualized by a
gauge indicating the result of this comparison. Thereby, he identies opportuni-
ties and problems, explores possible causes, or discovers interesting phenomena
(relationships between data). His comparative analysis may lead immediately to
insights that can be used for strategy formulation or implementation, or may
trigger further analysis by dedicated data mining tools, whereby the insights
gained so far help him to guide the formulation of the right analysis questions.
Unintelligent Cockpits oer only limited support to the business analyst for
his comparative analysis. With important meta knowledge unrepresented or rep-
resented in a form not processable by automatic reasoning, he is limited in the
analysis that can be formulated and his success entirely depends on his domain
knowledge as business expert. Some simple examples: The analysis compare
the prescription habits of general practitioners in tourist regions to other prac-
titioners in relation to the percentage of prescribing generic drugs vs. innovator
drug X cannot be formulated if domain knowledge about pharmacology is not
represented in machine-processable form. New concepts, even as simple as gen-
eral practitioners in tourist regions, are not easy to formulate, if expressible at
all. Judging scores comparisons of u medications across months requires the
background knowledge that sales of u medications are typically 30 % higher in
winter months. Business analysts have to deal with a lot of data and commonly
have insucient personal experience to guide themselves during the process of
information selection and interpretation [9]. It is up to the business analyst to
discriminate between usual phenomena and interesting situations that may give
rise to further action or need further analysis; moreover, similar results re-appear
all the time, overloading analysis results with already explained usual phenom-
ena such that he may unnecessarily repeat further analysis steps.
The Semantic Cockpit assists and guides the business analyst in dening
analysis tasks, discriminating between usual phenomena and novel interesting
situations to be followed up to avoid him being drown in information, and rec-
ommending actions or indicating further analysis steps that should be applied to
follow up interesting situations. The Semantic Cockpit is an intelligent partner of
the business analyst due to reasoning about various kinds of knowledge, explic-
itly represented by machine-processable ontologies such as: organization-internal
knowledge (e.g., denitions of concepts corresponding to business terms such
as weekend and evening visits), organization external domain knowledge (e.g.,
about medications or illnesses), the semantics of measures and measure values
(i.e., about upon what possible groups of interests a measure may be dened
and which particular group of interest a measure value describes), the semantics
of scores (i.e., what measure about a group of interest is scored against which
group of comparison along what dimension), knowledge about insights gained
from previous analysis (e.g., typical percentage of higher sales of u medications
in winter months), and knowledge about how to act upon a striking low or high
Semantic Cockpit 57
comparison score (e.g., initiate further analysis or recommend actions such as

an additional training for pharmacists).
The paper is structured as follows: in Sec. 2 we introduce the overall archi-
tecture of the Semantic Cockpit framework and introduce a show case from the
health insurance industry. In Sec. 3 we describe the Semantic Cockpit process.
In Sec. 4 we describe cockpit design and analysis by a use case. In Sec. 5 we give
a concise overview of related work. Sec. 6 concludes the paper with an overview
of the current state of the project.
2 Architecture and Sample Analysis Task

The left hand side of Fig. 1 illustrates the work of a business analyst with a con-
ventional OLAP-frontend to a data warehouse, while the right hand side shows
the setting and components of the Semantic Cockpit. In the former, the analyst
poses various OLAP queries against the data warehouse to inspect and compare
data from various perspectives at dierent detail with the aim to discover in-
teresting deviations or abnormalities that give rise to new insights about how
the business functions, potential drivers of best-practice examples or deciencies
in the organization, such as potential fraud. The cockpit itself is un-intelligent.
The business analyst brings in all required knowledge and is unassisted in com-
bining it with the data in the data warehouse: He must manually link domain
knowledge (e.g. about therapeutical drugs) to data in the data warehouse (and
cannot link both in one query), must re-formulate similar queries all the time
as the cockpit does not assist him what kinds of measures and scores previously
dened may be re-used (as such or modied) in a new context, must remember
previous insights to orientate himself in the bulk of information provided, must
remember previously encountered situations to discriminate whether a just dis-
covered deviation in data is already covered by similar previous insights, and he
must remember whether this deviation can be justied by given, unchangeable
environment conditions or may give rise to strategic action. Apart from the pos-
sibility to inspect data, he is unassisted by the OLAP-frontend in preparing an
analysis report for management.
The right hand side of Fig. 1 illustrates the work of a business analyst with
the Semantic Cockpit and the cockpits main components. The Semantic Cockpit
is an intelligent partner of the business analyst. It has access to various machine-
readable sources of knowledge formerly known only by the business analyst and
now assists the cockpit in intelligently interacting with him: a domain ontology
comprises individuals corresponding to entities in the data warehouse and link-
ing to concepts of (imported) ontologies (e.g., an external drug ontology such
as the Australian Medicines Terminology 1 ), a multi-dimensional measure and
score ontology describing the semantics of measures and scores based on con-
cepts dened upon the domain ontology, a judgment rule ontology that captures
knowledge about previous insights gained and related actions.
In Sec. 4 we will explain the functioning of the cockpits major components
(Multi-Dimensional-Ontology (MDO) Engine, Semantic Cockpit Frontend, and
1
http://www.ehealthinfo.gov.au/vendors/clinical-terminologies/
australian-medicines-terminology/
General Expertise General Expertise + asdf asdf

dfdse sdf
+ ujuki kkk
Previous Insights + jkili jkklj

asd ddd d
Knowledge
+ asdf ddd
Judgement Knowledge
Domain
p d
Business Analyst Manager
?
+ asdf asdf + asdf asdf
Query dfdse sdf dfdse sdf new
Templates insights
Business Analyst Manager

Judgement
Semantic Cockpit Frontend Rules
?
MultiDimensional Ontology (MDO) Measure &
Engine
Score Ontology
Ontology Ontology
Rule Engine
Reasoner Manager
OLAP Tool Domain
MDODWH Mapper Ontology
DWH DWH
Fig. 1. Conventional Comparative Data Analysis (left) vs. Semantic Cockpit: Setting
& Components (right)
MDO-DataWareHouse Mapper ) together with a step-by-step description of the

interaction of the business analyst with the Semantic Cockpit using the following
simplied show case:
Upper Austrian Public Health Insurance wishes to increase the percentage
of prescriptions of low-priced Psychotropic Drugs with indication anti depres-
sion during 2009 by General Practitioners in medium-to-large cities in Upper
Austria and asks the business analyst to prepare a comparative analysis report
and, if possible, recommend strategic or operational actions. Notice that such
open-ended analysis questions tied to specic kinds of drugs, groups of doctors,
and locations are common in a health insurance setting and, at such early state
of investigation, are usually not solved by specic data mining tools (But these
may be well used in later stages of an investigation when particular mining
tasks can be formulated based on results from the preceding open-ended analy-
sis). Such an open-ended analysis will, for example, comprise comparisons of a
group of interest (prescriptions of low-priced Psychotropic Drugs with indication
anti depression of 2009 in Upper Austria in medium-to-large cities) against
several groups of comparison, by generalizing or varying the dimensions (e.g.,
from Upper Austria to Austria, or from 2009 to 2008) to gain insights based on
studying in detail from various perspectives the data tied to striking dierences
encountered.
3 Semantic Cockpit Process

Fig. 2 shows a selection of the ontologies of our sample Semantic Cockpit and
indicates the process back-stage of the use case described in Sec. 4.
Semantic Cockpit 59
Domain Ontology Measure & Score Ontology

Dimensions&Facts Concepts Measure Schemata
Level: drug Concept: mediumtolargecity MeasureSchema: percentageOfCheapAntiDepressionDrugs 3
rollsUpTo: druggroup Level: city Scope: (AllLocation, AllPrescriber, Psychotropic, AllTime)
FactClass: prescription EquivalentTo: inhabitants only qualifiedBy: (drug: mainindication=depression)
Dimensions: (location, integer[>= 30000] Instructions:
prescriber, medication, time) 2 Concept: lowpriceddrug nrOfPrescriptions(drug: lowpriceddrug) / nrOfPrescriptions
BaseLevels: (city, doctor, drug, Level: drug MeasureSchema: nrOfPrescriptions
month) ... Scope: (AllLocation, AllPrescriber, AllMedication, AllTime)
... Instructions: COUNT prescription
Individual: Prozac Ontology Imports and Mappings
Level: drug Prefix: snomed: < .../snomeddrugs.owl> Measure Instances
rollsUpTo: Psychotropic Import: < .../snomeddrugs.owl> MeasureInstance: percentageOfCheapAntiDepressionDrugs
Individual: Psychotropic EquivalentClasses: drug, snomed:Drug Scope: (UpperAustria, GeneralPractitioner, Psychotropic, 2009)
Level: druggroup EquivalentClasses: Psychotropic[drug], qualifiedBy: (city: mediumtolargecity,
4
... snomed:psychoactivedrug drug: mainindication=depression)
Value: 27
1
7
5 (1) Initial mapping of dimensions (schema + instance) and
DWH
facts (schema) from DWH to MDO.
SELECT (2) Semantic enrichment with internal concepts and
time country ( SELECT COUNT(*) FROM groupOfInterest external ontologies.
year state WHERE checkMDO(drug, $lowpriceddrug$) 6 (3) Definition of measureschemata using the cockpit
city / ( SELECT COUNT(*) FROM groupOfInterest) desing view and
month location FROM (SELECT prescription (4) definition of measureinstances using the cockpit data
WHERE checkMDO(drug, $mainindication=depression$) analysis view (scope restrictions inherited from measure
prescription AND checkMDO(city, $mediumtolargecity$) schema are shown in grey).
AND state = UpperAustria (5) Mapping from MDO Measures to SQL (or similar).
drug doctor
AND doctorgroup = GeneralPractitioner (6) Ontologyconcepts need to be expanded.
AND year = 2009 (7) Query Execution by the conventional Data Warehouse
druggroup doctorgroup
AND druggroup = Psychotropic) AS groupOfInterest. and return of measure instance value.
medication prescriber
MDOSyntax is loosely based on OWLManchester Syntax (see http://www.w3.org/TR/owl2manchestersyntax/)
Fig. 2. Semantic Cockpit Process (simplied, without Scores and Judgement Rules)
The Domain Ontology is initialized by mapping the schema of the data

warehouse into an ontological representation, abstracting from specic data
warehouse details. While dimension instances (entities) and the roll-up hierarchy
of dimension instances are also included in the ontology, facts reside only in the
data warehouse. This initial Domain Ontology is enriched by additional Concepts
(such as medium-to-large-city) that constitute business-relevant subsets of entities
of one dimension level and by links to external ontologies. In our example, the
OWL class psychoactive-drug in the external drug ontology is equivalent to the de-
scendents of drug group Psychotropic at level drug (notated by Psychotropic[drug]).
The measure ontology shows a multi-dimensional ontology representation of the
measure schema dened by the analyst.
A measure schema consists of a scope that is given by a qualied multi-
dimensional point, i.e., a cross product of individuals (dimension instances in
the DWH) optionally with one or more qualiers that are concepts or ontolog-
ical expressions over concepts at some dimension level beneath the indicated
multi-dimensional point, and of measurement instructions. The measure is de-
ned for every multi-dimensional point subsumed by the scope.
The measurement dened by the business analyst is represented as mea-
sure instance in the md-measure ontology. To calculate the measure value, the
Ontology-DWH Mapper takes this measure instance together with the measure
schema (and its ontological representation of the associated measurement in-
structions) as input and translates it into an OLAP query with evaluation calls
for embedded ontological predicates. This OLAP query is evaluated against the
Data Warehouse after ontological predicates have been evaluated in interaction
with the MDO engine (see Fig. 2).
4 Sample Use Case of Cockpit Design and Analysis
We will now describe step-by-step how the business analyst interacts with the
Semantic Cockpit and how the Semantic Cockpit exploits its knowledge to in-
telligently support the analyst using our sample analysis task.
First, the business analyst opens the Cockpit Design View (see Fig. 3), which
is partitioned into ve parts: the Measure Denition Board, the Score Denition
Board, the Judgment Rule Board, the Domain Ontology Context View, and the
Measure and Score Ontology Context View.
Measure: percentageOfCheapAntiDepressionDrugs Measure Definition Board
Location: Prescriber Medication: Time:

Scope: AllLocation AllPrescriber Psychotropic AllTime
qualifiedBy: mainindication =
depression
Measurement Instructions
nrOfPrescriptions (unrestricted) (unrestricted) lowpriced drug (unrestricted)
/
nrOfPrescriptions (unrestricted) (unrestricted) (unrestricted) (unrestricted)
Score: Score Definition Board

percentage difference scaled to 0100
Rule: recommendTraining Judgement Rule Board

Situation: Scope (interest): AllLocation GenPractitioner Psychotropic AllTime
Scope (application): Comparison across dimension Prescriber against Neurologist
Condition: score < 20 Action: ! The low score is probably and should be acted upon by respective training courses.
Context: Medication Domain Ontology Context View Measure & Score Ontology Context View
drug druggroup Applicable Measure Schemata:
Individuals: Concepts: Individuals: nrOfPrescriptions

Celexa drug Psychotropic Scope: (AllLocation, AllPrescriber, AllMedication, AllTime)
Lexapro ...
Prozac lowpriceddrug
Instructions: COUNT prescription
...
... ...
... ... ...
Applicable Score Schemata:
Properties: SNOMED Drug
mainindication Ontology drug
... psychoactive ...
drug
...
anesthesia analgesic
Fig. 3. Cockpit Design View (simplied)
In our case, the business analyst wishes to dene a general measure percentage-
OfCheapAntiDepressionDrugs for psychotropic drugs that have its main indication
anti depression for all locations, all prescribers, and all times. To dene this
scope, he moves down in the Measure Denition Board in the Drug Dimension
from the top-most multi-dimensional point of all dimensions to (All-Location, All-
Prescriber, Psychotropic, All-Time) and adds the qualication main indication = anti
depression upon selecting the role main-indication from the properties presented for
drug group Psychotropic (which corresponds to psychoactive-drug in the external
drug ontology) in the Ontology Context View. For future use, he may dene a
new concept AntiDepressionPsychotropic for this qualication that will be added
and correctly placed into the domain ontology by the Ontology Manager (If that
concept had been dened previously, the business analyst would have seen it in
the Ontology Context View for possible selection).
Semantic Cockpit 61
After having dened the scope of interest for the measure, the business an-
alyst species the measurement instructions. He checks the Measure and Score
Ontology Context View for measures already dened for the scope of interest.
In our simple case this view contains the measure nrOfprescriptions. He drags this
measure into the Measurement Instructions section of the Measure Denition
Board and further specializes the measure by adding qualication LowPricedDrug
from the Domain Ontology. To calculate the percentage, he drags the measure
nrOfPrescriptions once more into the Measure Denition Board and indicates that
the value of the main measure is the ratio of both submeasures.
Next, the business analyst denes in the Score Denition Board a score to be
used for comparing (based on the dened measure) a specic group of interest
(in the scope of the measure) against some specic group of comparison. In
our simple example, the business analyst selects the predened scoring function
percentageDierence and scales the score value to [0,100].
The Judgement Rule Board will be explained later.
The business analyst moves to the Cockpit Data Analysis View (see Fig. 4),
that is partitioned into four parts: the Control Board, the Score Board, the Mea-
sure Board, and the Domain Ontology Context View, to apply measure percent-
ageOfCheapAntiDepressionDrugs to a particular group of interest within the scope
of the measure. In the Control Board the business analyst can narrow down
the group of interest as required for his specic analysis. For our analysis task
the business analyst moves in the location dimension from All-Locations to Upper-
Austria and in the doctor dimension from All-Doctors to GenPractitioner to multi-
dimensional point (UpperAustria, GenPractitioner, Psychotropic, All-Time) and selects
additional qualication medium-to-large-city from the domain ontology about lo-
cations using the Ontology Context View (not shown expanded in Fig. 4 but as
in Fig. 3).
Measure: percentageOfCheapAntiDepressionDrugs Control Board

Location: Prescriber: Medication: Time: Value: 47 %
Group of Interest: UpperAustria GenPractitioner Psychotropic 2009 Score: 17
qualifiedBy: mediumtolarge mainindication =
city depression ?!
The low score is
Group of Comparison: UpperAustria Neurologist Psychotropic 2009 probably due to lack of training
mediumtolarge mainindication = and should be acted upon by
city depression
respective training courses.
Score Board Measure Board Domain Ontology Context View
Fig. 4. Cockpit Data Analysis View (simplied; Score Board, Measure Board and Do-
main Ontology Context View unexpanded)
Scoring, i.e., determining a comparison score of a group of interest against a

group of comparison, is performed in basically the same way as outlined above
for measuring. The business analyst selects in the Control Board a group of
comparison that is to be compared against the previously selected group of
interest by indicating the variation in the scope of interest through moving up
or to siblings in one or several dimensions. In our example, the business analyst
compares general practitioners against neurologists. A score instance (consisting
of measure, group of interest and group of comparison) is generated by the MDO
engine (whereby the Ontology Reasoner determines the scope of comparison

from the scope of interest and the indicated variation), and translated by the
MDO-DWH mapper into an OLAP query to calculate the score (not shown in
Fig. 4).
Typically, the business analyst will perform several single- or multi-variant
comparisons, e.g., across location, prescriber, or time, and use the Score Board
to drill down in scores (e.g., showing how each state scores in a nation-wide
comparison) or the Measure Board to drill down in measures as known from
conventional dashboards. Dierent to conventional dashboards, however, the Se-
mantic Cockpit Frontend may be congured through generic guidance rules to
automatically drill down in scores (by interacting with the MDO-Engine) based
on a resulting low or high comparison score, e.g. to state level, if a nationwide
comparison of Upper Austria resulted in a striking score.
Our scoring example already gives a possible explanation for the low score of
general practitioners against neurologists (lack of training) and recommends an
action (oering training courses). This will not be the case when the business
analyst encounters such a situation for the rst time. Then the business analyst
may reason that general practitioners may be less trained than neurologists and
might, therefore, dierentiate less between descriptions of various kinds of anti
depression drugs. For future analysis (in other years or at other locations) the
business analyst decides to add a generic judgment rule recommendTraining to
the knowledge base expressing that low scores of general practitioners in cross-
doctor group comparisons to neurologists of prescribing low-priced anti depres-
sion drugs may be due to lack of training and should be acted upon by respective
training courses . He uses the Judgment Rule Board (see Fig. 3) to dene that
rule, by identifying the scope of the situation through a scope of interest (in
the same way as explained above for measures) and a scope of application that
indicates the comparison group(s) for which the rule is applicable. In our case,
the scope of the situation is given by the multi-dimensional point of the mea-
sure schema percentageOfCheapAntiDepressionDrugs, (All-Locations, GenPractitioner,
Psychotropic, All-Times). The situation should be relevant only for comparisons in
the prescriber dimension against neurologists (but not for comparisons in the
location or time dimension). The business analyst states this in that he denes
the scope of application to be comparisons in the dimension prescriber against
Neurologist. He then denes the condition of the rule to be a score value below
20 and the action. If in later analysis, in another year for the same or a dierent
state, apart from these dierences, the same situation occurs as just analyzed,
the judgment rules res and the score will be annotated by the previous nding.
For this, the Cockpit Engine will forward the situation and comparison at hand
to the Rule Engine, which will use the Ontology Reasoner for classifying the
situation and comparison at hand to determine whether the rule is applicable.
If it is applicable and the condition holds as well, it will report the action to
the Cockpit Engine. In a more advanced setting, such a judgment rule may be
congured to monitor the DWH continuously or at predened intervals or pre-
dened events and automatically prepares a report to management, consisting
of score and measure diagrams together with recommended actions.
Typical actions of judgment rules are: to explain a striking high or low compar-
ison score; to recommend strategic or operational action upon a low score (such
Semantic Cockpit 63
as initiating a fraud inspection); or to recommend a further problem analysis by

experts to nd possible drivers for high or low performance against comparison
groups. Only the situation that a low or high score is still unexplained, requires
further study by the business analyst; thus, he is guided in his analysis by the
insight gained so far, shielded from information overload and can concentrate
his eort on following up situations unexplained so far.
5 Related Work
The Semantic Cockpit is based on multidimensional modeling at the conceptual
level (an issue extensively discussed in the literature, with the Dimensional Fact
Model [3] being our main reference) enriched by the explicit representation of
and reasoning with additional knowledge, such as domain knowledge represented
in ontologies, semantics of derived measures and scores, and previous insights
represented as judgement rules.
Combining ontologies and multidimensional modeling has been discussed from
dierent perspectives and with dierent applications in mind: Nebot et al. [5] pro-
pose Multidimensional Integrated Ontologies as a basis for the multidimensional
analysis of Semantic Web data. Romero and Abell o [8] introduce an approach
to derive a multidimensional conceptual model starting from domain knowledge
represented in ontologies. Khouri and Bellatreche [4] introduce a methodology for
designing Data Warehouses from ontology-based operational databases. Niemi
and Niinim aki [6] discuss how ontologies can be used for reasoning about sum-
marizability in OLAP. Sell et al. [9] focus on using ontologies as a means to
represent data in business terms in order to simplify data analysis and cus-
tomizing BI applications. Baader and Sattler [1] and Calvanese et al. [2] extend
Description-Logics-based ontologies with aggregation functions.
Conceptual modeling and reasoning with (derived) measures and scores has
not received much attention so far, however it is related to the work of Pardillo
et al. [7], which extends OCL for dening OLAP queries as part of conceptual
multidimensional models.
The interplay of rules and ontologies was subject of the REWERSE
project (http://rewerse.net) and is subject of the ongoing ONTORULE
project (http://ontorule-project.eu/). The representation and reasoning
over multi-dimensional situation-condition-action rules representing interesting
relationships between compared data, as it is required to represent judgment
knowledge in the Semantic Cockpit, has not been researched so far.
6 Conclusion
In this paper we outlined the components and usage of the Semantic Cockpit,
which is developed in an ongoing cooperative research project (see footnote on
page 1).
We implemented a rst proof-of-concept prototype that we use together with
our partners from health insurance industry to study detailed requirements and
performance issues and to further revise and extend the architecture and basic
approach presented in this paper.
In the remaining phases of the project till 2013 we will investigate and im-
plement language constructs and reasoning techniques for measure & score on-
tologies and judgement rules, together with their mapping to the database level.
We will investigate the complexity and performance of the dierent reasoning
tasks, the costs of integrating external ontologies, problems with the quality of
external ontologies and the possibility to further automate design and analysis
tasks.
We expect that the Semantic Cockpit leads to higher-quality analysis re-
sults and signicant cost savings. We will validate the expected quantitative and
qualitative improvements by eld studies carried out with end-users from health
insurance industry.
References
1. Baader, F., Sattler, U.: Description logics with aggregates and concrete domains.
Inf. Syst. 28(8), 9791004 (2003)
2. Calvanese, D., Kharlamov, E., Nutt, W., Thorne, C.: Aggregate queries over ontolo-
gies. In: ONISW 2008: Proceeding of the 2nd International Workshop on Ontologies
and Information Systems for the Semantic Web, pp. 97104. ACM, New York (2008)
3. Golfarelli, M., Maio, D., Rizzi, S.: The dimensional fact model: A conceptual model
for data warehouses. Int. J. Cooperative Inf. Syst. 7(2-3), 215247 (1998)
4. Khouri, S., Bellatreche, L.: A methodology and tool for conceptual designing a data
warehouse from ontology-based sources. In: Song II, Y., Ordonez, C. (eds.) DOLAP,
pp. 1924. ACM, New York (2010)
5. Nebot, V., Llavori, R.B., Perez-Martnez, J.M., Aramburu, M.J., Pedersen, T.B.:
Multidimensional integrated ontologies: A framework for designing semantic data
warehouses. J. Data Semantics 13, 136 (2009)
6. Niemi, T., Niinim aki, M.: Ontologies and summarizability in olap. In: SAC, pp.
13491353 (2010)
7. Pardillo, J., Mazon, J.-N., Trujillo, J.: Extending ocl for olap querying on conceptual
multidimensional models of data warehouses. Inf. Sci. 180(5), 584601 (2010)
8. Romero, O., Abell o, A.: A framework for multidimensional design of data warehouses
from ontologies. Data Knowl. Eng. 69(11), 11381157 (2010)
9. Sell, D., da Silva, D.C., Beppler, F.D., Napoli, M., Ghisi, F.B., dos Santos Pacheco,
R.C., Todesco, J.L.: Sbi: a semantic framework to support business intelligence. In:
Duke, A., Hepp, M., Bontcheva, K., Vilain, M.B. (eds.) OBI. ACM International
Conference Proceeding Series, vol. 308, p. 11. ACM, New York (2008)
A Model-Driven Approach for Enforcing
Summarizability in Multidimensional Modeling
on1 , Jens Lechtenb

Jose-Norberto Maz orger2, and Juan Trujillo1
1
Lucentia, Dept. of Software and Computing Systems, University of Alicante, Spain
{jnmazon,jtrujillo}@dlsi.ua.es
2
Dept. of Information Systems, University of M
unster, Germany
lechten@wi.uni-muenster.de
Abstract. The development of a data warehouse system is based on

a conceptual multidimensional model, which provides a high level of
abstraction in the accurate and expressive description of real-world
situations. Once this model has been designed, the corresponding log-
ical representation must be obtained as the basis of the implemen-
tation of the data warehouse according to one specic technology.
However, there is a semantic gap between the dimension hierarchies
modeled in a conceptual multidimensional model and its implementa-
tion. This gap particularly complicates a suitable treatment of sum-
marizability issues, which may in turn lead to erroneous results from
business intelligence tools. Therefore, it is crucial not only to capture ad-
equate dimension hierarchies in the conceptual multidimensional model
of the data warehouse, but also to correctly transform these multidi-
mensional structures in a summarizability-compliant representation. A
model-driven normalization process is therefore dened in this paper to
address this summarizability-aware transformation of the dimension hi-
erarchies in rich conceptual models.
1 Introduction
Business intelligence tools, such as OLAP (On-Line Analytical Processing) tools

depend on the multidimensional (MD) structures of a data warehouse that al-
low analysts to explore, navigate, and aggregate information at dierent levels
of detail to support the decision making process. Current approaches for data
warehouse design advocate to start the development by dening a conceptual
model in order to describe real-world situations by using MD structures [13].
These structures contain two main elements. On one hand, dimensions which
specify dierent ways the data can be viewed, aggregated, and sorted (e.g., ac-
cording to time, store, customer, product, etc.). On the other hand, events of
interest for an analyst (e.g., sales of products, treatments of patients, duration
of processes, etc.) are represented as facts which are described in terms of a
set of measures. Every fact is based on a set of dimensions that determine the
granularity adopted for representing the facts measures. Dimensions, in turn,
are organized as hierarchies of levels that allow analysts to aggregate data at

66 J.-N. Maz
on, J. Lechtenb
orger, and J. Trujillo
dierent levels of detail. Importantly, dimension hierarchies must ensure sum-

marizability, which refers to the possibility of accurately computing aggregate
values with a coarser level of detail from values with a ner level of detail. If
summarizability is violated, then incorrect results can be derived in business
intelligence tools, and therefore erroneous analysis decisions [3,4]. In addition,
summarizability is a necessary precondition for performance optimizations based
on pre-aggregation [10].
Usually, summarizability are not solved at the conceptual level, but at late
stages of the development by using information from the data contained in the
implemented data warehouse [11,9]. This way of proceeding poses problems to
data warehouse designers, since great eorts are required to ensure summariz-
ability due to the huge amount of data stored. However, if one tries to ensure
summarizability at the conceptual level, one typically obtains MD models that
are more dicult to understand as they contain an excessive amount of detail
that is not required in the initial design steps. As understandability must be one
inherent property of conceptual MD models, designers should be able to specify
rich conceptual models without being concerned with summarizability problems.
Then, a normalization process should be applied to transform the designed MD
model into a constrained conceptual model, which is restricted to those MD
structures that do not violate summarizability. This normalized model should
also provide a high level of expressiveness in describing real-world situations.
Bearing these considerations in mind, in this paper, we take advantage of
model-driven development to propose a comprehensive normalization process by
using widely adopted formalisms. In essence, we describe how to (i) design dif-
ferent kinds of dimension hierarchies in a conceptual model in order to easily
and understandably represent real-world situations regardless of summarizability
problems, and (ii) automatically derive equivalent normalized conceptual mod-
els, which are constrained to those kind of dimension hierarchies that do not
violate summarizability. From this normalized MD model, an implementation
that satises summarizability can be easily deployed in any database platform
and can be accurately queried by any business intelligence tool.
The rest of this paper is structured as follows. Related work is described in
Section 2. Our normalization process for ensuring summarizability in dimension
hierarchies is presented in Section 3. Finally, conclusions and potential for future
work are provided in Section 4.
2 Related Work
In [9] we present a survey on summarizability issues in MD modeling. Briey, MD

modeling aims to represent measurable facts for real-world events under dierent
perspectives of detail, which are specied via dimensions. For example, using the
UML prole for MD modeling proposed in [5], Fig. 1 represents Sales via a Fact
Y
Z
( ) class and Date, Product, and Customer via Dimension ( ) classes. Facts are
X
composed of measures or fact attributes, which are represented as attributes with

the FactAttribute stereotype (FA) such as Price and Quantity in Fig. 1. Moreover,
A Model-Driven Approach for Enforcing Summarizability in MD Modeling 67
dimension levels, which allow to analyze measures at a specic level of detail, are
specied by Base classes ( B ) such as Day and Week. Associations (represented
by the stereotype Rolls-UpTo, ) between pairs of Base classes form dimension
hierarchies. Importantly, Rolls-UpTo associations between Base classes as well
as associations between Fact and Dimension classes are annotated with UML
multiplicities. E.g., the multiplicities for the association between Country and
Region in Fig. 1 indicate that every region belongs to exactly one country (1
in role r at the Country end) whereas there are countries (such as Andorra,
Monaco, etc.) without associated regions (0..* in role d at the Region end).
Finally, UML generalization relationships between Base classes can be used to
represent optional dimension levels within a hierarchy.
Fig. 1. Sample scenario
In the context of MD data, summarizability presents a guarantee concern-

ing the correctness of aggregated measures. The notion of summarizability was
originally introduced in [12] and later characterized in [4]. As observed in [9],
minimum and maximum multiplicities of associations characterize sub-structures
where summarizability is violated. In earlier work [8], we have shown how to nor-
malize MD schemata with non-summarizable fact-dimension associations into
summarizable ones. With respect to non-summarizable Rolls-UpTo associations,
however, a similar approach still needs to be designed.
Indeed, in a fundamental work Pedersen et al. [10,11] propose instance level
algorithms to automatically transform dimension hierarchies to achieve summa-
rizability. As this proposal works at the instance level, it is necessary to transform
68 J.-N. Maz
on, J. Lechtenb
the data that will populate the DW, which may involve considerable eorts of
preprocessing. In particular, ETL processes become more complex, as summariz-
ability checks must be incorporated and executed for every update. In addition,
as the data transformations produce articial data values, data analysis becomes
more complex.
In [6,7] the authors present a classication of dierent kinds of complex di-
mension hierarchies, and they dene the MultiDimER model for the conceptual
design of complex MD models based on an extension of the well-known Entity-
Relationship (ER) model. The idea is that this classication guides developers
to properly capture at a conceptual level the precise semantics of dierent kinds
of hierarchies without being limited by current data analysis tools. Furthermore,
the authors discuss how to map these conceptual hierarchies to the relational
model (enabling implementation in commercial tools). Unfortunately, the map-
ping between the conceptual and the logical level is described informally. In
addition, the commented mapping is tool-dependent and it may vary depending
on the scenario.
3 Model-Driven Development of Dimension Hierarchies

While a conceptual MD model should represent the real world in a way that
is easy to understand and that supports discussions with end users, a logical
MD model must support the implementation in a chosen target technology
in such a way that data can be accurately analyzed. To bridge this semantic
gap, we propose a model-driven normalization process to derive an intermediate
model, which should still be expressed at the conceptual level (to avoid lim-
itations imposed by particular target models) but where MD structures that
violate summarizability conditions are replaced with summarizable alternatives
(which are typically more precise as we will see below). In particular, we address
the three types of non-summarizable Rolls-UpTo associations enumerated in [9]:
Non-strict, roll-up incomplete, drill-down incomplete
Non-strict associations are those where the maximum multiplicity at role r
is (instead of 1). For example, the association between Week and Month in
Fig. 1 is non-strict, and requires special care to avoid the well-known double
counting problem. Next, an association is drill-down incomplete if the minimum
multiplicity at role d is 0; otherwise, it is drill-down complete. For example,
the association between Country and Region in Fig. 1 is drill-down incomplete
as there are countries (such as Andorra, Monaco, etc.) without associated
regions. As explained in [9] in this case one has to be careful when drilling down
from aggregate values at the level Country towards the level Region as values for
countries without regions may not be accounted for, leading to inconsistent grand
totals. Finally, an association is roll-up incomplete if the minimum multiplicity
at role r is 0. For example, the association between Product and Category in
Fig. 1 is roll-up incomplete. As explained in [9] in this case one has to be careful
when rolling up from aggregate values at the level Product towards the level
Category as values for products that are not assigned to any category will not
be accounted for, leading again to inconsistent grand totals.
In the following subsections, we show how to carry out a normalization process

to obtain a conceptual MD model that ensures summarizability while accurately
capturing the expressiveness of the demanded real-world situation. This process
is composed of a set of transformations to obtain a normalized MD model con-
strained to hierarchies that contain only those elements and relationships that
do not violate summarizability. For the sake of understanding, these transfor-
mations are rst dened informally and only two of them are formally described
in QVT (Query/View/Transformation) due to space constraints.
3.1 Eliminating Non-strictness

Non-strictness is eliminated by one transformation which is based on one QVT
relation (named as nonStrictBases) that replaces all occurrences of non-strict
Rolls-UpTo associations in the source model with constructs that do not violate
summarizability. The rationale behind this QVT relation is as follows. A non-
strict association, i.e., a many-to-many relationship among dimension instances,
represents the least restrictive possible case. In fact, even if no association is de-
clared among Base classes then adding a non-strict (and incomplete) association
does not impose any additional restriction on the instances. E.g., in Fig. 1 every
Product has a Brand and may have a Category. As the relationship among Brand
and Category is not declared explicitly, we may reasonably assume to nd many
Brands associated with the Products for each Category and vice versa. Hence,
we may safely add a non-strict association from Category to Brand without
changing the meaning of the model.
More generally, consider a non-strict association between Base classes b1 and
b2 . On the one hand, this association is redundant and can be removed safely
if there are alternative strict Rolls-UpTo associations to b2 (which is the Base
class that causes the non-strictness). On the other, the association cannot be
removed if the Base class b2 does not play role r in some strict association. In
this latter case, removing the association would isolate b1 from b2 . Moreover, in
this case the instances of b2 are in a many-to-many relationship not only with b1
but also with all Base classes that roll-up from (possibly transitively) b1 . This
many-to-many relation is naturally expressed by moving b2 into a newly created
dimension, which again leads to the removal of the non-strict association.
As an example for a many-to-many relation that should be represented via
a newly created dimension, assume that Products in the scenario of Fig. 1 are
books for which the authors are of interest. Then, we may add the Base class
Author along with a non-strict association from Book to Author (see Fig. 2(a)).
Although such an association allows to represent the relationship between
books and their authors, this relationship is unrelated to the sales of individual
books. Besides, computing sales volumes per author based on that relationship
may easily lead to summarizability problems due to double counting. Hence, our
normalization process removes Author from the Fact class Sales and transforms
the non-strict association into the natural many-to-many relationship of a newly
created fact, in this example into a two-dimensional Fact class NewFact with
Dimension classes Book and Author. As Dimension class Book is common to
70 J.-N. Maz
on, J. Lechtenb
(a) Excerpt of the source model. (b) Excerpt of the target model.
Fig. 2. Newly created dimension for eliminating non-strictness: the Book sales example
both facts, queries involving Sales for Authors are still possible via drill-across
operations. Moreover, to support summarizable queries, the designer may want
to manually add additional measures, e.g., each authors share per book, to the
new fact schema. The target model is shown in Fig. 2(b).
The nonStrictBases relation is shown in Fig. 3(a). It checks that there is a non-
strict Rolls-UpTo association between two Base classes (b1 and b2 ) in the source
model (multiplicity in the role r ) in order to create the appropriate elements in
the target model to obtain a representation without non-strict associations. The
two cases concerning the treatment of non-strict associations explained above
are captured by a condition that must hold to execute this relation (see when
clause of Fig. 3(a)). This condition checks whether Base class b2 plays role r in
some strict association in the source model. On the one hand, if this condition
does not hold then the QVT relation is not launched, and no new Rolls-UpTo
association is created in the target model, since the two Base classes are related
via a many-to-many relationship by default. On the other, if the condition is
satised then b2 does not play role r in some strict association. In this case, a
new Fact class f is created which is associated with two new Dimension classes:
d1 and d2 . Specically, d1 corresponds to the Dimension class related to the
Base classes b1 and b2 of the source model, while d2 is a new Dimension class
whose dening Base class is b2 p (which is a copy of the Base class that causes
the non-strictness in the source model b2 ).
After the execution of the nonStrictBases relation, an excerpt of the target
model related to the Date dimension is shown in Fig. 4(a). Here, the non-strict
Rolls-UpTo association between Month and Week has disappeared, since in this
way both Bases classes are already many-to-many related, and there is no need
for the creation of a new Fact class. The remaining parts of the source model that
do not present non-strictness problems are copied directly to the target model. It
is worth noting that all the possible strict Rolls-UpTo association between Base
classes are assumed to be explicitly modeled in the source model and they will
nonStrictBases
rollUpIncompleteBases
<<domain>>
<<domain>>
fd2: Association
r :Rolls-upTo
pF2: Property pD2: Property

<<domain>> appregation=shared pbD: Property pbR: Property
name = d name = r
s :Rolls-upTo upper = du upper = ru
f: Fact <<domain>>
lower = dl lower = 1
name=NewFact d2: Dimension s :Rolls-upTo
name=n_b2
sD: Property sR: Property b3: Base b2p: Base
MD MD
name = d name = r pF1: Property sD: Property sR: Property name=n_b1+w+n_b2
C E
upper = du upper = * pbD: Property MD MD specific
name = d name = r
lower = dl lower = rl C E
upper = du upper = ru
lower = dl lower = 0 g1: Generalization
fd1: Association
a: Association
b1: Base b2: Base general
name=n_b1 name=n_b2 b1: Base b2: Base b1p: Base
pD1: Property name=n_b1 name=n_b2
pbB: Property general
appregation=shared
g2: Generalization
b2p: Base
d1: Dimension specific
name=n_b2
b4: Base
when name=n_b1+wo+n_b2
s.rollBase().getDrilledDownBases()->size()=0; when
Class(b1.relatedDimension(),d1); Class(b2,b2p);
Class(b2,b2p); Class(b1,b1p);
(a) Eliminating non-strictness. (b) Eliminating roll up incompleteness.
Fig. 3. QVT relations for normalizing hierarchies
also appear in the target model. In this way, analysis capabilities of the source
model are not negatively aected. Anyway, if users would still like to navigate
between aggregate values by means of a non-strict relationship, then a new type
of association could be added to the conceptual model; such navigational arcs,
however, would need special support from implementing OLAP tools and are
beyond the scope of this paper.
With respect to the soundness of the nonStrictBases relation shown in Fig. 3(a)
we focus on the non-strict association of the source model, say association s be-
tween b1 and b2 , which is represented dierently in the target model. We consider
two cases: First, the QVT relation just removes the non-strict association. In this
case, the when clause of the relation assures that b2 is alternatively reachable
via strict Rolls-UpTo associations. Hence, in the target model both Base classes
still belong to a common dimension hierarchy, where all pairs of Base classes are
related via many-to-many relationships by default as we have explained above,
and there is no loss of information when removing the non-strict association.
Second, the QVT relation creates a new Fact class to represent the many-to-
many relationship. In this case, the associations between instances of b1 and b2
of the source model are simply stored as instances of the new Fact class in the
target model. Hence, the information that can be represented under the source
model can also be represented under the target model.
3.2 Eliminating Roll-Up Incompleteness
In line with the general analysis concerning optional properties for conceptual
design in [1] we argue that multiplicities of 0 should be avoided in understandable
conceptual models whenever possible. Instead, we advocate to apply generaliza-
tion for conceptual MD modeling as well. To eliminate roll-up incompleteness,
the transformation is based on one QVT relation that replaces all occurrences
of roll-up incomplete Rolls-UpTo associations in the source model with general-
ization constructs. In this case, the optional Base class (which has multiplicity
0 at the role r ) should be associated with a suitable sub-class in a generalization
72 J.-N. Maz
on, J. Lechtenb
(a) Normalized Date dimension. (b) Normalized Product dimension.
Fig. 4. Examples of normalized hierarchies
between Base classes: one to reect instances with the optional property and
the other one to reect instances without that property.
The corresponding QVT relation (rollUpIncompleteBases) is shown in Fig. 3(b).
It checks roll-up incompleteness in the Rolls-UpTo association between Base
classes in the source model. Specically, if a 0 multiplicity is detected in the role
r of a Rolls-UpTo association s between two Base classes b1 (e.g., Product in
Fig. 1) and b2 (e.g., Category in Fig. 1), then the relation enforces the creation of
new elements in the target model as follows: Two new Base classes b1 p and b2 p
that correspond to the source Base classes b1 and b2 , respectively. In addition,
two new Base sub-classes of b1 p, namely b3 and b4 , are created via new general-
ization relationships g1 and g2 . Here, b3 reects the instances of its super-class
b1 p that are associated with some instance of the optional Base class b2 p, and
b4 reects the remaining instances of b1 p. Furthermore, the roll-up incomplete
association s between b1 and b2 is replaced with a roll-up complete association
r between b3 and b2 p.
After the execution of the rollUpIncompleteBases relation, an excerpt of the
target model related to the Product dimension is shown in Fig. 4(b). Here, two
new Base classes, ProductWCategory and ProductWOCategory, are created to
reect those products that belong to a category or not, respectively. Again, those
parts of the source model that do not present roll-up incompleteness problems
are copied directly to the target model.
With respect to the soundness of the rollUpIncompleteBases relation, we focus
on the roll-up incomplete association of the source model, say association s
between b1 in the role d and b2 in the role r, which is represented dierently
in the target model. First, b1 and b2 are still present in the target model (as
b1 p and b2 p). Moreover, if an instance of b1 is not related to any instance of b2
(which exemplies the incompleteness of the association) then this instance is

simply stored as an instance of the same class under the target model (i.e. b1 p)
and as an instance of its subclass b4 . If, however, an instance i1 of b1 is related
to some instance i2 of b2 in the source model, then in the target model i1 will
be an instance of b1 p and simultaneously an instance of b1 ps sub-class b3 . Now,
this sub-class b3 has a roll-up complete association with b2 p, which allows to
retrieve the associated instance i2 in the target model. Hence, the information
that can be represented under the source model can also be represented under
the target model.
3.3 Eliminating Drill-Down Incompleteness

The transformation that eliminates drill-down incompleteness is based on one
QVT relation that replaces all occurrences of drill-down incomplete Rolls-UpTo
associations with normalized elements Due to space constraints this transforma-
tion is not shown, but the rationale of this QVT relation is removing summa-
rizability problems by using generalization constructs. In this way, the optional
Base class (which has multiplicity 0 at the role d, e.g., Region in Fig. 1) should
be associated with a sub-class in a generalization between Base classes.

Data warehouse designers have to make a great eort in dening dimension
hierarchies that accurately reect real-world situations in a MD model, whilst
summarizability problems are avoided. In this paper, we have described a normal-
ization approach for ensuring that the implemented MD model will be queried
without the summarizability problems derived from the dimension hierarchies.
Following our approach, designers can dene dimension hierarchies that violate
summarizability conditions in a conceptual model by using our UML prole. This
conceptual model reects real-world situations in an understandable way. Later,
several transformations can be applied to automatically obtain a normalized MD
model whose dimension hierarchies do not allow situations that attempt against
summarizability, thus avoiding erroneous analysis of data.
Finally, we remark that the multidimensional normal forms dened in [2],
which formalize quality aspects of MD models, deal with schemata with an
expressiveness that is similar to the one of our normalized models. However,
so far there is no work that considers the denition of such normal forms for
semantically rich conceptual models. As an avenue for future work it appears
attractive to dene normal forms at the level of our normalized model: The
generalization constructs included in this level enable a simplied treatment of
optional levels (in [2], generalization is simulated by a careful application of
context dependencies).
Our planned future work consists of evaluating and giving mechanisms to
deal with the notion of type compatibility for summarizability of [4], which
checks that the statistical function associated with the measure is summarizable
according to the type of the measure and the type of the related dimensions.
74 J.-N. Maz
on, J. Lechtenb
Acknowledgments. This work has been partially supported by the follow-

ing projects: SERENIDAD (PEII-11-0327-7035) from Junta de Comunidades de
Castilla-La Mancha (Spain) and by the MESOLAP (TIN2010-14860) project
from the Spanish Ministry of Education and Science.
References
1. Bodart, F., Patel, A., Sim, M., Weber, R.: Should optional properties be used in
conceptual modelling? a theory and three empirical tests. Info. Sys. Research 12(4),
384405 (2001)
2. Lechtenb orger, J., Vossen, G.: Multidimensional normal forms for data warehouse
design. Inf. Syst. 28(5), 415434 (2003)
3. Lehner, W., Albrecht, J., Wedekind, H.: Normal forms for multidimensional
databases. In: Rafanelli, M., Jarke, M. (eds.) SSDBM, pp. 6372. IEEE Computer
Society, Los Alamitos (1998)
4. Lenz, H.J., Shoshani, A.: Summarizability in OLAP and statistical data bases.
In: Ioannidis, Y.E., Hansen, D.M. (eds.) SSDBM, pp. 132143. IEEE Computer
5. Lujan-Mora, S., Trujillo, J., Song, I.Y.: A UML prole for multidimensional mod-
eling in data warehouses. Data Knowl. Eng. 59(3), 725769 (2006)
6. Malinowski, E., Zim anyi, E.: Hierarchies in a multidimensional model: From con-
ceptual modeling to logical representation. Data Knowl. Eng. 59(2), 348377 (2006)
7. Malinowski, E., Zim anyi, E.: Advanced data warehouse design: From conventional
to spatial and temporal applications. Springer, Heidelberg (2008)
8. Maz on, J.N., Lechtenb orger, J., Trujillo, J.: Solving summarizability problems in
fact-dimension relationships for multidimensional models. In: Song, I.Y., Abell o,
A. (eds.) DOLAP, pp. 5764. ACM, New York (2008)
9. Maz on, J.N., Lechtenborger, J., Trujillo, J.: A survey on summarizability issues in
multidimensional modeling. Data Knowl. Eng. 68(12), 14521469 (2009)
10. Pedersen, T.B., Jensen, C.S., Dyreson, C.E.: Extending practical pre-aggregation
in on-line analytical processing. In: VLDB, pp. 663674 (1999)
11. Pedersen, T.B., Jensen, C.S., Dyreson, C.E.: A foundation for capturing and query-
ing complex multidimensional data. Inf. Syst. 26(5), 383423 (2001)
12. Rafanelli, M., Shoshani, A.: STORM: A statistical object representation model.
In: Michalewicz, Z. (ed.) SSDBM 1990. LNCS, vol. 420, pp. 1429. Springer, Hei-
delberg (1990)
13. Rizzi, S., Abello, A., Lechtenb orger, J., Trujillo, J.: Research in data warehouse
modeling and design: dead or alive? In: Song, I.Y., Vassiliadis, P. (eds.) DOLAP,
pp. 310. ACM, New York (2006)
Repairing Dimension Hierarchies under Inconsistent
Reclassification
Monica Caniupan1 and Alejandro Vaisman2,3

1
Universidad del Bo-Bo, Chile
mcaniupa@ubiobio.cl
2
Universidad de la Republica, Uruguay
avaisman@fing.edu.uy
3
Universite Libre de Bruxelles
Abstract. On-Line Analytical Processing (OLAP) dimensions are usually mod-

elled as a hierarchical set of categories (the dimension schema), and dimension
instances. The latter consist in a set of elements for each category, and relations
between these elements (denoted rollup). To guarantee summarizability, a dimen-
sion is required to be strict, that is, every element of the dimension instance must
have a unique ancestor in each of its ancestor categories. In practice, elements in a
dimension instance are often reclassified, meaning that their rollups are changed
(e.g., if the current available information is proved to be wrong). After this oper-
ation the dimension may become non-strict. To fix this problem, we propose to
compute a set of minimal r-repairs for the new non-strict dimension. Each mini-
mal r-repair is a strict dimension that keeps the result of the reclassification, and
is obtained by performing a minimum number of insertions and deletions to the
instance graph. We show that, although in the general case finding an r-repair
is NP-complete, for real-world dimension schemas, computing such repairs can
be done in polynomial time. We present algorithms for this, and discuss their
computational complexity.
1 Introduction
Data Warehouses (DWs) integrate data from different sources, also keeping their his-
tory for analysis and decision support [1]. DWs represent data according to dimensions
and facts. The former are modeled as hierarchies of sets of elements (called dimension
instances), where each element belongs to a category from a hierarchy, or lattice of
categories (called a dimension schema). Figure 1(a) shows the dimension schema of a
Phone Traffic DW designed for an online Chilean phone call company, with dimensions
Time and Phone (complete example in [2]). Figure 1(b) shows a dimension instance for
the Phone schema. Here, TCH (Talcahuano), TEM (Temuco) and CCP (Concepcion) are
elements of the category City, and IX and VIII are elements of Region. The facts stored in
the Phone Traffic DW correspond to the number of incoming and outgoing calls of a
phone number at a given date. The fact table is shown in Figure 1(c).
To guarantee summarizability [3,4], a dimension must satisfy some constraints. First,
it must be strict, that is, every element of a category should reach (i.e., roll-up to) no
more that one element in each ancestor category (for example, the dimension instance
in Figure 1 (b) is strict). Second, it must be covering, meaning that every member
of a dimension level rolls-up to some element in another dimension level. Strict and

76 M. Caniupan and A. Vaisman
All All All Calls

all
Number Date In Out
Year Region Region N1 Jan 1,07 3 0
IX VIII
N2 Jan 1,07 2 1
Month AreaCode City N3 Jan 1,07 5 5
AreaCode City 45 41 TCH TEM CCP N1 Jan 2,07 8 0
Date Number N2 Jan 2,07 0 3
Number N1 N2 N3 N3 Jan 2,07 5 1
(a) Dimensions schemas (b) Phone dimension instance (c) Fact table
Fig. 1. The Phone Traffic DW (c.f [2])
covering dimensions allow to pre-compute aggregations, which can be used to compute

aggregations at higher category levels, increasing query answering efficiency [5].
Dimensions can be updated to adapt to changes in data sources or modifications
to the business rules [6,7], or even due to errors in the original data. Since strictness
is not enforced in current commercial DW systems, after a dimension update is per-
formed, a dimension instance may become non-strict. Considering that organizational
DWs can contain terabytes of data [1], ensuring strictness of dimensions is crucial for
efficient query answering. As an example, suppose that in Figure 1, the phone number
N2 was incorrectly classified as belonging to Temuco ( TEM) while in fact it belonged
to Concepcion (CCP). The DW administration must re-assign N2 to the correct city, an
operation we denote Reclassication. In the presence of strictness and covering con-
straints, assigning N2 to Concepcion makes the dimension to become non-strict, since
N2 still has 45 as its area code. Thus, while summarizing fact data, we can reach re-
gion IX if we choose the path NumberAreaCode Region, or region VIII if the path
is NumberCityRegion. To fix this inconsistency, a solution could be to move N2 to
the area code 41. There are, however, situations where the solution is not obvious, as we
show in this paper.
At least two approaches to the reclassification problem could be followed: (a) To
prevent reclassification if we know that it can lead to a non-strict dimension [7]. We
denote this consistent reclassification. (b) To allow any reclassification and repair the
updated dimension if it becomes non-strict. Note that, in the general case, the repair
may undo the reclassification, in particular if we are looking for a minimal repair (i.e.,
the repair closest to the original dimension, cf. Section 3). In this paper we study
approach (b), which captures the case when the user defines a reclassification about
which he/she is absolutely sure. Therefore, the new rollup must be taken for certain, and
a dimension instance, consistent with a set of constraints, must be produced by means of
a (possibly minimal) repair that keeps the reclassification. We refer to these repairs as r-
repairs. The r-repaired dimension instance is obtained from D by performing insertions
and deletions of edges between elements. We show that in the general case, finding a
minimal r-repair is NP-hard (Section 3). We also present an algorithm (Section 4) that
obtains an r-repair in polynomial time for the class of dimensions that contain at most
one conflicting level [6] (intuitively, a dimension that can lead to non-strict paths), and
study complexity issues.
Repairing Dimension Hierarchies under Inconsistent Reclassification 77
2 Background and Data Model

A dimension schema S consists of a pair (C, ), where C is a set of categories, and
is a child/parent relation between categories. The dimension schema can be also
represented with a directed acyclic graph where the vertices correspond to the categories
and the edges to the child/parent relation. The transitive and reflexive closure of is
denoted by . There are no shortcuts in the schemas, that is, if ci cj there is no
category ck such that ci ck and ck cj . Every dimension schema contains a
distinguished top category called All which is reachable from all other categories, i.e. for
every c C, cAll. The leaf categories are called bottom categories.1
A dimension instance D over a dimension schema S = (C, ) is a tuple (M, <),
such that: (i) M is a finite collection of ground atoms of the form c(a) where c C and
a is a constant. If c(a) M, a is said to be an element of c. The constant all is the only
element in category All. Categories are assumed to be disjoint, i.e. if ci (a), cj (a) M
then i = j. There is a function Cat that maps elements to categories so that Cat(a) = ci
if and only if ci (a) M. (ii) The relation < contains the child/parent relationships
between elements of different categories, and is compatible with : If a < b, then

Cat(a) Cat(b). We denote < the reflexive and transitive closure of <.
In what follows we use the term dimension to refer to dimension instances. For each
pair of categories ci and cj such that ci cj there is a rollup relation denoted RD (ci , cj )
that consists of the following set of pairs {(a, b) | Cat(a) = ci , Cat(b) = cj and a < b}.
We next define two kinds of constraints a dimension should satisfy.
Definition 1. [Strictness and Covering Constraints [8]] A strictness constraint over a

hierarchy schema S = (C, ) is an expression of the form ci cj where ci , cj C
and ci cj . The dimension D satisfies the strictness constraint ci cj if and only if
the rollup relation RD (ci , cj ) is strict. A covering constraint over S is an expression of
the form ci cj where ci , cj C and ci cj . The dimension D satisfies the covering
constraint ci cj if and only if the rollup relation RD (ci , cj ) is covering. s (S) and
c (S) denote, respectively, the set of all possible strictness and covering constraints
over hierarchy schema S.
A dimension D over an schema S is inconsistent if it fails to satisfy = s (S)

c (S). A dimension D is said to be strict (covering) if all of its rollup relations are
strict (covering) [3]. Otherwise, the dimension is said to be non-strict (non-covering).
The dimension in Figure 1(b) is both covering and strict. Thus, a query asking for the
number of calls grouped by Region can be computed by using pre-computed aggregations
at categories AreaCode or City. This is not the case of dimension D in Figure 2, which is
covering, but not strict (N3 rolls-up to both IX and VIII in category Region).
Most research and industrial applications of DWs assume strict and covering dimen-
sions [1,9,10]. For these kinds of dimensions, summarization operations between two
categories that are connected in the schema are always correct [3]. In practice, dimen-
sions may be non-strict and non-covering [11,12], which can lead to incorrect results
when summarizing data. We can prevent these errors specifying integrity constraints for
rollup relations [11].
1
To simplify the presentation and without loss of generality, we assume that categories do not
have attributes, and schemas have a unique bottom category.
all all all all
IX VIII IX VIII IX VIII IX VIII
45 41 TCH TEM CCP 45 41 TCH TEM CCP 45 41 TCH TEM CCP 45 41 TCH TEM CCP
N1 N2 N3 N1 N2 N3 N1 N2 N3 N1 N2 N3
D D1 D2 D3
Fig. 2. (Non-strict dimension instance (category names are omitted)(D); Repairs of the dimension
(dashed edges were inserted to restore strictness) (D1 -D3 )
3 Inconsistent Reclassification and r-Repairs

The reclassify operator presented in [7] is not defined for every possible dimension.
It allows to reclassify edges of dimensions only if the resulting dimension satisfies
= s (S) c (S). When the dimension contains a conflicting level (Definition 2),
a reclassification may leave the dimension inconsistent with respect to strictness, and
therefore the operation is forbidden.
Definition 2. [Conflicting Levels (cf. [13])] Given a dimension instance D = (M, <)
over a schema S = (C, ), a pair of categories ci and cj such that ci cj , a pair
of elements a, b with Cat(a) = ci and Cat(b) = cj . A category ck such that cj ck is
conflicting with respect to reclassification, if there exists a category cm such that cm
ci , there is an alternative path between cm and ck not including the edge (ci ,cj ), and a is
reached by at least one element in cm .
As an illustration, category Region in Figure 1(a) is conflicting with respect to reclas-
sification from AreaCode to Region or a reclassification from City to Region. Consider a
reclassification from AreaCode to Region, in this case, ci = AreaCode, cj = ck = Region,
and cm = Number. The edges (Number,City) and (City,Region) form an alternative path from
Number to Region not including edge (AreaCode,Region).
In practice, preventing reclassification is not an admissible solution (eg., if the op-
eration is applied to correct erroneous data). Therefore, non-strict dimensions resulting
from the operation must be allowed. Definition 3 captures this semantics.
Definition 3. [Reclassify] Given a dimension instance D = (M, <) over a dimension
schema S = (C, ), a pair of categories ci and cj such that ci cj , a pair of elements
a, b with Cat(a) = ci and Cat(b) = cj , operator Reclassify (D, ci , cj , a, b) returns a new
dimension instance Du = (Mu , <u ) with Mu = M, and <u = (< \ {(a, c) | (a, c)<
and Cat(c) = Cj }) {(a,b)}.
For example, the result of applying Reclassify(D, Number , AreaCode, N3 , 45) on dimension
D in Figure 1(b) is the non-strict dimension D in Figure 2. Since we know that the area
code for N3 is 45, we must perform the reclassification and, in a subsequent step, repair
the updated dimension in order to comply with the strictness constraint.
Thus, if a reclassification according to Definition 3 yields a non-strict dimension, we
must repair the dimension [8], i.e., perform the necessary changes in order to obtain
dimension satisfying the constraints. In particular, from all possible repairs we are in-
terested in finding the minimal one. Intuitively, a minimal repair of a dimension is a
new dimension that satisfies a given set of constraints, and is obtained by applying a
minimum number of insertions and deletions to the original rollup relations. Although
techniques to compute repairs with respect to a set of constraints are well-known in the
field of relational databases [14], they cannot be applied in a DW setting, since it is
not trivial to represent strictness or covering constraints using relational constraints like
functional dependencies [8].
Defining a minimal repair requires a notion of distance between dimensions: Let
D = (M, <D ) and D = (M, <D ) be two dimensions over the same schema S =
(C, ). The distance between D and D is defined as dist(D, D ) = |(<D <D )
(<D <D )|, i.e. the cardinality of the symmetric difference between the two roll-up
relations [8]. Based on this, the definition of repair is as follows [8]: Given a dimension
D = (M, <) over a schema S = (C, ), and a set of constraints = s (S) c (S),
a repair of D with respect to is a dimension D = (M , < ) over S, such that D
satisfies , and M = M. A minimal repair of D is a repair D such that dist(D, D )
is minimal among all the repairs of D.
Minimal repairs according to [8] may result in dimensions where the reclassification
is undone. If we assume that a reclassification always represents information that is
certain, this semantics is not appropriate. For example, the minimal repairs (as defined
in [8]) for dimension D in Figure 2 are dimensions D1 , D2 and D3 . All of them were
obtained from D by performing insertions and/or deletions of edges. For example, D1
is generated by deleting edge ( CCP, VIII) and inserting (CCP, IX). The distances between
the repairs and D are: (a) dist(D, D1 ) = |(CCP, IX), (CCP, VIII)| = 2; (b) dist(D, D2 ) =
|(N3 ,41), (N3 ,45)| = 2; (c) dist(D, D3 ) = |(N3 ,TEM), (N3 ,CCP)| = 2. Note that dimension
D2 has undone the reclassification, and should not be considered an appropriate repair.
In light of the above, we next study the problem of finding repairs that do not undo
the reclassification. We denote these repairs r-repairs.
3.1 r-Repairs
Given a dimension D, a set R of reclassify operations is called valid if the following
holds: for every Reclassify (D, ci , cj , a, b) R there is no Reclassify (D, ci , cj , a, c)
R with c = b. In what follows we consider only valid reclassification.
Definition 4. [r-repairs] Given a dimension D = (M, <) defined over a schema S =

(C, ) that is consistent with respect to = s (S) c (S), and a valid set of reclas-
sifications R, an r-repair for D under R is a dimension D = (M , < ) defined over S
such that: (i) D satisfies ; (ii) M = M; and (iii) for every Reclassify(D, ci , cj , a, b)
R, the pair (a, b) < . Let r-repair (D, R) be the set of r-repairs for D under R. A min-
imal r-repair D for a dimension D and a set of reclassifications R is an r-repair such
that dist (D, D ) is minimal among all the r-repairs in r-repair (D, R).
Note that the distance between a dimension D and an r-repair D is bounded by the
size of D. For the dimension in Figure 1(b) and the set R = {Reclassify (D, Number,
AreaCode, N3 , 45)}, r-repair (D, R) contains dimensions D1 and D3 in Figure 2.
all all
All
d1 d2 d1 d2
D
H h1 h1
B C G b1 b2 b3 b4 c1 c2 c3 g1 b1 b2 b3 b4 c1 c2 c3 g1
A F a1 a2 a3 a4 a5 f1 a1 a2 a3 a4 a5 f1
E e1 e1
(a) Dimension schema (b) Dimension D (c) r-repair of D
Fig. 3. Heuristics
The existence of r-repairs cannot be guaranteed if the reclassification set contains

more than one reclassify operation. However, a positive result can be obtained for a set
R containing only one reclassification.
Theorem 1. Let D be a dimension instance over a schema S with constraints =

s (S)c (S), and a reclassification set R applied over D, producing a new dimension
Du ; the problem of deciding if there exists an r-repair D of Du with respect to , such
that dist(Du , D ) k is NP-complete.
Theorem 2. Given a dimension D over a schema S with constraints = s (S)
c (S), and a set of reclassification R, the problem of deciding if D is a minimal r-
repair of D with respect to is co-NP-complete.
The proof of Theorem 1 proceeds by reduction from the set covering problem. Theorem
2 follows from considering the complement of the problem, that is, deciding wether or
not the r-repair is minimal with respect to and R which, from Theorem 1 is NP-
complete.
4 Algorithms for r-Repairs

We study r-repairs for dimensions containing at most one conflicting level (Definition 2)
that becomes inconsistent with respect to strictness after a reclassify operation. Solving
this problem efficiently we cover a wide range of real-life situations [9,10]. We present
two heuristics and algorithms that find an r-repair for a dimension under reclassification
in polynomial time. These heuristics are such that the distance between the r-repair
obtained and the minimal r-repair is bound. In what follows we assume that after a
reclassification a dimension becomes inconsistent with respect to strictness. Thus, we
can identify the paths that make the dimension non-strict. We denote these paths non-
strict.
The first heuristics we propose ensures that when choosing a repair operation we do
not generate new non-strict paths. Let us consider the dimension schema and instance
in Figure 3 (a)-(b). Element c2 in category C is reclassified from d2 to d1 in category D
as indicated in Figure 3(b) (dashed edge). The elements incident to c2 are a2 , a3 , and
All all all
D d1 d2 d1 d2
H I K h1 h2 i1 k1 h1 h2 i1 k1
F G B f1 g1 g2 b1 f1 g1 g2 b1
E C e1 c1 e1 c1
A a1 a2 a1 a2
(a) Dimension schema (b) Dimension D (c) r-repair of D
Fig. 4. The dimension schema, instance and r-repair for the Algorithm
a5 . The non-strict paths are: (i) a2 b2 d2 , a2 c2 d1 . (ii) a3 b3 d2 ,

a3 c2 d1 . (iii) a5 b4 d2 , a5 c2 d1 . Elements b3 and b4 in category
B have no incident edges other than a3 and a5 , respectively. Thus, a possible repair
operation would delete edges (b3 , d2 ) and (b4 , d2 ), and insert edges (b3 , d1 ) and (b4 , d1 )
(dashed edges in Figure 3(c)). This repair operation does not add new non-strict paths.
Conversely, b2 has two incident edges (from a2 and a4 ), and a4 rolls-up to d2 via c3 ;
therefore, deleting (b2 , d2 ) and inserting (b2 , d1 ), would produce a violation of strictness,
and the following new non-strict paths: a4 b2 d1 , a4 c3 d2 . A solution would
be a repair that changes the parent of a2 either to b1 (as depicted in Figure 3 (c)), to b3 ,
or to b4 . In addition, all edges incident to a2 must also be reclassified if they reach d2
through a path not including the edge (A,B) in the dimension hierarchy. This is the case
of e1 that can be repaired by deleting edge (h1 , d2 ) and inserting (h1 , d1 ) or by moving
e1 to any element ai reaching d2 , like a4 , as we show in Figure 3 (c).
The second heuristics is aimed at guaranteeing that at each step the algorithm chooses
a repair operation that, accomplishing the no new conflicts heuristics, requires the
least number of changes.
4.1 Computing the r-Repairs

We illustrate the algorithms with the dimension schema and instance in Figure 4(a)-(b).
The first algorithm search path() reads the dimension schema from a table storing the
child/parent relation between categories, obtains the conflicting level (CL) and stored
it in variable cat cl, and verifies that the schema has a unique such CL. It also com-
putes the category from where the paths reaching the CL start, and stores it in the vari-
able cat bottom. For instance, for the child/parent relation of the categories in Figure
4(a), variable cat cl=D since D is the CL, and the cat bottom = A. Then, the algorithm
computes the paths of categories that reach the CL, and stores them in the structure
cat list paths. Any update operation involving categories in this structure may leave the
dimension schema non-strict. For the schema in Figure 4, cat list paths contains: [1]:
A E F D. [2]: A C G H D. [3]: A B I D. Then, Algorithm
search repair() in Figure 5 applies repair operations over categories in this structure.
Algorithm search repair() (Figure 5) first verifies if an update operation leaves the
dimension instance non-strict. For this, the list list inconsistent paths containing the
non-strict paths is produced (line 2). If the dimension is non-strict, the algorithm re-
stores consistency of every non-strict path on the list. Let Reclassify(D, C1 , C2 , eu , pu )
be the update operation that affects categories in cat list paths and leaves the dimen-
sion non-strict. The algorithm obtains, for every cat bottom element in the inconsistent
list, the number of paths reaching new CL (new parent of eu in CL) and old CL (old
parent in CL) (Lines 5 to 10). If these numbers are equal, it means that there are only
two alternative paths for the corresponding cat bottom element, and the algorithm tries
to keep new CL as the ancestor to these paths in the CL (lines 12 to 21). If not, it
means that there are more paths reaching old CL, and the algorithm tries to update the
edge reaching new CL, since this produces less changes (lines 25 to 26). If not, the
algorithm assigns new CL to all the paths reaching old CL (lines 28 to 31).
As an illustration, consider the reclassification Reclassify (D, C, G, c1 , g2 ) applied
over the dimension in Figure 4(b). The reclassification affects to the bottom element
a1 and therefore list inconsistent paths contains the paths: [1]: a1 e1 f1 d1 .
[2]: a1 c1 g2 h2 d2 . [3]: a1 b1 i1 d1 . The old and new parent
in CL for a1 are: old CL = d1 , new CL = d2 , and the number of paths reaching d1
and d2 are, respectively, 2 and 1. Since there are more paths reaching the old parent
in CL, the algorithm tries to keep d1 as the ancestor in D for all the conflicting paths.
This operation is possible given that element h2 does not have other child different from
g2 , and also the update is not performed over h2 (validations performed by function
check change to new CL); thus, the algorithm deletes edge (h2 , d2 ) and inserts (h2 , d1 )
(function change new CL), producing the repair shown in Figure 4(c).
Proposition 1. Given a dimension D over an schema S, and a set of reclassify opera-
tions R of size 1. (a) Algorithm search repair() terminates in a finite number of steps.
(b) Algorithm search repair() finds an r-repair for dimension D.
4.2 Complexity Analysis

Algorithm search path(), that captures the hierarchy schema of a dimension, runs in
O(k) with k being the number of paths reaching the conflicting level and starting at
the bottom category. For Algorithm search repair(), the most expensive function is
check Consistency(), that finds out if the dimension instance becomes inconsistent after
an update, and, in that case, generates the list of inconsistent paths. It needs to verify
that every element at the bottom category reaches a unique element in the CL after an
update. Let n be the number of elements at the bottom category, m the longest path
from the bottom category to the CL, and k the number of alternative paths from the
bottom category to the CL. Note that m, k and n are all independent values. Then, the
function has to search k paths for n elements at the bottom category. Thus, the algorithm
runs in O(n m k) in a worst case scenario, which implies that all elements in the
bottom category are in conflict after an update, which is quite unlikely. Consider also
that, in general, the number of categories between the bottom and the CL category is
small, as well as the number of alternative paths to the CL category. More than often
the hierarchy schema is a tree (i.e., there is no CL), and in this case the algorithm runs
in O(n log m k) (the longest path can be computed in log m). The rest of the
functions in the algorithm run in lineal time using the list of inconsistent paths, the list
of categories in the hierarchy schema, and the rollup functions.
search repair ()
Structure paths{String element, String category, next, below};
paths list inconsistent paths = NULL;
String new CL, old CL, e u, p u, parent child CL, child CL1, child CL2;
Int cost=0, cont same elements;
1: if check Consitency() = 0 then
2: list inconsistent paths= non strict paths();
3: while (list inconsistent paths.below = NULL) do
4: i=0;
5: cont same elements = find number paths(list inconsistent paths(i));
6: new CL = find new parent CL(list inconsistent paths(i),e u);
7: old CL = find old parent CL(list inconsistent paths(i),new CL);
8: {the parents in the CL before and after the update};
9: cont 1 =number paths reaching element(list inconsistent paths(i),new CL);
10: cont 2 =number paths reaching element(list inconsistent paths(i),old CL);
11: if (cont 1 = cont 2) then
12: {Same # of paths reaching the old and new parent in CL, try to keep the new parent};
13: child CL1 = find child CL(list inconsistent paths(i),old CL);
14: child CL2 = find child CL(list inconsistent paths(i),new CL);
15: {it captures the element in the category that reach the old(new) parent in CL};
16: if (check change to new CL(child CL1)=1) then
17: {It is possible to change to the new parent in CL};
18: cost = cost + change new CL(list inconsistent paths(i),child CL1, new CL);
19: else
20: cost = cost + change old CL(list inconsistent paths(i),child CL2, old CL);
21: end if
22: else
23: {# of paths reaching the old parent in CL is greater than the # of paths reaching the new parent in CL, try
to keep the old parent (second heuristics)};
24: child CL2 = find child CL(list inconsistent paths(i),new CL);
25: if (check change to old CL(child CL2)=1) then
26: cost = cost + change old CL(list inconsistent paths(i),child CL2, old CL);
27: else
28: for j = 1 TO cont 2 do
29: child CL1 = find child CL(list inconsistent paths(i),old CL);
30: cost = cost + change new CL(list inconsistent paths(i),child CL1, new CL);
31: end for
32: end if
33: end if
34: i = i + cont same elements;
35: move(list inconsistent paths,i);
36: end while
37: end if
Fig. 5. Generating an r-repair
5 Discussion and Conclusion

Most efforts addressing inconsistency issues in DWs focus in solving inconsistencies
between operational and warehouse data [15,16,17]. No much work has been devoted
to study the inconsistencies that may arise when dimension updates are applied. This
is due probably to the fact that dimensions were assumed to be static. Hurtado et al.
showed that dimensions need to be updated when, for instance, changes in the business
rules that lead to the warehouse design occur, or data in the operational sources are
updated [7,6]. In these works, dimension updates guarantee that the dimensions remain
consistent after the updating operations are applied (if there is a risk of inconsistency,
updates are prevented). A similar approach is adopted in [18]. Other approaches to di-
mension updates accept that the changes may leave the updated dimension inconsistent.
Therefore, repairing techniques must be applied in order to guarantee summarizability
[4], which is crucial for OLAP operations. Pedersen et al. [12] presented a first ap-
proach to this problem, transforming non-strict into strict dimensions by means of in-
sertion of artificial elements. Caniupan et al. present a logic programming approach to
repair dimensions that are inconsistent with respect to a set of constraints [8,19]. Al-
though important to gain insight into the problem of repairing inconsistent dimensions,
and containing some interesting theoretical results, from a practical point of view, the
approach presented in [8,19] would be computationally expensive in real-world cases.
Besides, DW administrators and developers are not acquainted with logic programs.
Moreover, for the specific case of reclassification, the work in [8,19] only deal with
repairs that may undo the update. On the contrary, the r-repairs we present in this paper
do not undo the reclassification. Finally, the minimal repairs obtained in [8,19] could
lead to rollup functions that do not make sense in the real world (e.g., relating dimen-
sion members that are not actually related in any way). Following a different approach,
we propose efficient algorithms that lead to consistent dimensions (although not nec-
essarily minimal with respect to the distance function), and where undesired solutions
could be prevented.
We have shown that, in general, finding r-repairs for dimension instances is NP-
complete. However, we also showed that in practice, computing r-repairs can be done
in polynomial time when the set of updates contains only one reclassification, and the
dimension schema has at most one conflicting level. We have explored algorithms to
compute r-repairs for this class of dimension schemas, and discussed their computa-
tional complexity, being in a worst case scenario of order O(n m k), where the
key term is n, the number of elements in the bottom level affected by the inconsisten-
cies. We would like to remark the fact that in the algorithms presented in this paper,
for the sake of generality, we did not include the possibility of preventing rollups that
could make no sense in practice. However, it is straightforward to enhance the search-
repair algorithm to consider only repairs that are acceptable by the user. At least two
approaches can be followed here: to prioritize the rollup functions (as, for example, is
proposed in [20]), or even to define some rollups to be fixed (and therefore, not allowed
to be changed). Of course, in the latter case, it may be the case where a minimal r-repair
does not exist. We leave this discussion as future work, as well as the experimentation
of the algorithms in real-world data warehouses.
Acknowledgements. This project was partially funded by FONDECYT, Chile grant
number 11070186. Part of this research was done during visit of Alejandro Vaisman
to University del Bo-Bo in 2010. Currently, Monica Caniupan is funded by DIUBB
110115 2/R. A. Vaisman has been partially funded by LACCIR project LACR-FJR-
R1210LAC004.
References
1. Chaudhuri, S., Dayal, U.: An Overview of Data Warehousing and OLAP Technology.
SIGMOD Record 26, 6574 (1997)
2. Bertossi, L., Bravo, L., Caniupan, M.: Consistent query answering in data warehouses. In:
AMW (2009)
3. Hurtado, C., Gutierrez, C., Mendelzon, A.: Capturing Summarizability with Integrity Con-
straints in OLAP. ACM Transacations on Database Systems 30, 854886 (2005)
4. Lenz, H., Shoshani, A.: Summarizability in OLAP and Statistical Data Bases. In: SSDBM,
pp. 132143 (1997)
5. Rafanelli, M., Shoshani, A.: STORM: a Statistical Object Representation Model. In:
Michalewicz, Z. (ed.) SSDBM 1990. LNCS, vol. 420, pp. 1429. Springer, Heidelberg
(1990)
6. Hurtado, C., Mendelzon, A., Vaisman, A.: Maintaining Data Cubes under Dimension Up-
dates. In: ICDE, pp. 346355 (1999)
7. Hurtado, C., Mendelzon, A., Vaisman, A.: Updating OLAP Dimensions. In: DOLAP, pp.
6066 (1999)
8. Caniupan, M., Bravo, L., Hurtado, C.: A logic programming approach for repairing inconsis-
tent dimensions in data warehouses. Submitted to Data and Knowledge Engineering (2010)
9. Dodge, G., Gorman, T.: Essential Oracle8i Data Warehousing: Designing, Building, and
Managing Oracle Data Warehouses (with Website). John Wiley & Sons, Inc., Chichester
(2000)
10. Kimball, R., Ross, M.: The Data Warehouse Toolkit: The Complete Guide to Dimensional
Modeling. John Wiley & Sons, Inc., Chichester (2002)
11. Hurtado, C., Mendelzon, A.: Reasoning about summarizability in heterogeneous multidi-
mensional schemas. In: Van den Bussche, J., Vianu, V. (eds.) ICDT 2001. LNCS, vol. 1973,
p. 375. Springer, Heidelberg (2000)
12. Pedersen, T., Jensen, C., Dyreson, C.: Extending Practical Pre-Aggregation in On-Line An-
alytical Processing. In: VLDB, pp. 663674 (1999)
13. Vaisman, A.: Updates, View Maintenance and Materialized Views in Multidimnensional
Databases. PhD thesis, Universidad de Buenos Aires (2001)
14. Bertossi, L.: Consistent query answering in databases. ACM Sigmod Record 35, 6876
(2006)
15. Zhuge, Y., Garcia-Molina, H., Wiener, J.L.: Multiple View Consistency for Data Warehous-
ing. In: ICDE, pp. 289300 (1997)
16. Gupta, H., Mumick, I.S.: Selection of views to materialize under a maintenance cost con-
straint. In: Beeri, C., Bruneman, P. (eds.) ICDT 1999. LNCS, vol. 1540, pp. 453470.
Springer, Heidelberg (1998)
17. Schlesinger, L., Lehner, W.: Extending Data Warehouses by Semiconsistent Views. In:
DMDW, pp. 4351 (2002)
18. Letz, C., Henn, E.T., Vossen, G.: Consistency in Data Warehouse Dimensions. In: IDEAS,
pp. 224232 (2002)
19. Bravo, L., Caniupan, M., Hurtado, C.: Logic programs for repairing inconsistent dimensions
in data warehouses. In: AMW (2010)
20. Espil, M.M., Vaisman, A., Terribile, L.: Revising data cubes with exceptions: a rule-based
perspective. In: DMDW, pp. 7281 (2002)
GrHyMM: A Graph-Oriented Hybrid
Multidimensional Model
Francesco Di Tria, Ezio Lefons, and Filippo Tangorra
Dipartimento di Informatica
Universit degli Studi di Bari Aldo Moro
Via Orabona 4, 70125, Bari, Italy
{francescoditria,lefons,tangorra}@di.uniba.it
Abstract. The main methodologies for the data warehouse design are based on
two approaches which are opposite and alternative each other. The one, based
on the data-driven approach, aims to produce a conceptual schema mainly
through a reengineering process of the data sources, while minimizing the
involvement of end users. The other is based on the requirement-driven
approach and aims to produce a conceptual schema only on the basis of
requirements expressed by end users. As each of these approaches has valuable
advantages, it is emerged the necessity to adopt a hybrid methodology which
combines the best features of the two approaches. We introduce a conceptual
model that is based on a graph-oriented representation of the data sources. The
core of the proposed hybrid methodology is constituted by an automatic process
of reengineering of data sources that produces the conceptual schema using a
set of requirement-derived constraints.
Keywords: i* framework, graph-based modelling, schema validation.
1 Introduction
The actual lack of a standard process for data warehouse design has led to the
definition of several methodologies. This is especially true in the conceptual design,
where opposite approaches can be adopted based on the requirement-driven and data-
driven methodologies [1]. The requirement-driven approach, also known as demand-
driven or goal-oriented methodology, aims to define multidimensional schemas using
business goals resulting from the decision makers needs. The data sources are
considered later, when the Extraction, Transformation, and Loading (ETL) phase is
designed [2]. In this feeding plan, the multidimensional concepts (such as facts,
dimensions, and measures) have to be mapped on the data sources in order to define
the procedures to populate the data warehouse by cleaned data. At this point, it may
happen that the designer discovers that the needed data are not currently available at
the sources. On the contrary, the data-driven approach, also known as supply-driven
methodology, aims to define multidimensional schemas on the basis of a remodelling
of the data sources. This process is individually executed by the designer who
minimizes the involvement of end users and, consequently, goes towards a possible
failure of their expectations. To overcome these limits, in the last years the necessity
to define hybrid methodologies arose [3].
GrHyMM: A Graph-Oriented Hybrid Multidimensional Model 87
Here, we present a Graph-oriented Hybrid Multidimensional Model (GrHyMM for

short) for data warehouse conceptual design. This model is based on a graph-oriented
representation of (part of) data sources [4, 5]. In this way, the traditional operations
performed in the reengineering process (such as adding and removing attributes, or
modifying functional dependencies) correspond to basic operations on graphs (such as
adding and removing nodes). Nevertheless, this remodelling activity relies on a set of
constraints that have to be derived from the requirement analysis, avoiding the
oversight of business needs. Using these constraints, it is possible to perform the
remodelling activity in a supervised and automatic way. At the end of the conceptual
design, the validation of the obtained schema is performed [6], in order to verify
whether it supports all queries included into a preliminary workload, which contains
the typical queries that end users will execute in the analytical processing step.
The paper is organized as follows. Section 2 introduces the conceptual design
framework. Section 3 presents the language we defined to represent business goals.
Section 4 discusses the source analysis. Section 5 illustrates the multidimensional
model that is at the basis of the hybrid methodology. Finally, Section 6 contains our
concluding remarks and notes on work in progress.
2 Methodological Framework
Our framework for data warehouse design is depicted in Figure 1 and describes the
activities that must be performed by designers, along with the produced artifacts.
Fig. 1. Framework for data warehouse design
The activities are performed sequentially as follows.

1. Requirement analysis. In this step, the needs of end users (namely the decision
makers) are investigated. To this aim, we use the i* framework and its application
to data warehousing [7], which allows to explicitly represent business goals in
reference to the several actors of the system. In general, there are two main
categories of actors: the decision makers and the data warehouse itself, each of
them performs specific tasks in order to achieve their own goals. The designer has
to: (1a) define the tasks and the goals of the different actors using the i*
framework; (1b) translate the tasks of the decision makers into a preliminary
workload (see, Section 3.1); and (1c) translate the goals and the tasks of the data
warehouse into a set of constraints (see, Section 3.2). Then, both artifacts (ie, the
workload and set of constraints) must be given in input to the conceptual design
process in order to start the modelling phase in an automatic way.
88 F. Di Tria, E. Lefons, and F. Tangorra
2. Source analysis. In this step, the different schemas of data sources must be
analyzed and then reconciled, in order to obtain a global and integrated schema.
Also this artifact must be given in input to the conceptual design process. The
constraints derived from the requirement analysis are used to perform a
reengineering of the source schema.
3. Conceptual design. This step is based on GrHyMM, the graph-oriented
multidimensional model. The sub-steps to be performed in this phase are: (3a)
identifying facts present in the source schema on the basis of the constraints; (3b)
building an attribute tree for each fact; (3c) remodelling the tree on the basis of the
constraints; and (3d) verifying whether all the remodelled trees agree with the
workload (this is the so-called validation process).
4. Logical design. In this step, the conceptual schema is transformed into a logical
one with reference to the data model of the target database system.
5. Physical design. The logical schema implementation ends the design process with
defining the physical database properties based on the specific features provided
by the database system, such as indexing, partitioning, and so on.
Here, we address only the first steps 1 to 3, as steps 4 and 5 strongly depend on target
systems. As an example, ROLAP and MOLAP systems can be utilized in step 4.
3 Requirement Analysis
In the i* framework, user requirements, alias business goals, are exploded into a more
detailed hierarchy of nested goals: (a) strategic goals, or high-level objectives to be
reached by the organization; (b) decision goals, to answer how strategic goals can be
satisfied; and (c) information goals, to define which information is needed for
decision making. To do this, the designer must produce a model describing the
relationships among the main actors of the organization, along their own interests.
This model is the so-called strategic dependency model and aims to outline how the
data warehouse helps decision makers to achieve business goals. As in this context
the i* framework applies to data warehousing, the data warehouse itself has to be an
actor of the system. Each actor in a strategic dependency model is further detailed in a
strategic rationale model that shows the specific tasks the actor has to perform in
order to achieve a given goal.
In Figure 2, there is reported an example of strategic rationale model showing the
strategic goals and the tasks of the decision maker and data warehouse actors.
day
amount
Analyze the month
shipment costs year
per client from product
Provide category
2000 to now
D
Information information
about sales D sales
about products
selling store
Increase
the profit region
Information
about shipments D shipments Provide
day
Analyze the information
month
profit of the about
year
products selling shipments
in the last year cost location
client
Decision maker Data warehouse
Fig. 2. Strategic rationale model

In our methodology, the designer translates the tasks of the decision makers into a
workload, while the goals and the tasks of the data warehouse are transformed into a
set of constraints that must be taken into account in the next data remodelling phase.
3.1 Workload Representation
The workload contains a set of queries derived from user requirements and helps the
designer to identify the information the users are interested in. In a few words, it
includes the typical queries that will be executed by decision makers in the analytical
processing step (OLAP).
The grammar for a high-level representation of the queries of the workload follows.
<query> ::- <function>(<fact_pattern>);

<fact_pattern> ::- <fact>[<aggreg_pattern>;<sel_clause>].<measure>
<aggreg_pattern> ::- <level> | <aggreg_pattern>,<level>
<sel_clause> ::- <attribute> <comp_op> <constant> |
<sel_clause> <logical_op> <sel_clause>
<function> ::- avg | sum | count
<logical_op> ::- and | or
<comp_op> ::- | | < | > | =
<fact> ::- <identifier>
<measure> ::- <identifier>
<level> ::- <identifier>
<attribute> ::- <identifier>.
Notice that constant is any number or string, and identifier a user-defined name
corresponding to a valid variable (the name of a table or column, for example).
Example 1. With reference to the decision makers tasks shown in Figure 2, we have
to manually translate them in high-level queries. First, the task Analyze the profit per
products sold in 2010 corresponds to the SQL-like statement select product,
sum(amount) from sale join product where year = 2010 group by product_id; and
grammar-based statement sum(sale[product; year = 2010].amount);. On the other
hand, the second task corresponds to the query select client, sum(cost) from shipment
join client where year 2000 and year 2011 group by client_id; and statement
sum(shipment[client; year 2000 and year 2011].cost);.
The workload will be used in the final step of the conceptual design in order to
perform the validation process. If all the queries of the workload can be effectively
executed over the schema, then such a schema is assumed to be validated and the
designer can safely translate it into the corresponding logical schema. Otherwise, the
conceptual design process must be revised.
3.2 Constraints Representation
For each resource needed from decision makers, the data warehouse must provide
adequate information by achieving its own goals. Moreover, a goal must have
measures that are resources to be used in order to provide the information required for
decision making. Therefore, a fact is generated in order to allow the data warehouse
to achieve its own goal. Finally, for each measure, a context of analysis must be
provided by a task of the data warehouse. So, starting from measures and dimensions
emerged from business goals, they can be identified some constraints the designer
must necessarily consider. The constraints will be used in the main step of the
conceptual design in order to perform the remodeling process in a supervised way.
The grammar for a high-level representation of constraints follows.
<constraint> ::- <fact>[<dimensions>].[<measures>];

<dimensions> ::- <dimension> | <dimensions>;<dimension>
<dimension> ::- <level> | <dimension>,<level>
<measures> ::- <measure> | <measures>,<measure>
<level> ::- <identifier>
<measure> ::- <identifier>
<fact> ::- <identifier>.
Example 2. The constraint sales[product, category; day, month, year; store, region].
[amount]; states that we must have a fact, namely sales, provided with the amount
measure. This fact has three dimensions. The first dimension has two levels: product
(the first dimensional level of the hierarchy) and category (the second one). The
second dimension has levels day, month, and year, while the third dimension levels
store and region.
4 Sources Analysis
The aim of this activity is to produce a global and reconciled schema coming from the
integration of the heterogeneous data sources. In this phase, it is very important to
align the different schemas [8] using a unique model. The methodology to accomplish
this is faced in [9], where a supermodel is proposed provided with a set of meta-
constructs that can be mapped to constructs of specific models. The transformation
between schemas is performed via Datalog rules.
A class of problems derives from inconsistency among schemas, as cardinality
constraints. As an example, in a university database a professor can hold one or many
courses but in another one a professor can hold zero or two courses. Whereas there is
an agreement on the meaning of the professor entity, there is a discordance about how
many courses a professor may hold.
Inconsistencies can be treated using an ontological approach [10]. So, starting from
a logical schema, an abstraction process has to be performed to derive a conceptual
schema, such as an Entity Relationship (ER) schema. Then, all the inconsistencies in
the conceptual schemas must be solved by defining a common and shared ontology.
Indeed, an ER schema is used to represent locally true concepts, that is, concepts that
are true in a given context. On the other hand, an ontology is used to represent
necessarily true concepts, that is, concepts that are always true [11].
Relative to the previous example, if a professor may hold one or many courses in
one database and a professor may hold zero or two courses in another database, then
this inconsistency can reconciled in an ontology that states that a professor, in general,
may hold zero or many courses.
In what follows, we assume that there are no inconsistencies among schemas. In

particular, we assume that also user requirements agree with the concepts and the
terminology used in data sources.
5 Conceptual Design
This section describes how to build and to remodel an attribute tree to represent a fact
identified from user requirements. In detail, the design consists of four steps to be
performed in automatic way: the identification of facts is done by marking possible
fact tables in data source and by matching them with constraints derived from user
requirements; the building of an attribute tree is defined by a set of formal
assumptions; the remodeling of the tree is defined by a novel algorithm; and, at last,
the validation is based on a set of non-ambiguous rules represented using the first
order logic [6].
5.1 Identifying Facts
The main difficulty in this step is to correctly map the multidimensional concepts to
the integrated schema. For example, in a relational schema, the designer must face the
problem to identify which table can be considered as a fact. To solve this problem,
several methodologies have been defined to automatically identify multidimensional
concepts in order to correctly map them onto the data sources.
For example, in [12] the user requirements can be entirely derived by defining a
preliminary workload. On the basis of this assumption, the authors propose an
algorithm able to automatically create a graph (whose nodes are the tables of the data
sources and edges are the joins between tables) that aims to identify whether each
table can be considered as a fact table or a dimension table. They state that a correct
labelling of all nodes generates a valid multidimensional schema. The labels are
assigned by examining the role played by tables and attributes in the SQL queries
included in the preliminary workload.
In our model, we mainly deal with the correct identification of facts, as these are
the starting point to build the initial attribute tree. According to some heuristics
reported in [13], we suggest that a table in the data source is a candidate fact provided
that: (a) it is a very-frequently-updated relation; (b) it has numeric attributes; (c) it
does not have its own primary key; (d) its primary key is composed of two or more
foreign keys; and (e) it represents a many-to-many relationship among relations.
We consider the facts involved in the constraints coming from the requirement
analysis. Given a fact F1 in a constraint, we choose a candidate fact F2 in the
integrated schema such that F2 corresponds to F1. We assume no inconsistencies exist
(nor syntactic neither semantic) among user requirements and data sources, though in
many cases user requirements do not agree with concepts in data source.
Given a fact, we now show how to build the initial attribute tree. Of course, there
can be as many trees as many facts.
5.2 Building the Attribute Tree
Here, we present GrHyMM, a suitable model to represent relational databases.

Let G = (N, E) be a tree, where:

N = {A1, A2, , An} is a set of n nodes,
E = {(Ai, Aj) | Ai,AjN, i j} NN is a set of edges, and
A1 is the root of G.
Assumption 1. Let R(X1, , Xn) be a relation, and let G = (N, E) be an attribute tree.
We assume XiN, i = 1, , n.
We also assume that G = (N, E) is the tree obtained from R, by invoking the algorithm
tree(R). In particular, G = (N, E) is the tree constructed by considering the relation R
as a starting point.
Assumption 2. Let R(X1, , Xn) be a relation, and let G = (N, E) be a tree. We
assume (Xi, Xj)E, if Xi is the primary key of R and i j.
On the basis of Assumption 2, the edge (Xi, Xj) states that the non-trivial (for i j)
functional dependency Xi Xj holds on R (in this case, established by a primary key
constraint).
It is worth noting that the primary key of a relation can be composed of more than
one attribute. In this case, the node representing the primary key is a composite node.
Example 3. Let Student(code, university, name, address) be a relation, whose primary
key is composed of code and university. Then, naming the primary key by the relation
name, we have that:
(code, university) code (Student, code)E

(code, university) university (Student, university)E
(code, university) name (Student, name)E
(code, university) address (Student, address)E.
Assumption 3. Let R(X1, , Xn) and S(Y1, , Ym) be relations, and let G = (N, E) be
a tree. We assume (Xi,Yj)E, if
Yj is the primary key of the relation S,

Xi is a foreign key referencing Yj.
On the basis of Assumption 3, an edge can also indicate the functional dependency
established by a foreign key constraint. So, the next Assumption 4 describes how to
build a tree starting from a relation having r foreign keys. Accordingly, we assume
that the algorithm tree is able to navigate among relations via foreign key constraints.
To this end, Assumption 5 describes how to build a tree when a many-to-many
relationship is encountered in the navigation process.
Assumption 4. Let R1(X11, , X1h), R2(X21, , X2k), , Rr(Xr1, , Xrq) be r
relations, and let T(Z1, , Zp) be a relation where r p. If
Xiji is the primary key of the relation Ri, i = 1, 2, , r, and
Zt1, , ZtrT, such that
o i = 1,, r, Zti is a foreign key referencing Xiji, and

o the set Z = {Zt1, , Ztr} forms the primary key of the relation T,
then, the tree G = (N, E) is defined so:
N = {T} {Xij | Xij Ri; i = 1, ..., r},
T is the root node of the tree,
(Xiji, Xili)E, j l,
(T, Xiji)E, i = 1,, r, and
(T, Ztv)E, ZtvT and ZtvZ.
Assumption 5. Let R(X1, , Xh), S(Y1, , Yk), and T(Z1, , Zp) be three relations,
and let G = (N, E) a tree. If
Xi is the primary key of the relation R,

Yj is the primary key of the relation S,
Zti,Ztj T such that
o Zti is a foreign key referencing Xi,
o Ztj is a foreign key referencing Yj, and
o (Zti, Ztj) is the primary key of the relation T, and
T is not the root node of the G,
then
(Xi, T)E,
(T, Yj)E, and
(T, Zv)E, v = 1,, p and v ti, tj .
Example 4. Let us consider the schema of Figure 3(a). The algorithm tree starts from
Sale and reaches Cataloging. The primary key of the Cataloging relation is composed
of foreign keys. In fact, this relation is an intermediate relation, that establishes a
many-to-many relationship between Product and Catalog. So, the edge between
Product and Cataloging is represented by a dot-headed arrow, as depicted in Figure
3(b), to indicate that, given a prodId instance, many occurrences in the Cataloging
relation will correspond to.
In conclusion, we note that, sometimes, a node can have multiple parents. This
happens when an attribute is pointed out by more than one table. In this case, the tree
is a graph or a semi-tree, since there is always a root node representing the fact.
5.3 Remodeling the Attribute Tree
In what follows, given an attribute A, we denote with A the node representing the
corresponding attribute. Moreover, we indicate with A B the edge existing from the
A node to the B node. At last, we denote with (A, B) :- C the fact that the attribute C
can be computed using A and B, that is, C is a derived measure. As an example,
(price, quantity) :- amount means that there exists an expression to compute amount
Cataloging Sale
Catalog Product Order
PK,FK1 catId PK,FK1 prodId (a)
PK catId PK prodId PK orderId
PK,FK2 prodId PK,FK2 orderId
catDesc prodDesc date
stock quantity
(b)
Fig. 3. (a) relational schema; (b) the result of tree(Sale)
using price and quantity. The basic operations on a tree are: (a) add A B, or adding
an edge from A to B; (b) remove A B, or removing the edge from A to B; and (c)
prune A, or removing the A node with all its children.
Let us consider a tree T and a constraint coming from the user requirements. In
informal way, we create as many root children as many measures there are in the
constraint. Moreover, we add a root child for each first dimensional level in the
constraint. In a recursive way, the other dimensional levels are added as children
nodes of their own predecessor levels. In general, when we add a new node B to a
parent node A, the node B can be created ex novo or can be already present in the tree.
In the latter case, the edge between B and the old parent of B must be deleted and a
new edge between B and the new parent A must be created; this is the so-called
change parent operation.
Algorithm 1 performs the attribute tree remodelling.
Example 5. On the tree of Figure 4(a), given the constraint shipments[client; location;
day, month, year].[cost]; we perform the following operations. First, since cost can be
computed by the sum of transport_cost and delivery_cost, then we delete both the
transport_cost and delivery_cost nodes, and we add the cost node as root child (lines
6-8). Second, also the client, location, and day nodes becomes three distinct root
children via a change parent operation (lines 15-18). Third, in the constraint, the only
hierarchy to be built is formed by day, month, and year. So, a new node month
becomes the child of day and a new node year becomes the child of month (line 24).
All the other nodes, such as carrier and order are pruned (lines 30-31). The resulting
tree is shown in Figure 4(b).
Algorithm 1. Attribute tree remodelling.

Input: T graph
1. for each measure M
2. if MT then
3. remove parent(M) M
4. add root M
5. else
6. if (X1, X2, , Xn) :- M and (X1, X2, , Xn)T
7. remove parent(Xi) Xi for i = 1, , n
8. add root M
9. end if
10. end if
11. end for
12. for each dimension D
13. for each level Lj in D, for j = 1, , m
14. if Lj = L1
15. if LjT then
16. remove parent(Lj) Lj
17. end if
18. add root Lj
19. else
20. if parent(Lj) Lj 1
21. if LjT then
22. remove parent(Lj) Lj
23. end if
24. add Lj - 1 Lj
25. end if
26. end if
27. end for
28. end for
29. for each NT
30. if D such that ND
31. prune N
32. end if
33. end for
Fig. 4. (a) shipments attribute tree; (b) remodelled shipments attribute tree
5.4 Validating the Conceptual Schema
In the validation process [14], we have several attribute trees (whose collection is a
conceptual schema) and a workload, composed of high-level queries. A query is
assumed to be validated if there exists at least an attribute tree such that the following
conditions hold: (a) the fact is the root of the tree; (b) the measures are the children
nodes of the root; (c) for each level in the aggregation pattern, there exists a path from
the root to a node X, where X is a non-leaf node representing the level; and (d) for
each attribute in the selection clause, there exists a path from the root to a node Y,
where Y is a leaf node representing the attribute.
If all the queries are validated, then each attribute tree can be considered as a cube,
where the root is the fact, non-leaf nodes are aggregation levels, and leaf nodes are
descriptive attributes belonging to a level. So, the conceptual design ends and the
designer can transform the conceptual schema into a logical one. On the other hand, if
a query cannot be validated, then the designer has to opportunely modify the tree. For
example, if an attribute of the selection clause is not in the tree, then the designer can
decide to add a further node. A deeper discussion on the validation process can be
found in [6], along with the methodology to execute this task in automatic way.
Example 6. Let us consider the following query: sum(shipments[client; year 2000
and year 2011].cost);. Such a query is validated on the tree of Figure 4(b) because
shipments is the root of the tree, cost is the child node of the root, client is a non-leaf
node reachable from the root (that is, client is a correct aggregation level belonging to
the first dimension), and year is a leaf node reachable from the root.
The validation process ends the conceptual design. Two similar approaches can be
found in [15, 16]. They differ from our approach in that they produce conceptual
schemas by reconciling user requirements with data sources. In this way, possible
lack of compliance to the user requirements needs can arise, for some requirements
could have been disregarded in order to preserve data integrity. On the other hand, we
start from data source and use user requirements as constraints to remodel a source
schema in automatic way, preserving both business needs and data integrity.
6 Conclusions
In this paper, we have presented a multidimensional model for data warehouse
conceptual design. This model can be surely adopted in a hybrid methodology for
data warehouse design. In fact, the model uses a graph-oriented representation of an
integrated relational schema. So, the data remodelling process is expressed according
to traditional operations on a tree and is based on a set of constraints derived from the
requirement analysis, along with a preliminary workload to be used to validate the
conceptual schema. The main contribution of this model is that all the steps to be
performed in the conceptual design can be automated thanks to the high degree of
formalization given by i* schemas and to the precise and non-ambiguous rules to be
followed in the remodeling activity.
We are now working on the development of a logical program that considers such
rules for the construction and the remodeling of the attribute trees, and the validation
of the resulting conceptual schema.
References
1. Ballard, C., Herreman, D., Schau, D., Bell, R., Kim, E., Valencic, A: Data Modeling
Techniques for Data Warehousing. IBM Redbooks (1998)
2. Kimball, R.: The Data Warehouse Lifecycle Toolkit, 2nd edn. Practical Techniques for
Building Data Warehouse and Business Intelligence Systems. John Wiley & Sons,
Chichester (2008)
3. Romero, O., Abell, A.: A Survey of Multidimensional Modeling Methodologies.
International Journal of Data Warehousing and Mining 5(2), 123 (2009)
4. Golfarelli, M., Maio, D., Rizzi, S.: The Dimensional Fact Model: a Conceptual Model for
Data Warehouses. International Journal of Cooperative Information Systems 7, 215247
(1998)
5. dellAquila, C., Di Tria, F., Lefons, E., Tangorra, F.: Dimensional Fact Model Extension
via Predicate Calculus. In: 24th International Symposium on Computer and Information
Sciences, Cyprus, pp. 211217 (2009)
6. dellAquila, C., Di Tria, F., Lefons, E., Tangorra, F.: Logic Programming for Data
Warehouse Conceptual Schema Validation. In: Pedersen, T.B., Mohania, M.K., Tjoa, A.M.
(eds.) DAWAK 2010. LNCS, vol. 6263, pp. 112. Springer, Heidelberg (2010)
7. Mazn, J.N., Trujillo, J., Serrano, M., Piattini, M.: Designing Data Warehouses: from
Business Requirement Analysis to Multidimensional Modeling. In: Cox, K., Dubois, E.,
Pigneur, Y., Bleistein, S.J., Verner, J., Davis, A.M., Wieringa, R. (eds.) Requirements
Engineering for Business Need and IT Alignment. Wales Press, University of New South
(2005)
8. Rahm, E., Bernstein, P.: A Survey of Approaches to Automatic Schema Matching. The
International Journal on Very Large Data Bases 10(4), 334350 (2001)
9. Atzeni, P., Cappellari, P., Torlone, R., Bernstein, P., Gianforme, G.: Model-Independent
Schema Translation. The International Journal on Very Large Data Bases 17(6), 1347
1370 (2008)
10. Romero, O., Abell, A.: Automating Multidimensional Design from Ontologies. In:
Proceedings of the ACM 10th International Workshop on Data Warehousing and OLAP,
Lisbon, Portugal, pp. 18 (November 9, 2007)
11. Spyns, P., Meersman, R., Jarrar, M.: Data Modelling versus Ontology Engineering. ACM
SIGMOD Record 31(4), 1217 (2002)
12. Romero, O., Abell, A.: Multidimensional Design by Examples. In: Tjoa, A.M., Trujillo,
J. (eds.) DaWaK 2006. LNCS, vol. 4081, pp. 8594. Springer, Heidelberg (2006)
13. Carm, A., Mazn, J.N., Rizzi, S.: A Model-Driven Heuristic Approach for Detecting
Multidimensional Facts in Relational Data Sources. In: Pedersen, T.B., Mohania, M.K.,
Tjoa, A.M. (eds.) DAWAK 2010. LNCS, vol. 6263, pp. 1324. Springer, Heidelberg
(2010)
14. Golfarelli, M., Rizzi, S.: A Methodological Framework for Data Warehouse Design. In: 1st
ACM International Workshop on Data Warehousing and OLAP, Washington D.C., USA,
pp. 39 (1998)
15. Giorgini, P., Rizzi, S., Garzetti, M.: GRAnD: A Goal-oriented Approach to Requirement
Analysis. Decision Support Systems 45(1), 421 (2008)
16. Mazn, J.N., Trujillo, J., Lechtenborger, J.: Reconciling Requirement-driven Data
Warehouses with Data Sources via Multidimensional Normal Forms. Data Knowl.
Eng. 63(3), 725751 (2007)
Ontologies and Functional Dependencies for
Data Integration and Reconciliation
Abdelghani Bakhtouchi1 , Ladjel Bellatreche2, and Yamine Ait-Ameur2

1
National High School for Computer Science (ESI), Algiers, Algeria
a bakhtouchi@esi.dz
2
LISI/ENSMA Poitiers University, Futuroscope, France
{bellatreche,yamine}@ensma.fr
Abstract. Integrating data sources is the key success of business in-

telligence systems. The exponential growth of autonomous data sources
over the Internet and enterprise intranets makes the development of in-
tegration solutions more complex. This is due to two main factors: (i)
the management of the source heterogeneity and (ii) the reconciliation
of query results. To deal with the rst factor, several research eorts
proposed the use of ontologies to explicit semantic of each source. Two
main trends are used to reconcile the query results: (i) the supposition
that dierent entities of sources representing the same concept have the
same key a strong hypothesis that violates the autonomy of sources.
(ii) The use of statistical methods which are not usually suitable for
sensitive-applications. In this paper, we propose a methodology integrat-
ing sources referencing shared domain ontology enriched with functional
dependencies (FD) in a mediation architecture. The presence of FD
gives more autonomy of sources in choosing their primary keys and fa-
cilitates the result reconciliation. Our methodology is validated using
dataset of Lehigh University Benchmark.
1 Introduction
In the past decades, Enterprise and Information Integration (EII) became an es-
tablished business, where commercial and academic tools integrating data from
various sources exist. They provide uniform and transparent access to data. The
spectacular development of this business is largely due to companies requiring
being able to access data located over the Internet and within their Intranets
[8,12]. Integration problem inputs are a set of distributed, heterogeneous, au-
tonomous sources where each one has its schemes and populations. It outputs
a unied description of source schemes via an integrated schema and mapping
rules allowing the access to data sources. The construction of a data integration
system is a hard task due to the following main points: (a) the large number
of data sources candidate for integration, (b) the lack of explicitation of the
semantic of sources, (c) the heterogeneity of sources and (d) the autonomy of
sources. (a) The explosion of data sources: the number of data sources involved
in the integration process is increasing. The amount of information generated in

Ontologies and Functional Dependencies for Data Integration 99
the world increases by 30% every year and this rate is bound to accelerate [8],
especially in domains such as E-commerce, engineering, etc. Integrating these
mountains of data requires automatic solutions. (b) The lack of explicitation of
the semantic of sources: the semantics of data sources is usually not explicit.
Most sources participating in the integration process were designed to satisfy
day-to-day applications and not to be integrated in the future. Often, the small
amount of semantic contained in their conceptual models is lost, since only their
logical models are implemented and used by applications. The presence of a
conceptual model may oer designers to express the application requirements
and domain knowledge in an intelligible form for a user. Thus, its absence or
any other semantic representation in nal databases makes their interpretation
and understanding complicated, even for designers who have good knowledge of
the application domain. (c) The heterogeneity of data sources impacts both the
structure and the semantic. Structural heterogeneity exits because data sources
may have dierent structures and/or dierent formats to store their data. The
autonomy of the sources increases heterogeneity signicantly. Indeed, the data
sources are designed independently by various designers with dierent applica-
tion objectives. Semantic heterogeneity presents a major issue in developing in-
tegration systems [11]. It is due to dierent interpretations of real world objects,
generating several categories of conicts (naming conicts, scaling conicts, con-
founding conicts and representation conicts [10]). (d) Autonomy of sources:
most sources involved in the data integration are fully autonomous in choosing
their schemes.
To deal with semantic problem and ensure an automatic data integration, an
important number of research studies propose the use of ontologies, where several
integration systems were proposed around this hypothesis. We can cite COIN
[10], Observer [14], OntoDaWa [3], etc. In [3], we claim that if the semantic of
each source participating in the integration process is explicit (in a priori way),
the integration process becomes automatic. This means the used ontology exists
before the creation of the sources. This assumption is reasonable since several
domain ontologies exist in various areas: medicine, engineering, travel, etc. The
explicitation of dierent concepts used in a database leads to the concept of
ontology-base databases (OBDB). Several academic and industrial systems oer
solutions to manage this type of databases (e.g., Jena, Sesame, Oracle, IBM
Sor ).
To deal with data reconciliation issue, we gure out that most existing inte-
gration systems (with a mediator architecture) suppose that there is a common
single identier for each common concept between the sources. The assumption
facilitates the reconciliation of query results, but it violates the sources auton-
omy. Other research eorts use of entity reconciliation methods [4,17] performed
either by entity matching and data fusion. These approaches are ecient for
linguistic and information retrieval applications [8], but they may suer in the
context of sensitive applications such as banking, healthcare, travel, engineer-
ing, etc. The similarity between conceptual models and ontologies and the recent
work focusing on the denition of functional dependencies F D on ontologies [16]
100 A. Bakhtouchi, L. Bellatreche, and Y. Ait-Ameur
motivate us to consider them as a part of the ontology denition. The presence of

F D allows designers generating all candidate keys for each class of an ontology.
As consequence, a source designer may pick her/his primary keys from candidate
keys. This gives more autonomy for sources and contributes in reconciling query
results. This issue is studied in this paper, where a methodology of integrating
ontology-based databases referencing a shared ontology enriched by functional
dependencies is given in a mediator architecture.
The paper is structured as follows. Section 2 presents the concepts and the
formal denitions of ontology and OBDB. Section 3 describes an extension of
ontology model by F D and shows their impact on data reconciliation. Section 4
describes in details our integration system with its main components. Section 5
presents experimental studies. Section 6 concludes the paper.
2 Background
In this section, we present concepts and denitions related to the ontology and
data ontology-based database to facilitate the understanding of our proposal.
Formal Model for Ontologies. In this work, we concentrate on canonical ontolo-

gies that describe concepts and not the words of a language and whose denitions
do not contain any redundancy. They adopt an approach of structuring of in-
formation in term of classes and properties and associate to these classes and
properties a single identiers reusable in various languages. These ontologies can
be considered as shared conceptual models. They contain the core classes and play
the role of a global schema in database integration architecture. Formally, a such
ontology is dened as the quadruplet O :< C, P, Sub, Applic > [3], where: (-) C
is the set of the classes used to describe the concepts of a given domain; (-) P
is the set of properties used to describe the instances of the C classes; (-) Sub is
the subsumption function dened as Sub: C 2C . For a class c of the ontology,
it associates its direct subsumed classes. Sub denes a partial order over C. (-)
Applic is a function dened as Applic : C 2P . It associates to each class of the
ontology, the properties that are applicable for each instance of this class and
that may be used, in the database, for describing its instances. Note that for
each c C, only a subset of Applic(c) may be used in any particular database,
for describing c instances.
OBDB is a database usually composed of four part [7], since it stores both data
and ontology describing their sense. Part 1 and 2 are traditional parts available
in all DBMSs, namely the data part that contains instance data and meta-base
part that contains the system catalog. The ontology part (3) allows the repre-
sentation of ontologies in the database. The meta-schema (4) part records the
ontology model into a reexive meta-model. For the ontology part, the meta-
schema part plays the same role as the one played by the meta-base in tra-
ditional databases. By means of naming convention, the meta-base part also
represents the logical model of the content, and its link with the ontology, thus
representing implicitly the conceptual model of data in database relations. For-

mally, an OBDB is a quadruplet < O, I, Sch, Pop >, where: (-) O is an ontology
O :< C, P, Sub, Applic >, (-) I is the set of instances of the database. The se-
mantics of these instances is described in O by characterizing them by classes
and properties values, (-) P op : C 2I associates to each class its own instances.
Pop(c) constitutes the population of c, (-) Sch: C 2P associates to each ontol-
ogy class c of C the properties, which are eectively used to describe the instances
of the class c. For each class c, Sch(c) must satisfy: Sch(c) Applic(c).
3 Adding Functional Dependencies to Ontologies
Traditional ontology formalisms do not support F D in their denition. Data

dependencies have been introduced as a general formalism for a large class of
database constraints that augments the expressivity of database models [1]. F D
compose a particularly interesting data dependency that elegantly models the
relationships between attributes of a relation. F D are used for dening primary
keys and in the normalization theory. Other important application of F D in
database includes query rewriting and query evaluation [13]. If we transpose
similar rules to ontology world, we discover that F D could be very useful to
enrich the expressivity of the knowledge representation and data cleaning [9].
Recently, couple of research studies F D in the context of ontologies. Two
main categories of F D are distinguished [5,6,16,18]: (1) intra-class dependencies
and (2) inter-class dependencies. In the rst category, we nd the work of [2]
which is quite similar to those proposed in traditional databases. Each ontology
class c may have a set of F D dened on its simple properties {p1 , ..., pn }1 .
The second category involves dependency between classes. Two types arise:
(1) F D with a single class in the left part and (2) F D with several classes in
the left part. In the rst type; we nd the work of [16]. The authors dene a
F D (C1 C2 ) between classes C1 and C2 when each instance of the class C1
determines a single instance of the class C2 . In the second type, [5] denes a F D
(R : {C1 , ..., Cn } C) between the classes {C1 , ..., Cn } linked to a root class
R by properties (or properties chains) and a class C linked to the root class by
a property (or properties chain), if the instances of the n classes determines a
single instance of the class C.
Since, F D are a part of ontologies (ontological concept), we propose to extend
the initial formal model of ontologies by considering F D. To do so, we rst
formalise the F D in a similar way as [5]. A F D is composed of the following
elements: the left part LP , the right part RP and a root class R. This denition
can also be expressed as an implication, as in traditional F D: f d R : LP RP
with R a class, LP = {p1,1 , ..., pn,mn } a set of paths (properties chains) and
RP = {p1 , ..., pl } a path (chain of properties). The left part LP is a set of n
paths. A path is composed of a chain of properties, each one being pi . The right
part is dened by a single path, which is composed of l properties. The root class
1
A simple property is a property with atomic range.
R is the starting point of all paths in the left part and the right part, so that a
F D expresses relationships among properties of a single instance of the class R.
After the F D formalisation, we propose to extend the initial ontology model
proposed in Section 2 as follows: O :< C, P, Sub, Applic, F D >, where F D is a
binary relationship F D: C (2P 2P ... 2P , 2P ) which associates to each
class c of C, the set of the functional dependencies (LP, RP ), where the class c
is the root (f d c : LP RP ).
Note that reconciliation of query results in a mediator architecture leads to
four possible cases: (1) manual reconciliation based on the experience and deep
knowledge of data sources of designers which is practically impossible in the
real life, where a large number of sources is involved. (2) Only sources having
common identiers are taken into consideration to process queries. In this case,
mediator may propagate the query on sources having the common identiers.
This solution compromises the quality of returned results. (3) Query results are
merged, where some instances overlap which may cause error. (4) Overlapping
instances may be discarded using probabilistic reconciliation.
The presence of F D may help and facilitate the data reconciliation, especially
when no common identier is used by various sources. To illustrate this point,
let us consider the following example.
Example 1. Let S1 , S2 and S3 be three sources containing the same relation
Customer. With dierent properties as follows: S1 .Customer (id(PK), name,
address, phoneNumber), S2 .Customer (id(PK), name, phoneNumber) and
S3 .Customer (phoneNumber(PK), name, address). On this table, the following
F D are dened: f d1 : Customer : id name, f d2 : Customer : id address,
f d3 : Customer : id phoneN umber, f d4 : Customer : phoneN umber
name, f d5 : Customer : phoneN umber address.
This table has two candidate keys: id and phoneN umber. Suppose that the
mediator schema contains a Customer relation with the following properties:
id(P K), name, address. Suppose the following query: list names and addresses
of all customers. The mediator decomposes this query on the three sources.
Without F D, we cannot reconcile all sources, since the source S3 has dierent
identier. By using f d4 : phoneN umber name and f d5 : phoneN umber
address, we notice that the attribute phoneN umber is a common candidate key
between the three sources. Therefore, a reconciliation of the results coming from
these three sources becomes possible.
4 Our Integration Methodology

Contrary to classical systems which require the existence of all sources before
running the integration process, our system integrates the sources on their ar-
rival. The mediator global schema is incrementally enriched when considering a
new source. Dierent modules composing our integration system are described
in Figure 1: (1) an OBDB repository, (2) a user interface, (3) a query engine and
(4) a result reconciliator.
Fig. 1. Dierent Components of our Integration System
4.1 The OBDB Repository

Our mediator uses the same structure as the used sources participating in the
integration process. It follows OntoDB model [7], where two parts are well iden-
tied (Section 2) (Figure 4. The meta-schema part of this repository contains
(i) a mediator and source schema model, (ii) a model of mapping between the
mediator ontology and source ontologies and (iii) a F D model. In the ontology
part, we store the mediator ontology, source ontologies and schemas, the map-
ping between the mediator ontology and source ontologies and the F D between
the classes and properties of the mediator ontology. The data part can be used
as a caching for optimise queries (in this work this issue is not addressed).
Formally, the ontology part is dened as a triplet < G, S, M >, where:
1. G :< O, Sch > is the global schema which is composed of the mediator
ontology O :< C, P, Applic, Sub, F D > and the schema Sch of this ontology
classes. Sch : C 2P associates to each mediator ontology class c of C the
properties describing the instances of the class c, which are valuated in at
least one integrated source.
2. S is the set of source schemas, where each source schema is dened as a
acouple Si :< OLi , SchLi >. Oi :< Ci , Pi , Applici , Subi , F Di > is the on-
tology of Si and SchLi : CLi 2P Li is the schema of the OLi ontology
classes.
3. M is the mapping between the classes of mediator ontology O and the
classes of source ontologies OL. M : C 2{CL1 ...CLn} associates to each
mediator ontology class c of C the classes of source ontologies in correspon-

dence with the class c.
Before starting the integration process, the integration system components are
initialized as follows: The mediator ontology O is imported by selection of classes
and properties from a shared ontology Os :< Cs , Ps , Applics , Subs , F Ds >. The
process is done following these steps:
1. Starting from users requirements, the administrator of the mediator selects
classes and properties from the shared ontology.
2. The selected classes and properties are added to the mediator ontology.
3. If an imported class has a super class, its super class is imported also, and
so on if its super class has a super class until attaining the root class in the
hierarchy.
4. To keep the semantic of complex properties (object properties), the impor-
tation of a complex property involves the importation of its range class.
5. Likewise, to keep F D, the importation of a property appearing in a right
part of a F D implies the importation of all the properties of the left part of this
F D.
The schema Sch, the source schemas S and the mapping M are initially empty
(Sch(c) = c C, S = and M(c) = c C).
Integrating a new source. the mediator ontology is determined only once whereas
the schema Sch, the source schemas S and the mapping M are updated af-
ter each integration of a new source. The integration of a new source Si :<
Oi , Ii , Schi , P opi > is run in the following steps:
1. We update the source schemas S by adding the schema of the new source
(S = S Si :< OLi , SchLi >).
2. In the ontology OLi :< CLi , P Li , SubLi , ApplicLi >, we keep only classes
and properties existing in the mediator ontology (OLi = O Oi ).
3. We import the schemas of the OLi classes from Schi (c CLi SchLi (c) =
Schi (c)).
4. We update the schema of the mediator ontology classes Sch by adding the
properties valuated in Si to the schema of their classes (Sch(c) = Sch(c) {p
SchLi (c)}).
5. We update the mapping of the mediator classes by adding the mapping be-
tween the classes of the mediator ontology O and the classes of the new source
ontology OLi (c CLi M(c) = M (c) Si .c).
4.2 The User Interface

It allows the user to express her/his query and displays its results. After pressing
the input query, the user interface send to the query engine a Select-Project-Join
queries dened on a set of classes and properties of the mediator ontology.
4.3 The Query Engine
The query engine performs the following tasks for a given user query Qi . Let
P roj be the set of projected properties used in Qi . Among this set, two types of
F D may be distinguished: (1) direct F D already exist in the mediator ontology,
where a property from P roj exists in the right part of F D and (2) generated F D
obtained using a similar algorithm of [15]. The presence of both types of depen-
dencies allows us to generate the reconciliation key. The query engines identies
then the relevant sources and rewrites a global query dened on mediator on-
tology in local queries dened in sources, where each one is sent to relevant
sources. Finally, the reconciliator merges the results using the reconciliation key
and sends the nal result to the user interface.
5 Validation of Our Architecture
To validate the feasibility and eciency of our system, we conduct experiments

using dataset of Lehigh University Benchmark (LUBM) and its 14 queries2 . The
used ontology of LUBM has 45 classes and 32 properties (including 25 object
properties, and 7 data type properties). Based on this ontology a set of ontology-
based databases is generated. All experiments have been carried out on an Intel
Pentium IV machine, with 3,2 GHz processor clock frequency, equipped with 1
Gb of RAM, under the operating system Windows XP professional. Two main
Fig. 2. Query Response Time vs. Number of Sources
experiments are conducted to evaluate the scalability of our system based on

the number of sources and instances. Figure 2 shows the results of executing
14 queries in (millisecond) by varying the number of sources participating in
the integration process from 10 to 50. Generated sources have the same schema
(22 relations). The biggest relation has 2000 tuples. The obtained results show
2
http://swat.cse.lehigh.edu/projects/lubm/
that our system executes eciently queries involving a small set of classes (less
joins) (e.g. Q14 (x):- UndergraduateStudent(x)), but, for queries involving large
number of classes (e.g. Q9 (x):- Student(x), Faculty(y), Course(z), advisor(x, y),
takesCourse(x, z), takesCourse(y, z)), the response time is quite high, but still
reasonable. An interesting issue from this result is to separate the query response
time into two parts: mediator processing time (including nding the functional
dependencies that hold in the query, deriving the reconciliation key and recon-
ciliation of result) and local query evaluation.
In the same direction of the previous experiment, we conduct another one,
by considering low costly and high costly queries (Q7 and Q9) and varying the
number of instances of 10 used sources. Figure 3 shows the obtained results. An
interesting result came from the query 10 considered as low costly query in the
rst experiments, but when the number of instances increases, join operation
becomes costly where it becomes costly. This shows the query response time
depends heavily on the sources and their ability of processing queries and not
on the mediator.
Fig. 3. Query Response Time vs. Number of Sources
6 Conclusion
The need for developing semantic integration systems increases with the evo-
lution of domain ontologies in various systems such as engineering, medicine,
etc. The presence of ontologies contributes largely in solving heterogeneity of
sources. Some actual integration systems suppose that the manipulated sources
have similar keys to ensure data integration which violates the autonomy charac-
teristic of sources. Others use statistical techniques to reconcile data. In sensitive
domains, such techniques cannot be used. In this paper, we proposed a complete
ontology-based integration method that covers most important phases of system
integration life cycle. The presence of ontology contributes for both reducing het-
erogeneity and oering mechanisms for data reconciliation, since it is enriched
by functional dependencies dened on each ontology class. Our approach is eval-
uated using the dataset of Lehigh University Benchmark. The obtained results
show its eciency and feasibility.
Two main issues that arise from our preliminary work should be explored: (i)
conducting of a large scale evaluation to measure the real eciency of our system
and (ii) dening of metrics to measure the quality of our integration system.
References
1. Abiteboul, S., Hull, R., Vianu, V.: Foundations of Databases (1995)
2. Bellatreche, L., Ait Ameur, Y., Chakroun, C.: A design methodology of ontology
based database applications. Logic Journal of the IGPL, 118 (2010)
3. Bellatreche, L., Xuan, D.N., Pierra, G., Dehainsala, H.: Contribution of ontology-
based data modeling to automatic integration of electronic catalogues within engi-
neering databases. Computers in Industry Journal Elsevier 57(8-9), 711724 (2006)
4. Bleiholder, J., Naumann, F.: Data fusion. ACM Computing Surveys 411(1), 141
(2008)
5. Calbimonte, J.P., Porto, F., Maria Keet, C.: Functional dependencies in owl abox.
In: Brazilian Symposium on Databases (SBBD), pp. 1630 (2009)
6. Calvanese, D., Giacomo, G., Lenzerini, M.: Identication constraints and functional
dependencies in description logics. In: Proc. of IJCAI, pp. 155160 (2001)
7. Dehainsala, H., Pierra, G., Bellatreche, L.: OntoDB: An ontology-based database
for data intensive applications. In: Kotagiri, R., Radha Krishna, P., Mohania, M.,
Nantajeewarawat, E. (eds.) DASFAA 2007. LNCS, vol. 4443, pp. 497508. Springer,
Heidelberg (2007)
8. Dong, X.L., Naumann, F.: Data fusion - resolving data conicts for integration.
PVLDB 2(2), 16541655 (2009)
9. Fan, W.: Dependencies revisited for improving data quality. In: PODS, pp. 159170
(2008)
10. Goh, C.H., Bressan, S., Madnick, E., Siegel, M.D.: Context interchange: New fea-
tures and formalisms for the intelligent integration of information. ACM Transac-
tions on Information Systems 17(3), 270293 (1999)
11. Hakimpour, F., Geppert, A.: Global Schema Generation Using Formal Ontologies.
In: Spaccapietra, S., March, S.T., Kambayashi, Y. (eds.) ER 2002. LNCS, vol. 2503,
pp. 307321. Springer, Heidelberg (2002)
12. Halevy, A.Y., Ashish, N., Bitton, D., Carey, M.J., Draper, D., Pollock, J., Rosen-
thal, A., Sikka, V.: Entreprise information integration: successes, challenges and
controversies. In: SIGMOD, pp. 778787 (2005)
13. Hong, J., Liu, W., Bell, D.A., Bai, Q.: Answering queries using views in the presence
of functional dependencies. In: Jackson, M., Nelson, D., Stirk, S. (eds.) BNCOD
2005. LNCS, vol. 3567, pp. 7081. Springer, Heidelberg (2005)
14. Mena, E., Kashyap, V., Sheth, A.P., Illarramendi, A.: Observer: An approach for
query processing in global information systems based on interoperation across pre-
existing ontologies. In: CoopIS, pp. 1425 (1996)
15. Mohania, M.K., Radha Krishna, P., Pavan Kumar, K.V.N.N., Karlapalem, K.,
Vincent, M.W.: Functional dependency driven auxiliary relation selection for ma-
terialized views maintenance. In: COMAD (2005)
16. Romero, O., Calvanese, D., Abello, A., Rodriguez-Muro, M.: Discovering functional
dependencies for multidimensional design. In: ACM 12th Int. Workshop on Data
Warehousing and OLAP (2009)
17. Sas, F., Pernelle, N., Rousset, M.C.: Combining a logical and a numerical method
for data reconciliation. Journal of Data Semantics 12, 6694 (2009)
18. Toman, D., Weddell, G.E.: On keys and functional dependencies as rst-class citi-
zens in description logics. J. of Automated Reasoning 40(2-3), 117132 (2008)
A Comprehensive Framework on
Multidimensional Modeling
Oscar Romero and Alberto Abello
Universitat Politècnica de Catalunya, BarcelonaTech

Barcelona, Spain
{aabello,oromero}@essi.upc.edu
Abstract. In this paper we discuss what current multidimensional de-

sign approaches provide and which are their major aws. Our contribu-
tion lays in a comprehensive framework that does not focus on how these
approaches work but what they do provide for usage in real data ware-
house projects. So that, we do not aim at comparing current approaches
but set up a framework (based on four criteria: the role played by end-
user requirements and data sources, the degree of automation achieved
and the quality of the output produced) highlighting their drawbacks,
and the need for further research on this area.
1 Introduction
Developing a data warehousing system is never an easy job, and raises up some
interesting challenges. One of these challenges focuses on modeling multidimen-
sionality. OLAP tools are conceived to exploit the data warehouse for analysis
tasks based on the multidimensional (MD) paradigm and therefore, the data
warehouse must be structured according to the MD model. Lots of eorts have
been devoted to MD modeling, and several models and design methods have
been developed and presented in the literature. Consequently, we can nowadays
design a MD conceptual schema, create it physically and later, exploit it through
the model algebra or calculus (implemented in the exploitation tools).
MD modeling was rst introduced by Kimball in [9]. Kimballs approach was
well received by the industry and also introduced the rst method to derive
the data warehouse logical schema. Similar to traditional information systems
modeling, Kimballs method is requirement-driven: it starts eliciting business
requirements of an organization and through a step-by-step guide we are able to
derive the MD schema. Only at the end of the process data sources are considered
to map data from sources to target.
In short, Kimballs approach follows a traditional modeling approach (i.e.,
from requirements), but it set down the principles of MD modeling. MD modeling
is radically opposite to OLTP systems modeling: the data warehouse conceptual
schema is directly derived from the organization operational sources and provides
a single, detailed, integrated and homogenized view of the business domain.
Consequently, the data warehouse can be thought as a strategic view of the

A Comprehensive Framework on Multidimensional Modeling 109
organization data and for this reason, and unlike most information systems that
are designed from scratch, the organization data sources must be considered as
rst-class citizens in the data warehouse design process. This major additional
requirement has such interesting consequences so much so that it gave rise to
a new research topic and up to now, several MD modeling methods have been
introduced in the literature. With the perspective of time, we may now highlight
those features that drew the attention of the community. The evolution of the
modeling methods introduced in the literature pivots on a crucial aspect: the
dichotomy requirements versus data sources (and how to deal with it).
In this paper we discuss what current approaches provide and which are their
major aws. Our contribution lays in a comprehensive framework that does not
focus on how these approaches work but what they do provide. Importantly, note
that by no means we aim at comparing current approaches but providing a com-
prehensive, general picture on MD modeling and identify what is (yet) missing
on this area. The criteria used for this analysis can be summarized as follows: the
role played by end-user requirements and data sources for each method, the de-
gree of automation achieved and the quality of the output produced (i.e., which
MD concepts and features do they really consider). The use of this criteria is
justied by the conclusions drawn by a previous, exhaustive analysis of current
design methods that can be found in [17].
The paper is structured as follows. Section 2 summarizes briey our previous
research on MD design and highlights how this area evolved with time. Next,
Section 3 provides a detailed, comprehensive discussion of what can be achieved
by using current approaches in real projects. We wrap up the discussion pointing
out the main aws that still need to be addressed in order to better support the
data warehouse design.
2 Multidimensional Modeling
In this section we introduce the background of MD modeling. Our objective
here is to provide an insightful view of how this area evolved with time. The
interested reader is addressed to [17] for details.
Shortly after Kimball introduced his ad hoc modeling method for data ware-
houses [10], some other methods were presented in the literature (e.g., [4,6,2,7,12]).
Like Kimballs method, these methods were originally regarded as step-by-step
guides to be followed by a data warehouse expert who start gathering the end-
user requirements. However, unlike Kimballs work, they give more and more
relevance to the data sources. Involving the data sources in these approaches
means that it is compulsory to have well-documented data sources (e.g., with
up-to-date conceptual schemas) at the experts disposal but it also entailed two
main benets: on the one hand, the user may not know all the potential analysis
contained in the data sources and analyzing them we may nd unexpected poten-
tial analysis of interest to the user; on the other hand, we should assure that the
data warehouse can be populated with data available within the organization.
As said, to carry out these approaches manually it is compulsory to have well-
documented data sources, but in a real organization, the data sources
110 O. Romero and A. Abell
o
documentation may be incomplete, incorrect or may not even exist [6] and,
in any case, it would be rather dicult for a non-expert designer to follow these
guidelines. Indeed, when automating this process is essential not to depend on
the experts ability to properly apply the method chosen and to avoid the tedious
and time-consuming task (even unfeasible when working over large databases)
of analyzing the data sources.
In order to solve these problems, several new methods automating the design
task were introduced in the literature [14,21,8]. These approaches work directly
over relational database logical schemas. Thus, despite they are restricted to a
specic technology, they get up-to-date data that can be queried and managed by
computers. They also argue that restricting to relational technology makes sense
since nowadays it is the most widely used technology for operational databases.
About the process carried out, these methods follow a data-driven process fo-
cusing on a thorough analysis of the data sources to derive the data warehouse
schema in a reengineering process. This process consists of techniques and de-
sign patterns that must be applied over the data sources schema to identify data
likely to be analyzed from a MD perspective.
Nevertheless, a requirement analysis phase is crucial to meet the user needs
and expectations [3,5,22,15,11,1]. Otherwise, the user may nd himself frustrated
since he / she would not be able to analyze data of his / her interest, entailing
the failure of the whole system. Today, it is assumed that the ideal scenario
to derive the data warehouse conceptual schema embraces a hybrid approach
(i.e., a combined data-driven and requirement-driven approach) [22]. Then, the
resulting MD schema will satisfy the end-user requirements and it will have been
conciliated with the data sources simultaneously.
According to [22], MD modeling methods may be classied within a demand-
driven, a supply-driven or a hybrid framework:
Supply-driven approaches (SDAs): Also known as data-driven, start from

a detailed analysis of the data sources to determine the MD concepts in a
reengineering process.
Demand-driven approaches (DDAs): Also known as requirement-driven or
goal-driven, focus on determining the user MD requirements (as typically
performed in other information systems) to later map them onto data sources.
Hybrid approaches: Combine both paradigms to design the data warehouse
from the data sources but bearing in mind the end-user requirements.
Each paradigm has its own advantages and disadvantages. Carrying out an ex-
haustive search of dimensional concepts among all the concepts of the domain
(like SDAs do) has a main benet with regard to those approaches that derive
the schema from requirements and later conciliate them with the data sources
(i.e., DDAs): in many real scenarios, the user may not be aware of all the po-
tential analysis contained in the data sources and, therefore, overlook relevant
knowledge. Demand-driven and current hybrid approaches do not consider this
and assume that requirements are exhaustive. Thus, knowledge derived from
the sources not depicted in the requirements is not considered and discarded.
As a counterpart, SDAs tend to generate too many results (since they overlook
the MD requirements, they must apply their design patterns all over the data
sources) and mislead the user with non relevant information. Furthermore, DDAs
(or demand-driven stages within a hybrid approach) are not automated whereas
supply-driven stages tend to facilitate their automation. The main reason is
that demand-driven stages would require to formalize the end-user requirements
(i.e., translate them to a language understandable by computers). Unfortunately,
most current methods handle requirements mostly stated in languages (such as
natural language) lacking the required degree of formalization. Thus, matching
requirements over the data sources must be performed manually. However, the
time-consuming nature of this task can render it unfeasible when large databases
are used.
In general, most approaches do not automate the process and just present a
set of steps (i.e., a guideline) to be followed by an expert in order to derive the
MD schema. Mainly, these methods introduce dierent patterns or heuristics to
discover concepts likely to play a MD role and to carry out these approaches
manually it is compulsory to have well-documented data sources at the experts
disposal. This prerequisite is not easy to fulll in many real organizations and
in order to solve this problem, current automatable methods directly work over
relational databases (i.e., getting up-to-date data). To our knowledge, only three
exceptions exist to this rule [20,19,13], which automate the process from ER
schemas (the rst one) and ontologies (the other two). Consequently, all these
methods (or stages within hybrid approaches) follow a supply-driven paradigm
and thus, rely on a thorough analysis of the sources.
All in all, DDAs assume that requirements are exhaustive, whereas SDAs rely
on discovering as much MD knowledge as possible. As a consequence, SDAs
generate too many results. Furthermore, current automatable methods follow a
SDA, whereas current DDAs overlook the process automation, since they tend to
work with requirements at a high level of abstraction. Finally, all current hybrid
approaches follow a sequential approach with two well-dierentiated steps: the
supply-driven and the demand-driven stages. Each one of these stages, however,
suers from the same drawbacks as pure SDAs or DDAs do.
2.1 The State of the Art in a Nutshell

Previous experiences in the data warehouse eld have shown that the data ware-
house MD conceptual schema must be derived from a hybrid approach: i.e., by
considering both the end-user requirements and the data sources, as rst-class
citizens. Like in any other system, requirements guarantee that the system de-
vised meets the end-user necessities. In addition, since the data warehouse design
task is a reengineering process, it must consider the underlying data sources of
the organization: (i) to guarantee that the data warehouse must be populated
from data available within the organization, and (ii) to allow the end-user dis-
cover unknown additional analysis capabilities.
Nowadays, we may nd several methods for supporting the data warehouse
conceptual design but, all of them, start from very dierent assumptions that
o
make them hardly comparable. For example, some approaches claim to fully au-
tomate the design task, but they do so by overlooking the end-user requirements
in a fully SDA (and thus, making the user responsible for manually ltering the
results obtained according to his / her needs). Similarly, exhaustive DDAs claim
to derive high-quality outputs, but they completely overlook the task automa-
tion. For this reason, every approach ts to a narrow-ranged set of scenarios and
do not provide an integrated solution for every real-world case, which, in turn,
makes the data warehouse designers to come up with ad hoc solutions for each
project. For example, we cannot follow the same approach in a scenario where
the end-user requirements are clear and well-known, and in a scenario in which
the end-user requirements are not evident or cannot be easily elicited (e.g., this
may happen when the users are not aware of the analysis capabilities of their
own sources). Clearly, this is the major aw of current approaches, which do not
suit well for the wide range of real projects a designer could meet. Interestingly,
it has already been pointed out [18] that, given a specic design scenario, the
necessity to provide requirements beforehand is smoothed by the fact of having
semantically rich data sources. In lack of that, requirements gain relevance to
extract the MD knowledge from the sources. In both cases, we can still achieve
an acceptable degree of automation and output quality, as discussed later on.
3 The Big Picture
To overcome the situation above discussed, we aim to establish a clear framework

in which to place the most relevant design methods introduced in the literature.
This comprehensive picture of the state of the art will help to identify the major
drawbacks of current approaches. As earlier introduced in this paper, the data
warehouse design task must consider (i) the end-user requirements and (ii) the
data sources. Furthermore, we also aim to analyze the (iii) automation degree
achieved and (iv) the quality of the output produced. In the following, we rate
the most relevant methods introduced in the literature with regard to these
four criteria. However, we do not intend to classify nor rank approaches (for
a detailed comparison on MD design methods, see [17]) but to identify, at rst
sight, the assumptions made by each kind of approach and moreover, analyze the
consequences of the process proposed regarding the automation degree achieved
and the quality of the outputs produced. In short, identify trends and aws that
should be addressed in the future.
Consider Figures 1 and 2. Axes x and y represent the assumptions of each
method; i.e., the use of the requirements and the data sources in each approach.
The x axis measures how important requirements are in the approach, and if
the method proposes to formalize them somehow, to facilitate their analysis.
The y axis assesses how important the analysis of the data sources is for the
approach, and if detailed patterns are provided to exploit them. Finally, axes z
measure either the automation degree achieved (see Figure 1) and the quality
of the output produced (see Figure 2) regarding the assumptions made by the
method (i.e., axes x and y). In the 3D-space formed, every approach is identied
Fig. 1. Output quality analysis
as a rhombus labeled with the rst initial of each author plus the year of the
bibliographical item it represents. Furthermore, for the sake of understandability,
we provide the projection of each rhombus in the three planes (green points for
the XZ plane projections; blue points for the XY plane and red points for the
XZ plane). Each approach is placed in the 3D-space according to the conclusions
extracted from [17]. The rst conclusion is that the duality requirements / data-
sources is clearly shown in both gures, as SDAs and DDAs are placed in opposite
axis (to better appreciate it, check the plane projections of each point).
Requirements Specicity: DDAs integrate the end-user requirements, which
lead the whole process by exploiting the knowledge of the requirements. There-
fore, the quality and expressiveness of the input requirements must be high. On
the contrary, at the beginning of the process, SDAs do not need the end-user
requirements to work. Indeed, results provided by SDAs, are eventually shaped
by the end-user needs a posteriori. In this latter step, the end-user just state
his / her requirements by choosing his / her concepts of interest regarding the
results provided. Therefore, the user would even be able to state them on-the-y
regarding the output presented to the user by SDAs.
Data Source Expresiveness: SDAs lead the process from a thorough analysis
of the data sources and, in general, they ask for high quality inputs capturing
the data sources (i.e., relational schema, ER diagram, domain ontology, etc.). In
case of inputs at the conceptual level, a mapping between the conceptual schema
and the sources as well as means to access the data sources at the instance level
are also required. Regarding DDAs, the quality of the inputs is not that relevant
o
Fig. 2. Automation analysis
given that the requirements provide the lack of semantics captured in the sources.
Thus, they could even handle not well-formed data sources (e.g., denormalized
sources).
Automation: The rst gure shows that the automation degree achieved, in the
general case, is medium or low. Only 6 approaches automate the design task up
to a fair degree. Regarding DDAs, new techniques to automatically manipulate
requirements during the design phase are needed. In this sense, [16] sets a basis
on this direction but it can only deal with relational sources. Oppositely, SDAs
achieve an interesting degree of automation, but most of them happen not to be
useful in practice due to the big set of assumptions made. For example, the kind
of sources (normally, only relational sources are allowed but this is clearly unsat-
isfactory nowadays, where unstructured data and the Web is a relevant source
of knowledge) or additional ones (such as relational schemas in, at least, 3NF).
Furthermore, ltering techniques based on objective evidences are a must. SDAs
tend to generate too many results. Consequently, they unnecessarily overwhelm
users with blindly generated combinations whose meaning has not been analyzed
in advance. Eventually, they put the burden of (manually) analyzing and ltering
results provided onto the designers shoulder, but the time-consuming nature of
this task can render it unfeasible when large data sources are considered. To our
knowledge, only [19] lters out results obtained prior to show the results to the
user. Furthermore, all these facts directly aect the computational complexity
of SDAs.
Quality Output: Both SDAs and DDAs are able to extract valuable knowledge
from the requirements / data sources but only a few of them deal with concepts
such as factless facts, MD space denitions, aggregate measures and semantic

relationships between the MD concepts identied. However, this is not tied to
the kind of framework used but a decision made by the authors. Indeed, both can
produce quality outputs if the appropriate inputs are provided. This is obviously
sound, since, given the same scenario, we would expect to obtain the same result
regardless of the approach chosen. The dierence between both approaches is just
on how we obtain the nal result depending on our current inputs and if they
provide enough semantics. Thus, DDAs are exhaustive regarding requirements
so in case of disposing of quality requirements a DDA suits better. However, if
requirements are not clear but we dispose of quality data sources then a SDA
is mandatory. For example, DDAs can compute derived measures or concept
specializations not explicitly captured in the data sources, but present in the
end-user requirements. However, this kind of measures and specializations can
only be identied by SDAs if they are captured in the input representation of
the data sources (and thus, only if they are of enough quality). Analogously, this
also happens regarding semantic relationships between MD concepts, aggregate
measures and MD space denitions. The case of the factless facts, however, is
slightly dierent. DDAs might identify them by means of requirements, but in
SDAs, some kind of quality function used to identify facts would be needed [19].
4 Discussion and Conclusions
Several methods for supporting the data warehouse modeling task have been
provided. However, they suer from some signicant drawbacks, which need to
be addressed. In short, DDAs assume that requirements are exhaustive (and
therefore, do not consider the data sources to contain alternative interesting ev-
idences of analysis), whereas SDAs (i.e., those leading the design task from a
thorough analysis of the data sources) rely on discovering as much MD knowl-
edge as possible from the data sources. As a consequence, SDAs generate too
many results, which misleads the user. Furthermore, the design task automation
is essential in this scenario, as it removes the dependency on an experts ability
to properly apply the method chosen, and the need to analyze the data sources,
which is a tedious and time-consuming task (which can be unfeasible when work-
ing with large databases). In this sense, current automatable methods follow a
SDA, whereas current DDAs overlook the process automation, since they tend
to work with requirements at a high level of abstraction. Indeed, this scenario
is repeated regarding SDA and DDA stages within current hybrid approaches,
which suer from the same drawbacks than pure DDA and SDA approaches.
Consequently, previous experiences in this eld have shown that the data
warehouse MD conceptual schema must be derived from a truly hybrid approach:
i.e., by considering both the end-user requirements and the data sources, as rst-
class citizens. Currently, several methods (i.e., detailed design approaches) and
dissertations (i.e., high level discussions highlighting the necessities in each real
scenario) for supporting the data warehouse design task have been introduced in
the literature, but none of them provides an integrated and automated solution
o
embracing both aspects. On the one hand, dissertations about how the design
task must be adapted to every real-world scenario provide an insightful idea of
how to proceed in each case. However, they fail to provide detailed algorithms
to undertake this task (thus, ad hoc solutions are needed). On the other hand,
detailed methods introduced tend to focus on a narrow-ranged set of scenarios.
For example, today, it is assumed that the approach to follow in a scenario where
the end-user requirements are clear and well-known is completely dierent from
that in which the end-user requirements are not evident or cannot be easily
elicited (for example, this may happen when the users are not aware of the
analysis capabilities of their own sources). Similarly, the necessity to provide
requirements beforehand is smoothed by the fact of having semantically rich
data sources. In lack of that, requirements gain relevance to extract the MD
knowledge from the sources. Indeed, a combined and comprehensive framework
to decide, according to the inputs provided in each scenario, which is the best
approach to follow, is missing. This framework should be built considering that:
If the end-user requirements are well-known beforehand, we can benet from
the knowledge captured in the data sources, but we should guide the de-
sign task according to requirements and consequently, we will be able to
work and handle semantically poorer data sources. In other words, providing
high-quality end-user requirements, we can guide the process and overcome
the fact of disposing of bad quality (from a semantical point of view) data
sources.
As a counterpart, a scenario in which the data sources available are seman-
tically richer, the approach should be guided by a thorough analysis of the
data sources, which eventually will be properly adapted to shape the output
result and meet the end-user requirements. In this context, disposing of high-
quality data sources we can overcome the fact of lacking of very expressive
end-user requirements.
Acknowledgements. This work has been partly supported by the Ministerio

de Ciencia e Innovacion under project TIN2008-03863.
References
1. Annoni, E., Ravat, F., Teste, O., Zuruh, G.: Towards multidimensional require-
ment design. In: DaWaK 2006. LNCS, vol. 4081, pp. 7584. Springer, Heidelberg
(2006)
2. Bohnlein, M., vom Ende, A.U.: Deriving Initial Data Warehouse Structures from
the Conceptual Data Models of the Underlying Operational Information Systems.
In: Proc. of 2nd Int. Wksp on Data Warehousing and OLAP, pp. 1521. ACM,
New York (1999)
3. Bonifati, A., Cattaneo, F., Ceri, S., Fuggetta, A., Paraboschi, S.: Designing Data
Marts for Data Warehouses. ACM Trans. Soft. Eng. Method 10(4), 452483 (2001)
4. Cabibbo, L., Torlone, R.: A Logical Approach to Multidimensional Databases. In:
Schek, H.-J., Saltor, F., Ramos, I., Alonso, G. (eds.) EDBT 1998. LNCS, vol. 1377,
5. Giorgini, P., Rizzi, S., Garzetti, M.: Goal-oriented Requirement Analysis for Data
Warehouse Design. In: Proc. of 8th Int. Wksp on Data Warehousing and OLAP,
pp. 4756. ACM Press, New York (2005)
6. Golfarelli, M., Maio, D., Rizzi, S.: The Dimensional Fact Model: A Conceptual
Model for Data Warehouses. Int. Journal of Cooperative Information Systems
7(2-3), 215247 (1998)
7. Husemann, B., Lechtenb orger, J., Vossen, G.: Conceptual Data Warehouse Model-
ing. In: Proc. of 2nd Int. Wksp on Design and Management of Data Warehouses,
p. 6. CEUR-WS.org (2000)
8. Jensen, M.R., Holmgren, T., Pedersen, T.B.: Discovering Multidimensional Struc-
ture in Relational Data. In: Kambayashi, Y., Mohania, M., W o, W. (eds.) DaWaK
9. Kimball, R.: The Data Warehouse Toolkit: Practical Techniques for Building Di-
mensional Data Warehouses. John Wiley & Sons, Inc., Chichester (1996)
10. Kimball, R., Reeves, L., Thornthwaite, W., Ross, M.: The Data Warehouse Lifecy-
cle Toolkit: Expert Methods for Designing, Developing and Deploying Data Ware-
houses. John Wiley & Sons, Inc., Chichester (1998)
11. Maz on, J., Trujillo, J., Lechtenborger, J.: Reconciling Requirement-Driven Data
Warehouses with Data Sources Via Multidimensional Normal Forms. Data &
Knowledge Engineering 23(3), 725751 (2007)
12. Moody, D., Kortink, M.: From Enterprise Models to Dimensional Models: A
Methodology for Data Warehouse and Data Mart Design. In: Proc. of 2nd Int.
Wksp on Design and Management of Data Warehouses. CEUR-WS.org (2000)
13. Nebot, V., Llavori, R.B., Perez-Martnez, J.M., Aramburu, M.J., Pedersen, T.B.:
Multidimensional integrated ontologies: A framework for designing semantic data
warehouses. J. Data Semantics 13, 136 (2009)
14. Phipps, C., Davis, K.C.: Automating Data Warehouse Conceptual Schema Design
and Evaluation. In: Proc. of 4th Int. Wksp on Design and Management of Data
Warehouses., vol. 58, pp. 2332. CEUR-WS.org (2002)
15. Prat, N., Akoka, J., Comyn-Wattiau, I.: A UML-based Data Warehouse Design
Method. Decision Support Systems 42(3), 14491473 (2006)
16. Romero, O., Abell o, A.: Automatic Validation of Requirements to Support Multi-
dimensional Design. Data & Knowledge Engineering 69(9), 917942 (2010)
17. Romero, O., Abell o, A.: A Survey of Multidimensional Modeling Methodologies.
Int. J. of Data Warehousing and Mining 5(2), 123 (2009)
18. Romero, O.: Automating the Multidimensional Design of Data Warehouses.
Ph.D. thesis, Universitat Politecnica de Catalunya, Barcelona, Spain (2010),
http://www.tdx.cat/handle/10803/6670
19. Romero, O., Abell o, A.: A Framework for Multidimensional Design of Data Ware-
houses from Ontologies. Data & Knowledge Engineering 69(11), 11381157 (2010)
20. Song, I., Khare, R., Dai, B.: SAMSTAR: A Semi-Automated Lexical Method for
Generating STAR Schemas from an ER Diagram. In: Proc. of the 10th Int. Wksp
on Data Warehousing and OLAP, pp. 916. ACM, New York (2007)
21. Vrdoljak, B., Banek, M., Rizzi, S.: Designing Web Warehouses from XML Schemas.
In: Kambayashi, Y., Mohania, M., W o, W. (eds.) DaWaK 2003. LNCS, vol. 2737,
22. Winter, R., Strauch, B.: A Method for Demand-Driven Information Requirements
Analysis in DW Projects. In: Proc. of 36th Annual Hawaii Int. Conf. on System
Sciences, pp. 231239. IEEE, Los Alamitos (2003)
Preface to Variability@ER11
As software requirements constantly increase in size and complexity, the need for
methods, formalisms, techniques, tools and languages for managing and evolving
software artifacts become crucial. One way to manage variability when dealing with a
rapidly growing variety of software products is through developing and maintaining
families of software products rather than individual products. Variability management
is concerned with controlling the versions and the possible variants of software
systems. Variability management gained a special interest in various software-related
areas in different phases of the software development lifecycle. These areas include
conceptual modeling, product line engineering, feature analysis, software reuse,
configuration management, generative programming and programming language
design. In the context of conceptual modeling, the terminology of variability
management has been investigated, yielding ontologies, modeling languages, and
classification frameworks. In the areas of software product line engineering and
feature analysis, methods for developing core assets and efficiently using them in
particular contexts have been introduced. In the software reuse and configuration
management fields, different mechanisms for reusing software artifacts and managing
software versions have been proposed, including adoption, specialization, controlled
extension, parameterization, configuration, generation, template instantiation, analogy
construction, assembly, and so on. Finally, generative programming deals with
developing programs that synthesize or generate other programs and programming
language design provides techniques for expressing and exploiting commonality of
source code artifacts, but also for specifying the allowed or potential variability,
whether it is static or dynamic.
The purpose of this workshop is to promote the theme of variability management
from all or part of these different perspectives, identifying possible points of synergy,
common problems and solutions, and visions for the future of the area. The workshop
accepted 4 papers dealing with variability management related issues:
1. Mohammed Eldammagh and Olga De Troyer. Feature Modeling Tools:
Evaluation and Lessons learned.
2. Ateeq Khan, Gunter Saake, Christian Kaestner and Veit Koeppen. Service
Variability Patterns.
3. Angela Lozano. An Overview of Techniques for Detecting Software
Variability Concepts in Source Code.
4. Jaap Kabbedijk and Slinger Jansen. Variability in Multi-tenant
Environments: Architectural Design Patterns from Industry.
The workshop also had an invited talk given by Timo K. Kkl and entitled "ISO
Initiatives on Software Product Line Engineering: Vision and Current Status."
For more information about the workshop, please visit our web site at
http://www.domainengineering.org/Variability@ER11/
July 2011 Iris Reinhartz-Berger

Arnon Sturm
Kim Mens

ISO Initiatives on Software Product Line Engineering:
Vision and Current Status
Invited Talk for Variability@ER2011
Timo K. Kkl
University of Jyvskyl, Finland

timo.kakola@jyu.fi
Abstract. Software product line engineering and management is still a

relatively young discipline and its industrial diffusion is somewhat limited,
partly due to the lack of international standards. It involves sub-disciplines that
may not necessarily be mature enough yet for standardization. On the other
hand, well-focused standardization efforts contribute to the diffusion of best
product line practices and help raise the maturity of these practices. Careful
roadmapping and execution of the standardization initiative is thus vital. This
talk discusses the current roadmap for the international standardization initiative
of software product line engineering and management methods and tools and
the status of the work done so far in this area in the International Organization
for Standardization (ISO). One of the purposes of the talk is to invite discussion
about the most critical areas to be standardized and the time frames involved.
The role of variability management in the standards will be especially
emphasized.

Feature Modeling Tools:
Evaluation and Lessons Learned
Mohammed El Dammagh and Olga De Troyer
Vrije Universiteit Brussel, Pleinlaan 2,

1050 Brussels, Belgium
{Mohammed.ElDammagh,Olga.DeTroyer}@vub.ac.be
Abstract. This paper presents an evaluation of feature modeling tools. The

purpose of the evaluation was to gain insight in the aspects that influence the
quality and more in the particular usability. The evaluation focused on the quality
criteria: usability, safety, and the support for functional usability requirements.
The study involved 9 feature-modeling tools and was done using an experimental
evaluation and an investigation by the authors of the paper. From the results,
recommendations are formulated that can be taken into consideration in future
tool design for these kind of modeling tools.
Keywords: feature modeling tool, quality, usability, evaluation.
1 Introduction
During the past years, several variability modeling techniques as well as tools have
been developed to model variability during domain analysis [1]. Example modeling
techniques are: COVAMOF [2], OVM (Orthogonal Variability Modeling) [1], VSL
(Variability Specification Language) [3] and FAM (Feature Assembly Modeling) [4].
Notwithstanding the wide range of possible approaches to support variability
modeling, feature modeling remains the most commonly used technique for
identifying and capturing variability requirements and dependencies between product
characteristics. Also, most variability modeling tools support feature modeling [6].
Industrial software product lines are characterized by a rapid growth of the number of
variation points, associated variants and dependencies. Previous research points out that
there is a lack of adequate tools supporting this increase in variability information
[5,6,16]. Moreover, in the case of large-scale software systems, usability and scalability
issues quickly grow and become a major source of frustration [7].
Because of the importance of adequate tool support, we want to investigate how
the quality of feature modeling tools can be improved. As a first step in this research,
the quality of existing tools will be investigated in order to gain insight in the aspects
that influence the quality. Later on, we can then try to improve on these aspects. In a
first study performed in this context, we have concentrated on evaluating the quality
of existing tools from a usability point of view. Scalability issues will be investigated
in later work. In this paper, we present the results of this first study. For this study, we
selected 9 feature modeling tools [8] using a graphical user interface. These tools are
evaluated against the criteria Usability, Safety, and Functional Usability Features.
Feature Modeling Tools: Evaluation and Lessons Learned 121
The rest of the paper is organized as follows. We start by identifying the quality
criteria that we will use (Section 2). Next, we describe the methodology of our quality
evaluation in Section 3. Whereas Section 4 concerns the setup of the evaluation,
Section 5 concentrates on the results. Section 6 discusses the differences in quality
compliance of the tools and highlights the most important lessons learned. Next,
Section 7 mentions the related work. Finally, Section 8 recaps the main ideas and
presents further research.
2 Quality Criteria
For our quality evaluation of tools, we can use the system quality in use model, as
defined by ISO/IEC 9126, ISO 924111 and the ISO/IEC 25000 series of standards.
This model offers a broad framework of quality requirements. It consists of three
characteristics: usability, flexibility and safety. These are on their turn subdivided into
sub-characteristics. Accordingly, usability can be measured by the degree to which a
specified group of users conducts certain tasks with effectiveness, efficiency and
satisfaction. Whereas effectiveness is defined in terms of accuracy and
completeness, efficiency is defined in terms of resources expended in relation to
effectiveness. Satisfaction describes the extent to which users are satisfied. Similarly,
flexibility deals with the context within which the tool operates. Safety includes all
the potential negative effects resulting from incomplete or incorrect output [9].
For this first study, we decided to focus on usability and safety. We omit
flexibility, as in this study the context of use will be fixed. However, some other
aspects of flexibility will be measured by considering functional usability features
(FUFs), which are usability requirements with a major impact on the functionality.
According to Juristo [10], these are important to consider because of their high
functional implications. Since a relationship between usability and functional
requirements has been proven, functional requirements should be taken into
consideration in the case that they have an impact on usability attributes.
3 Methodology
The purpose of our study is to measure the quality of existing feature modeling tools
using the criteria identified in Section 2. Please note that, in no way, it is our purpose
to rank or give a judgment on the tools evaluated. The purpose of the study is to use
the information collected to draw some lessons learned, and to use this to make
recommendations on how to improve the quality of feature modeling tools in general.
3.1 Tools Identification
Firstly, tools were selected on their ability to support feature modeling. Secondly, we
selected tools with an interactive graphical user interface (GUI), in which the features,
types, feature group and feature dependencies are visualized. We decided to
concentrate on tools with a GUI, as the use of a GUI has many advantages [11],
especially in the communication with non-technical domain experts.
122 M. El Dammagh and O. De Troyer
To select the tools, we mainly based us on the study A systematic review of

domain analysis tools [6]. Nine of these 19 tools were executable. Seven of the
executable tools use feature modeling and thus were selected (CaptainFeature [19],
FeatureIDE [21], Pure::Variants [20], RequiLine [22], XFeature [23], GEARS [28]
and FeaturePlugin [29]). Of these seven tools, GEARS and FeaturePlugin were
abandoned. GEARS was not available to openly evaluate and FeaturePlugin missed
an interactive graphical interface. Thus, from the original list of 19 tools, 5 were
selected.
However, the study in [6] dated from January 2008, therefore, following the same
search strategy as provided in that review, we have added six new tools (MOSKitt
[24], Feature Modeling Tool [25], Feature Model DSL [26], CVM Tool [27], FORM
[20] and ToolDAy [31]). FORM and ToolDAy were excluded based on their non-
availability. Finally, nine tools were retained, as is shown in the Table 1.
It may be noted that most of the selected tools, except Pure::Variants, were
developed for an academic purpose. Three of these tools are designated to industrial
as well as academic environments. The fact that most tools are developed for
academic purposes, and therefore, should be considered more as prototypes rather
than as full-fledged tools, is not an issue. On the contrary, they may better reveal the
aspects influencing the quality of a tool, which is the main purpose of the study.
Table 1. Tools
Tool Developed by Used Released

T1 CaptainFeature Fachhochschule Kaiserlautern in Germany. A 2002
T2 Pure::Variants Pure-Systems company in Germany. I 2003
Otto-von-Guericke-University Magdeburg in
T3 FeatureIDE A 2005
Germany.
Research Group Software Construction in
T4 RequiLine B 2005
Germany.
An association of P&P Software Company with
T5 XFeature B 2005
the Swiss Federal Institute of Technology
gvCASE project by the Valencian Regional
T6 MOSKitt Ministry of Infrastructure and Transport in A 2008
Spain.
Feature Modeling Research Group of GIRO at the University of
T7 A 2008
Tool Valladolid and Burgos in Spain.
Gunther Lenz and Christoph Wienands in
T8 Feature Model DSL A 2008
Practical Software Factories in .NET book.
T9 CVM Tool European project ATESST in Germany. B 2009
I. Industrial, A. Academic, B. Both.
3.2 Evaluation Criteria
This study will evaluate whether and to which extend the nine tools support the
selected quality criteria, i.e. Usability and Safety, and whether the FUFs are present.
Usability
Efficiency: The expended resources as referred to in ISO 924111, are in our
experiment defined as follows. On one hand, task completion time (TCT) is measured
as the time that is needed to model the features, feature groups and feature
dependencies. On the other hand, the users effort (e) that is needed to complete the
task is measured as well. In order to calculate effort, we rely on [12]. Accordingly to
this work, effort (e) equals the number of mouse clicks (mc) + the number of
keyboard strokes (mk) + the number of mouse pixels traversed by the user - mouse
trajectory - (mic). Note that the time and effort to arrange the model according to
individual preferences (esthetic aspect) was excluded from the results.
Satisfaction: In order to evaluate the degree to which users are satisfied, we base
ourselves on the studies of [9] and [13]. Hence, participants were asked to rate the
following three statements: (Q1) You like very much to use the tool, (Q2) You
find the tool very easy to use and (Q3) You strongly recommend the tool to a
friend. A 5-point Likert scale has been used for this (1strongly disagree to 5
strongly agree).
Note that we will not measure effectiveness. In this study the accuracy and
completeness with which users achieve specified goals will not be considered as all
tools selected, support the creation of an accurate feature model.
Safety. We rely on the work of [14] to measure all the potential negative effects
resulting from incomplete or incorrect output [9]. The author draws a parallel
between inconsistent product configuration (output) and the disability of the tools to
provide automatic redundancy, anomaly and inconsistency checks, defined as follows:
Redundancy: Refers to information that is modeled in multiple ways. Redundancy
can decrease the maintainability of the model (negative effect), while on the other
hand it can increase the readability and understandability of the feature model
(positive effect). Hence, redundancy is considered as a light issue.
Anomalies: Refers to the modeling of senseless information. As a consequence,
potential configurations are being lost, although these configurations should be
possible. This can be considered as a medium issue.
Inconsistency: Refers to contradictory information within a model, i.e. information
that is conflicting with some other information in the model. Since inconsistent
product configuration can be derived from such a model, it is a severe issue.
Complementary to these three checks, a fourth measure of Safety has been added:
Invalid semantics: Since all the given tools support a feature model based on a tree
structure, the feature model should be modeled with respect to certain semantic rules
inherent to this tree structure, e.g., each child has only one parent.
In our study, the tools are tested on their compliance with these four safety checks
by using a rating scale from 0 to 3 (0not supported to 3fully supported).
Functional Usability Features. As motivated in Section 2, functional requirements

having a major impact on usability should be included in our evaluation. As a result, 7
FUFs have been selected from the initial lists of [10] according to their relevance:
Feedback: To inform the user about actions with important consequences.
Undo: To undo the users action in order to save time to recover from mistakes and
to make it more pleasant to work with the tools.
Form/Field Validation: To improve data input and software correction as soon as

possible.
Shortcuts: To allow the user to activate a task with one quick gesture.
User Expertise: To customize the functionalities of the tool to the users
preferences and experience. E.g., does the user have more than one way to perform
his action, or is the user able to create his own shortcuts.
Reuse information (cut, copy and paste): To allow the user to easily move data.
Help: To provide different support.
To evaluate the FUFs, the same rating scale as to measure Safety is used.
4 Setup of the Evaluation

The evaluation has been achieved in two steps: an experimental evaluation followed
by a questionnaire, and an investigation performed by the authors of this paper.
As our main purpose was to obtain a better understanding of how and to which
extent the existing tools offer quality support during the modeling process, we opted
for a small-scale experiment. Five persons were asked to create a small feature
diagram having 20 features, two feature groups and two feature constraints. Although
five participants is a small number, it has been shown that five participants are
sufficient to discover 85% of the usability problems [15]. Next, we opted for a small
feature diagram, as scalability will be studied separately.
We divided the experiment into three main sub processes: (1) specifying features
(refers to feature and its type), (2) specifying feature groups (alternative or or-
relationship), and (3) specifying feature constraints. Each of these sub processes is
measured against the criteria for efficiency, i.e. task completion time and effort. In
order to record all the activities of the participants, programs recording screen
activities have been used, i.e. ALLCapture [32] and WinOMeter [33].
The participants were 4 PhD students, and 1 PhD graduated in computer science,
having good modeling experience and skills. To make them acquainted with the tools,
a demo for each tool was made and handed over in advance to the participants. This
demo explains all the functionalities to know in order to do the experiment.
The 9 tools were evaluated in 3 sessions (three tools in one session). Each day one
session took place in order not to overload the participants. As mentioned earlier,
satisfaction was measured by using a questionnaire that was handed over after the
usage of the tool. The participants also had the opportunity to justify their answers.
Safety and the FUFs were evaluated by the authors themself. As to measure Safety,
the authors tested in the first place if the tools possess a check for redundancy,
anomalies, inconsistency, and invalid semantics. Secondly, a situation analogue to
each of the four deficiencies has been modeled with each tool. The results were given
using a rating scale from 0 to 3. The same rating scale has been used for the FUFs.
The authors examined if each of the FUFs, as listed earlier, were present in the tools.
5 Results
We discuss the results of the evaluation following the evaluation criteria:
Usability
Efficiency: One-way analyses of variance (ANOVAs) were conducted to outline
whether the tools differ significantly from each other in terms of task completion
time and effort spent. The independent variable consists of the different tools, while
the dependent variables are task completion time (TCT) and effort. Both dependent
variables are measured for each of the sub processes. The results of these ANOVAs
indicate that there is a significant difference among the tools.
Additionally, Tukey's HSD [35] range test was used to identify homogeneous
subsets of means that are not significant differently from each other. It allows us to
group tools together and draw parallels between non-literally similar tools. Equally, it
enables us to search for a justification why a certain group of tools scores better in
efficiency than another group. The latter will be further explored in Section 6.
Table 2 depicts TCT and effort required to model one feature, one feature group
and one feature constraint. The groups are arranged in a sequential manner, with G1
being the most efficient and G4 being the least. Table 2 suggests that all tools differ in
offering support to each of the three sub processes. Unfortunately, no tool scores well
(G1) in all the three sub processes.
Satisfaction: None of the tools was given the maximum rating by each of the
participants. Nevertheless, RequiLine scores the best on satisfaction. Subsequently,
the satisfaction ratings of Feature Modeling Tool, CVM Tool, Feature Model DSL
and Pure::Variants are close to each other. The worst results are obtained for
XFeature, CaptainFeature, FeatureIDE and MOSKitt.
From participants comments given, it is clear that most of the tools failed in
satisfying them. The reasons brought up mainly are: (a) the inability to adapt to the
participants modeling skills, i.e. a lack to support user expertise; (b) the unfitness to
adapt to participants preferences; (c) the non-availability of functionalities like
copy/paste, shortcuts and redo/do; (d) requiring more steps than needed; (e)
restrictions/lack of flexibility, e.g. features, like parent and child are displayed and
locked into levels on top of each other; and (f) bugs.
Table 2. Efficiency
Task Completion Time Effort

Feature Feature Feature
Feature Feature Feature Group
Group Constraints Constraints
T9, T7, T6, T9, T4,
G1 T3, T9 T4 T3 T3, T4
T8, T4 T8, T7
T4, T9, T7, T6, T3,
G2 T4, T7, T2 T8,T5 T3, T2, T5 T9, T1, T5
T2 T2, T1
T8, T7, T2,
G3 T8, T1, T6 T9,T7, T3 T1 T1, T5, T6 T5
T6
G4 T5 T2, T1, T6 --- T8 --- ---
Safety
The tools were investigated on their compliance with the checks for redundancy,
anomalies, inconsistency, and invalid semantics. Table 3 shows the results.
Functional Usability Feature

The availability of the selected FUFs was evaluated for each tool; the results are
given in Table 4. Analyzing Table 4, we observe that all tools lack support for the
FUF user expertise. Feedback and shortcuts are slightly supported. Although
reuse information is available in four tools, it was not working properly.
Table 3. Safety Table 4. Functional Usability Features
Tools Ra Ab Ic Sd Tools Fa Ub Vc Ed Se Rf Hg
T7 3 3 3 3 T2 1 3 3 0 1 2 3
T2 0 0 3 3 T7 1 3 3 0 1 2 0
T4 0 0 3 3 T9 0 3 3 0 1 0 3
T9 0 0 0 3 T4 1 2 3 0 1 2 0
T3 0 0 0 3 T8 1 3 3 0 1 0 0
T8 0 0 0 3 T6 0 3 0 0 1 2 0
T5 0 0 0 1 T1 0 0 3 0 0 0 3
T1 0 0 0 0 T5 0 3 1 0 1 0 0
T6 0 0 0 0 T3 1 0 3 0 0 0 0
a. Redundancy, b. Anomalies, c. Inconsistency, a. Feedback, b. Undo, c. Field Validation, d. User Expertise, e. Shortcuts,
d. Invalid semantics. r. Reuse information, g. Help.
6 Discussion and Lessons Learned

The objective of the evaluation was to analyze whether and to which extent the
existing tools offer the necessary quality support to model variability, and
subsequently, to learn from the imperfections of the existing tools. We have grouped
our finding according to the three criteria considered: efficiency, safety, and FUFs.
Regarding the first criteria, we deduce from the results shown in Table 2 in the
previous Section, that no tool meets the efficiency demands on all aspects. Table 2
unveils the strength and the weakness of each tool in each of the three sub processes.
Based on an analysis and a thorough comparison of these tools, following
considerations were made in an effort to justify the differences in efficiency.
First of all, we consider the input of information. In this respect four main
approaches are distinguished:
By an external window: i.e. information is not added directly on the design surface;
instead, an external window pops up in which the user writes the name of the
feature and in which he selects its type e.g. Pure::Variants and CaptainFeature
use this technique for a feature, a feature group and a feature constraint.
By using syntax: i.e. a kind of formal language, like for instance Extended Backus-
Naur Form (EBNF) [18], is used e.g., CaptainFeature and FeatureIDE use this
technique to specify feature constraints.
By using a toolbox: i.e. the user makes his selection from a list of buttons, e.g.,
RequiLine, Feature Modeling Tool, Feature Model DSL, and MOSKitt use this
technique to create a feature as well as a feature group and a feature constraint.
By using a context menu: e.g., by right clicking on a feature a menu pops up to edit
it or to create a sub feature/feature group (CVM Tool uses this technique to create a
feature group, and FeatureIDE uses it to create a feature and a feature group).
Specifying information by using an external window or/and by syntax are the most
effort and time consuming. The use of syntax also requires good knowledge of the
syntax to avoid errors.
The best results in efficiency were obtained when input can be done by a context
menu. It owes its success to the fact that it is concentrated directly on the design
surface, where the diagram is located. Although a toolbox is commonly used in
modeling tools, its use turns out to be very counterproductive because of the
trajectory of going forth and back from the toolbox to design surface.
Secondly, with relevance to efficiency, we encountered three different ways of
editing. Editing was done by either (a) a properties menu, or (b) a context menu or (c)
a single- and double-click of the mouse. Editing by mouse clicks appears to be least
effort and time consuming, whereas editing by a properties menu should be avoided.
Thirdly, unnecessary steps should be omitted. The cumbersome way for modeling
a feature group in 3 separated steps (like done in most tools) aptly illustrates this.
Since the feature group logically consists of one parent and at least two children,
modeling the feature group can be easily reduced to one single step.
And last but not least, the use of defaults has a negative effect on the efficiency,
e.g., default feature type, default position (i.e. position of the feature on the design
surface after its creation), and default feature size (i.e. the size of its symbol). A
default carries the disadvantage that it may need to be adjusted afterwards, which
requires twice as much effort and time. Therefore, defaults must be used with care.
With respect to safety, any kind of inconsistencies, anomalies and invalid
semantics should be avoided. With respect to the redundancy check, the user should
have the option to allow it since in some cases redundancy can add readability and
understandability to the model.
Concerning the Functional Usability Features (FUFs), it is undisputable that these
should be supported. The comments of the participants post-questionnaire unveil a
significant influence of the FUF on satisfaction.
To summarize, we can give the following advices:
Any action like input, editing, arranging features taking place outside of the
design surface should be avoided as much as possible. The use of a context menu
meets these needs the best. Another modeling technique worthwhile to explore is
one that visualizes features, feature group and feature constraints on the design
surface (with small icons) and where the user can create these by a single mouse
click (cf. CmapTool [34]). Although such a technique looks promising, it should be
evaluated to verify if indeed it results in better efficiency.
At the same time, input and editing should take as few steps as possible. Shortcuts
and a kind of single- and double-click method can be advised.
In general, defaults should only be used if in most cases the user does not need to
change them. In case of default position, we advise to position the created features
either under the parent or at the position of the mouse. As to default size, we
propose to AutoFit the size of the feature to its name.
Moreover, the safety checks (except redundancy check) as well as the Functional
Usability Features have to be provided.
Furthermore, allowing the user to configure the tool according to his personal
expertise and preferences is also considered important (e.g., define his own
shortcuts and to (de)activate safety checks).
7 Related Work
To the best of our knowledge, no previous work has evaluated these specific quality
requirements regarding tools supporting modeling variability.
In [6] the author presented a systematic functionality review of 19 tools, which
support the domain analysis process. However, the review only included functional
requirements. [16] provides an evaluation report of three tools on the importance of
tool support for functionality, usability and performance within software product
lines. The tools were completely reviewed based on the authors own opinion without
a scientific experiment. An industry survey of 4 tools was conducted in [17], where
usability had been categorized as a technical criterion. The literature review in [8]
highlights the need for an inconsistency, redundancy and anomalies check.

In order to investigate how to improve the quality of feature modeling tools in
general, we conducted a quality evaluation of 9 feature modeling tools. These tools
were measured against the evaluation criteria Usability, Safety and Functional
Usability Features. From the results, we could extract justifications for the differences
in quality support of the tools. Some lessons could be drawn to improve the quality
support of such tools in the future. The next step in our research is to investigate
quality requirements related to scalability. Many tools work fine for small models, but
when the size of the models increases, they suffer from severe scalability problems.
References
1. Pohl, K., Bckle, G., van der Linden, F.: Software Product Line Engineering: Foundations,
Principles, and Techniques. Springer, New York (2005)
2. Sinnema, M., Deelstra, S., Nijhuis, J., Bosch, J.: COVAMOF: A Framework for Modeling
Variability in Software Product Families. In: Nord, R.L. (ed.) SPLC 2004. LNCS,
3. Becker, M.: Towards a General Model of Variability in Product Families. In: Proceedings
of the 1st Workshop on Software Variability Management, Netherlands (2003)
4. Abo Zaid, L., Kleinermann, F., De Troyer, O.: Feature Assembly Framework: Towards
Scalable and Reusable Feature Models. In: Fifth International Workshop VaMoS (2011)
5. Chen, L., Babar, M.A.: A Systematic Review of Evaluation of Variability Management
Approaches in Software Product Lines. Information and Software Technology 53, 344
362 (2011); Elsevier Journal
6. Lisboa, L.B., Garcia, V.C., Almeida, E.S., Meira, S.L., Lucrdio, D., Fortes, R.P.: A
Systematic Review on Domain Analysis Tools. Information and Software Technology 52,
113 (2010)
7. Chen, L., Babar, M.A.: Variability Management in Software Product Lines: An

Investigation of Contemporary Industrial Challenges. In: Bosch, J., Lee, J. (eds.) SPLC
8. Benavides, D., Segura, S., Ruiz-Corts, A.: Automated Analysis of Feature Models 20
Years Later: A Literature Review. Information Systems 35, 615636 (2010)
9. Bevan, N.: Extending Quality in Use to Provide a Framework for Usability Measurement.
In: Proceedings of HCI International, San Diego, California, USA (2009)
10. Juristo, N.: Impact of usability on software requirements and design. In: De Lucia, A.,
Ferrucci, F. (eds.) ISSSE 2006-2008. LNCS, vol. 5413, pp. 5577. Springer, Heidelberg
(2009)
11. Baecker, R.M.: Readings in Human-Computer Interaction: Toward the year 2000. Morgan
Kaufmann, San Francisco (1995)
12. Tamir, D., Komogortsev, O.V., Mueller, C.J.: An Effort and Time Based Measure of
Usability. In: The 6th International Workshop on Software Quality. ACM, Leipzig (2008)
13. Hornbk, K.: Current Practice in Measuring Usability: Challenges to Usability Studies and
Research. International Journal of Human-Computer Studies 64, 79102 (2006)
14. Massen, T.V.D., Lichter, H.: Deficiencies in Feature Models. In: Workshop on Software
Variability Management for Product Derivation - Towards Tool Support (2004)
15. Lazar, J.: Research methods in Human-Computer Interaction. Wiley, Chichester (2010)
16. Chong, S.: An Evaluation Report for Three Product-Line Tools (Form, Pure::Variants and
Gear). NASA Software Assurance Research Program (2008)
17. Djebbi, O., Salinesi, C., Fanmuy, G.: Industry Survey of Product Lines Management
Tools: Requirements, Qualities and Open Issues. In: 15th IEEE International Requirements
Engineering Conference, RE 2007, pp. 301306 (2007)
18. Wirth, N.: Extended Backus-Naur Form (EBNF). ISO/IEC 14977:1996 (2996)
19. CaptainFeature, http://sourceforge.net/projects/captainfeature/
20. Pure::Variants, http://www.pure-systems.com/pure_variants.49.0.html
21. FeatureIDE, http://wwwiti.cs.uni-magdeburg.de/iti_db/research/
featureide/
22. RequiLine, http://www-lufgi3.informatik.rwth-aachen.de/TOOLS/
requiline/index.php
23. XFeature, http://www.pnp-software.com/XFeature/
24. MOSKitt, http://www.moskitt.org/eng/moskitt0/
25. Feature Modeling Tool, http://giro.infor.uva.es/index.html
26. Feature Model DSL,
http://featuremodeldsl.codeplex.com/releases/view/20407
27. CVM, http://www.cvm-framework.org/index.html
28. BigLevers Gears SPLE Too,
http://www.biglever.com/solution/product.html
29. Feature Modeling Plug-in,
http://gsd.uwaterloo.ca/projects/fmp-plugin/
30. FORM CASE Tool, http://selab.postech.ac.kr/form/
31. ToolDAy - Tool for Domain Analysis,
http://www.rise.com.br/english/products_toolday.php
32. ALLCapture, http://www.balesio.com/allcapture/eng/index.php
33. WinOMeter, http://www.tjelinek.com/main.php?section=w
34. CmapTools Knowledge Modeling Kit, http://cmap.ihmc.us/
35. Tukey, J.W.: The Problem of Multiple Comparisons. Princeton University, USA (1953)
Service Variability Patterns
Ateeq Khan1 , Christian Kastner2 , Veit Koppen1, and Gunter Saake1

1
University of Magdeburg, Germany
2
Philipps Universitat Marburg, Germany
{ateeq,vkoeppen,saake}@iti.cs.uni-magdeburg.de,
kaestner@informatik.uni-marburg.de
Abstract. Service-oriented computing (SOC) increases flexibility of IT systems

and helps enterprises to meet their changing needs. Different methods address
changing requirements in service-oriented environment. Many solutions exist to
address variability, however, each solution is tailored to a specific problem, e.g. at
one specific layer in SOC. We survey variability mechanisms from literature and
summarize solutions, consequences, and possible combinations in a pattern cata-
logue. Based on the pattern catalogue, we compare different variability patterns
and their combinations. Our catalogue helps to choose an appropriate technique
for the variability problem at hand and illustrates its consequences in SOC.
1 Introduction
Service-Oriented Computing (SOC) is a paradigm to create information systems and
provides flexibility, interoperability, cost effectiveness, and higher quality characteris-
tics [1]. The trend of service-usage is increasing in enterprise to support processes.
However, even in the flexible world of services, variability is paramount at all layers.
Variability is the ability of a system to extend functionality, modify, customise or con-
figure the system [2]. We do not want to provide the same service to all consumers but
need to provide customised variants. Consumers want to fine tune services according
to their needs and will get a unique behaviour, which is tailored (personalised) for their
requirements. Fine-tuning depends on available features of the services, where a feature
is a domain-abstraction used to describe commonalities and differences [3].
However, variability approaches in SOC are ad-hoc. Many solutions exist; however,
each one is tailored and aimed for a specific problem or at a specific layer. Some ap-
proaches use simple mechanisms for variability, such as, using if-else structure imple-
mentations for variability in services. Others try to prevent bloated results of putting all
variability into one service (which also violates the service principle that each service
should be an atomic unit to perform a specific task) with various strategies, such as
frameworks ( [4, 5, 6]) and languages-based approaches ( [7, 8]). A single and perfect-
for-all solution does not exist in variability. Such a solution is also unrealistic, due to
very different requirements and technologies at different layers. Still, we believe that
there are common patterns, and developers do not need to rule out inefficient solutions
and reinvent better solutions again and again.
We contribute a catalogue of common variability pattern, designed to help devel-
opers to choose a technique for specific variability needs. We survey the literature and

Service Variability Patterns 131
abstract from reoccurring problems and individual implementation strategies and layers.
We summarise our results in six common patterns for variability in the SOC domain (in
general many patterns are even transferable to other domains). The patterns are general
enough to describe the problem and the solution strategy including its trade-offs, dif-
ferent implementation strategies at different SOC layers, but also concrete enough to
guide a specific implementation. To help developers decide for the appropriate solution
to a variability problem at hand, we discuss trade-offs, limitations and possible com-
binations of different patterns. To aid understanding, we discuss example scenarios of
each pattern with their consequences.
2 Variability Patterns in SOC

We use the pattern template by Gamma et al. [9] with modification to describe our pat-
terns in SOC domain. Our pattern structure is simple and consists of a pattern name,
pattern motivation or recurring problem, applications, examples, implementation tech-
nique or solution for the pattern, and consequences of the pattern.
In our pattern catalogue, we include some general patterns which are used in various
variability situations. We discuss some implementation techniques and examples. Dis-
cussion of all implementation techniques for each pattern is out of scope of this paper
(for details see [10]). In contrast to related pattern catalogues [2, 11], which are focused
on product lines, we focus on the SOC domain. We use examples from a sports SaaS
application, which is used to manage a sports club. The SaaS application contains differ-
ent services, e.g. to display the matches results, managing players and members. Our
sports application can be used in other sports domains by using variability approaches.
2.1 Parameter Pattern

Motivation: Service providers offer different implementations of a service and selec-
tion of services are based on the parameters. Service consumers have different kinds of
preferences for a service or need a specific behaviour from services.
Application: This is a simple and widely used pattern. This pattern provides variability
solutions based on parameters. Service providers offer variability depending on param-
eters (depicted in Figure 1) e.g. who is calling the service (consumer id). Access to
specific services is decided using this pattern. Service providers plan for variability at
design time and this result in variability for a consumer at runtime. Parameters and
consumer specific configurations may be bundled together and stored. There are dif-
ferent options to store the configuration of the consumers, mostly stored at the service
provider side (although, storage does not have an impact, e.g. at the consumer side or
at the service provider side). When a consumer accesses the service, consumer specific
configuration is accessed for variability and unique behaviour. We can use parameter
pattern for user-interface or workflow preferences, database attributes or for domain
specific extensions.
Example: We can use the parameter pattern for sorting, rendering, or for different lay-
outs in a sports service scenario, e.g. offering text commentary of a match based on the
consumer language or changing scoring fields for different sports domain.
132 A. Khan et al.
Solution: We can store consumer specific settings and parameters as configuration files,
e.g. as XML files or stored in a database for each consumer. Parameter storage is also
not necessary; a possible extension is passing all required parameters every time when a
consumer accesses the SaaS application. There are two types of data associated with this
pattern, one is configuration specific data (values configured by consumers for different
options) and other is application specific data for each consumer (contain database,
values, and users). Configuration data is usually small and less updated as compared to
application specific data. For general needs or requirements, configuration data for each
consumer can be stored as key-value pair, e.g. consumer id and configuration values (for
user-interface favourite colour, selected endpoint, or fields to display).
Consequences: This pattern provides an easy approach to provide variability from the
same source code by storing and accessing consumer-specific behaviour based on pa-
rameters. Services are selected based on attribute values. Such approach is simple to
program and does not require a lot of expertise. This pattern provides flexibility but
consumer can choose only from the provided set. Management will be an issue in larger
scenarios if parameter conditions are scattered within the code.
2.2 Routing Pattern

Motivation: Even if requirements are same between two consumers, business rules can
vary between them. Consumers want to change the business rules to follow a specific
behaviour. This pattern routes the request based on the rules or consumers requirements.
Application: We can use this pattern for routing requests to different targets, selection
of services, changing application behaviour using rules or based on consumer descrip-
tion. Changes can be made at runtime. Flexibility is provided by consumer, provider or
by both depending on the scenario and can be used at different layers. Service providers
offer consumers to change the business rules of an application. Rules are used to handle
complex scenarios and different conditions. Such conditions are due to user preferences.
Meta rules or algorithms can be used to choose which rule has to be executed. Service
providers can also allow to use specific operators, e.g. allowing consumers to add if-
else branches in the business rules (shown in Figure 2) to control the business logic or
Consumer
A Consumer
A
SaaS
SaaS
If(gid=foreign)
pref(creditC)
Service else `local`
Service
acting as a parameter
acting as a
consumer consumer
Consumer Consumer
B B
Fig. 1. Parameter pattern Fig. 2. Routing Pattern

using logical operators. Logical operators can also be source of variability, e.g. some
consumers may use simple operators and others prefer or require more flexible rules for
business logic. We can use this pattern to to handle exceptions. This pattern is similar
to the facade or proxy pattern, discussed in [9].
Example: In our sports system, members pay club membership fees. For payments dif-
ferent options, or routing of services are possible, e.g. local members pay using credit
card, bank transfer or both, and foreign members can only pay using credit card.
Solution: Different solutions for implementation do exist for routing. These approaches
range from simple if-else statements to complex Aspect-Oriented Programming (AOP)
based approaches [12]. Message interception can also be used for routing. A message is
intercepted and analysed to add user-specific behaviour. Different techniques are used
to intercept message. Rahman et al. [12] use an AOP-based approach to apply business
rules on the intercepted message in SOA domain.
A web service request is intercepted, rules are applied on the request, and then re-
sult is forwarded. Routing can be done by analysing SOAP header or SOAP body (may
carry extra data for routing) and request is routed accordingly.
Consequences: Routing allows consumer to use application which suits to their re-
quirements. It also allows to separate business logic from service implementation (for
easy modification in rules at runtime). It is also easy to change routing rules and only
few changes are necessary. Consumers influence the application behaviour by changing
rules.
Adding new business rules or logical operators may add unnecessary loop in an
application or inconsistency in application. Validation rules or validators are applied
before adding branching rule [13,14]. Higher complexity of involved services may lead
to inconsistency in application due to rules. Algorithms for validation [15] can also be
used to find inconsistent or contradictory rules. Scalability is also an issue for complex
applications, routing rules may increase in size and their management become difficult.
Routing pattern may introduce single point of failure or decrease in performance.
2.3 Service Wrapping Pattern

Motivation: We use this pattern when service is incompatible to use (due to technical
or business issue) or provider want to add/hide functionality in services. So, modifica-
tion is required to use the service in a scenario.
Application: We can use this pattern (as depicted in Figure 3) for the wide variety of
changes, e.g. from technical perspective interface mismatch, message or data transfor-
mation, protocols transformation, or for business modifications (content modification).
This pattern helps to delegate, modify or extend the functionality for consumers [16,11].
Service wrapping can be used to modify existing services and to resolve incompatibili-
ties between services or service interfaces. Services are wrapped and arranged together
so that a service delegates the request to other services or component, which implement
the service logic. Composite, decorator, wrapper, proxy, and adaptor patterns [9] are
similar patterns with the service wrapping pattern. We can also use this pattern to offer
a group of services (from different providers, platforms, or languages) as a composite
service to provide sophisticated functionality and vice versa. Consumers use services
through the provided interface without knowing whether the service provider adds or
134 A. Khan et al.
hides the functionality. We can also use this pattern to support legacy systems without
major modification of existing code of the system and exposing functionality as a ser-
vice [1, 17, 18]. The consumers may want to expose her existing systems as a service
for other consumers, and restrict the access of some private business logic.
Example: An example from our sports system is offering email and SMS message ser-
vices (wrapped together as a notify match composite service) to send reminder about
change in match schedule to members and players.
Solution: We can use different solutions, e.g. using intermediate service, middleware
solutions or tools for variability. To expose legacy systems as service, different tech-
niques are possible, e.g. service annotations in Java. Intermediate service acts as an
interface between incompatible services and contains required logic to overcome the
mismatch.
Using SAP Process Integration (SAP PI) as a middleware, different service imple-
mentation, workflows, or client interfaces can be used to provide variability. We can use
different types of adapters to solve interface mismatch or to connect different systems.
When a request from a consumer side is sent to SAP PI, different service implementa-
tions, business rules, and interfaces can be selected based on the request. We also use
middleware for synchronous-asynchronous communication, in which results are stored
at middleware and delivered to the consumers based on their requests. The consumer or
provider both (not necessary service owner, could be third party providers) are respon-
sible for variability in this pattern.
Consequences: Using this pattern, we offer different variability solutions. Service wrap-
ping hides the complexity of the scenario from the consumer and simplifies the commu-
nication between consumer and composite service (consumers do not care about dif-
ferent interfaces or number of underlying services). Addition or removal of a service
becomes easy for the consumer (considered as include/exclude component in case of
component engineering). Services are reused and become compatible without changing
their implementation details by using service wrapping.
Composite services increase the complexity of the system. Adding services from
other providers may effect non-functional properties. Service wrapping increases the
number of services (depending on the scenarios composite, adapters or fine-grained)
offered from the provider and management of such a system becomes complex.
2.4 Variant/Template Pattern

Motivation: We assume that providers know consumers variability requirements for
services. Therefore, providers offer static variants of services, and consumers configure
these variants according to their needs, e.g. variants based on the consumer geographical
location, cultural aspects, subscription, consumer group, and devices.
Application: Providers offer a set of service variants to consumers (as illustrated in
Figure 4). Service providers plan for the variability and provide variants at design time
and consumers select these variants, mostly at runtime. Service providers select features
and varying options based on industry best practices, as variants, with a pre-defined set
of configuration options. Consumers choose options. In [13,14], authors suggest to offer
a set of templates, so consumers can choose a template in a process or workflow. In [19],
authors discuss different workflow patterns.
Consumer Consumer
A A
SaaS SaaS
Variant1 Variant2
Service
Service
acting as a
acting as a
wrapper consumer
consumer
Consumer Consumer
B C
Consumer
B Fig. 4. Variant Pattern
Fig. 3. Service Wrapping Pattern
Example: In our sports system, different user-interface variants are used to display
match scores (suppose in Figure 4, text commentary is displayed in Variant1 for the
consumer B, online video streaming in Variant2 from provider side for consumer C,
while the consumer A sees the score only).
Solution: The variant pattern is a general pattern and used in various scenarios. Con-
sumers choose from a set of variants and use options to configure it, e.g. for unique
look and feel, workflows, or for viewing/hiding data fields in interface. These variants
are typically generated from the same source code at provider side. We can use gen-
erators, inheritance, polymorphic, or product line approaches to generate variants of a
service at design time [3, 20, 21, 9]. In [3], we discuss how different variants can be
offered based on a feature set from the same code base and benefits achieved using
variability. WSDL files can also be tailored and used for representing different variants.
The consumer specific options are stored as configuration files.
Consequences: It pattern allows to offer optimal solutions in the form of variants. In-
dustry best practices help consumers to choose right options and result in higher quality.
This pattern does not allow full flexibility to consumers. Developers provide variants
in advance and consumers have to choose only from given set. Managing different vari-
ants of a service increases the complexity. Additional information is needed to decide
which variant of a service is useful or compatible. Complex scenarios need a flexible
platform or architecture, which allows handling of different variants (challenges men-
tioned in [3]).
2.5 Extension Points Pattern
Motivation: Sometimes, consumers have specific requirements which are not fulfilled
by the above mentioned patterns. For instance, consumers want to upload their own im-
plementation of a service, replace part of a process, to meet the specific requirements.
Therefore, providers offer extension points in a SaaS application.
Application: This pattern requires pre-planning. Service providers prepare the variabil-
ity as extension points at design time. Consumers share the same code base and provide
behaviour at those extension points at runtime. Other consumers access the service
136 A. Khan et al.
without any change. It is similar to the strategy design pattern [9], frameworks, or call-
backs (can use inheritance methods at design time). The consumer modifies the applica-
tion behaviour by uploading implementations, rules, or fine-tuning services (changing
service endpoints). Extension points allow consumers to add consumer-specific imple-
mentations or business logic in the system at runtime as shown in Figure 5.
Example: In our sports system, a consumer configures extension point for alternative
scoring services from different providers using web service endpoint binding method.
Solution: In SOC, service interfaces (WSDL files), service implementations, service
bindings, and ports (endpoints) act as extension points in the architecture [22, 23, 24].
Consumers change these extensions points for variability. We can use physical sepa-
ration of instances or virtualisation as solutions for this pattern. A provider allocates
a dedicated hardware or a virtual instance for consumer-specific code execution sepa-
rately. In case of malicious code or failure, only the tenant-specific instance or virtual
image will be effected instead of the whole system. The consumer can perform modifi-
cations for service binding in WSDL. Endpoint modification is a method to modify the
service address in a WSDL or in a composite service, e.g. adding an end-point service
as an alternative in a web service binding. Endpoint modification can be done at run-
time.
Consequences: Extension points offer flexibility to the consumer and allow customisa-
tion of application behaviour. There are some potential risks due to offering flexibility
through extension points. In a workflow, by allowing a consumer to add activities, it is
possible that adding new activities in a workflow introduce loops in application, con-
suming resources or might result in never ending loops. Another problem is in allowing
a consumer to insert her own code, which may lead to failure of the whole system or
instance, e.g. in case of malicious code or virus uploading. Once variability is realised
by consumers, the system must check for the modification (extension points) and test
scenarios for correctness of the system, e.g. for resource consumption or effect on the
whole process (availability, time constraints for response, etc.)
2.6 Copy and Adapt Pattern

Motivation: Offering variability from the same code base in SaaS is not always a best
choice. Sometimes, available patterns or approaches fail to fulfil consumers demands
from the same code base. Another reason is, if we apply those patterns, management
become complex or result in higher costs as compared to separate service instances.
Application: We use this pattern when shared instance modifications for a consumer
harm other consumers. Therefore, a developer copies the service code and modifies
it for individual consumer as depicted in Figure 6. This pattern requires source code
access for modification. Mostly, the consumer is responsible for managing changes or
updating the new version of service with own modifications. We also use this pattern
where consumers have data privacy issues, e.g. in some countries, data storing, or pro-
cessing in the shared environment is not feasible.
Example: We use this pattern in scoring service. Scoring is different for football (for
consumer group A) as compared to baseball (for consumer group B) and a lot of changes
are required, which makes the scenario complex.
Consumer
A
SaaS SaaS SaaS

Implementa- Clients Clients
tion, WSDL implementation1 implementation2
modfication
Service
acting as a
consumer Service Consumer Service Consumer
Consumer acting as a A acting as a B
B consumer consumer
Fig. 5. Extension Points Pattern Fig. 6. Copy and Adapt Pattern
Solution: Service providers offer a separate instance for a consumer to keep the solu-
tion simpler, although it may introduces services with similar codes and functionalities.
The consumer introduces her own implementation and exposes as a service or modifies
the provided solution. In such a case, every consumer gets a independent customised
service instance. We use this pattern at the process or database layer as well, where a
consumer adds or develops her own process in SaaS. In such cases, at the database layer,
a consumer uses a separate database instance to accommodate new database relations
and different business requirements.
Consequences: SOC benefits are achieved in this pattern, although for some parts the
application service provider (ASP [25]) model is used, in which each consumer shares
the infrastructure facilities (shifting infrastructure and management tasks to providers)
but separate service instances. Legacy systems or other applications can be shifted to
SOC using this pattern easily. This pattern allows full flexibility, and consumers can
modify or customise respective services freely.
From service provider perspective, this pattern does not scale. It is expensive in terms
of costs for the large number of consumers and service instances. Hardware costs also
increase in such cases due to separate instances. Code replication increases the effort for
management and decreases productivity. Software updates or new version of software
must be updated for each instance manually or individually. Due to these main problems,
it is often not advisable to use this pattern and sometimes considered as anti-pattern.
3 Patterns Comparison and Combinations

We discuss different patterns for variability in SOC. In Table 1, we compare these pat-
terns with each other against evaluation factors for variability. Our pattern catalogue
covers the common variability problems and solutions in SOC and by no means a
comprehensive pattern catalogue. We identify that some patterns can also be combined
together for a better solution or to solve variability problems. For example, the param-
eter pattern can be combined with the extension points pattern to keep the consumer
138 A. Khan et al.
Table 1. Pattern comparison and combinations
Patterns Required Flexibility Scalability Risk Maintenance Responsibility

changes
Parameters (P) low medium high low easy provider
Routing (R) low medium medium medium easy both
Service Wrapping (SW) medium high medium medium medium both
Variants (V) very low low medium low medium provider
Extension Points (E) medium medium low high difficult provider
Copy and Adapt (CA) very high very high high low difficult both
Combining P + E medium medium high low low provider
Combining R + SW medium high high low medium consumer
Combining R + V low high medium low medium both
Combining R + E medium low low medium difficult both
Combining SW + V medium medium high low medium provider
Combining V+ E medium high medium low medium provider
implementation separate from other consumers. Consumers implementations are stored

in configuration files and retrieved when consumers access the service.
We can also combine the routing pattern with the variant pattern or the service wrap-
ping pattern to select different variants of services and protocols or messages transfor-
mation based on some criteria. The routing pattern is used with the extension points
pattern to inject routing rules in application (e.g. uploading code containing routing
logic). We can also use the routing pattern to offer a set of valid rules based on vari-
ants. The service wrapping pattern can be mixed with the variant pattern or the routing
pattern to offer different variants of services. Theses variants are shared between con-
sumers and used for different service flows or to overcome a mismatch at middleware
level. The bariant pattern with the extension points pattern allows us to restrict the ex-
tension points options to valid combinations instead of giving consumers flexibility to
add random activities. So, consumers can add activities or rules from offered templates.
An example of such an activity in our sports system is a notification activity where
a consumer can send an email for a match notification but other consumers want to
add additional SMS message activity for notification. So, SMS message activity can be
added in the workflow from templates activity.
It is possible that different patterns fit in a particular environment or problem. Choos-
ing a pattern depends on many factors, e.g. patterns consequences, application scenarios,
business needs, architectures, and customers business models. In some organisation and
countries, consumers have legal or organisational issues, restrictions for shared access
of applications (despite the efforts for data and processes confidentiality in multi-tenant
applications), so the consumer may prefers other patterns.
4 Summary and Outlook
We contributed six variability patterns for SOC that can guide developers to solve
different variability problems in practice. We discuss trade-offs according to several
evaluation criteria to help deciding for the right solution strategy for a problem at hand.
Our pattern catalogue helps to reuse solutions strategies in a manageable way.
In future work, we plan to extend our pattern catalogue into a framework that con-
tains decision criteria to choose and manage variability in SOC with specific imple-
mentation techniques. We will also evaluate our pattern catalogue further in practice to
compare performances where more than one patterns can be used at the same time.
Acknowledgement. Ateeq Khan is supported by a grant from the federal state of

Saxony-Anhalt in Germany. This work is partially supported by the German Ministry
of Education and Science (BMBF), within the ViERforES-II project No. 01IM10002B.
References
[1] Papazoglou, M.P., van den Heuvel, W.J.: Service oriented architectures: approaches, tech-
nologies and research issues. VLDB 16(3), 389415 (2007)
[2] Svahnberg, M., van Gurp, J., Bosch, J.: A taxonomy of variability realization techniques.
Software - Practice and Experience 35(8), 705754 (2005)
[3] Apel, S., Kastner, C., Lengauer, C.: Research challenges in the tension between features
and services. In: ICSE Workshop Proceedings SDSOA, pp. 5358. ACM, NY (2008)
[4] Camara, J., Canal, C., Cubo, J., Murillo, J.M.: An Aspect-Oriented Adaptation Framework
for Dynamic Component Evolution. Electr. Notes Theor. Comput. Sci. 189, 2134 (2007)
[5] Guo, C.J., Sun, W., Huang, Y., Wang, Z.H., Gao, B.: A framework for native multi-tenancy
application development and management. In: The 9th IEEE International Conference on
E-Commerce Technology, pp. 551558 (2007)
[6] Kongdenfha, W., Saint-Paul, R., Benatallah, B., Casati, F.: An aspect-oriented framework
for service adaptation. In: Dan, A., Lamersdorf, W. (eds.) ICSOC 2006. LNCS, vol. 4294,
[7] Charfi, A., Mezini, M.: AO4BPEL: An aspect-oriented extension to BPEL. WWW 10(3),
309344 (2007)
[8] Zur Muehlen, M., Indulska, M.: Modeling languages for business processes and business
rules: A representational analysis. Information Systems 35, 379390 (2010)
[9] Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable
Object-Oriented Software. Addison Wesley, Reading (1995)
[10] Khan, A., Kastner, C., Koppen, V., Saake, G.: Service variability patterns in SOC.
Technical Report 05, School of Computer Science, University of Magdeburg, Magde-
burg, Germany (May 2011), http://wwwiti.cs.uni-magdeburg.de/iti_db/
publikationen/ps/auto/KKKS11.pdf
[11] Topaloglu, N.Y., Capilla, R.: Modeling the Variability of Web Services from a Pattern Point
of View. In: Zhang, L.J. (ed.) ECOWS 2004. LNCS, vol. 3250, pp. 128138. Springer,
Heidelberg (2004)
[12] ur Rahman, S.S., Khan, A., Saake, G.: Rulespect: Language-Independent Rule-Based AOP
Model for Adaptable Context-Sensitive Web Services. In: 36th Conference on Current
Trends in Theory and Practice of Computer Science (Student Research Forum), vol. II, pp.
8799. Institute of Computer Science AS CR, Prague (2010)
[13] Chong, F.T., Carraro, G.: Architecture strategies for catching the long tail, Microsoft
Corporation (April 2006), http://msdn.microsoft.com/en-us/library/
aa479069.aspx (last accessed June 24, 2011)
140 A. Khan et al.
[14] Carraro, G., Chong, F.T.: Software as a service (SaaS): An enterprise perspective, Microsoft
Corporation (October 2006), http://msdn.microsoft.com/en-us/library/
aa905332.aspx (last accessed June 24, 2011)
[15] Bianculli, D., Ghezzi, C.: Towards a methodology for lifelong validation of service com-
positions. In: Proceedings of the 2nd International Workshop on Systems Development in
SOA Environments, SDSOA, pp. 712. ACM, New York (2008)
[16] Mugge, H., Rho, T., Speicher, D., Bihler, P., Cremers, A.B.: Programming for Context-
based Adaptability: Lessons learned about OOP, SOA, and AOP. In: KiVS 2007 - Kommu-
nikation in Verteilten Systemen, vol. 15. ITG/GI-Fachtagung (2007)
[17] Yu, Q., Liu, X., Bouguettaya, A., Medjahed, B.: Deploying and managing web services:
issues, solutions, and directions. The VLDB Journal 17(3), 537572 (2006)
[18] Mughrabi, H.: Applying SOA to an ecommerce system, Master thesis (2007), http://
www2.imm.dtu.dk/pubdb/p.php?5496 (last accessed May 5, 2011)
[19] Aalst, W., Hofstede, A., Kiepuszewski, B., Barros, A.P.: Workflow patterns. Distributed and
Parallel Databases 14(1), 551 (2003)
[20] Papazoglou, M.P., Kratz, B.: Web services technology in support of business transactions.
Service Oriented Computing and Applications 1(1), 5163 (2007)
[21] Pohl, C., Rummler, A., et al.: Survey of existing implementation techniques with respect
to their support for the requirements identified in m3. 2, AMPLE (Aspect-Oriented, Model-
Driven, Product Line Engineering), Specific Targeted Research Project: IST- 33710 (July
2007)
[22] Jiang, J., Ruokonen, A., Systa, T.: Pattern-based variability management in web service
development. In: ECOWS 2005: Proceedings of the Third European Conference on Web
Services, p. 83. IEEE Computer Society, Washington, DC, USA (2005)
[23] Moser, O., Rosenberg, F., Dustdar, S.: Non-intrusive monitoring and service adaptation for
WS-BPEL. In: WWW, pp. 815824. ACM, New York (2008)
[24] Erradi, A., Maheshwari, P., Tosic, V.: Policy-Driven Middleware for Self-adaptation of Web
Services Compositions. In: van Steen, M., Henning, M. (eds.) Middleware 2006. LNCS,
[25] Lacity, M.C., Hirschheim, R.A.: Information Systems Outsourcing; Myths, Metaphors, and
Realities. John Wiley & Sons, Inc., Chichester (1993)
An Overview of Techniques for Detecting
Software Variability Concepts in Source Code
Angela Lozano
Universite catholique de Louvain (UCL), ICTEAM,

Place Sainte Barbe 2, B-1348 Louvain La Neuve, Belgium
Abstract. There are two good reasons for wanting to detect variability
concepts in source code: migrating to a product-line development for an
existing product, and restructuring a product-line architecture degraded
by evolution. Although detecting variability in source code is a com-
mon step for the successful adoption of variability-oriented development,
there exists no compilation nor comparison of approaches available to
attain this task. This paper presents a survey of approaches to detect
variability concepts in source code. The survey is organized around vari-
ability concepts. For each variability concept there is a list of proposed
approaches, and a comparison of these approaches by the investment re-
quired (required input), the return obtained (quality of their output),
and the technique used. We conclude with a discussion of open issues in
the area (variability concepts whose detection has been disregarded, and
cost-benet relation of the approaches).
1 Introduction
Todays companies face the challenge of creating customized and yet aordable
products. Therefore, a pervasive goal in industry is maximizing the reuse of com-
mon features across products without compromising the tailored nature expected
from the products. One way of achieving this goal is to delay customization de-
cisions to a late stage in the production process, which can be attained through
software. For instance, a whole range of products can be achieved through a scale
production of the same hardware, and a software customization of each type of
product.
The capability of building tailored products by customization is called vari-
ability. Software variability can be achieved through combination and congu-
ration of generic features.
Typical examples of variability can be found in embedded software and soft-
ware families. Embedded software facilitates the customization of single pur-
pose machines (i.e. those that are not computers) such as cars, mobile phones,
airplanes, medical equipment, televisions, etc. by reusing their hardware while

Angela Lozano is funded as a post-doc researcher on a an FNRS-FRFC project. This
work is supported by the ICT Impulse Program of ISRIB and by the Inter-university
Attraction Poles (IAP) Program of BELSPO.

142 A. Lozano
varying their software to obtain dierent products. Software families are groups
of applications that come from the conguration and combination of generic
features. Both embedded software and software families refer to groups of appli-
cations related by common functionality. However, variability can also be found
in single applications when they delay design decisions to late stages in order
to react to dierent environments e.g. mobile applications, games, fault tolerant
systems, etc.
Motivations for Detecting Variability: When companies realize that slight
modications of a product could enlarge their range of clients they could mi-
grate to a product-line development. Detecting variability opportunities in the
current product is the rst step to assess which changes have a higher return
in terms of potential clients. This return assessment is crucial for the success of
such migration because the reduction on development cost may not cover the
increase in maintenance cost if the variation introduced is unnecessary.
Once a product-line architecture is in place, it will degrade over time. Degra-
dation of the architecture is a reality of software development [7]. In particular,
product-lines have well-known evolution issues that can degrade their architec-
ture [3,12]. Therefore, at some point it might become necessary to restructure
the product-line; and the rst step is reconstructing its architecture from the
source code.
Both previous scenarios start from the source code of the (software) system
as source of information. Source code mining is a reverse engineering technique
that extracts high-level concepts from the source code of a system. In order to
mine for variability concepts, we need to clearly dene these high-level concepts.
Although mining for variability in source code is a common step towards the
successful adoption of variability-oriented development, there exists no compi-
lation nor comparison of existing approaches available to attain this task. The
goal of our paper is two-fold. First, we identify high-level concepts targeted by
variability mining approaches and describe the intuition behind them. Second,
we use these concepts to classify the approaches that detect variability as they
uncover the intuition and assumptions behind the technique used.
2 Variability Concepts
In order to compare variability mining approaches we establish a common ground

of terms found in literature. The purpose of this common ground is not to provide
a formal denition of each term, but to x its meaning in an intuitive manner.
In particular, we consider four variability concepts central to variability mining:
features, variability dependencies, variation points, and variants.
Features: Variability is described in terms of features. There are two types of
features: mandatory and variable. To illustrate these kinds of features we present
an example of the possible congurations of features in a car. Figure 1 depicts
the car feature diagram, illustrating the relations between variability concepts.
A feature represents a unit of software functionality i.e. an increment of be-
havior (w.r.t. some standard car behavior). The features in Figure 1 are the
An Overview of Techniques for Detecting Software Variability Concepts 143
Fig. 1. A feature diagram
suspension, transmission, engine, and extra options. Mandatory features can be

implemented directly in the application because they do not depend on the usage
environment i.e. they do not require customizations. The mandatory features of
Figure 1 are the suspension, transmission and engine. Mandatory features rep-
resent functionality that must be included in all products.
Variants: As mentioned in the introduction, the goal of variability is to
allow for exibility by delaying customization decisions. Variable features are
those features that require customizations. The transmission, engine, and ex-
tras are the variable features of Figure 1, because they can vary from one car
to another. The options available for a variable feature are called its variants.
The transmission is a variable feature with two variants: automatic and manual
(Fig. 1).
Depending on its variants a feature can be classied into optional or alter-
native [1]. Optional features do not require a variant and are included only in
certain products, e.g. the extra options in a car (see example on Fig. 1). Alterna-
tive features implement an obligatory feature in the product family in dierent
ways depending on the product developed. Alternative features are composed
of mutually inclusive or mutually exclusive variants [1]. Mutually inclusive vari-
ants depend on each other, so including one of them requires to include the rest
of them. Having mutually inclusive variants turns an alternative feature into a
multiple feature because it can have several values assigned. Mutually exclusive
variants are interchangeable. Having mutually exclusive variants make an alter-
native feature a single feature because it can have only one value assigned. In
the example of Fig. 1, the transmission is a single feature because the manual
and the alternative transmissions are mutually exclusive, while the engine is a
multiple feature because the gasoline and electric engines are mutually inclusive.
Variable features can be single if they must have one value assigned, multiple
if they can have several values assigned, and optional if they do not require a
value assigned. The example shown in Figure 1 presents a single feature (the
transmission), a multiple feature (the engine), and an optional feature the extra.
Variability Dependencies: There are two types of variability dependencies
which dictate constraints among variable features: when including a feature
requires including another feature, and when including a feature excludes or
prohibits the inclusion of another feature. For instance, automatic transmission
requires extra horsepower while the manual transmission excludes use of an
electric engine (Fig. 1).
144 A. Lozano
Variation Points: Variable features are implemented in the application in the

form of variation points. A variation point is the placeholder for a value that has
associated variable functionality. Variation points make explicit delayed design
decisions. Associating a value to a variation point is called binding. Variation
points with a value are bound, while those without a value are unbound.
3 Mining for Feature Diagrams
Feature diagrams describe the commonalities and dierences of some domain

model. Therefore feature diagram mining requires to analyze multiple applica-
tions of the same domain.
Antkiewicz et al. [2] analyzed applications that extend the same framework.
These applications can be viewed as instances of the same domain because their
usage of the framework shows congurations of the concepts provided by the
framework. The authors aim at detecting variable features. The feature to be
detected is described by an abstract concept that is the starting point of the
analysis. For instance, Applet will look for all instances of Applet in the ap-
plications analyzed. A feature is extracted in the form of sets of distinguishing
structural and behavioral patterns that allow discriminating congurations of
the same concept. The patterns are detected with source code queries. The re-
sults of the queries are facts that describe the structural and run-time relations
among source code entities. That is, variables/parameters/returned objects and
types, methods implemented and understood, calls sent and received, precedence
relations between methods called, etc. The mining builds a tree of source code
code facts obtained from the source code entity that is the starting point of the
analysis. The algorithm then calculates commonalities and dierences among
the facts to establish mandatory, optional, multiple and indispensable patterns
when conguring a feature of the framework.
Yang et al. [24] analyzed open source applications with similar functionality.
The assumption is that data models (entity-relationship) of these applications
are similar and uncover a basis for mapping the common concepts among dif-
ferent applications. The starting point of the mining is a reference domain data
model. The data schema of the applications is then mapped to the reference do-
main model by detecting entities or elds with similar names in the applications.
The approach is based on detecting consistent data access semantics (i.e., simi-
lar usage of data entities by the methods in the applications). The data access
semantics are obtained by detecting SQL statements using aspects which inter-
cept invocations to the database library and store SQL run-time records. In order
to verify that dierent methods have a similar data access semantics, the SQL
records must contain the tables, elds and constraints involved in the queries.
These records describe the data access semantics of each method in each appli-
cation. The records are then analyzed using Formal Concept Analysis (FCA),
a classication technique that aims at nding the maximal set of objects that
share a maximal set of properties or attributes. The resulting concepts represent
the usage of data-entities mapped to the reference domain model. Depending
on the level of the concept, it is merged with neighbor concepts or pruned so

that each concept represents one feature. The result is a domain feature diagram
comprising mandatory features, variable features, whether they are alternative
or multiple, its variants, and whether they are inclusive or exclusive. However,
the approach is incapable of detecting variability dependencies.
4 Mining for Variability Dependencies
Variability dependencies are constraints between features that establish the valid
products of a feature diagram. In terms of source code, variability dependen-
cies (requires/excludes) are related with control ow relations between features.
Nevertheless, other types of feature overlaps have been found by analyzing im-
plementations of features regardless of being variable or mandatory.
Czarnecki et al. [5] dene Probabilistic Feature Models for feature diagrams,
organized using the probability of having a feature given the presence of another
feature. The approach is based on counting the legal congurations of a feature
diagram. The legal congurations are used to determine a set of legal samples
(of legal congurations), which are in turn used to calculate the frequency of co-
existence of all possible combinations of features. These frequencies are then used
to obtain conditional probabilities, that is, the probability of requiring a feature
given the presence in the application of another feature. Conditional probabilities
are used to structure the feature diagram and to decide when a variable feature
is optional, alternative, mandatory, inclusive or exclusive. Finally, a Bayesian
Network with a Directed Acyclic Graph of the features, and the conditional
probability table is used to learn variability dependencies. The Bayesian Net-
work is capable of detecting require relations (probability(f eature1|f eature2))
and exclude relations (probability(f eature1|f eature2)) among features. A dis-
advantage of this approach is that it does not analyze source code but it requires
an intermediate approach to detect the Directed Acyclic Graph of features in
the domain and their mapping to several products.
Parra et al. [19] propose an analysis of feature constraints based on the as-
sumption that variable features are implemented with aspects. The approach
detects that one feature requires a second feature when the pointcut that de-
nes the variation point for the rst feature references source code elements
referred to by the aspect that denes the second feature. The approach can de-
tect when one feature excludes a second feature, when the pointcuts (that dene
the variation points) for both features refer to the same source code elements.
This analysis is used to detect the correct order (if it exists) to compose the
variants represented by aspects in the source code. The disadvantage of this
approach is that presupposes an aspect-oriented implementation of variability.
Egyed [6] assumes that calling a similar set of source code entities when ex-
ecuting dierent features implies that one feature is a sub-feature of the other.
Similarly, Antkiewicz et al.[2] consider that a sub-feature is essential if it is com-
mon to all applications (of the same domain) analyzed. This approach locates
a feature by identifying similar patterns in entities that may be related to the
146 A. Lozano
feature analyzed, a sub set of these patterns is considered a sub-feature. Aside

from detecting essential sub-features, their approach is also capable of detecting
incorrect features due to missing essential sub-features. However, this approach
is incapable of detecting variability dependencies across features that do not
have a containment relation.
Lai and Murphy [16] described two situations in which several features are
located in the same source code entity: overlap and order. Overlap occurs when
there is no control or data ow dependency between the features in the source
code entity. Overlap is expected and encouraged in sub-features; however, other
types of overlap should be documented and handled during maintenance. Order
occurs when the features in the source code entity have a control or data ow
dependency, i.e. they require a partial execution order. Usually wherever many
features were related, there was no partial order.
In his PhD thesis [11], Jaring proposes four types of variability dependencies
depending on the binding of variation points. The categories are: dependencies
between variation points , dependencies between a variation point and a vari-
ant , dependencies between a variant and a variation point , and dependencies
between variants . This characterization is used to uncover hidden variability
dependencies in a legacy application (that uses C macros to implement its vari-
ability). However it is not clear to what extent the analysis is automated and to
what extent it requires user-input.
5 Mining for Variation Points and Variants
Variation points capture the functionality areas in which products of the same
product family dier. Mining for variation points aims at detecting source code
entities that allow diverging functionality across dierent products of the same
domain. Although there exists literature describing how to implement variabil-
ity [13,1,4,22,17], we could only nd one approach to detect variation points and
variants. The lack of approaches may be due to the wide variety of possibilities
to translate a conceptual variation point (i.e. a delayed decision) to the imple-
mentation of a variation point, as well as to the diculty to trace this translation
[20,14].
Thummalapenta and Xie [23] analyze applications that extend the same frame-
work. They calculate metrics that describe the amount and type of extensions
per class and method of the framework. These metrics allow to classify the
methods and classes of the framework into variation points (hotspots/hooks)
and coldspots/templates. Authors, analyzed the level of variability of the frame-
works analyzed by counting the percentage of classes and methods identied as
variation points. The disadvantage of this approach is that it requires a high
variety of applications from the domain to give reliable results.
A variant is an option available for a variable feature. Mining for variants
implies assigning a high level concept to the values (or objects) used in the
variation points to decide when to change the implementation of a variable
feature. This means that mining for variants requires detecting variation points
and linking them to their corresponding variable feature, so it is possible to trace

them to a single feature. We could not nd any approaches to mine for variants.
However this lack of results is predictable because of the lack of approaches
to mine for variation points. Given that the approach described above [23] was
designed to analyze the exibility of frameworks, it lacks references to variability,
and therefore, to variants.
6 Mining for Products of the Same Domain

Snelting [21] analyzes macros (Cs preprocessor directives like #ifndef ). The lines
of code corresponding to each macro are characterized with the global variables
(or conguration variables) that aects them. This characterization produces a
table where each line has the lines of code of each macro and each column the
variables congured in such macro. The table is analyzed using Formal Concept
Analysis (FCA). The concepts of the lattice resulting from the analysis represent
a possible conguration of the application. The intent of the concepts provides
the variables that aect that conguration, and the extent the lines of code af-
fected by that conguration. Moreover, the relations between concepts indicate
subsumed congurations. Crossed relations between chains of concepts would in-
dicate interference among those congurations. If the application is implemented
separating concerns and anticipating changes the lattice would have disjoint sub-
lattices in the middle of the lattice (i.e. high conguration coupling). Otherwise
conguration variables of dierent features would be merged in single concepts
in the middle area of the lattice, indicating dependencies and low coupling.
Hummel et al.[10] analyzed the signatures of the methods of several open
source applications to recommend methods that classes in the same domain im-
plement but that are missing from the users implementation. The approach
assumes that the domain concept that a class represents is summarized as the
set of signatures of its methods. Using this information, their technique nds
all classes with a similar set of signatures to the users class, and detects the
signatures missing from the user implementation. The disadvantage of this tech-
nique is that it is limited to the domain concepts that are implemented in open
source applications, and therefore it might be dicult to use for business-specic
domain concepts.
7 Mining for Variable vs. Mandatory Features

Several approaches mine for features.However, this section focuses on approaches
to dierentiate between mandatory (common functionality across products of the
same domain) and variable features (divergent functionality across products of
the same domain). This is usually achieved by analyzing the results of clone
detection.
Faust and Verhoef [8] were the rst ones to propose the analysis of diverse
products of the same domain to explore development paths for mandatory fea-
tures. They use bonsai maintenance as a metaphor to keep product lines under
148 A. Lozano
control. The approach is called grow and prune because it aims at letting prod-
ucts of the domain evolve (grow), and then merge as mandatory features (prune)
the successful source code entities of these products. For that reason, they pro-
posed metrics to evaluate the success of a source code entity. A source code
entity is dened as successful if its implementation contained a large amount of
code, a low number of decisions, and a low frequency of changes, was highly used
and cloned. Nevertheless the approach is incapable of oering further assistance
for restructuring the product line.
Mende et al. [18] use clone detection to measure the level of commonalities
across directories, les and functions of dierent products of the same domain.
The idea is to assess to what extent a product (p1) can be merged into a basic
product (p2), and to what extent the functionality of the product to be merged
(p1) is included in the other product (p2). Depending on the number of identical
functions (similarity = 1) and of similar functions (similarity between 0 and 1)
of the product p2 into the product p1, it is possible to say if the correspondence
is identical or potential, and if such correspondence is located in one function
or not. Therefore the analysis proposed helps to detect potential mandatory
features parts in an existing product line (i.e., product-specic functions identical
across several products), as well as variability points that may require some
restructuring to separate better mandatory and variable features (i.e., product-
specic functions similar across several products).
Frenzel et al.[9] extract the model of a product-line architecture based on
several products of the same domain. To extract the model they use reexion
models, which gives them the static components, their interfaces, their depen-
dencies, and their grouping as layers and sub-layers in the system. The model
is then compared with the implementation of the products by checking whether
dierent products have corresponding components (based on clone similarity).
Clone detection is also used to transfer common implementation areas to the
common design. The latter two approaches are merged and further developed
in [15]. However, given that these approaches do not mine for features, they
are unable infer the feature diagram and its correspondence with the inferred
architecture .
8 Conclusions
This paper compiles techniques to propose refactorings from variable to manda-
tory features, and to improve the comprehension of variable products by dis-
covering the decomposition of features in a domain, the hidden links among
implementations of variable features, the source code entities in charge of the
variation, and valid products of a domain. Although we found several approaches
to mine for most of the variability concepts the approaches can be improved in
several ways. Some of the techniques have demanding requirements. For instance,
reconstructing feature diagrams require an initial domain model [24] or entity
that implements the feature to analyze [2], while detecting excludes/requires
dependencies may require an aspect-oriented implementation of variable fea-
tures [19] or an initial feature diagram and its mapping to several applications
[5]. Other techniques have a restricted automated support. For example, recon-
structing feature diagrams may require manual post processing [24]. Finally, the
usefulness of the output of some techniques is limited to address architectural
degradation of product-line design from single products. For instance, knowing
the congurations of a product line and the variables involved [21] does not pro-
vide any hints on how to restructure it or on how to map this implementation
details to domain concepts; which limits the usage of the approach to deal with
architectural degradation due to evolution.
Mining for variation points is the area with highest potential because there
are several papers that describe how variability should be implemented. Mining
for variants also has potential given that is a neglected area, and that it is com-
plimentary to the detection of variation points. Nevertheless, detecting variation
points is not enough to detect variants because each variation point needs to be
linked to a variable feature. However, the assignment of a variation points to a
variable feature could be technically challenging because the majority of order
interactions are due to control ow dependencies [16]. Another area open for
future work is extending the approaches to mine for feature diagrams, and for
variable and mandatory features to analyze the exibility of single products in
order to support the migration towards product-line development.
References
1. Anastasopoulos, M., Gacek, C.: Implementing product line variabilities. In: SSR
2001: Proc. of the 2001 Symposium on Software Reusability, pp. 109117. ACM,
New York (2001)
2. Antkiewicz, M., Bartolomei, T.T., Czarnecki, K.: Fast extraction of high-quality
framework-specic models from application code. Autom. Softw. Eng. 16(1), 101
144 (2009)
3. Bosch, J., Florijn, G., Greefhorst, D., Kuusela, J., Obbink, J.H., Pohl, K.: Variabil-
ity issues in software product lines. In: Revised Papers from the 4th Intl Workshop
on Software Product-Family Engineering, PFE 2001, pp. 1321. Springer, Heidel-
berg (2002)
4. Brown, T.J., Spence, I., Kilpatrick, P., Crookes, D.: Adaptable components for soft-
ware product line engineering. In: Chastek, G.J. (ed.) SPLC 2002. LNCS, vol. 2379,
5. Czarnecki, K., She, S., Wasowski, A.: Sample spaces and feature models: There
and back again. In: SPLC 2008: Proc. of the 2008 12th Intl Software Product Line
Conference, pp. 2231. IEEE Computer Society, Washington, DC, USA (2008)
6. Egyed, A.: A scenario-driven approach to traceability. In: ICSE 2001: Proc. of
the 23rd Intl Conference on Software Engineering, pp. 123132. IEEE Computer
Society, Washington, DC, USA (2001)
7. Eick, S.G., Graves, T.L., Karr, A.F., Marron, J.S., Mockus, A.: Does code decay?
assessing the evidence from change management data. IEEE Trans. Softw. Eng. 27,
112 (2001)
8. Faust, D., Verhoef, C.: Software product line migration and deployment. Software:
Practice and Experience 33(10), 933955 (2003)
150 A. Lozano
9. Frenzel, P., Koschke, R., Breu, A.P.J., Angstmann, K.: Extending the reexion
method for consolidating software variants into product lines. In: WCRE 2007:
Proc. of the 14th Working Conference on Reverse Engineering, pp. 160169. IEEE
Computer Society, Washington, DC, USA (2007)
10. Hummel, O., Janjic, W., Atkinson, C.: Proposing software design recommendations
based on component interface intersecting. In: Proc. of the 2nd Intl Workshop on
Recommendation Systems for Software Engineering, RSSE 2010, pp. 6468. ACM,
New York (2010)
11. Jaring, M.: Variability Engineering as an Integral Part of the Software Product
Family Development Process. PhD thesis, Rijksuniversiteit Groningen (2005)
12. Johansson, E., H ost, M.: Tracking degradation in software product lines through
measurement of design rule violations. In: Proc. of the 14th Intl Conference on
Software Engineering and Knowledge Engineering, SEKE 2002, pp. 249254. ACM,
New York (2002)
13. Keepence, B., Mannion, M.: Using patterns to model variability in product families.
IEEE Softw. 16, 102108 (1999)
14. Kim, S.D., Her, J.S., Chang, S.H.: A theoretical foundation of variability in
component-based development. Inf. Softw. Technol. 47, 663673 (2005)
15. Koschke, R., Frenzel, P., Breu, A.P., Angstmann, K.: Extending the reexion
method for consolidating software variants into product lines. Software Quality
Control 17, 331366 (2009)
16. Lai, A., Murphy, G.C.: The structure of features in Java code: An exploratory
investigation. In: Ossher, H., Tarr, P., Murphy, G. (eds.) Workshop on Multi-
Dimensional Separation of Concerns (OOPSLA 1999) (November 1999)
17. Maccari, A., Heie, A.: Managing innite variability in mobile terminal software:
Research articles. Softw. Pract. Exper. 35(6), 513537 (2005)
18. Mende, T., Beckwermert, F., Koschke, R., Meier, G.: Supporting the grow-and-
prune model in software product lines evolution using clone detection. In: Proc. of
the 2008 12th European Conference on Software Maintenance and Reengineering,
CSMR 2004, pp. 163172. IEEE Computer Society, Washington, DC, USA (2008)
19. Parra, C., Cleve, A., Blanc, X., Duchien, L.: Feature-based composition of software
architectures. In: Babar, M.A., Gorton, I. (eds.) ECSA 2010. LNCS, vol. 6285, pp.
20. Salicki, S., Farcet, N.: Expression and usage of the variability in the software prod-
uct lines. In: Revised Papers from the 4th Intl Workshop on Software Product-
Family Engineering, PFE 2001, pp. 304318. Springer, London (2002)
21. Snelting, G.: Reengineering of congurations based on mathematical concept anal-
ysis. ACM Trans. Softw. Eng. Methodol. 5(2), 146189 (1996)
22. Svahnberg, M., van Gurp, J., Bosch, J.: A taxonomy of variability realization tech-
niques: Research articles. Softw. Pract. Exper. 35, 705754 (2005)
23. Thummalapenta, S., Xie, T.: Spotweb: detecting framework hotspots via mining
open source repositories on the web. In: Proc. of the 2008 Intl Working Conference
on Mining Software Repositories, MSR 2008, pp. 109112. ACM, New York (2008)
24. Yang, Y., Peng, X., Zhao, W.: Domain feature model recovery from multiple appli-
cations using data access semantics and formal concept analysis. In: WCRE 2009:
Proc. of the 2009 16th Working Conference on Reverse Engineering, pp. 215224.
IEEE Computer Society, Washington, DC, USA (2009)
Variability in Multi-tenant Environments:
Architectural Design Patterns from Industry
Jaap Kabbedijk and Slinger Jansen
Utrecht University
Department of Information and Computing Sciences
Princetonplein 5, 3584CC, Utrecht, Netherlands
{j.kabbedijk,s.jansen}@cs.uu.nl
Abstract. In order to serve a lot of dierent customers in a SaaS envi-

ronment, software vendors have to comply to a range of dierent vary-
ing requirements in their software product. Because of these varying
requirements and the large number of customers, a variable multi-tenant
solution is needed to achieve this goal. This paper gives a pragmatic
approach to the concepts of multi-tenancy and variability in SaaS en-
vironments and proposes three architectural patterns that support vari-
ability in multi-tenant SaaS environments. The Customizable Data Views
pattern, the Module Dependent Menu pattern and the Pre/Post Update
Hooks pattern are explained and shown as good practices for applying
variability in a multi-tenant SaaS environment. All patterns are based on
case studies performed at two large software vendors in the Netherlands
who are oering an ERP software product as a service.
Keywords: Software-as-a-Service, Variability, Multi-tenancy, Architec-

tural Patterns.
1 Introduction
Increasingly, product software vendors want to oer their product as a service
to their customers [1]. This principle is referred to in literature as Software as a
Service (SaaS) [2]. Turning software into a service from a vendors point of view
means separating the possession and ownership of software from its use. Software
is still maintained and deployed by the vendor, but used by the customer. The
problem of moving a software product from dierent on-premises locations to one
central location, is the fact that it becomes really dicult to comply to specic
customer wishes. In order to serve dierent customers wishes, variability in
a software product is needed to oer specic functionality. By making use of
variability in a software product, it is possible to supply software functionality
as optional modules, that can be added to the product at runtime. Applying
this principle can overcome many current limitations concerning software use,
deployment, maintenance and evolution in a SaaS context [3]. It also reduces
support costs, as only a single instance of the software has to be maintained [4].
Besides complying to specic customer requirements, a software vendor should
be able to oer a service to a large number of customers, each with their own

152 J. Kabbedijk and S. Jansen
requirement wishes, without running into scalability and conguration prob-

lems [5]. The solution to this problem is the use of multi-tenancy within a SaaS
product. Multi-tenancy can be seen as an architectural design pattern in which
a single instance of a software product is run on the software vendors infrastruc-
ture, and multiple tenants access the same instance [6]. It is one of the key com-
petencies to achieve higher prot margins by leveraging the economy of scale [7].
In contrast to a model incorporating multiple users, multi-tenancy requires cus-
tomizing the single instance according to the varying requirements among many
customers [8]. Currently, no well documented techniques are available on how to
realize the variability needed in multi-tenant SaaS environments.
First the research method is discussed in section 2, after which the most im-
portant concepts in this paper will be explained and discussed in section 3. Then,
the trade-o between the level of variability needed and the number of customers
is discussed in section 4, followed by three architectural design patterns for vari-
ability in SaaS product in section 5. The paper ends with a conclusion and future
research in section 6.
2 Research Method
In this research, the variability realization techniques (VRTs) currently described
in literature and in place in large SaaS providers are observed. In order to do this,
a thorough literature study has been performed, in which the combinations of
variability, saas and variability, multi-tenancy were used as keywords in Google
Scholar1 . The VRTs discussed in the papers having the previous mentioned
keywords in their title or abstract were collected and patterns in those patterns
were put in a pattern database. A total of 27 papers was collected this way.
Besides the literature study, two independent case studies were performed at
large ERP providers who recently launched their enterprise resource planning
(ERP) software as a service through the Internet (refered to as ErpCompA and
ErpCompB from here on). ErpCompA has a turnover of around 250 million
euros and around 20,000 users using their online product, while ErpCompB has
a turnover of around 50 million euros and around 10,000 users. The case studies
were performed using the case study research approach by Yin [9].
The VRTs are presented as architectural design patterns and created based
on the Design Science principles of Hevner [10], in which a constant design
cycle consisting of the construction and evaluation of the VRTs takes place.
The initial model is constructed using a exploratory focus group (EFG) [11],
consisting out of participants from academia and the case companies, and a
systematic literature review [12]. The focus group has been carefully selected
and all participants have experience in the area of variable multi-tenant SaaS-
environments. Additional validation of the VRTs was done conducting interviews
with software architects within the two case companies [13].
1
Google Scholar (www.scholar.google.com indexes and searches almost all academic
publishers and repositories world-wide.
Variability in Multi-tenant Environments 153
3 Related Work and Denitions

To explain the multi-faceted concepts used in this paper, this section will discuss
multi-tenancy, design patterns and variability in more depth. The denition
proposed are meant to enable researchers to have one shared lexicon on the
topic of multi-tenancy and variability.
Multi-tenancy
Multi-tenancy can be dened as the ability to let dierent tenants share the
same hardware resources, by oering them one shared application and database
instance, while allowing them to congure the application to t their needs as
if it runs on a dedicated environment [5]. A tenant refers to an organization or
part of an organization with their own specic requirements, renting the software
product. We dene dierent levels of multi-tenancy:
Data Model Multi-tenancy: All tenants share the same database. All
data is typically provided with a tenant specic GUID in order to keep
all data separate. Even better is native support for multi-tenancy in the
database management system [14].
Application Multi-tenancy: Besides sharing the same database, all ten-
ants also share the same instance of the software product. In practice, this
could also mean a couple of duplications of the same instance, coupled to-
gether with a tenant load balancer [8].
Full Multi-tenancy: All tenants share the same database and software
instances. They can also have their own variant of the product, based on
their tenant requirements. This level of multi-tenancy adds variability to the
software product.
All items above are sorted on ascending implementation complexity.
Variability
The concept of variability comes from the car industry, in which dierent com-
binations of for example chassis, engine and color were dened as dierent vari-
ants. In software the concept is rst introduced in the area of software product
lines [15], in which variability is dened as the ability of a software system or
artefact to be eciently extended, changed, customized or congured for use in
a particular context [16]. Within the area of software product lines, software is
developed by the software vendor and then shipped to the customer to be run
on-premises. This means variants have to be compiled before product shipping.
Within the area of Software-as-a-Service, software is still developed by the soft-
ware vendor, but the product is served to all customers through the internet from
one central place [3,8]. In principle, all variants can be composed the moment
customers ask for some specic functionality, so at run-time.
We identify two dierent types of variability within multi-tenant SaaS
deployments:
Segment Variability: Product variability based on the segment a tenant is
part of. Examples of such variability issues are dierent standard currencies
or tax rules per country or a dierent layout for SMEs and sole proprietor-
ships.
Tenant-oriented Variability: Product variability based on the specic
requirements of a tenant. Examples of such variability issues are dierent
background colors or specic functionality.
We also identify dierent levels of variability in tenant oriented variability:
Low: Look and Feel: Changes only inuencing the visual representation
of the product. These changes only occur in the presentation tier (tier-based
architecture [17]) or view element (MVC-base architecture [18]). Examples
include dierent background colors or dierent element sorting in lists.
Medium: Feature: Changes inuencing the logic tier in tier-based archi-
tecture or the model or controller element in a MVC-based architecture.
Examples include the changes in workow or the addition of specic func-
tionality.
High: Full: Variability of this level can inuence multiple tiers at the same
time and can be specic. Examples of this level of variability includes the
ability for tenant to run their own program code.
The scope of this research is focussed on runtime tenant-oriented low and medium
variability in multi-tenant SaaS deployments.
Design Patterns
The concept of patterns was rst introduced by Christopher Alexander in his
book about the architecture of towns [19]. This concept was quickly picked up
in the software engineering world and led to the famous Gang of Four pattern
book by Gamma et al. [20]. This book describes several patterns that are still
used today and does this in a way that inspired a lot of subsequent pattern au-
thors. The denition of a pattern used in this paper originates from the Pattern
Oriented Software Architecture series [21,22,23,24,25] and reads: A pattern for
software architecture describes a particular recurring design problem that arises
in specic design contexts, and presents a well-proven generic scheme for its solu-
tion. The solution scheme is specied by describing its constituent components,
their responsibilities and relationships, and the ways in which they collaborate.
Patterns are not articially created artifacts, but evolve from best practices
and experiences. The patterns described in this paper result from several case
studies and discussions with experienced software architects. All patterns have
proven to be a suitable solution for the problems described in section 5, since they
are applied in successful SaaS products at our case companies. Also, all patterns
are described language or platform independent, so the solution can be applied
in various situations in the Software-as-a-Service domain. More information on
future research concerning the patterns proposed can be found in section 6.
4 User-Variability Trade-o
The best solution for deploying a software product from a software vendors per-
spective depends on level of resources shared and the level of variability needed
to keep all users satised. In gure 1 four deployment solutions are introduced,
that are considered best practices in the specic situations shown. In this section,
the need for multi-tenant deployment models is explained.
Standard Configurable
Multi-tenant Multi-tenant a = Business Growth
Solution b Solution b = Customer
Need for resource
Requirements Growth
PAAS
sharing
IAAS
a
a+
Custom b
SPL
Software Solution
Solution
Need for Variability

Fig. 1. Level of variability versus Number of users
By using the model shown in gure 1, software vendors can determine the
best suited software deployment option. On the horizontal axis, the need for
variability in a software product is depicted and the number of customers is
shown on the vertical axis. For a small software vendor who does not have
a lot of customers with specic wishes, a standard custom software solution
is sucient. The more customers software vendors get (business growth), the
higher the need for a standard multi-tenant solution because of the advantages
in maintenance. When the amount of specic customer wishes grows, software
vendors can choose the software product line (SPL) approach to create variant
for all customers having specic requirements. This solution can lead to a lot of
extra maintenance issues as the number of customers grows. In case of a large
number of customers having specic requirements, a congurable multi-tenant
solution is the best solution for software vendors, keeping an eye on performance
and maintenance.
5 Variability Patterns
In this section three patterns are described that were observed in the case stud-
ies that were conducted. The patterns are designed based on patterns observed
within the case companies software product, extended by patterns already doc-
umented in literature [20,16]. All patterns will be explained by an UML-diagram,
together with descriptive topics proposed by Buschmann et al. [24] and Gamma
et al. [20]
5.1 Customizable Data Views
In this section, a variability pattern is discussed, enabling developers to give

tenants a way to indicate their preferences on the representation of data within
the software product.
0.* uses 0.*

UserSettings DataRepresentation FunctionalComponent
+UserID
+lterData() +lter()
+SortOrder
+sortData() +sort()
+FilterItems
+xData()
+FontSize
+FontColor 0.*
+AttributeN uses
1
DataComponent
+storeSetting(userID,setting)
+retrieveSetting(userID,setting)
Fig. 2. Customizable Data Views Pattern
Intent - To give the tenant the ability to indicate and save his preferences on
the representation of data shown.
Motivation - In a multi-tenant solution it is important to give tenants the feel-
ing they can customize the product the way they want it. This customizability
is most relevant in parts of the product where data is presented to the tenant.
Solution - In this variability pattern (cf. gure 2), the representation of data is
performed at client side. Tenants can for example choose how they want to sort
or lter their data, while the data-queries do not have to be adapted. The only
change needed to a software product is the introduction of tenant-specic rep-
resentation settings. In this table, all preferred font colors, sizes and sort option
can be stored in order to retrieve this information on other occasions to display
the data again, according to the tenants wishes.
Explanation - As can be seen in the UML representation of the pattern in g-
ure 2, the DataRepresentation class can manipulate the appearance of all data
by making use of a FunctionalComponent able of sorting, ltering, etcetera. All
settings are later stored by a DataComponent in a specic UserSettings table.
Settings can later be retrieved by the same DataComponent, to be used again
by the DataRepresentation class and FunctionalModule.
Consequences - By implementing this pattern, one extra table has to be imple-
mented. Nothing changes in the way data selection queries have to be formatted.
Representation of all data has to be formatted in a default way, except if a ten-
ant changes this default way and stores his own preferences.
Example - In a bookkeeping program, a tenant for example, can decide what
columns he wants to display and how he wants to order them. By clicking the
columns he wants to display, his preferences are saved in the database. When
the tenant uses the product again later, his preferences are fetched from the
database and applied to his data.
5.2 Module Dependent Menu
This section describes a pattern to create dynamic menus, based on the modules
associated to a tenant.
0.* uses 0.1

Menu ModuleChecker UserModules
+userID
+addButton() +checkModuleID(moduleID)
+moduleID
+checkModule(moduleID) +checkUserID(userID)
0.*
0.*
0.* links to 0.*
Button Module
+image +moduleID
+description +functionA()
+link +functionB()
+mandatoryModule = moduleID +functionN()
Fig. 3. Module Dependent Menu
Intent - To provide a custom menu to all tenants, only containing links to the
functionality relevant to the tenant.
Motivation - Since all tenants have specic requirements to a software product,
they can all use dierent sets of functionality. Displaying all possible function-
ality in the menu would decrease the user experience of tenants, so menus have
to display only the functionality that is relevant to the tenant.
Solution - The pattern proposed (cf. gure 3), creates a menu out of dierent
buttons based on the modules associated to the tenant. Every time a tenant
displays the menu, the menu is built dynamically based on the modules he has
selected or bought.
Explanation - The Menu class aggregates and displays dierent buttons, con-
taining a link a specic module and the prerequisite for displaying this link
(mandatoryModule). The selection of buttons is done, based on the results of
the ModuleChecker. This class checks whether an entry is available in the User-
Modules table, containing both the ID of the tenant (user) and the mandatory
module. If an entry is present, the Menu aggregates and displays the button
corresponding to this module.
Consequences - To be able to use this pattern, an extra table containing user
IDs and the modules available to this user has to be implemented. Also, the
extra class ModuleChecker has to be implemented. All buttons do need a notion
of a mandatory module that can be checked by the ModuleChecker to verify if
a tenant wants or can have a link to the specic functionality.
Example - In a large bookkeeping product, containing several modules that can
be bought by a tenant, the menus presented to the tenant can be dynamically
composed based on the tenants license.
5.3 Pre/Post Update Hooks
In this section a pattern is described, capable of implementing modules just

before or after a data update.
PreComponent PostComponent
+attributeA +attributeA
+attributeB +attributeB
+attributeN +attributeN
+operationA() +operationA()
+operationB() +operationB()
+operationN() +operationN()
0.* 0.* UserModules
+userID
+moduleID
implements
0.*
0.* calls 1 1 uses 0.*
BusinessComponent FunctionalComponent ComponentChecker
+update(void) +update() +checkModuleID()

+preProcess(userID,componentID) +checkUserID()
+postProcess(userID,componentID)
0.*
calls
1
DataComponent DataTable
+xData
+updateData()
+yData
+zData
Fig. 4. Pre- Post Update Hooks
Intent - To provide the possibility for tenants to have custom functionality just
before or after an event.
Motivation - In business oriented software, workows often dier per tenant.
To let the software product t the tenants business processes best, extra actions
could be made available to tentants before or after an event is called.
Solution - The pattern introduced here (cf. gure 4), makes use of a component
able of calling other components before and after the update of data. The tenant-
specic modules are listed in a separate table, similar to the pattern described
in section 5.2.
Explanation - Before the FunctionalComponent calls the BusinessComponent
in order to perform an update, the ComponentChecker is used to check the
UserModules table if a tenant wants and may implements an extra component
before the update is performed. After this, the BusinessComponent is called
and the update is performed. The DataComponent takes care of the writing of
data to a specic data table. After this, the ComponentChecker again checks the
UserModules table and a possible PostComponent is called.
Consequences - Extra optional components have to be available in the software
system in order to be able to implement this pattern. The amount and type of
components available depends on the tenants requirements.
Example - In a bookkeeping program, tenants can choose, whether they want

to update a third party service as well by using a component that uses the API
of a third party service to make changes there. If so, the FunctionalComponent
can call the third party communicator after an internal update is requested.
6 Conclusion and Future Research

This paper gives a classication of dierent types of multi-tenancy and variabil-
ity, enabling researchers to have one shared lexicon. Satisfying the need for a
pragmatic overview on how to comply to the specic requirements of large num-
bers of customers, while keeping a product scalable and maintainable, this paper
showed an introduction to the concept of variability in multi-tenant Software-
as-a-Service solutions and presented three patterns gathered from industry case
studies. By applying these patterns, companies can better serve customers and
keep their software product maintainable and scalable. All three patterns are
proven to be eective within the case companies and are reviewed by experts
from the case companies, but still need to be analyzed more in terms of perfor-
mance and eectiveness.
More VRTs still have to be identied and the eectiveness, maintainability,
scalability and performance of all VRTs still has to be tested in future research.
Currently a preliminary VRT evaluation model and testbed are being developed
enabling researchers to test all identied VRTs and draw conclusions on their
eectiveness. Also more case companies from other domains will be examined,
enabling us to identify and test more VRTs.
Acknowledgment. This research is part of the Product as a Service project.

Thanks goes to both case companies and their helpful architects, experts and
developers.
References
1. Ma, D.: The Business Model of Software-As-A-Service. In: IEEE International
Conference on Services Computing, SCC 2007, pp. 701702. IEEE, Los Alamitos
(2007)
2. Gold, N., Mohan, A., Knight, C., Munro, M.: Understanding service-oriented soft-
ware. IEEE Software 21(2), 7177 (2005)
3. Turner, M., Budgen, D., Brereton, P.: Turning software into a service. Com-
puter 36(10), 3844 (2003)
4. Dubey, A., Wagle, D.: Delivering software as a service. The McKinsey Quarterly 6,
112 (2007)
5. Bezemer, C., Zaidman, A.: Multi-tenant SaaS applications: maintenance dream or
nightmare? In: Proceedings of the International Workshop on Principles of Software
Evolution (IWPSE), pp. 8892. ACM, New York (2010)
6. Bezemer, C., Zaidman, A., Platzbeecker, B., Hurkmans, T., Hart, A.: Enabling
multi-tenancy: An industrial experience report. In: 26th IEEE Int. Conf. on Soft-
ware Maintenance, ICSM (2010)
7. Guo, C., Sun, W., Huang, Y., Wang, Z., Gao, B.: A framework for native multi-
tenancy application development and management. In: The 9th IEEE International
Conference on E-Commerce Technology, pp. 551558 (2007)
8. Kwok, T., Nguyen, T., Lam, L.: A software as a service with multi-tenancy support
for an electronic contract management application. In: IEEE International Confer-
ence on Services Computing, SCC 2008, vol. 2, pp. 179186. IEEE, Los Alamitos
(2008)
9. Yin, R.: Case study research: Design and methods. Sage Publications, Inc., Thou-
sand Oaks (2009)
10. Hevner, A.R., March, S., Park, J., Ram, S.: Design science in information systems
research. Mis Quarterly 28(1), 75105 (2004)
11. Tremblay, M.C., Hevner, A.R., Berndt, D.J.: The Use of Focus Groups in Design
Science Research. Design Research in Information Systems 22, 121143 (2010)
12. Cooper, H.: Synthesizing research: A guide for literature reviews (1998)
13. Runeson, P., H ost, M.: Guidelines for conducting and reporting case study research
in software engineering. Empirical Software Engineering 14(2), 131164 (2009)
14. Schiller, O., Schiller, B., Brodt, A., Mitschang, B.: Native support of multi-tenancy
in RDBMS for software as a service. In: Proceedings of the 14th International
Conference on Extending Database Technology, pp. 117128. ACM, New York
(2011)
15. Pohl, K., Bockle, G., van der Linden, F.: Software product line engineering: founda-
tions, principles, and techniques. Springer-Verlag New York Inc., Secaucus (2005)
16. Svahnberg, M., van Gurp, J., Bosch, J.: A taxonomy of variability realization tech-
niques. Software: Practice and Experience 35(8), 705754 (2005)
17. Eckerson, W.: Three Tier Client/Server Architectures: Achieving Scalability, Per-
formance, and Eciency in Client/Server Applications. Open Information Sys-
tems 3(20), 4650 (1995)
18. Krasner, G., Pope, S.: A description of the model-view-controller user inter-
face paradigm in the smalltalk-80 system. Journal of Object Oriented Program-
ming 1(3), 2649 (1988)
19. Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., Angel,
S.: A pattern language. Oxford Univ. Pr., Oxford (1977)
20. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design patterns: elements of
reusable object-oriented software, vol. 206
21. Buschmann, F.: Pattern-Oriented Software Architecture: A System of Patterns,
vol. 1. John Wiley & Sons, Chichester (1996)
22. Schmidt, D.: Pattern-Oriented Software Architecture: Patterns for Concurrent and
Networked Objects, vol. 2. Wiley, Chichester (2000)
23. Kircher, M., Jain, P.: Pattern-Oriented Software Architecture : Patterns for Re-
source Management, vol. 3 (2004)
24. Buschmann, F., Henney, K., Schmidt, D.: Pattern-Oriented Software Architecture:
Pattern Language for Distributed Computing, vol. 4. Wiley, Chichester (2007)
25. Buschmann, F.: Pattern-Oriented Software Architecture : On patterns and Pattern
Languages, vol. 5 (2007)
Preface to Onto.Com 2011
This volume collects articles presented at the first edition of the International
Workshop on Ontologies and Conceptual Modeling (Onto.Com 2011). This workshop
was organized as an activity of the Special Interest Group on Ontologies and
Conceptual Modeling of the International Association of Ontologies and Applications
(IAOA). It was held in the context of the 30th International Conference on Conceptual
Modeling (ER 2011), in Brussels, Belgium. Moreover, the workshop was designed
with the main goal of discussing the role played by formal ontology, philosophical
logics, cognitive sciences and linguistics, as well as empirical studies in the
development of theoretical foundations and engineering tools for conceptual
modeling.
For this edition, we have received 18 submissions from Belgium, Canada, France,
Germany, Italy, New Zealand, Russia, South Africa, Spain, Tunisia, United Kingdom,
and the United States. These proposals were carefully reviewed by the members of
our international program committee. After this process, 7 articles were chosen for
presentation at the workshop. In the sequel, we elaborate on these selected
submissions.
In the paper entitled Experimental Evaluation of an ontology-driven enterprise
modeling language, Frederik Gailly and Geert Poels discuss an experiment to
evaluate the use of an enterprise modeling language which was developed using the
Resource Event Agent (REA) enterprise ontology and the Unified Foundational
ontology (UFO). The effect of using the ontology-driven modeling language is
analyzed using a well-known method evaluation model which contains both actual
and perception-based variables for measuring the efficiency and effectiveness of the
used method.
In Levels for Conceptual Modeling, Claudio Masolo proposes a (non-exclusive)
alternative to taxonomic structuring based on subtyping relations in conceptual
modeling. The authors proposal relies on two relations: factual existential
dependence and extensional atemporal parthood. On the basis of these relations, the
author elaborates on a strategy to stratify object types in different levels, and to
manage inheritance in a manner that addresses some classical difficulties in the
modeling of this notion (e.g. attribute overriding, attribute hiding, or dynamic and
multiple classifications and specialization).
In Principled Pragmatism: A Guide to the Adaptation of Ideas from
Philosophical Disciplines to Conceptual Modeling, David W. Embley, Stephen W.
Liddle, and Deryle W. Lonsdale discuss the synergism among the traditional
disciplines of ontology, epistemology, logic, and linguistics and their potential for
enhancing the discipline of conceptual modeling. The authors argue that application
objectives, rather than philosophical tenets, should guide the adaptation of ideas from
these disciplines to the area of conceptual modeling.
In Ontology Usage Schemes: A Working Proposal for the Ontological Foundation
of Language Use, Frank Loebe proposes three thesis regarding the relations between
formal semantics, ontological semantics and representation systems. Based on these
theses, the author outlines and illustrates a proposal for establishing usage-specific
and ontology-based semantic schemes. Moreover, the author establishes a relation
162 Preface
between these findings and works regarding the specific case of conceptual modeling
languages. Finally, he discusses potential applications of these proposals, including
semantics-preserving translations and the re-engineering of representations.
In Gene Ontology based automated annotation: why it isn't working, Matthijs
van der Kroon and Ana M. Levin propose an analysis of the current practice of
ontology-based annotation in genome sequence applications. In particular, they
analyze the current approaches based on the Gene Ontology (GO) and elaborate on
the use of ontological categories to reflect on the pitfalls of these approaches.
In Formal Ontologies, Exemplars, Prototypes, Marcello Frixione and Antonio
Lieto discuss a fundamental notion in Knowledge Representation and Ontology
Specification, namely, the notion of Concept. In the paper, they discuss problematic
aspects of this notion in cognitive science, arguing that Concept it is an overloaded
term, referring to different sorts of cognitive phenomena. Moreover, they sketch some
proposals for concept representation in formal ontologies which take advantage from
suggestions coming from cognitive science and psychological research.
Finally, in the paper entitled Unintended Consequences of Class-based
Ontological Commitment, by Roman Lukyanenko and Jeffrey Parsons elaborate on a
rather controversial thesis, namely, that what appears to be a clear advantage of
domain-specific ontologies, i.e., the explicit representation of domain semantics, may
in fact impede domain understanding and result in domain information loss.
Moreover, the paper discusses what the authors claim to be unintended consequences
of class-based ontological commitment and advocates instead for the adoption of an
instance-and property ontological foundation for semantic interoperability support.
We would like to thank the authors who considered Onto.Com as a forum for
presentation of their high-quality work. Moreover, we thank our program committee
members for their invaluable contribution with timely and professional reviews.
Additionally, we are grateful to the support received by the IAOA (International
Association for Ontologies and Applications). Finally, we would like to thank the ER
2011 workshop chairs and organization committee for giving us the opportunity to
organize the workshop in this fruitful scientific environment.
July 2011 Giancarlo Guizzardi

Oscar Pastor
Yair Wand
Experimental Evaluation of an Ontology-Driven
Enterprise Modeling Language
Frederik Gailly and Geert Poels
Faculty of Economic, Political and Social Sciences and Solvay Business School,
Vrije Universiteit Brussel
Frederik.Gailly@vub.ac.be
Faculty of Economics and Business Administration, Ghent University
Geert.Poels@ugent.be
Abstract. In this workshop paper an experiment is designed which evaluates the

use of an enterprise modeling language that was developed with the Resource
Event Agent enterprise ontology and the Unified Foundational ontology as a
theoretical base. The effect of using the ontology-driven modeling language is
analyzed using Moodys Method Evaluation Model which contains both actual
and perception-based variables for measuring the efficiency and effectiveness of
the used method.
1 Introduction
In the conceptual modeling domain it is generally accepted that ontologies can be

used as a theoretical base for conceptual modeling languages [1]. This has resulted in
using both core and domain ontologies for the identification of shortcomings in
existing languages [2], the proposal of improvements to existing modeling languages
[3] and the development of new conceptual modeling languages [4]. In most cases the
validation of this research has been limited to demonstration of the shortcomings,
improvements or languages using a relevant conceptual modeling cases.
In this research we plan to empirically evaluate an enterprise modeling language
that is based on both a core ontology and a domain ontology. It is generally accepted
that ontologies can support communication by making some basic assumption
explicit, enable the reuse of domain knowledge and allow the creation of
interoperability by sharing some common understanding about a domain [5]. These
potential benefits are also relevant when ontologies are used for the development of
modeling languages but are in most cases only used as a reason for employing
ontologies but not actually proven by empirical research [6].
The empirical study designed in this paper wants to provide evidence that using a
domain-specific modeling language which is engineered using a core and a domain
ontology will result in on the one hand a model which is easier to integrate with other
models because some general ontology axioms are taken into account that are also
relevant for other domain. On the other hand we also want to evaluate the impact of
using the method on the domain-specific quality of the model which we define as the
degree to which a model respects the invariant conditions of a domain as axiomatised
164 F. Gailly and G. Poels
in the domain ontology [7]. Finally as we believe that ontology-driven modeling

languages also facilitate the reuse of domain knowledge we also want to evaluate the
efficiency and the perceptions of the modeling language user with respect to the used
method.
The ontology-driven modeling languages that will be empirically evaluated is the
Resource Event Agent (REA) enterprise modeling language. This domain-specific
modeling languages was developed in previous research [8] and is based on the
Resource Event Agent enterprise ontology (REA-EO) [9] and the Unified
Foundational ontology [7]. In the next section the REA ontology-driven modeling
language is introduced. Section 3 develops the research model and introduces the
hypotheses that will be analyzed by the experiment. In section 4 the actual design of
the experiment is presented. The paper ends with a short conclusion and an overview
the risks and limitations of the experimental design.
2 Enterprise Modeling Language
The enterprise modeling language used in this experiment is based on the Resource
Event Agent enterprise ontology and the Unified Foundational Ontology. The REA-
EO focuses on the creation of value in an enterprise and specifies that a business
process or transaction consists of Economic Events that transfer or consume
Economic Resources and Economic Agents that participate in these Economic Events.
Additionally the ontology differentiates between different layers that deal with (i) the
actual past and present in enterprise reality (i.e., what occurred or is occurring), (ii)
the known future (i.e., what will occur), and (iii) the allowable states of the unknown
future (i.e., what should occur). UFO is a core ontology developed by Guizzardi [7]
and represents a synthesis of a selection of core ontologies. It is tailored towards
applications in conceptual modeling. During the creation of the REA enterprise
modeling language UFO is used for the ontological analysis of the REA-EO concepts,
relations and axioms.
The development of the REA enterprise modeling language is described in [8] and
results in the creation of a UML profile (i.e. the REA profile) that transforms the
ontologies in a useful modeling language. The ontological evaluation of the REA-EO
using UFO supports the development of the REA profile in two ways. Firstly it allows
to define the stereotypes of the enterprise modeling language as specializations of the
stereotypes of the OntoUML profile which is a general purpose modeling language
that is core ontology-driven because it extends the UML class diagram metamodel
with stereotypes that have their origin in UFO [10]. Secondly the ontological analysis
also influences the development of the structuring rules for the enterprise modeling
language because it identifies the domain-independent axioms, the domain-specific
specializations of general axioms and the domain-specific extensions that need to be
translated into structuring rules. In the profile the domain-independent axioms are
inherited from the OntoUML profile and domain-specific axioms are implemented
using OCL.
Experimental Evaluation of an Ontology-Driven Enterprise Modeling Language 165
The REA-EO has been empirically evaluated for business modeling in previous
research projects. These experiments have shown that being able to consult the REA
enterprise ontology as a reference model, has a significant impact on the pragmatic
quality of the developed models [11]. Moreover model users perceive diagrams with
REA pattern occurrences as easier to interpret than diagrams without [12]. The main
difference between this research and this previous work, is that in this experiment the
REA ontology is not used as a reference model but instead is implemented as a
domain specific modeling language with accompanying structuring rules that are
based on the ontology axioms which have their origin in both a domain ontology and
a core ontology.
3 Research Model and Hypotheses

The goal of this research is evaluating the use of ontology-driven modeling method
for the creation of conceptual models. This is done by comparing the process of
creating a business model using the REA enterprise modeling language with creating
a business model with a domain-independent modeling language where the REA-EO
is used as a reference model. This is operationalized in the research model (see figure
2) by distinguishing two modeling methods: REA ontology-driven modeling and
enterprise modeling using REA as a reference.
As the focus of this research lies on evaluating a conceptual modeling method, the
research framework is derived from the Method Evaluation Model (MEM) [13].
According to the MEM the success of a modeling method is determined by the
efficacy and the adoption in practice. In this paper we will focus on the efficacy
because this is a new method that is not used in practice and following the MEM the
actual usage has a causal relation with the intention to use which has a causal relation
with the efficacy.
In the MEM the efficacy is determined using both performance based (i.e. actual
efficacy) and perception based (i.e. perceived efficacy) variables. The actual efficacy
measures whether the method improves the performance of the task and is determined
by the effort required to apply the method (i.e. efficiency) and the degree to which a
method achieves its objectives (i.e. effectiveness). The actual efficiency is
operationalized using the development time, defined as the time needed to create the
model. As the goal of the ontology-driven modeling method is creating models that
are easier to integrate and have a higher domain-specific quality, the effectiveness of
the method is operationalized using two variables: (1) integration quality which
measures the degree in which the part of the model that uses the REA modeling
language integrates concepts that are not within the scope of the domain-specific
modeling language and (2) domain-specific quality which we define as the degree to
which a model respects the invariant conditions of a domain as axiomatized in the
domain ontology.
The concept of perceived efficacy is operationalized by measuring the perceived
ease of use and the perceived usefulness. On the one hand the perceived ease of use is
a perception-based variable that measures the efficiency of using the modeling
method and is defined as the degree to which a person believes that using the method
would be free of effort. On the other hand the perceived usefulness measures the
Fig. 1. Research model
effectives of using the modeling method and is defined as the degree to which a
person believes that a particular method will be effective in achieving its attended
objectives.
Following the work of Topi and Ramesh [14] the research model in figure 1 also
contains the variables that need to be constant or controlled in the experiment because
they could influence the performance and perception based variables and we only
want to measure the influence of the used method. Firstly the characteristics of the
modeler (e.g. domain knowledge, personal characteristics, modeling language
knowledge) should be controlled. This will be done by randomly selecting the
participants for a specific treatment (cfr. Infra). Secondly the task that should be
performed is constant by making sure that all modelers must develop a business
model for the same business case. Finally the used notation of the modeling language
is also constant by using in both method the UML class diagram notation.
The specification of the experimental hypotheses is based on two different
foundational theories and results in two different sets of hypotheses. On the one hand
based on the contiguity principle of the multimedia learning theory of Mayer [15] we
believe that when using an integrated tool that implements both the language and the
rules instead of reference model with accompanying textual description of the axioms,
the actual and perceived efficiency will be higher:
Ha: The efficiency of creating a business model using the REA profile is
significantly higher when the model is created using the REA profile than when it is
created using standard UML class diagrams with REA as a reference framework.
Hb: The perceived ease of use while creating a business model using the REA
profile is significantly higher when the model is created using the REA profile than
when it is created using standard UML class diagrams with REA as a reference
framework.
On the other hand we also believe that the integration of the core ontology axioms
and domain-specific axioms in the domain specific modeling language forces the
modeler to take into account some general purpose and domain-specific modeling
structuring rules which actually make it easier to create a high-quality model. This
effect will be intensified by providing to the group that use the REA ontology as a
reference model only the domain-specific axioms and not the domain independent
axioms. Consequently the second hypothesis expects that modelers that use the profile
will develop models with a higher-domain specific quality and higher integration
quality, which should also result in a higher perceived usefulness:
Hc: The domain-specific quality of a business model created using the REA profile
is significantly higher when the model is created using the REA profile than when it is
Hd: The integration quality of a business model created using the REA profile is
He: The perceived usefulness of creating a business model using the REA profile is
modeled using standard UML class diagrams with REA as a reference framework.
4 Experimental Design
The potential users of an enterprise modeling language like REA are business people
who want to model the value creation of the business processes. Consequently the
participants of the experiments are students of a master in business engineering which
have followed a business modeling course that contains topics such as conceptual data
modeling (using ER modeling), business process modeling (using BPMN) and
domain-specific modeling using profiles.
The dependent variable is operationalized by dividing the group of participants in
two groups which will receive a different treatment. Group A will get one hour
introduction into REA enterprise modeling where the REA-model is used as a
reference model and the relevant axioms are described in text. Group B of students
will also learn the REA enterprise modeling language but will learn this by means of
the REA UML profile. Important to notice is that for both groups only a limited
version of the REA enterprise modeling languages will be taught because the
complete modeling languages is too complex to be taught in a limited time frame. As
a consequence we decided to exclude the policy layer of the REA ontology and only
take into account a limited set of structuring rules. The domain-specific structuring
that will be thought to the all participants are represented in table 1. The domain-
independent structuring rules that are only thought to group B and influence the
integration quality of the model are presented in table 2.
Table 1. REA structuring rules based on domain-specific specializations
Structuring Description
rule
1 Every Economic Agent must be related to an Economic Event via an
accountability or participation relationship
2 Instances of economic event must affect at least one instance of an
economic resource by means of an inflow or outflow relation
3 Instances of economic event must be related to at least one instance of
economic agent that is accountable for the event (i.e. inside agent) and
to at least one instance of an economic agent that participates in the
event (i.e. outside agent).
4 Instances of commitment must affect respectively at least one instance
of an economic resource or economic resource type by means of a
reserve or specify relationship.
5 Instances of commitment must be related to at least one instance of an
economic agent that is accountable for the event (i.e. inside agent) and
to at least one instance of an economic agent that participates in the
event (i.e. outside agent).
6 A Commitment that is connected to an economic resource or
economic resource type via a reserve-inflow or specify-inflow relation
must be connected via a inflow-fulfill relation to an Economic Event
that is connected to an inflow relation.
A Commitment that is connected to an economic resource or
economic resource type via a reserve-outflow or specify-outflow
relation must be connected via an outflow-fulfill relation to an
Economic Event that is connected to an outflow relation.
Table 2. REA structuring rules based domain-independent axioms
Structuring Description
rule
7 Instances of REA-EO Economic Resource and Economic Agents must
always directly or indirectly be an instance of a Substance Sortal
8 Economic Resources and Economic Agents cannot include in their
general collection more than one Substance Sortal
9 Economic Resources and Economic Agents cannot be specialized in
an entity representing a Kind
After receiving the treatment the two groups will receive the same business case
which is actually based on a existing business which sells trainings to their customers.
The business case contains on the one hand the description of business process which
contains both the planning and the actual execution of the training, can be modeled
using the REA profile or using the REA ontology as reference. Additionally the
business case contains some information that is not within the scope of REA but is
also relevant. The modeling of this information is given to the participants and should
be integrated in the model. For instance the business case indicates that every
available training is provided by a partner organization and a training is a special kind
of product for the company. Moreover the company makes a distinction between a
training and a planned training.
Fig. 2. Process models

Based on the case description the students have to perform two tasks. First they
have to develop a BPMN model for the business process. The creation of this model
has two goals: it forces the modeler to understand the process and it will be used to
control the domain knowledge and modeling experience of the students. Next they
have to develop a business model where the group A must use UML class diagrams
and group B the REA UML profile. Figure 2 and 3 represent respectively the BPMN
models and the REA UML profile business model for the business case. The
constructs in bold in figure 3 present the part of the business model that is given to the
participants.
Fig. 3. REA enterprise model
Following the hypotheses developed in previous section the following dependent

variables need to be measured: development time, integration quality, domain-specific
quality, perceived ease of use and perceived usefulness. Development time is
measured for the development of the process model and the business model
separately. Integration quality is measured by looking at how the business process of
the business model is integrated with the other domain information specified by
the case. An actual rating will be given by three business modelers from the firm that
has provided the case. Domain-specific quality is determined by evaluating in what
extent the developed model takes into account the domain-specific axioms. For
the models developed using the REA profile, the validation of the OCL constraints
can give an exact number. However for the other models three REA experts were
asked to annotate the models with REA concepts and afterwards evaluate the axioms.
The perception-based variables are measured by adding a post-task survey which
contains 12 items and uses a Likert scale. The items of the perceived ease of use (see
table 3) and perceived usefulness scale (see table 4) are based on the work of Davis
[16] and have been adopted and validated in other empirical research in conceptual
modeling [17].
Table 3. Perceived ease of use (PEOU)
PEOU1 I found the procedure for applying the method complex and difficult to
follow
PEOU2 Overall, I found the method difficult to use
PEOU3 I found the method easy to learn
PEOU4 I found it difficult to apply the method to the business case
PEOU5 I found the rules of the method clear and easy to understand
PEOU6 I am not confident that I am now competent to apply this method in
practice
Table 4. Perceived usefulness (PU)
PU1 I believe that the method reduces the effort required to create a business
model
PU2 I believe that this method has improved my overall performance during
the development of the business model
PU3 This method makes it easier for users to create business models
PU4 Overall, I found the method to be useful for the development of a
business model
PU5 I believe that this method allows me to create business models more
quickly
PU6 Overall, I think this method does not provide an effective solution to the
problem of representing business models
5 Conclusion, Limitations and Risks

In this position paper the research model, the hypotheses and the design of an
experiment is presented which has as goal the evaluation of an ontology-driven
enterprise modeling language. It is expected that using language that has been
developed using both a domain and core ontology has a positive impact on the
efficiency and effectiveness of the method. The described experiment will be pre-
tested in June 2011 and will be executed in October 2011.
The proposed experimental design has also some limitations and risks. First the
external validity of the experiment might be limited by the fact that business students
are used as modelers. This approach was followed because we want to control the
characteristics of the users and because of difficulties in finding companies that want
to participate in these type of experiments. However we believe the generalizability of
the results is improved by using a real business case and by involving the business
people that provides us with the case in the assessment of the quality of the models. A
possible risk of the experiment is that no real differences will be found because a slim
version of the ontology-driven modeling language is used. However we believe that
this unavoidable because experience with previous experiments clearly showed that in
a time frame of max 3 hours the complexity of the language must be bordered.
References
1. Wand, Y., Weber, R.: An Ontological Model of an Information System. IEEE
Transactions on Software Engineering 16, 12821292 (1990)
2. Wand, Y., Storey, V.C., Weber, R.: An Ontological Analysis of the Relationship Construct
in Conceptual Modeling. ACM Transactions on Database Sysems 24 (1999)
3. Evermann, J., Wand, Y.: Ontology based object-oriented domain modelling: fundamental
concepts. Requirements Engineering 10, 146160 (2005)
4. Tairas, R., Mernik, M., Gray, J.: Using Ontologies in the Domain Analysis of Domain-
Specific Languages. In: Chaudron, M.R.V. (ed.) MODELS 2008. LNCS, vol. 5421, pp.
5. Gruninger, M., Lee, J.: Ontology Applications and Design: Introduction. Communications
of the ACM 45, 3941 (2002)
6. Henderson-Sellers, B.: Bridging metamodels and ontologies in software engineering.
Journal of Systems and Software 84 (2011)
7. Guizzardi, G.: Ontological Foundations for Structural Conceptual Models.
TelematicaInstituut cum laude. University of Twente, Twente (2005)
8. Gailly, F., Geerts, G., Poels, G.: Ontology-driven development of a domain-specific
modeling language: the case of an enterprise modeling language. FEB working paper
series. Ghent University (2011)
9. Geerts, G., McCarthy, W.E.: An Accounting Object Infrastructure for Knowledge Based
Enterprise Models. IEEE Intelligent Systems and Their Applications 14, 8994 (1999)
10. Benevides, A.B., Guizzardi, G.: A Model-Based Tool for Conceptual Modeling and
Domain Ontology Engineering in OntoUML. In: Filipe, J., Cordeiro, J. (eds.) Enterprise
Information Systems. LNBIP, vol. 24, pp. 528538. Springer, Heidelberg (2009)
11. Poels, G., Maes, A., Gailly, F., Paemeleire, R.: The pragmatic quality of Resources-
Events-Agents diagrams: an experimental evaluation. Information Systems Journal 21, 63
89 (2011)
12. Poels, G.: Understanding Business Domain Models: The Effect of Recognizing Resource-
Event-Agent Conceptual Modeling Structures. Journal of Database Management 21 (2011)
13. Moody, D.: The Method Evaluation Model: A Theoretical Model for Validating
Information Systems Design Methods. In: 11th European Conference on Information
Systems, ECIS 2003 (2003)
14. Topi, H., Ramesh, V.: Human Factors research on Data Modeling: A review of Prior
Research, An extended Framework and Future Research Directions. Journal Database
Management 13, 319 (2002)
15. Moreno, R., Mayer, R.E.: Cognitive Principles of Multimedia Learning: The Role of
Modality and Contiguity. Journal of Educational Psychology 91, 358368 (1999)
16. Davis, F.D.: Perceived Usefulness, Perceived Ease of Use, and User Acceptance of
Information Technology. MIS Quarterly 13, 319340 (1989)
17. Maes, A., Poels, G.: Evaluating quality of conceptual modelling scripts based on user
perceptions. Data & Knowledge Engineering 63, 701724 (2007)
Levels for Conceptual Modeling
Claudio Masolo
Laboratory for Applied Ontology, ISTC-CNR, Trento, Italy

masolo@loa-cnr.it
Abstract. Usually object types are organized in taxonomies by means

of a specialization relation (also called subtyping or isa) implemented
by means of inheritance. This paper proposes a (non-incompatible) alter-
native to taxonomies that relies on three primitives: grounding, a specic
kind of factual existential dependence, extensional atemporal parthood,
and existence at a time. On the basis of these relations, specic, generic,
and compositional grounding relations between object types are intro-
duced. By clearly separating the objects from the substrata on which
they are grounded, these grounding relations allow to stratify object
types in levels and to manage inheritance in a exible way. In particular,
this approach helps to avoid isa overloading and to overcome some classi-
cal diculties related to inheritance, e.g. attribute overriding, attribute
hiding, or dynamic and multiple classication and specialization, that
are relevant aspects especially in modeling roles.
Keywords: Grounding, Dependence, Levels, Taxonomies, Inheritance.
Classication schemes taxonomies based on subtyping (isa) among object

types and inheritance are central notions in conceptual modeling (CM) and
in object-oriented modeling. By assuming, for instance, that Statue is a subtype
of Amount Of Matter1 , Statue inherits all the attributes and associations2 of
Amount Of Matter. However, new attributes can be introduced. For instance,
Statue, but not Amount Of Matter, could have the attribute Style. Similarly
roles 3 like Student, Customer, or President could be modeled as subtypes of
Person. Student, but not Person, has a Matriculation. Customer, but not Per-
son, has a Code, etc. This powerful mechanism of inheritance faces some well
known problems. Statue and Amount Of Matter could have dierent values for
the same attribute, e.g. Price: a statue could be more expensive than a brute
piece of bronze. Customer, dierently from Person, could not have Weight or
Place Of Birth. Attribute overriding and hiding try to manage these problems.
Furthermore, roles can be played by objects with incompatible attributes. For
instance, both companies and persons can be customers, but Customer is neither
1
Amounts of matter are concrete entities, pieces of matter, specic sums of molecules,
e.g. the piece of gold that now constitutes my ring, not the gold or gold.
2
In this paper I will focus only on data modeling and not on behavior modeling.
3
The term role indicates here a specic kind of object types (properties). Roles in-
tended as parts in relationships are close to relational roles (see [12]).

174 C. Masolo
a subtype nor a supertype of both Company and Person. [W]e have the para-
doxical situation that, from the extensional point of view, roles are supertypes
statically, while dynamically they are subtypes ([17], p.90). While keeping the
same domain, this problem can be managed by adding new objects types, e.g.
Private Customer (subtype of both Person and Customer) and Corporate Cus-
tomer (subtype of both Company and Customer) [7], or by introducing dynamic
and multiple classication and specialization (see [17] for a review). Alterna-
tively, more permissive or multiplicative approaches extend the domain with
new entities. Steimann [17] separates natural types (e.g. Person) from role types
(e.g. Customer). Roles are adjunct instances linked by a played-by relation to
their players (the persons or companies in the case of customers). The object and
its roles form an aggregate and the dynamic picking up of a role corresponds
to the creation of a new instance of the corresponding role type and its integra-
tion in a compound, and dropping a role means releasing the role instance from
the unit and destroy it ([17], p.91). In object-oriented database management
systems, by distinguishing specialization, an abstract concept, from inheritance,
a mechanism that implements specialization, [1] systematically multiplies the
instances in the presence of a subtype relation. If P is a subtype of Q, then the
creation of an object p of type P produces the creation of an object q of type Q
plus a link between them that allows p to inherit attributes from q. An object
then is implemented by multiple instances which represent its many faceted
nature. Those instances are linked together through aggregation links in a spe-
cialization relation ([1], p.561). The attributes are locally dened and stored
but additional ones can be inherited via the links between the instances. From a
more foundational perspective, multiplicative approaches have been investigated
to solve the counting problem [9]. For instance, to count the Alitalia passengers
(during 2010), one cannot just count the persons that ew Alitalia (during 2010).
By adding qua-entities [12], (sum of) relational tropes [7], or role-holders [13]
entities that inhere in (a sort of existential specic dependence), but are dif-
ferent from, the players (see Section 1 for more details) the counting problem
is solved. In philosophy, multiplicativism is often considered also in the case of
statues, organisms, tables, etc. (see [14] for a review and [3] for a recent defense).
Interestingly, qua-entities have been originally introduced in this contest [6]. As
in the case of roles, statues and amounts of matter have dierent properties (in
particular causal properties) and dierent persistence conditions. The amount
of matter that constitutes a specic statue can change through time. Or, an
amount of matter can constitute some statue only during a part of its life, when
it is statue-shaped. Therefore, some authors assume that statues are constituted
by (a sort of existential dependence), but dierent from, amounts of matter.
Taxonomies are undeniably an important conceptual tool to organize object
types according to the set-theoretical inclusion between their extensions. But it
is not the only one. This paper proposes a complementary structuring mecha-
nism founded on a specic kind of existential dependence called grounding. This
mechanism allows to account for both roles and material objects with a exible
management of inheritance that helps to avoid isa overloading and misuse.
Levels for Conceptual Modeling 175
1 Statues, Customers, Presidents, and Tables
Let us assume that statues can change their material support through time while
maintaining their shape, i.e. the shape, not the material support, is essential for
statues. It follows that Statue is not a subtype of Amount Of Matter. One
can represent being a statue as a binary predicate with a temporal argument,
Statuet x stands for at the time t, the amount of matter x is a statue (is statue-
shaped) (d1)4 . According to (d1), being a statue becomes a sort of (relational)
role played by amounts of matter. Counting seems unproblematic: the statues
present at t are the amounts of matter that are statue-shaped at t. However,
problems arise by considering a non atomic time, e.g. the whole 2010. A statue
could change its material support during 2010, i.e. we could have two amounts
of matter that are statue-shaped during 2010 but only one single statue. On
the other side, if the same amount of matter, at a given time, is the support
of two dierent statues, then we have one amount of matter but two statues.
This sounds wrong because one usually excludes co-location of statues. Dierent
are the cases of artifacts intended as (material) objects with an assigned (by
the creator) functionality [4], and roles where, for example, at a given time the
same person can be the customer of dierent companies or a multiple-customer
of the the same company (see [12] for more details). The strategy to multiply
predicates, e.g. one specialization of Statue for each statue, incurs in the problem
of expressing what is the exact property that identies the amounts of matter
that, for instance, are David at dierent times.
d1 Statuet x AmountOfMatterx xHasShapet y StatueShapey
A multiplicative approach helps in managing these problems. In the literature,
the nature and the relations among dierent kinds of entities are discussed.
Four-dimensionalism (see [15]) accepts spatio-temporal-worms. A statue, say
david, and the amount of matter m that constitutes david only during a part of
its life, are two overlapping but dierent worms: some temporal slices of david
are not part of m. Problems can arise when david and m coincide (share the
same slices) during their whole lives. Some approaches refuse spatio-temporal
coincidence. Other approaches support a modal distinction founded on slices
spreading across possible worlds: david and m are dierent world-spatio-temporal
worms because david can exist without coinciding with m (and vice versa).
In a three dimensionalist perspective, multiplicative positions (see [18]) as-
sume that statues (generically) existentially depend on, more precisely they are
consituted by, amounts of matter without overlapping with them. In particular,
Fine [6] analyzes constitution on the basis of the notion of qua-entity. If an object
a, the basis, instantiates a property P , the gloss, then there exists an additional
entity, a-qua-P that is a sort of amalgam of a and P .5 The entity a-qua-P , e.g.
m-qua-s-shaped (m-qua-having-shape-s) exists at every time at which a instanti-
ates P , it is uniquely determined by a and P , and it can inherit (not necessarily
4
To avoid reference to shapes one can consider StatueShapedt x where x is an object.
5
Qua-entities seem similar to states of aairs as dened in [2].
176 C. Masolo
all) the properties of a. Therefore, by assuming that at a given time t an amount

of matter m can have only an unique shape, say s, then only a single m-qua-
s-shaped entity exists at t. On the other hand, a s-shaped amount of matter
m = m generates, say at t , a necessarily dierent qua-entity m -qua-s-shaped.
If m and m constitute, respectively at t and t , one single statue, then still we
have two qua-entities and just one statue. According to [6], statues are mereo-
logical sums of qua-entities (m-qua-s-shaped + m -qua-s-shaped) aggregated by
(spatio-temporal) unity criteria.6
Because of their relational nature, roles (and artifacts) are more controver-
sial than material objects. While, at a given time t, amounts of matter have
an unique shape, the same person, e.g. john, can be simultaneously a customer
of dierent companies, e.g. alitalia and airfrance, i.e. both john-qua-customer-of-
alitalia and john-qua-customer-of-airfrance can exist at t.7 Moreover, dierently
from statues, customers always depend on the same person. This implies that
dierent customers can share the same support, the same player.8 Second, the
president of Italy and the president of Alitalia, are constituted-by dierent
persons through time and they can also share the same support at some time
(somebody can be both the president of Italy and the president of Fiat). There-
fore, in the case of roles, both the nature of the glosses9 and the unity criteria
are quite heterogeneous. Customers have always the same support (player) be-
cause they are discriminated on the basis of the glosses, e.g. being a customer
of Alitalia vs. being a customer of Airfrance (see saturated roles in [12]) while
presidents require unity criteria based on laws or social rules because spatio-
temporal considerations are no relevant.10
The same abstract mechanism works also for structured objects. For instance,
one can think that (a specic kind of) tables necessarily have four legs and one
top even though it is possible to substitute them during their life. In this case
tables can be aggregates of qua-entities where the basis is a complex object, e.g.
6
Dierently from classical temporal slices (see the denition in [15]), qua-entities
persist through time when the basis instantiates the gloss during a whole interval.
7
Here customer-of is a relation dened on persons and companies. Qua-entities are
then identied by a person and a property like being a customer of company A.
DBs often add customer codes that, however, in general, are keys to identify persons
not customers. This is due to the fact that DBs do not refer to persons, they just
manage cluster of attributes (e.g. Name, Date Of Birth, etc.) that do not always
identify persons. Customer codes could be conceptually necessary when the same
person can have dierent customer roles inside the same company according to, for
instance, his/her rights or obligations. In this case, the way qua-entities are identied
is dierent because there is a third argument in customer-of.
8
In this view customers coincide with single qua-entities, a limit case of mereological
sum, that have the form person-qua-customer-of-A. This explains why multiplica-
tivist models of roles often consider only qua-entities and not general sums.
9
Some authors claim that roles are necessary based on anti-rigid properties. I will
not address here this topic.
10
It is not clear to me whether unity criteria that involve diachronic constraints are
part of the glosses.
a sum of four legs and one top, and the gloss is a structural property reducible
to some spatial relations holding between the legs and the top. In this case
there are two unity criteria. A synchronic one that establishes how the legs and
the top must be structured, and a diachronic one that establishes the allowed
substitutions of legs and tops through time.
Despite the dierences previously discussed, I think that a unied view on
(structured and unstructured) material objects and roles is possible. At the end,
all these kinds of objects have an intensional dimension, to be identied, they
rely on intensional rules.
2 Founding Modeling Primitives on a Theory of Levels

I consider a temporally qualied and factual primitive called grounding: x t y
stands for x grounds y at t. Following Husserl and Fine, Correia [5] bases his
theory of dependence on grounding, informally interpreted as at t, the existence
of x makes possible the one of y or y owes its existence at t to x. Grounding
is factual because the usual denition of the specic existential dependence of x
on y, i.e. (Ex Ey) (where Ex stands for x exists)11 , reduces dependence
to the necessary truth of a material conditional whose antecedent is about x
only and whose consequent is about y only; and given that any such material
conditional fails to express any real relation between the two objects, it is
hard to see how prexing it with a necessary operator could change anything in
this connection ([5], p.58). Grounding is temporally qualied because the usual
denition of the generic existential dependence of an object on an type P , i.e.
(Ex y(Ey P y)), does not allow to represent on which object an object
depends at a given time.
Even though I completely agree on these remarks, I consider here a notion of
grounding that is stricter than the one of Correia, a notion somewhere in between
pure existential dependence and constitution. Let us come back to qua-entities.
Fine considers a-qua-P as an amalgam of a and P . From a purely existential
perspective, a-qua-P depends on both a and P . If P is a relational property,
e.g. being the customer of alitalia, then john-qua-customer-of-alitalia existen-
tially depends not only on john but also on alitalia. Intuitively, my grounding
aims at capturing the specic existential dependence between john and john-qua-
customer-of-alitalia by excluding the one between alitalia and john-qua-customer-
of-alitalia. To add intuitions. Let us suppose that supplier-for is the inverse of
customer-of, i.e. john is a customer of alitalia if and only if alitalia is a supplier
for john. Ontologically, there are reasons to identify customer-of and supplier-
for. However also in this case, john-qua-customer-of-alitalia is intuitively dierent
from alitalia-qua-supplier-for-john because we are changing the perspective, we
are changing the basis (and therefore the gloss). In particular, even though the
rst qua-entity existentially depends on alitalia, it is strictly linked to (directed to
and thicker than) john. Approaches based on constitution, often advocate spa-
tial co-location. The constituted entity is co-located with the constituent entity.
11
This denition has been modied to answer some criticisms. See [16] and [5].
178 C. Masolo
In the case of qua-entities, john-qua-customer-of-alitalia is intuitively co-located

with john not with alitalia. However, my grounding is dened on objects that are
not necessarily in space. In addition, constitution (and supervenience [10]) often
excludes relational properties from the ones that can generate new (kinds of)
entities. Aiming at managing roles, this constraints is too strong for my goal.
Formally, I simplify the theory in [11] by avoiding the temporal qualication
of parthood and by discarding the primitive of being at the same level as.
Grounding is asymmetric, transitive, down linear (a1), and implies existence
(a2), where the primitve Et x stands for the object x exists, is present, at time
t, or, more neutrally, x is temporally extended through the time t.12 Direct
grounding (d2) captures one single grounding step.
Parthood, xPy stands for x is part of y, is a a purely formal notion on the
basis of which overlap (O) is dened as usual [16]. More precisely, I consider a
classical extensional mereology: parthood is reexive, antisymmetric, transitive,
implies existence, and satises the strong supplementation principle (a3) guar-
anteeing that two objects with the same parts are identical [16]. Mereological
sums, sSM{a1 , . . . , an } stands for s is the mereological sum of a1 , . . . , an (d3),
refer to multitudes of objects without a strong ontological commitment. For
instance, four legs and one top exist if and only if their mereological sum exists,
but if they are disassembled no table exists.13 Grounding is not a specic kind
of parthood. Dierently from (improper) parthood, grounding is irreexive (di-
rectly from asymmetry). Dierently from proper parthood, grounding does not
satisfy the strong (and the weak) supplementation principle. For example, the
fact that an amount of matter m grounds a statue does not require the statue
to be grounded on additional entities disjoint from m, i.e. m could be the only
grounding of the statue. More strongly, I assume that grounding and parthood
are incompatible: x t y xPy. Note however that a grounding object is not
necessarily atomic, i.e. it can have proper parts.
a1 y t x z t x y t z y = z z t y (down linearity)
a2 x t y Et x Et y
a3 xPy z(zPx zOy) (strong supplementation)
a4 x t y (Tx Ty) (T is a leaf type)
a5 T1 x T2 y x t y zut (T1 z T2 u u t z) (T1 , T2 leaf types)
d2 xt y x t y z(x t z z t y) (direct grounding)
d3 sSM{a1 , . . . , an } z(zPs (zPa1 ... zPan )) (mereological sum)
Levels are partially captured by (a nite set of) types that are assumed to be
non-empty and rigid properties formally represented by (non temporally quali-
ed) unary predicates Ti . Types can be extensionally organized in a taxonomy.
Leaf types, types with no subtypes, partition the domain. According to (a4),
grounding always relies on a dierence in type that is expressible in the theory,
12
I will focus here only on objects present at some time.
13
Sums need to be carefully managed because not all the summands necessarily exist
at every time at which the sum exists.
i.e. grounding does not hold between objects belonging to the same leaf type.
Together with (a5), it avoids grounding loops. (a4) and (a5) are basic require-
ment for structuring (leaf) types in levels that assure also the maximality (with
respect to parthood) of the grounds.14
After all these technical details, I will now introduce three grounding rela-
tions useful to organize types in levels. The formal denitions characterize the
semantic of these grounding relations, but, once understood, they can be used as
conceptual modeling primitives. In this sense, according to the following quote,
they can be seen as an abstraction, simplication, and hiding of the previous
analysis: The theoretical notions which are required for suitable characteriza-
tions of domain conceptualizations are of a complex nature. This puts emphasis
on the need for appropriate computational support for hiding as much as possible
this inherent complexity from conceptual modeling practitioners. ([8], p.9).
T1 is (directly) specically grounded on T2 (a6), noted T1 T2 , if every T1 -
object is (directly) grounded on a single T2 -object during its whole life, e.g.
Customer Person. It is often motivated by emergent properties. Customer is
no more modeled as a subtype of Person. Customer is now a rigid type, i.e. a
customer is necessarily a customer, with specic attributes. I think this is a quite
simplifying CM technique. Furthermore, the temporal extension of a customer
is included in the one of the person (a dierent object) that grounds him, i.e.,
to exist, a customer requires a grounding person while persons do not require
customers. We will see how (some of) the attributes of Person can be inherited
by Customer and vice versa.
T1 is (directly) generically grounded on T2 (a7), noted T1 T2 , if every T1 -
object is (directly) grounded on some, but not necessarily the same, T2 -object,
e.g. StatueAmountOfMatter. It is often motivated by dierent persistence con-
ditions.15 Note that the proposed framework does not commit on a specic on-
tological theory of persistence. One can quantify on both statues and amounts
of matter without including in the domain temporal slices, qua-entities, states
of aairs, events, or tropes. Indeed without being forced to, the modeler can,
through axioms that links statues and amounts of matter, make explicit the
underlying theory of persistence (in addition to the unity criteria).
T is (directly and generically) compositionally grounded on T1 , . . . , Tm if every
T-object is (directly) grounded on some, but not necessarily the same, mereologi-
cal sum of T1 -,. . . ,Tm -objects. It is often motivated by structural relations among
T1 -,. . . ,Tm -objects. I distinguish denite compositional grounding (a8)16 , noted
14
In general, levels are not necessarily linear and they can be conceived as collections
of objects that obey the same laws of nature, have common identity criteria or
persistence conditions. These are interesting points for CM that deserve future work.
15
Customer are not completely determined by persons, nor statues by amounts of mat-
ters. Grounding does not necessarily imply reduction, it diers from determination
used to explain supervenience, e.g. The mental is dependent on the physical, or the
physical determines the mental, roughly in the sense that the mental nature of a
thing is entirely xed by its physical nature ([10], p.11).
16
In (a8) and (a9) Ti (x + y) is a shortcut for s(sSM{x, y} Ti s) s(sSM{x, y}).
180 C. Masolo
T(n1 )T1 ; . . . ; (nm )Tm , e.g. TableSurface; (4)Leg17 , i.e. when a table exists
it is grounded on exactly one surface and four legs, from (at least) indenite
compositional grounding (a9), noted T1 ( n)T2 , e.g. Organism ( 2)Cell, i.e.
organisms are grounded on at least two cells even though the exact number of
grounding cells can vary in time.18 To count the grounding objects one must rely
on clear principles that identify unitary objects. For example, I would exclude
Statue ( 2)AmountOfMatter and Statue (2)AmountOfMatter. Here I just as-
sume a mereological principle, i.e. the grounding Ti -objects does not overlap and
their sums are not of type Ti (see (a8) and (a9)).19
a6 T1 x y(T2 y t(Et x y t x)) (specic direct grounding)
a7 T1 x t(Et x y(T2 y y t x)) (generic direct grounding)
a8 Tx t(Et x y11 ... y1n1 ... ym1 ... ymnm s
Et y11 ... Et ymnm sSM{y11 ,..., ymnm } st x
T1 y11 ... T1 y1n1 y11 Oy12 ... y1,n1 1 Oy1n1 T1 (y11 + y12 ) ...
...
Tm ym1 ... Tm ymnm ym1 Oym2 ... Tm (ym1 + ym2 ) ...
a9 T1 x t(Et x s(st x z(zPs u(uPz T2 u))
y1 ... yn (Et y1 ... Et yn y1 Ps ... yn Ps T2 y1 ... T2 yn
y1 Oy2 ... yn1 Oyn T2 (y1 + y2 ) T2 (y1 + y3 ) ...)))
Generic (or specic) grounding relations can be easily combined. For exam-
ple, KitchenTable; Oven; ( 2)Chair. To mix specic and generic (composi-
tional) grounding, one just needs to introduce more elaborate denitions. E.g.,
Car Chassis; Engine; (4)Wheel; ( 1)WindscreenWiper ( is het-
erogeneous grounding) stands for cars specically depend on a chassis and
generically depend on an engine, four wheels, and at least one windscreen wiper.
Methodologically, one can start from the fundamental types, types that are
not grounded20 , and then, according to the grounding relations, progressively
arrange the other (leaf) types in layers. Figure 1 depicts a simple example (with
only a fundamental type, namely AmountOfMatter) that shows the weakness of
the notion of level: types can be grounded on types that have a dierent distance
from the fundamental level as in the case of Exhibition.
Inheritance. All the types involved in grounding relations are rigid and disjoint
from the ones on which they are grounded. Customers, statues, and tables are
17
I write TableSurface; (4)Leg instead of Table(1)Surface; (4)Leg. This is con-
sistent with the fact that T1 T2 is equivalent to T1 (1)T2 , i.e. generic compositional
grounding is an extension of generic grounding.
18
At most indenite compositional grounding, cardinality constraints (for exam-
ple, FootballTeam(11...22)FootballPlayer). Moreover, indenite compositional
grounding can also be used to introduce levels of granularity, even though addi-
tional constraints are necessary (see [11] for a preliminary discussion).
19
Specic compositional grounding can be dened starting from the corresponding
generic case by considering the form in (a6) instead of the one in (a7).
20
The existence of a (unique) fundamental level is debated in philosophy. However, in
applicative terms, I dont see any drawback in accepting fundamental types.
Exhibition
s (1)
ss
sss
s
ss Table UU
UUUU
sss(1) (4) UUU
s
Statue UU Leg
i Surface
UUUU iiii
UU
ii ii
AmountOfMatter
Fig. 1. Structuring object types according to grounding relations
such during their whole life. Grounding and subtyping are separate relations,
therefore the problems due to isa overloading trivially disappear. As drawback,
we loose the power of the inheritance mechanism. However, Baker [3] observes
that constitution (a specic grounding) provides a unity, it allows the constituted
entity to inherit (to derivatively have) some properties from the constituting one
and vice versa.21 E.g. amounts of matter (persons) can inherit the style (right
to vote for student representatives) from the statues (students) they ground.
On the basis of these observations, following [1], the inheritance of attributes
of grounded types must be controlled. By default, T1 T2 or T1 T2 implies
that all the attributes of T2 are inherited by T1 . T1 [A11 , ..., A1n ] T2 [A21 , ..., A2m ]
means that only the T2 attributes A21 , ..., A2m are exported to T1 while the T1 at-
tributes A11 , ..., A1n are exported to T2 . Similarly in the case of generic grounding.
Statue[Style]AmountOfMatter means that Statue inherits all the attributes
of AmountOfMatter, while the last type inherits only the attribute Style from
Statue. In this way, attribute hiding can be trivially modeled. Attribute overrid-
ing can be approached by systematically override the attributes of the grounding
type or by localizing all the attributes as in [1]. The case of compositional de-
pendence is interesting. Some attributes of the grounded object can be obtained
from a composition of the attributes of the grounds. For example, the weight of
tables is the sum of the weights of the grounding legs and surfaces. If necessary
these rules can be explicitly added as constraints. Alternatively, one can add
dependences among the values of attributes.
Grounding and Subtyping. It is trivial to prove that if T1 T2 22 and T2 T3
then T1 T3 . Vice versa, from T1 T2 and T1 T3 , T2 T3 does not follow.
Moreover, from T1 T2 and T2 T3 it follows that T1 T3 but one looses the
information about the specic subtype on which T1 is grounded. A parsimonious
approach considers only maximally informative grounding relations T1 T2 : T1
is maximal with respect to subtyping, while T2 is minimal. This criterion (to-
gether with the fact that only direct grounding relations are considered) allows to
clarify the nature of abstract types like MaterialObject. Let us assume Leg
MaterialObject, Surface MaterialObject, and Table MaterialObject
and compare the model that considers all the grounding relations in Figure 1
21
However, high-level properties are not always reducible to properties of substrata.
22
represents the subtyping relation. The following results hold also for generic
dependence. Here I do not consider the composition of grounding relations.
182 C. Masolo
with the one with only MaterialObjectAmountOfMatter. Given the same tax-
onomical information, only the rst model makes explicit that MaterialObject
is an abstract and multi-level type.
Acknowledgments. I would like to tank Emanuele Bottazzi, Nicola Guar-

ino, Laure Vieu, and the reviewers for the helpful comments and discussions.
This work has been carried out in the framework of the EuJoint project (Marie
Curie IRSES Exchange Project n.247503) and the ICT4Law project (Converging
Technologies project nanced by Regione Piemonte).
References
1. Al-Jadir, L., Michel, L.: If we refuse the inheritance... In: Bench-Capon, T.J.M.,
Soda, G., Tjoa, A.M. (eds.) DEXA 1999. LNCS, vol. 1677, pp. 569572. Springer,
Heidelberg (1999)
2. Armstrong, D.M.: A World of States of Aairs. Cambridge University Press,
Cambridge (1997)
3. Baker, L.R.: The Metaphysics of Everyday Life. Cambridge Univerity Press,
Cambridge (2007)
4. Borgo, S., Vieu, L.: Artefacts in formal ontology. In: Meijers, A. (ed.) Handbook
of Philosophy of Technology and Engineering Sciences, pp. 273308. Elsevier, Am-
sterdam (2009)
5. Correia, F.: Existential Dependence and Cognate Notions. Ph.D. thesis, University
of Geneva (2002)
6. Fine, K.: Acts, events and things. In: Sixth International Wittgenstein Symposium,
Kirchberg-Wechsel, Austria, pp. 97105 (1982)
7. Guizzardi, G.: Ontological Foundations for Structural Conceptual Models. Ph.D.
thesis, University of Twente (2005)
8. Guizzardi, G., Halpin, T.: Ontological foundations for conceptual modeling. Ap-
plied Ontology 3(1-2), 112 (2008)
9. Gupta, A.: The Logic of Common Nouns. Phd thesis, Yale University (1980)
10. Kim, J.: Mind in a Physical World. MIT Press, Cambridge (2000)
11. Masolo, C.: Understanding ontological levels. In: Lin, F., Sattler, U. (eds.) Proceed-
ings of the Twelfth International Conference on the Principles of Knowledge Repre-
sentation and Reasoning (KR 2010), pp. 258268. AAAI Press, Menlo Park (2010)
12. Masolo, C., Vieu, L., Bottazzi, E., Catenacci, C., Ferrario, R., Gangemi, A., Guar-
ino, N.: Social roles and their descriptions. In: Dubois, D., Welty, C., Williams,
M.A. (eds.) Proceedings of the Ninth International Conference on the Principles
of Knowledge Representation and Reasoning (KR 2004), pp. 267277 (2004)
13. Mizoguchi, R., Sunagawa, E., Kozaki, K., Kitamura, Y.: A model of roles within
an ontology development tool: Hozo. Applied Ontology 2(2), 159179 (2007)
14. Rea, M. (ed.): Material Constitution. Rowman and Littleeld Publishers (1996)
15. Sider, T.: Four-Dimensionalism. Clarendon Press, Oxford (2001)
16. Simons, P.: Parts: a Study in Ontology. Clarendon Press, Oxford (1987)
17. Steimann, F.: On the representation of roles in object-oriented and conceptual
modelling. Data and Knowledge Engineering 35, 83106 (2000)
18. Vieu, L., Borgo, S., Masolo, C.: Artefacts and roles: Modelling strategies in a
multiplicative ontology. In: Eschenbach, C., Gruninger, M. (eds.) Proceedings of
Fith International Conference on Formal Ontology and Information Systems (FOIS
2008), pp. 121134. IOS Press, Amsterdam (2008)
Principled Pragmatism: A Guide to the
Adaptation of Ideas from Philosophical
Disciplines to Conceptual Modeling
David W. Embley1 , Stephen W. Liddle2 , and Deryle W. Lonsdale3

1
Department of Computer Science
2
Information Systems Department
3
Department of Linguistics and English Language,
Brigham Young University, Provo, Utah 84602, U.S.A.
Abstract. The synergism among the traditional disciplines of ontol-

ogy, epistemology, logic, and linguistics and their potential for enhancing
conceptual-modeling applications is not fully understood. Better under-
standing how to adapt ideas from these disciplines should lead to im-
proved serviceability of conceptual modeling. We argue in this position
paper, however, that application objectives, rather than philosophical
tenets, should guide the adaptation of ideas from these disciplines. Thus,
an appropriate balance of discipline-based theory and pragmatism should
temper adaptations. We evaluate the principled pragmatism we advo-
cate by presenting several case-study examples. Each illustrates that an
appropriate adaptation of ideas from the disciplines of ontology, episte-
mology, logic, and linguistics can signicantly guide conceptual-modeling
research and help build successful conceptual-modeling applications.
1 Introduction
The applicability of ontology, epistemology, logic, and linguistics to conceptual

modeling seems compelling. But what role should these disciplines play in fa-
cilitating conceptual-modeling applications? To what extent should conceptual-
modeling researchers adopt or adapt philosophical ideas, positions, adages, and
objectives from these disciplines? Must they be purists in their adaptation, or is
it appropriate to leverage fundamental ideas and objectives and let the pragma-
tism of the application dictate the adoption and adaptation of theoretical tenets
of the various perspectives within and surrounding these disciplines?
We argue in this position paper that application-dependent pragmatism should
guide the adaptation of ideas from these disciplines to the various research direc-
tions within the conceptual-modeling community. In adapting ideas from these
disciplines to conceptual modeling, we espouse the adage attributed to Einstein
that everything should be made as simple as possible, but no simpler.
To establish our position, we rst sketch our contextual view of ontology,
epistemology, logic, linguistics, and conceptual modeling (Section 2.1). We then
argue that being solution-oriented requires appropriate selective adaptation of

184 D.W. Embley, S.W. Liddle, and D.W. Lonsdale
ideas from these areas (Section 2.2). Appropriate selectivity requires tempering
by two crucial, overarching considerations: the adaptation must be principled,
and it must be pragmatic. From our perspective forcing purist views for adap-
tation may overly complicate the conceptual-modeling application in opposi-
tion to Einsteins suciency-with-simplicity adage. To make our views concrete,
we present several case-study examples to show how the principle of practical
pragmatism has served and can further serve as a guide to adapting ideas to
conceptual modeling (Section 3). Then, as we conclude (Section 4), we general-
ize and assert that the principled pragmatism we advocate is potentially more
far-reaching in its implications than to just the case-study examples we use
for illustration. It provides a vision and perspective for adapting philosophical
disciplines to conceptual-modeling applications. Further, it answers in part the
question about the relationship among Ontology as an Artifact, Ontology as a
Philosophical Discipline, Conceptual Modeling, and Metamodeling.
2 Philosophical Disciplines and Conceptual Modeling
2.1 Contextual Overview
Ontology, as a eld of philosophy, investigates problems of existence: what exists,

how do we know what exists, how does an objects existence relate to univer-
sal reality, and related questions. Deciding what reality is, and which relations
characterize reality, are at the core of ontological investigation. A central theme
of ontology is ontological commitment, which is about having enough evidence
to commit to an objects existence.
Epistemology studies knowledge and belief. It explores where knowledge comes
from, how it is represented (including its structure), what its limits are, and
how it can be used to refute assertions or support belief and discover truths.
Important topics include how to quantify, describe, create, disseminate, and op-
erationalize knowledge. For example, how much knowledge is necessary (or su-
cient) for accomplishing a given task? How do we acquire and codify knowledge?
What constitutes good evidence for justication of a belief?
Logic is about valid reasoning. It allows us to explore generalization, abstrac-
tion, and inferred relationships among objects that exist. Logic can be formalized
in several dierent ways: proof theory, model theory, formal languages, linguis-
tic expressions, mental representations, or graphical visualizations. Principles
of correct reasoning guarantee the validity of inferences and set up systems of
meaning that can be manipulated at higher levels of abstraction.
Linguistics investigates languages, either formal (e.g. logic or mathematics) or
natural (i.e. human languages). Since language is crucial to communicating ideas,
knowledge, beliefs, and logic, all of the above areas are of concern to linguists. So,
too, are the structure, properties, contextual realities, and meaning of sounds,
words, sentences, discourse, and dialog.
Conceptual modeling deals with computational representation of concepts
and how to communicate these representations. Concept representation, from
Principled Pragmatism 185
a linguistically-informed semantics perspective, is in part referential or denota-

tional: symbols relate to objectively veriable, external, real-world objects. Com-
munication about conceptualizations is social: symbols facilitate interpersonal or
intergroup communication. Conceptual modeling comprises both perspectives:
most model instances are explicitly denotational or referential in their content
and serve a social function by facilitating communication among stakeholders.
2.2 Principled Pragmatism

Our approach to adapting ideas from philosophical disciplines to conceptual
modeling is based on principled pragmatism. The overarching epistemological
principle is that our work is ontology-driven. Our pragmatism views ontolo-
gies as formal specications of some domain that are simple enough that users
can encode them without extensive experience in knowledge engineering or the
truth-maintenance systems typically used for large-scale ontology development.
We maintain simplicity by minimally selecting and adapting ideas from each of
the disciplines in a combination that appropriately enhances our application.
By extension, we assert that these same principles hold for other conceptual-
modeling applications. We believe, for example, in harmony with Smith [1], that
more exacting and purer ontological descriptions would enhance integration and
interoperability applications.1
In summary, we assert our position: When adapting ideas from philosophical
disciplines to conceptual modeling, we should nd the right balance, being nei-
ther too dogmatic (insisting on a discipline-purist point of view) nor too dismis-
sive (ignoring contributions other disciplines can make to conceptual-modeling
applications).
3 Case Study Applications

To illustrate the principled pragmatism we advocate, we present ve case-study
examples. For each case study, we explain how the disciplines of ontology, epis-
temology, logic, and linguistics guide the theoretical conceptual-modeling under-
pinnings of these applications. We also show that as the applications
become more complex, they draw more heavily on philosophical disciplines for
1
Although we have engaged in a fair amount of research on integration (e.g., see [2]
as a summary), we have observed (unfortunately) that other than having a formally
dened conceptual-modeling language that encourages adherence to ontological prin-
ciples, we do not know how to ensure that users will model in an ontologically correct
way. (We thus omit integration and interoperability from our case-study examples.)
We assert, however, that although applications should drive abstraction, abstrac-
tion should be propershould maintain generally-agreed upon ontological descrip-
tions for the application. Doing so will surely enhance integration applications since
integration of conceptualizations across abstraction levels is less painful than inte-
gration across user-modeled peculiarities. Cost eectiveness in interoperability will
likely drive us toward more exacting ontological descriptions, and ontology-oriented
conceptual modelers can and should provide appropriate and needed guidance.
support. Thus, the relationship between philosophical disciplines and conceptual-

modeling applications becomes blurred so that it is no longer clear whether the
artifact produced is a conceptual model or whether it is an ontology drawing
heavily on conceptualizations from epistemology, logic, and linguistics. Further,
we argue: it does not matter. What matters is that the application is well-served
by the artifact and that researchers are able to build serviceable applications
by nding good synergistic combinations of ideas drawn from the overlapping
disciplines of conceptual modeling, ontology, epistemology, logic, and linguistics.
3.1 Conceptual-Model-Based Information Extraction

The problem of information extraction is to turn raw text into searchable knowl-
edge. It requires nding computational answers to the fundamental questions of
ontology (What exists?), epistemology (What is knowledge and how can it
be represented?), logic (What facts are known or can be inferred from known
facts?), and linguistics (What meaning do language symbols convey?).
Answering these questions computationally leads naturally to a conceptual-
modeling resolution of the information-extraction problem [3,4]. This should
not be surprising since ontological conceptualizations have been the basis for
formalizing information since the days of Aristotle [5], and they still provide
the underlying schemas for todays fact-lled databases. Our principled prag-
matic approach to building an information-extraction system thus begins with
a conceptual model that denes a narrow domain of interest. For example, the
conceptual-model instance in Figure 1 models the information found in typical
car ads. The conceptual-model instance answers the question of what exists
in the narrow domain of interest and is therefore ontological in nature. Next,
we linguistically ground the conceptual-model instance by saying what language
symbols convey meaning for each of the object sets. In Figure 2, for example, the
regular expression for the external representation of Price recognizes $11,995
in the car ad in Figure 3. The dictionary CarMake.lexicon includes an entry for
CHEVY, and thus it, along with the recognized price and the other informa-
tion in the car ad, are extracted and entered into a data repository (RDF triples
in our implementation) whose schema (OWL in our implementation) corresponds
to the conceptual-model instance in Figure 1. The populated conceptual-model
instance is a model-theoretic interpretation and thus immediately supports in-
ference via established logic systems (the Pellet reasoner in our implementation
and SPARQL queries generated from free-form user input).
As for principled pragmatism, we emphasize that although the ideas we adapt
for conceptual-model-based information extraction are foundational, we do not
plumb the depths of these foundational ideas. Purists might not agree, for ex-
ample, that the conceptualization we propose is even an ontology. We argue,
however, that since our conceptualizations not only answer What exists? but
also explain how we know what exists in terms of linguistic clues, they are on-
tologies. Similarly, purists might not agree that populating a data repository
involves epistemology, but because it computationally answers a fundamental
epistemological question (How is knowledge acquired?), it is epistemological.
Mileage
Price 1:* Color
1:*
1:*
0:1 0:*
0:1
0:* 1:*
Make 1:* 0:1 Car Feature
0:1 0:1
1:*
Year 1:* +
ModelTrim
0:1 0:1
Engine Transmission
1:* 1:*
Model Trim Body Type Accessory
Fig. 1. Diagram for Conceptual-Model-Based Information Extraction
Price
internal representation: Integer
external representation: \$[1-9]\d{0,2},?\d{3} | \d?\d [Gg]rand | ...
context keywords: price|asking|obo|neg(\.|otiable)| ...
...
LessThan(p1: Price, p2: Price) returns (Boolean)
context keywords: (less than | < | under | ...)\s*{p2} | ...
...
Make
...
external representation: CarMake.lexicon
...
Fig. 2. Linguistic Grounding of Price and Make (partial)
Our use of logic and reasoning is likely not controversial, although we must be
careful not to adopt so much that our system becomes undecidable or intractable.
Our use of linguistics is intentionally simplistic: our lexical grounding compu-
tationally enables the conveyance of linguistic meaning without the necessity of
the traditional depth of natural-language processing systems.
3.2 The Conceptual-Modeling Language OSM

Perspectives that motivate dierent approaches to conceptual-model language
design are varied, but it is generally true that the target domain inspires the
set constructs in the modeling language. In the context of database design, the
ER model is natural, but in the context of real-time systems, a language like
Statecharts is more appropriate. The challenge in modeling-language design is
determining the best set of constructs to use: enough to cover the required
concepts, but not so many that the language is too dicult to master. Also,
it is important to dene languages carefully and precisely, preferably with an
underlying mathematical formalism that supports unambiguous denitions and
even the ability to translate the model directly to an executing system.
Under the guise of the principled but pragmatic approach we advocate in
this position paper, we created Object-oriented Systems Modeling (OSM), an
97 CHEVY Cavalier, Red, 5 spd, only 7,000 miles on her.

Previous owner heart broken! Asking only $11,995.
#1415 JERRY SEINER MIDVALE, 566-3800 or 566-3888
Fig. 3. Car Ad (unaltered from original)
object-oriented conceptual modeling language [6]. Figure 4 shows an example

of a simple surveillance controller and illustrates how OSM describes objects
(e.g. Surveillance Controller, Dectector ID, Dectection Event, and Timestamp
in Figure 4), relationships among objects (e.g. Detector Event has Timestamp),
object behavior (e.g. event detection via @detection and controller reaction), and
interaction among objects inside and outside the controller (e.g. user abort ). It
properly describes the behavior of a surveillance controller using a mixture of
natural language and formal constructs, in real-world terms. And yet this model
instance can directly execute in prototype fashion and can be fully formalized
in terms of OSM to become operational. Thus, OSM is a conceptual-model
programming language [7] as well as a conceptual-modeling analysis language.
In designing OSM, we tried to hold to ontological principles, believing that
having the right abstractions and expressing concepts in natural terms (not
programming terms) leads to better models. The ideas in Bunges ontology of
physical systems [8] resonate nicely with our work on OSM. At the same time,
we wove principles of epistemology and logic into the fabric of OSM. Populated
OSM model instances constitute formal interpretations in model theory, and
thus immediately provide a perspective on facts and knowledge (epistemology)
and a basis for formal query and inference (logic). As a communication lan-
guage, we used simple linguistic principles to make OSM human-readable. It is a
small detail, but by convention we name object sets with spaces separating the
words, not dashes or underscores as is more typical of many computer-friendly
languages, and OSM provides for readable, sentence-like, relationship-set names
(e.g. Surveillance Controller has record of Detector Event rather than more typ-
ical detectedEvent that is easier for a machine to parse).
3.3 Conceptualizations for Learning and Prediction
Recent initiatives by government agencies (e.g. IARPA-KDD [9]) and by aca-

demic think-tank groups (e.g. ACM-L [10]) require conceptualizations that track
behavior, model what has happened and is currently happening, and analyze
past and present behavior. The objectives of tracking, modeling, and analyz-
ing include being able to predict future behavior, play out what-if scenarios,
and warn of possible impending disasters. Although conceptual modeling can
provide the foundation for storing the necessary information to support these
initiatives, the lack of a unied, fact-oriented, conceptual-model formalism for
temporal semantics, metamodeling, and reication leads to diculties in reason-
ing about system properties and predicting future behavior from past behavior
[11]. We can better serve these needs by a formalized conceptualization, called
OSM-Logic [12], that more closely matches application demands.
Surveillance Controller 3
1 2 @delay end
@init @reset Active
emergency notify
4
init detectors reset detectors
init alarms reset alarms @detection
^ current time is within the active
schedules start and stop times
Delay
activate alarm
Ready record a new detection event
start delay 5
@user abort
reset detectors
reset alarms
0:*
has record of
1 user abort
has has
Detector ID 0:* 1
Detector Event 1 1:*
Timestamp
Fig. 4. OSM Diagram Illustrating Object Behavior
OSM-Logic illustrates both the as simple as possible and the no simpler

aspects of principled pragmatism. The formalism is no simpler because the
complexity of learning-and-prediction applications demands the inclusion of real-
world temporality. The inclusion of temporality, however, is as simple as possi-
ble because it consists only of adding a timestamp argument to each event-fact
predicate and a timestamp-argument pair to each existence-fact predicate. Thus,
for example, in OSM-Logic, we formalize the fact that surveillance controller s is
in the Active state of the behavior conceptualization in Figure 4 from time t to
time t as the predicate-calculus fact inStateActive(s, t, t ). Also of prime impor-
tance for simplicity, the temporal predicate-calculus formalism applies uniformly
to all aspects of the modelingthe metamodel instance as well as the model
instance, object behavior as well as object existence, and reication for both
high-level and low-level specication. And yet, it is no simpler than necessary
for these applications, because its temporal semantics provides for a temporal
history of the existence and behavior of all objects, its time-dependent meta-
modeling supports the tracking of model-instance evolution, and its reication
properties make high-level abstractions as concrete and formal as low-level par-
ticulars, allowing users to either remove detail to survey the broader landscape
or to drill down to the nest level of detail to nd relevant facts and associations.
3.4 Multilingual Extraction Ontologies
Valuable local information is often available on the web, but encoded in a for-
eign language that non-local users do not understand. Hence the epistemological
and linguistic problem: Can we create a system to allow a user to query in
language L1 for facts in a web page written in language L2 ? We propose a
suite of multilingual extraction ontologies as a solution to this problem [13]. We
ground extraction ontologies in each language of interest, and we map both the
data and the metadata via the language-specic extraction ontologies through
a central, language-agnostic ontology, reifying our ontological commitment to
cross-linguistic information extraction in a particular domain. Our world model
can thus be language-neutral and grounded in semantic and lexical equivalencies
to a practical, operational degree [14]. This allows new languages to be added
by only having to provide one language-specic ontology and its mapping to the
language-agnostic ontology.
Mappings at several linguistic levels are required to assure multilingual func-
tionality. Structural mappings (à la mappings for schema integration) associate
related concepts across languages. Data-instance mappings mediate content of
largely terminological nature: scalar units (i.e. xed-scale measurements such as
weight, volume, speed, and quantity); lexicons (i.e. words, phrases, and other
lexical denotations); transliteration (i.e. rendering of proper names across or-
thographic systems); and currency conversions (i.e. mapping temporally varying
indexes like monetary exchange rates). Most of this type of information is pri-
marily referential in nature, with some element of pragmatics since commonly
adopted standards and norms are implied, and these vary across cultural and
geopolitical realms (e.g. use of the metric vs. imperial measurement systems).
One other type of mapping, called commentary mappings, are added to the on-
tologies: these document cultural mismatches that may not be apparent to the
monolingual information seeker, for example tipping practices in restaurants in
the target culture.
3.5 Fact Extraction from Historical Documents

Many people are interested in explicit facts, as well as implied facts, found in
historical documents. From the document snippet in Figure 5, taken from an on-
line Ely Family History, facts such as SonOf(William Gerard Lathrop, Mary
Ely, Gerard Lathrop) and BornInYear(Mary Ely, 1818) are evident, as
are implied facts such as SurnameOf(Maria Jennings, Lathrop) and Grand-
motherOf(Mary Ely, Maria Jennings Lathrop). Images of these documents
exist, and OCR engines can produce searchable text from these images.
To make explicit facts searchable, we can semantically annotate the OCRed
text of the original document images using conceptual-model-based information
extraction. To make implicit facts searchable, we can generate them via logic
rules. Unlike the assumption of a short, data-rich text description of a single item
like in a classied ad, an obituary, or a Wikipedia article, historical documents
have facts about many items (e.g. many people, places, and events in the Ely
family history). Therefore, computational solutions require us to delve more
deeply into ontology, epistemology, logic, and linguistics.
To obtain ontological commitment, we must address the question of having
sucient evidence to declare the existence of an object. For historical docu-
ments, the appearance of names for named entities is usually sucient, but seeing
the name of a make of a car like Ford in The Ford Administration, 1974
1977 does not imply the existence of a car, although seeing Ford in John
drove the Ford he bought in 1925 for 20 years does imply a cars existence.
Fig. 5. Text Snippet from Page 419 of the Ely Family History
In seeking computational solutions, we apply principled pragmatism by appro-

priately seeking for linguistic clues denoting the existence of things but do not
go so far as to delve into ethereal metaphysical arguments about existence.
Regarding epistemology and logic, Plato, and those who follow his line of
thought, demand of knowledge that it be a justied true belief [15]. Computa-
tionally, for facts in historical documents, we establish truth via provenance.
Users can ask for fact authentication: the system responds by returning rule
chains for inferred facts grounded in fact sources with extracted facts highlighted
in images of original documents.
Linguistically, our goal for fact extraction from historical documents is to en-
able automated reading. We simplistically dene reading as being able to extract
fact instances with respect to a declared ontology. As a matter of principled prag-
matism, we not delve into the depths of reading cognition; however, we can learn
from the observation that people typically do not read data-rich text snippets
like in Figure 5 left-to-right/top-to-bottom, but rather skip aroundimplying
that tting facts into an ontological conceptualization likely requires best-t
heuristics for reading the maximal number of correct facts.
4 Concluding Remarks
We have argued in this position paper that the relationship among Ontology as
an Artifact, Ontology as a Philosophical Discipline, Conceptual Modeling, and
Metamodeling is synergistic, but should be tempered with principled pragma-
tism. For conceptual-modeling applications the goal is practical serviceability,
not philosophical enrichment. Thus, conceptual-model researchers should draw
ideas and seek guidance from these disciplines to enhance conceptual-modeling
applications, but should not become distracted from computationally practical
solutions by insisting that philosophical tenets should prevail.
To show how principled pragmatism works for building conceptual-modeling
applications, we presented several case-study examples. Tempered by Einsteins
suciency-with-simplicity adage, each case study illustrates how to directly
leverage ideas from philosophical disciplines. Further, these case studies show
that the requirements for applications to have computationally tractable so-
lutions, itself, leads to principled pragmatism. Discipline principles can spark
ideas, but decidability, tractability, and usability requirements demand practi-

cality. Lastly, the case studies show that appropriate adaptation of ideas from
philosophical disciplines have enhanced the serviceability of conceptual model-
ing and moreover indicate (as future work) that adaptation will likely further
enhance the serviceability of conceptual modeling.
References
1. Smith, B.: Ontology. In: Floridi, L. (ed.) Blackwell Guide to the Philosophy of
Computing and Information, pp. 155166. Blackwell, Oxford (2003)
2. Xu, L., Embley, D.W.: A composite approach to automating direct and indirect
schema mappings. Information Systems 31(8), 697732 (2006)
3. Embley, D.W., Campbell, D.M., Jiang, Y.S., Liddle, S.W., Lonsdale, D.W., Ng,
Y.-K., Smith, R.D.: Conceptual-model-based data extraction from multiple-record
web pages. Data & Knowledge Engineering 31(3), 227251 (1999)
4. Embley, D.W., Liddle, S.W., Lonsdale, D.W.: Conceptual modeling foundations
for a web of knowledge. In: Embley, D.W., Thalheim, B. (eds.) Handbook of Con-
ceptual Modeling: Theory, Practice, and Research Challenges. ch. 15, pp. 477516.
5. Aristotle. Metaphysics. Oxford University Press, New York, about 350BC (1993
translation)
6. Embley, D.W., Kurtz, B.D., Woodeld, S.N.: Object-oriented Systems Analysis: A
Model-Driven Approach. Prentice-Hall, Englewood Clis (1992)
7. Embley, D.W., Liddle, S.W., Pastor, O.: Conceptual-Model Programming: A Man-
ifesto. ch. 1, pp. 316. Springer, Heidelberg (2011)
8. Bunge, M.A.: Treatise on Basic Philosophy: Ontology II: A World of Systems,
vol. 4. Reidel, Boston (1979)
9. Knowledge discovery and dissemination program,
http://www.iarpa.gov/-solicitations_kdd.html/
10. ACM-L-2010 Workshop, http://www.cs.uta.fi/conferences/acm-l-2010/
11. Liddle, S.W., Embley, D.W.: A common core for active conceptual modeling for
learning from surprises. In: Chen, P.P., Wong, L.Y. (eds.) ACM-L 2006. LNCS,
12. Clyde, S.W., Embley, D.W., Liddle, S.W., Woodeld, S.N.: OSM-Logic: A Fact-
Oriented, Time-Dependent Formalization of Object-oriented Systems Modeling
(2012) (submitted for publication, manuscript), www.deg.byu.edu/papers/
13. Embley, D.W., Liddle, S.W., Lonsdale, D.W., Tijerino, Y.: Multilingual ontologies
for cross-language information extraction and semantic search. In: De Troyer, O.,
et al. (eds.) ER 2011 Workshops. LNCS, vol. 6999, Springer, Heidelberg (2011)
14. Nirenburg, S., Raskin, V., Onyshkevych, B.: Apologiae ontologiae. In: Proceedings
of the 1995 AAAI Spring Symposium: Representation and Acquisition of Lexical
Knowledge: Polysemy, Ambiguity, and Generativity, Menlo Park, California, pp.
95107 (1995)
15. Plato: Theaetetus. BiblioBazaar, LLC, Charleston, South Carolina, about 360BC
(translated by Benjamin Jowett)
Ontological Usage Schemes
A Working Proposal for the Ontological Foundation of
Language Use
Frank Loebe
Department of Computer Science (IfI) and Institute of Medical Informatics, Statistics

and Epidemiology (IMISE), University of Leipzig, Germany
frank.loebe@informatik.uni-leipzig.de
Abstract. Inspired by contributing to the development of a top-level

ontology and its formalization in logical languages, we discuss and de-
fend three interrelated theses concerning the semantics of languages in
general. The rst is the claim that the usual formal semantics needs to be
clearly distinguished from an ontological semantics, where the latter aims
at explicating, at least partially, an ontological analysis of representations
using a language. The second thesis is to utilize both types of semantics
in parallel. Thirdly, it is argued that ontological semantics must be ori-
ented at particular cases of using a language, which may lead to dierent
manifestations of ontological semantics for one and the same language.
Based on these views, we outline and illustrate our proposal for establish-
ing usage-specic and ontology-based semantic schemes. Moreover, rela-
tions to works regarding conceptual modeling languages are established
and potential applications are indicated, including semantics-preserving
translations and the re-engineering of representations.
1 Introduction
1.1 Background and Motivation
The proposals in this article and the considerations that lead to them arose and
have been pursued since then in the context of a long-term ontology development
enterprise, building the top-level ontology General Formal Ontology (GFO)1 [9].
Top-level ontologies naturally lend themselves to nding applications in numer-
ous areas. This poses a challenge as regards the representation of the ontology,
i.e., its provision in appropriate formats / languages (of primarily formal and
semi-formal, and to some extent informal kind) for those dierent areas and
for applications regarding dierent purposes. Due to this we are interested in
translations among representations that provably preserve the semantics of the
ontology.
Motivated by the ultimate goal of meaning-preserving translations, we are
working towards formally dening the semantics of languages on the basis of
1
http://www.onto-med.de/ontologies/gfo

194 F. Loebe
ontologies. The latter is deemed an indispensable tool for meaning-preserving

translations. In [11] we argue that a truely ontological semantics has not yet
been provided with formal rigor. Herein we aim at defending central views in
the same regard and extend our (work-in-progress) proposals concerning the
semantics of languages. Despite focusing on logical languages in our use cases, the
ideas appear generally transferable, including conceptual modeling languages.
1.2 Related Work and Paper Structure

There are two major lines of related work. In conceptual modeling, a general
notion of ontological semantics is known, in the sense of providing mappings of
language constructs to ontologies. In particular, starting around 1990, a series
of works by Y. Wand, R. Weber, A.L. Opdahl, J. Evermann, G. Guizzardi and
others provide an ontological semantics for constructs in the Unied Modeling
Language (UML) or, more generally, for conceptual modeling languages; of these,
[4,5,6,7,8,15] are relevant herein. We subscribe to many of the general ideas in
these approaches and advocate similar positions below, at which we arrived in
a logical setting. With hindsight and as far as we can see, nevertheless these
approaches do not fully satisfy our goals, see the discussion in sect. 4.2.
The second line of research is concerned with the formal establishment of
ontological semantics, e.g. [2,13]. However, the drawback of all approaches that
we have become aware of is to dene ontological semantics by recourse / reduction
to accounts of formal semantics. This discounts some of our core presuppositions,
as elaborated below, which lead us to seeking a dierent approach.
The remainder of the paper is structured as follows. Brief terminological re-
marks conclude the introduction. In the main sections we defend three strongly
interrelated theses on language semantics and sketch the working proposal of
ontological usage schemes to account for / implement the theses in assigning on-
tological semantics to languages in a formal way. The paper concludes with dis-
cussing some (intended) benets and applications of the proposal (very briey),
as well as a reconsideration of related work and an outline of future work.
1.3 Terminological Preliminaries

Our discussion aims at covering a very broad range of (representation) languages,
for which we expect a precisely dened syntax only. Despite a certain bias to-
wards sentential / word languages the majority of the following ideas applies
analogously to graphical / diagrammatic languages. Accordingly, we use repre-
sentation as a general term for particular sets of expressions (R) of sentential
languages (L) or particular diagrams (R) of a graphical language (L); formally,
we write R L for R being stated in L. In semantic considerations of languages,
we assume a domain of discourse that comprises entities. By referential terms we
mean constant or variable symbols or symbolic constructions intended to denote
entities in the domain of discourse, whereas sentences reect states of aairs.
The term ontology is used in a general sense for theory of existential
commitments, which is not limited to highly general notions but may be very
Ontological Usage Schemes 195
domain-specic, in contrast to the usual understanding in conceptual modeling

according to [8, sect. 3.3], [4, p. 235]. Ontology herein is renable to conceptual-
ization / conceptual model if the focus is on the theory contents independently
of any language aspects, or to formalized ontology if a particular formalization
language is assumed in which the conceptualization is represented.
Eventually, the notions of ontological analysis, ontological translation, and on-
tological foundation are of relevance herein. We refer to an ontological analysis
as any process through which an ontology is established, i.e., a conceptualiza-
tion is developed and possibly represented in informal and / or formal manner.
Arbitrary domains as well as pre-established representations are the main target
types of ontological analyses, according to our experience. Concerning represen-
tations, an ontological translation is a translation of a representation R L that
results in a formalized ontology which accounts for the ontological claims that
that use of L commits to. Where the analysis does not start from scratch but uti-
lizes available ontologies, reuse and integration become an aspect of ontological
analysis. Ontological foundation refers to that part of ontological analysis that
relates the notions targeted at with more general concepts, which are not among
the analysis targets. A very simple case is to declare more general categories for
target notions, e.g. that lion (an analysis target) specializes animal (in a core
ontology) and continuant (in a top-level ontology).
2 Three Theses on Language Semantics

The number of (representation) languages is vast. They cover a broad range of
purposes and domains which they were designed for. Two important landmark
clusters in this spectrum are domain-specic languages and general-purpose lan-
guages (with representatives like UML and many logical languages, e.g. rst-
order logic (FOL), description logics (DLs) [1], or Semantic Web languages like
the Web Ontology Language (OWL) [14]. All languages under consideration here
are equipped with a precise, mostly formal denition of their semantics. By for-
mal here we refer to the use of abstract mathematical notions like sets, tuples,
etc. in the denition of the semantics. The subsequent analysis focuses on such
languages. The proposal of ontological usage schemes should be applicable to
arbitrary (representation) languages, however.
2.1 Distinguishing Two Types of Semantics

The rst important thesis herein is that the formal semantics of a language
must be clearly distinguished from the ontological contents / commitment that
a representation using the language may express in particular circumstances.
Consider a DL role hasPurchased. Conceptually, this may refer to a relationship
has-purchased (which, in turn, may be derived from purchase event), connect-
ing a person with a commodity. Yet, the standard formal semantics of a role in
a DL interpretation structure is a set of pairs over the interpretation domain.
196 F. Loebe
This basic distinction has already been defended in some detail by others,
e.g. [8, sect. 2.1], and ourselves [11]. One supportive argument is that encodings
of conceptual notions by mathematical constructs occur and lead to problems
where mathematical properties correspond no longer to conceptual interrela-
tions. Further, iterated translations among formalisms are problematic if encod-
ings produce anomalies that aggregate over repeated translations. Nevertheless,
the distinction between formal and ontological semantics is worth being stressed.
At least, this is our observation regarding many proponents with a formal / logical
background. For instance, major, seemingly accepted denitions of notions like
ontology-based semantics and equivalence [2,13] and of semantics-preserving
translations (like those between UML and OWL in the Ontology Denition
Metamodel) purely rest on the formal semantics of the languages under study.
For conceptual modeling and ontology research related with conceptual modeling
the awareness of the dierence may be greater, cf. [8, sect. 2.1].
2.2 Formal and Ontological Semantics in Parallel

Given the distinction between formal and ontological semantics, the question
arises which type of semantics should be assigned to a language. On the one hand,
a language with formal semantics has its benets, including being very precise
and exhibiting a well-understood mathematical basis. This supports clear and
precise characterizations of dynamic aspects of the language as well as it allows
for the verication of the correctness of algorithms / implementations. Moreover,
many languages with formal semantics are tuned to particular purposes and are
particularly successful regarding those one may think of Petri nets [3] and their
capabilities of behavioral analysis, for example. Ontological semantics, on the
other hand, we deem necessary for translations between languages that preserve
conceptual contents and, equivalently, necessary for semantic interoperability
(of information systems). Clearly, almost every use of a language involves some
conceptual contents. But either ontological semantics is not explicated at all,
like frequently in knowledge representation, or it is not rigorously established,
i.e., the link to ontologies is kept rather informal and leaves room for vagueness.
Thus far we conclude that an ontological account of semantics should be es-
tablished for a language L in parallel to a (perhaps purpose-specic) formal
semantics of L. At least, this should be done if the represented contents is (pos-
sibly) to be transferred to another form of representation. In the specic case
where the purpose of a representation is the mere statement of ontological claims,
formal and ontological semantics might collapse.
2.3 Establishing Ontological Semantics

The previous section leads us immediately to the question of How to establish
ontological semantics?. In the context of the development of the General Formal
Ontology (cf. sect. 1.1), we have been facing this question for the representation
of ontologies themselves. As is nowadays well-established for some communities,
the starting point was the use of logical languages, for us rst order logic (FOL).
Resulting from detailed analysis and in connection with translation eorts, in

[11] we argue that even general purpose languages like FOL cannot be considered
to be ontologically neutral. Hence a novel account of semantics for logical syn-
tax is required that assigns to a logical theory a direct ontological semantics (as
a kind of referential, model-theoretic semantics, parametrized by an ontology).
[11] outlines a corresponding approach for FOL syntax and eventually involves
some methodological constraints for the use of FOL for formalizing ontologies,
respecting the standard formal semantics, as well. However, a detailed elabora-
tion is beyond the scope of this paper and is largely irrelevant in the sequel.
Basically, it suces to acknowledge that ontologies / ontological claims can be
adequately captured in terms of logical theories.
Accordingly, a logically formalized ontology base forms the backbone of es-
tablishing indirect ontological semantics. By performing an ontological analysis
of any representation R L, such semantics can be dened by a translation of R
or L into an ontological theory, i.e., an ontological translation (sect. 1.3). The
latter phrases require some care, however. Notice that, for a substantially rich
ontological translation, base must cover the conceptual contents of R (including
the hidden knowledge) at Rs level of specicity. In particular, the ontology
must then elaborately account for all entities named in the representation. We
expect that these circumstances are hard to meet. Therefore, striving for an in-
complete / abstracting translation of R appears more realistic. This corresponds
more closely to the ontological foundation for syntactic constituents of R or L.
Yet there is another aspect to be acknowledged. We argue that the ontolog-
ical analysis of a representation must take each single referential constant into
account, i.e., actually its intended referent. That means, dening ontological se-
mantics usually cannot start at the same syntactic level that formal semantic
denitions start from, even if one merely aims at an ontological foundation. Our
point here is that employed atomic symbols of a representation R i.e., sym-
bols occurring in a particular use of the language L form the bottom line for
ontological analysis. From the point of view of Ls grammatical denition, there
may be a large set of potentially usable constants. But the latter are opaque
to / not usable in typical denitions of formal language semantics. Each use of L,
however, involves a much smaller subset of constants, which are equipped / linked
with intended referents by the user of the language. We hold that this forms a
signicant part of the conceptual contents of R, in a sense claiming at least the
existence of those entities named by constants. Of course, beyond constants, one
may consider syntactic compositions and to what extent they contribute further
ontological claims. The central conclusion that we draw in this connection is that
ontological semantics should be oriented towards particular uses of a language L
rather than nding the (single) ontological semantics for L. In particular, this
applies to general-purpose formalisms, including logical languages and, to a sim-
ilar extent, UML. Rephrased again, the grammatical distinctions in the syntax
of the language are fairly limited, in contrast to the basically arbitrary choice of
entities / notions that one might wish to capture in terms of a language. Con-
sequently, one must expect that much more ontological distinctions exist than
198 F. Loebe
could be mapped uniquely to available syntactic / grammatical distinctions. Thus

it is reasonable to orient the assignment of ontological semantics at particular
cases of usage of a language, and to have multiple possible ontological semantic
denitions for one and the same language. It remains open to what extent the
notion of context may be employed to account for this diversity.
Further support arises from encoding uses of a language, e.g. for reasons of
expressiveness, exploitation of behavioral properties or algorithms provided for
that language, etc. For such reasons, users may be lead to misuse a language.
3 Ontological Usage Schemes
In this section we present a general method to provide indirect ontological seman-

tics for a language in a rigorous manner. Basically, the notion of ontological usage
schemes (OUSes) refers to a specic form of dening an ontological translation.
On the basis of our approach as summarized in sect. 2.3 and of the additional
considerations therein, the following more precise denition is given. Despite its
bias to sentential languages, we hope that the general approach behind becomes
visible. Table 1 provides an illustration, which is briey further discussed below.
Denition 1 (Ontological Usage Scheme). For a language L, Tm(L) de-
notes the set of referential terms (sect. 1.3) that can occur in representations
using L.
An ontological usage scheme (OUS) of a language L is captured as a structure
S(L) = (L, L , base , , , ), where L is a logical language with direct onto-
logical semantics that is established on the basis of the ontology base , where
base is formalized in L . The remaining components are translation mappings:
: Tm(L) (Tm(L )) maps referential terms of L into sets of such of L ,
: Tm(L) (L ) accounts for the ontological analysis of referential terms,
and : L (L ) explicates the ontological analysis of L expressions.
It should be stressed again that multiple OUS are perfectly reasonable for any
single language L. Moreover, L and base are parameters in Def. 1, allowing
for dierent languages and base ontologies. For our purposes, we have equipped
FOL syntax with a direct ontological semantics [11, sect. 3.2] and thus use FOL
(as L ) in conjunction with the methodology mentioned in sect. 2.3 for ontology
representation, including the ontology of categories and relations (outlined in [11,
sect. 4]). The schematic aspect of ontological usage schemes becomes manifest
in generic denitions for certain sets of identiers, like NC , NR , and NI in Table 1.
This is similar to usual denitions of formal semantics and primarily useful for
the ontological foundation of language elements.
It is important, on the one hand, that the translations , , and must be
specied such that they formally capture the intended meaning of representa-
tions in L. On the other hand, they can be dened with great freedom concerning
the (semi-)formal semantics of L. This is contrary to existing formal accounts of
ontology-based semantics, like [2]. However, due to the encoding of conceptual
notions into Ls syntax and, thereby, semantics (see sect. 2.1), the translation of
Table 1. S(ALC) = (ALC, FOL, CR, , , ), an exemplary ontological usage scheme

for (a subset of) ALC syntax [1, ch. 2], based on an ontology of categories and relations,
cf. [11], closely associated with the General Formal Ontology [9].
ALC Syntax Mappings (, , ; auxiliary: xV )

Vocabulary
C NC (C) = {C }
(C) = {C :: Cat, C Ind}
R NR (R) = {R , q1 (R ), q2 (R )}
(R) = {R :: Reln, q1 (R ) :: RoleCat, q2 (R ) :: RoleCat,
RoleBase2 (R , q1 (R ), q2 (R ))}
a NI (a) = {a }
(a) = {a :: Ind}
Concepts
C NC xV (C) = x :: C
C D xV (C D) = x :: xV (C) x :: xV (D)
C xV (C) = x :: Ind x :: xV (C)
V {y}
R.C x (R.C) = y(y :: Indrel2 (R , q1 (R ), x, q2 (R ), y) y
V
(C))
(for any new variable y / V)
TBox and ABox axioms (where C, D concepts, a, b NI )
{x} {x}
C
D (C
D) = {x . x (C) x (D)}
{x} {x}
C=D (C = D) = {x . x (C) x (D)}

C(a) (C(a)) = {
a (C)}
R(a, b) (R(a, b)) = {rel2 (R , q1 (R ), a , q2 (R ), b )}
Symbol NC (set of) concept names, NR role names, NI individual names

legend: :: instantiation Reln relation
(extensional) specialization RoleCat role category
Cat category RoleBase2 role base (of a binary relation)
Ind individual rel2 relator (binary)
an explicit representation in L should be given priority compared to additionally

accounting for anything that is implicitly derivable by means of the formal se-
mantics of L. If both can be achieved without corrupting adequate translation of
what is explicitly represented, of course, this is the ideal case. Otherwise, it may
be useful to identify mismatches between reasoning over the ontological contents
of a representation and formal-semantic derivations in L.
Eventually and as just anticipated, OUSes allow for dening the formally
captured, ontological theory that arises from a representation:
Denition 2 (Ontological Image). Let S(L) = (L, L , base , , , ) an on-

tological usage scheme. For a representation R
L, the ontological

image of R
according to S is the deductive closure of base tTm(R) (t) eR (e).
Table 1 illustrates a (specication of a section of a) sample usage scheme

S(ALC) = (ALC, FOL, CR, , , ) for very common expressions in description
200 F. Loebe
logics (DLs) [1].2 A detailed explanation of it does not t here, but for readers
aware of DL the scheme is designed to strongly correspond to an ontological
reading of the standard translation between DL and FOL [1, sect. 4.2], i.e., DL
concepts are understood as categories of (ontological) individuals, DL roles as
binary relations among (ontological) individuals. In terms of Def. 1, this prox-
imity between L and L is no prerequisite. For more intuitions on the ontology
of categories and relations CR, the reader is referred to [11,10]. To complete the
illustration with a very simple translation of a DL representation, the ontological
image of the DL statement lion animal is the deductive closure of the theory
CR{lion :: Cat, lion Ind, animal :: Cat, animal Ind, x.x :: lion x :: animal}.
4 Discussion
4.1 Applications and Benets
Ontological semantics in general and ontological usage schemes (OUSes) in par-
ticular allow for at least the following applications. Firstly, the formal-logical,
ontological theory resulting from applying an OUS to a particular representa-
tion R allows for reasoning over the conceptual contents of R. Such theories also
form the basis of notions of conceptual equivalence. Notably, logical equivalence
within those theories is a rst candidate, cf. [2], but we are convinced that fur-
ther renements are required. Secondly, with notion(s) of conceptual equivalence
(seemingly) non-standard translations become justiable. In particular, these play
a role when translating from less expressive to more expressive languages. Ex-
pressiveness here refers to the distinctions available in the abstract syntax. For
instance, consider the case of DLs and UML. (Almost all) DLs do not provide
immediate means to express relationships with an arity greater than two, which
leads to encoding proposals like [12]. Accordingly, catch-all language-level3 trans-
lations like the ones from UML to OWL and vice versa in the Ontology Denition
Metamodel must fail in a number of cases, and circular translation chains lead
to non-equivalent representations in the same language.
Thirdly, based on an OUS one may derive constraints / rules for using a
language in accordance with that OUS. For instance, the disjointness of rela-
tions and purely non-relational categories suggests that a DL concept encoding
an n-ary relation should be declared disjoint with every DL concept capturing
a non-relational category. Fourthly, OUSes should be useful for re-engineering
purposes, because frequently the ontological semantics of a representation is aug-
mented / elaborated in greater detail. Consider the example of modeling pur-
chase (processes), initially encoded as a binary relation / association between a
buyer and a commodity (in DL and UML), then expanded to include the time of
the purchase (requiring a concept in DL and, e.g., an association class in UML).
If the connection to the notion of purchase is explicated in both OUS (for DL
and UML), the relationships between the two versions should be at least easier to
grasp in terms of the OUS and might support (semi-)automatic data migration.
2
ALC is derived from the phrase attribute logic with complement.
3
As opposed to usage-level.
4.2 Reexamining Ontological Semantics in Conceptual Modeling
Spatial limitations dictate to exclude a reconsideration of the formal approaches

[2,13] mentioned in sect. 1.2, but note the assessment of [2] in [11, sect. 5.2].
Respective work in conceptual modeling typically provides mappings of lan-
guage constructs to ontologies. As far as we can see, those mappings are of
informal or semi-formal nature and they are attached to basic modeling con-
structs / abstract syntax categories, i.e., at the language-level. This corresponds
best to our translation mapping in an OUS (L, L , base , , , ), although
actual formal-logical theories are not established through the given mappings.4
The general line of application in those works, besides providing semantics itself,
appears to be the evaluation of language constructs and the provision of con-
straints on their usage. Though valuable, currently this prescriptive approach
remains subsidiary for us. Instead, we follow an explanatory approach, originat-
ing from a dierent angle. Our primary aims are reasoning over the translation
theories and justiable translations between dierent languages based on ad-
equate and provable notions of conceptual equivalence. Especially, we see the
need to allow for various translations for the same pair (or set) of languages,
because syntactic distinctions are limited. Moreover, if specialized ontologies are
available, these should be employed for ontological semantics, even of general
purpose languages. The mentioned approaches, e.g. [5,6], dier and seemingly
suggest to determine a one-to-one correspondence between language constructs
and ontological notions.5 Eventually, the intended scope of the present discus-
sion is not restricted to conceptual modeling languages, but aims at covering the
ontological contents of arbitrary representations.
The overall aim herein is to unite the formal and conceptual viewpoints on lan-
guage semantics beneath a common roof, but without reducing one to the other.
We advocate the general theses that specic uses of languages should be ac-
companied by explicating the ontological semantics of the (usage of) language
constructs, in addition to (possibly) having a formal or semi-formal semantics
assigned to the language already. This presumes that ontological and formal se-
mantics are dierent. To the best of our knowledge, these positions are not well
accepted in formal language communities (if discussed at all), whereas they seem
to be acknowledged at least by some researchers in conceptual modeling. After
arguing for these views, the approach of ontological usage schemes (OUSes)
is outlined and briey illustrated. It is based on formalization in logical lan-
guages and research in top-level ontology, and thus far contributes a translation
approach to dene precisely ontological semantics for languages.
4
Only recently, a translation of a UML representation of Bunges ontology into OWL
was presented by J. Evermann [4].
5
Notably, [6, p. 32] restricts this to only when using UML for conceptual modeling
of a domain, as distinguished from software modeling.
202 F. Loebe
Future work will comprise the denition of further OUSes for languages that
are relevant to our ontology development projects. In combination with appro-
priate notions of (conceptual) equivalence, which we are currently developing,
these OUSes should allow us to oer provably conceptually equivalent versions
of contents represented in multiple languages. Regarding the rather large col-
lection of works on ontological semantics for UML / in conceptual modeling, it
appears worthwhile to elaborate mutual relationships in greater detail. Remem-
bering the distinction of conceptual models and software models in [6], it appears
interesting to study the relation and information ow between conceptual and
software models by means of OUS (or an extension of these). Not at least, this
might become one kind of evaluation in practice.
References
1. Baader, F., Calvanese, D., McGuinness, D., Nardi, D., Patel-Schneider, P. (eds.):
The Description Logic Handbook. Cambridge University Press, Cambridge (2003)
2. Ciocoiu, M., Nau, D.S.: Ontology-based semantics. In: Cohn, A.G., Giunchiglia, F.,
Selman, B. (eds.) Proc. of KR 2000, pp. 539546. Morgan Kaufmann Publishers,
San Francisco (2000)
3. Diaz, M. (ed.): Petri Nets: Fundamental Models, Verication and Applications.
ISTE, London (2009)
4. Evermann, J.: A UML and OWL description of Bunges upper-level ontology
model. Software Syst. Model 8(2), 235249 (2009)
5. Evermann, J., Wand, Y.: Ontology based object-oriented domain modelling: Fun-
damental concepts. Requir. Eng. 10(2), 146160 (2005)
6. Evermann, J., Wand, Y.: Toward formalizing domain modeling semantics in lan-
guage syntax. IEEE T. Software Eng. 31(1), 2137 (2005)
7. Evermann, J.M.: Using Design Languages for Conceptual Modeling: The UML
Case. PhD Thesis, University of British Columbia, Vancouver, Canada (2003)
8. Guizzardi, G.: Ontological Foundations for Structural Conceptual Models. CTIT
PhD Series No. 05-74, Telematica Instituut, Enschede, The Netherlands (2005)
9. Herre, H.: General Formal Ontology (GFO): A foundational ontology for conceptual
modelling. In: Poli, R., Healy, M., Kameas, A. (eds.) Theory and Applications of
Ontology: Computer Applications. ch. 14, pp. 297345. Springer, Berlin (2010)
10. Loebe, F.: Abstract vs. social roles: Towards a general theoretical account of roles.
Appl. Ontology 2(2), 127158 (2007)
11. Loebe, F., Herre, H.: Formal semantics and ontologies: Towards an ontological
account of formal semantics. In: Eschenbach, C., Gr uninger, M. (eds.) Proc. of
FOIS 2008, pp. 4962. IOS Press, Amsterdam (2008)
12. Noy, N., Rector, A.: Dening N-ary relations on the Semantic Web. W3C Working
Group Note, World Wide Web Consortium (W3C) (2006),
http://www.w3.org/TR/swbp-n-aryRelations/
13. Schorlemmer, M., Kalfoglou, Y.: Institutionalising ontology-based semantic inte-
gration. Appl. Ontology 3(3), 131150 (2008)
14. W3C: OWL 2 Web Ontology Language Document Overview. W3C Recommenda-
tion, World Wide Web Consortium (W3C) (2009)
15. Wand, Y., Storey, V.C., Weber, R.: An ontological analysis of the relationship
construct in conceptual modeling. ACM T. Database Syst. 24(4), 494528 (1999)
Gene Ontology Based Automated Annotation:
Why It Isnt Working
Matthijs van der Kroon and Ana M. Levin
Centro de Investigaci
on en Metodos de Producci
on de Software -PROS-, Universidad
Politecnica de Valencia, Camino de Vera s/n, 46022 Valencia, Valencia, Spain
Abstract. Genomics has seen a great deal of development since the

milestone of the sequencing of the human genome by Craig Venter and
Francis Collins in 2000. However, it is broadly accepted now that real
challenges are lying ahead in actually understanding the meaning of these
raw data. Traditionally this process of assigning meaning to biological
crude data is being performed by domain specialists and has been known
as annotation. As data chaos becomes larger due to rapid advances in se-
quencing technologies, the interest for automated annotation has equally
increased. Current approaches are often based on the Gene Ontology
(GO), but often fail to meet the requirements. Determining why and
how they fail will prove crucial in nding methods that perform better,
and ultimately might very well deliver the promising feat of turning the
Human Genome data chaos into actual knowledge.
1 Introduction
The sequencing of the Human Genome in the year 2000 by Craig Venter and
Francis Collins [1] came with tremendous promises. These eects are most prob-
ably not yet apparent and science still struggles to process the huge accomplish-
ment into knowledge artifacts. Scientists now broadly agree that reading the
sequence of DNA was the relatively easy part of genome analysis; guring out
what the sequence actually means is the real challenge. Following these insights
a new scientic line of research was opened as the marriage of informatics and
biology: bioinformatics. It is here that bioinformaticians try to combine rigorous
yet computationally powerful informatics with the ambiguous and fuzzy biology.
And as Venter and Collins eorts start to bear fruits and technology rapidly ad-
vances, more and more sequencing experiments are being performed world-wide
generating large amounts of data; leading to the following question: how do we
manage the data chaos?
Current solutions are often based on ontologies, most notably the Gene On-
tology (GO). Literally translated from ancient Greek, ontos means of that
which is and -logia: science, study. The science of Ontology (uppercase O)
is diverse and dates back to the early Greeks, where it referred to the analytic
philosophy of determining what categories of being are fundamental, and in what
sense items in those categories can be said to be. In modern times, an ontol-
ogy (lowercase o) is considered many things. Gruber is credited for introducing

204 M. van der Kroon and A.M. Levin
the rst compact, yet complete description: [an ontology is a] specication of a

conceptualization [2].
2 Gene Expression Data Annotation

As technology advances the amount of data generated by sequencing experiments
increases at an equally rapid pace. A DNA microarray is a multiplex technology
used in molecular biology. It consists of an arrayed series of thousands of mi-
croscopic spots of DNA oligonucleotides, called features, each containing small
amounts of a specic DNA sequence, known as probes. These probes can be a
short section of a gene or other DNA element. Since an array can contain tens
of thousands of probes, a microarray experiment can accomplish many genetic
tests in parallel and as such generate abundant amounts of data. Interpreting
these data is the main task of the biologist and is often referred to as annotating.
It comes as no surprise that research is ongoing to achieve an automated method
of annotation. Over the years many automated annotation systems have been
proposed, among the most recent ones; [3], [4], [5]. Capturing the meaning of
gene expression data by interpretation is an issue that largely depends on, and
relates to the theory of knowledge. In some sense, it can be thought of as the
quest to identify what in the human genome is thought to be, which main cat-
egories of being can be identied and how these interrelate. As these questions
correspond largely to the underlying principles of ontologies, it is no coincidence
various attempts have been made to combine these two; Tirrell et al. [5] de-
scribes RANSUM (Rich Annotation Summarizer) which performs enrichment
analysis using any ontology in the National Center for Biomedical Ontologys
(NCBO) BioPortal. Jung et al. [6] describes the PoGO (Prediction of Gene On-
tology terms) that uses statistical pattern recognition methods to assign Gene
Ontology (GO) terms to proteins from fungi.
Khatri et al. [7] provides an overview of current practice on the application
of ontologies in the analysis of gene expression data. As a potential pitfall is
mentioned that an ontological analysis approach might be biased in favor of
certain genes and pathways. Indeed, the number of annotations available is di-
rectly proportionate to the number of experiments performed with those genes
or pathways. Some biological processes are more intensively studies, thus gener-
ating more data. If more data about a specic process are available, this process
is more likely to appear in the results. Another potential pitfall is that the re-
sults of any analysis are limited by the availability of accurate annotations. It
is acknowledged that the existing data are incomplete. Finally, an ontological
analysis approach can be criticized because certain genes are more important
than others, so the sheer number of genes may not tell the whole story.
3 Gene Ontology Gone Ontology?

Ontologies enable us to build large, maintainable knowledge bases that can cod-
ify what we know about specic areas of practice in precise, unambiguous terms.
Gene Ontology Based Automated Annotation: Why It Isnt Working 205
Adding to this, it allows us to reason over these structured knowledge bases, with
the purpose of deducing new knowledge. In this short description we identify two
dierent applications; knowledge management and knowledge deduction. An on-
tology can be of varying level of rigor, where a lower level, and as such more
ambiguous ontology will be ne to deliver the promise of maintaining knowledge
bases, but unable to allow for automated reasoning necessary to deduce new
knowledge. A higher level of rigor will allow for both accurate knowledge man-
agement, and deduction of new knowledge at the cost of increased complexity.
When the Gene Ontology was conceived in 2000 [8], it came with the promise
of enabling a conceptual unication of biology by providing a dynamic, controlled
vocabulary. Adding to this, it was hoped that the common vocabulary would
result in the ability to query and retrieve gene and proteins based on their
shared biology, thus deducing new knowledge. Later research has shown that
Gene Ontology in reality often lacks rigor to allow for this high level of ontology
application. The early discussion started by Smith [9] and Kumar [10], stating
that It is unclear what kinds of reasoning are permissible on the basis of GOs
hierarchies. and No procedures are oered by which GO can be validated..
We now proceed to discuss the main points of their work.
3.1 Universals versus Particulars

In metaphysics, a universal is a meta-concept. It denes what particular things
have in common, namely characteristics or qualities.The idea is that universals
can be instantiated by particular things, or particulars (also called individuals,
exemplars, instances, tokens). For example, the species E. coli, with the function
to boost insulin production is a universal. Instantiated as the particular E. coli
bacterium now existing in the Petri dish, its function is to boost insulin produc-
tion in specic cells in your pancreas. Why is it important to have a distinction
between particulars and universals? Consider the following case in which we have
modeled a universal, say gene, that corresponds to the biological concept by
the same name and has a few properties: it is known for instance that a gene
has a promotor and a terminator while being located on a specic chromosome.
Once we now establish during a biological experiment that a certain stretch of
DNA must be a gene (eectively instantiating the universal to an instance), we
are now able to deduce from this knowledge that this particular stretch of DNA
must have a promotor, terminator and that it is positioned on a chromosome.
Imagine this same case but now we have not modeled the universal, instead stor-
ing a list of stretches of DNA (instances) that we consider to be genes. When
we try to make the same deduction as earlier in case we nd a new stretch of
DNA that corresponds to the biological concept of gene, we can not deduce
what other properties it has.
3.2 Continuants versus Occurrents

Entities that continue to exist through time are often referred to as continuants.
In the GO context, organisms, cells and chromosomes are all continuants, even
while undergoing changes they do not cease to preserve their identity.
Occurrents on the other hand, are never said to exist in full for a single instant
of time. Rather they they unfold during successive phases, like for example a viral
infection unfolds itself over time. (Biological) processes usually are characterized
by passing through dierent states: where the nucleus is part of the cell, mitosis
is a part of the cellular process.
The continuant/occurrent opposition corresponds in the rst place to the dis-
tinction between substances (objects, things) and processes. GOs cellular com-
ponent ontology is in our terms an ontology of substance universals; its molecular
function and biological process ontology are ontologies of function and process
universals. But functions, too, are from the perspective of philosophical ontology
continuants. For if an object has a given function which means a token function
for a given interval of time, then this token function is present in full at every
instant in this interval. It does not unfold itself in phases in the manner of an
occurrent. If, however, the token function gets exercised, then the token process
that results does indeed unfold itself in this manner. Each function thus gives
rise, when it is exercised, to processes or activities of characteristic types.
3.3 GOs Relations

The GO relation isa is referred to as meaning instance of, however in practice
it is clearly used in such a way to indicate is a kind of or specialization between
universals (e.g. p53 is a protein). Adding to this, sometimes the isa relation
is used to indicate part-of, as in the denition of vacuolar proton-transporting
V-type ATPase, V0 domain (GO:0000220), which identies the concept as isa
vacuolar part, rather than as a component part thereof.
The part-of relation as dened by GO indicates a transitive relation intended
to conceptualize can be part of, not is always part of. GO uses the part-
of relation for representation of parts of both substances and processes, and of
functions/activities. The part-of relation is ambiguous in that it does not provide
clear means of distinguishing between the following cases:
A part-of any B
A part-of some B
A part-of B, only when a condition holds
However useful as a controlled vocabulary, Gene Ontology all to often fails to
deliver on the promise of allowing for deduction of new knowledge due to a
lack of necessary conceptual rigor. Egaa Aranguren [11] captures the essence of
this issue by stating that The computers understanding is determined by the
semantics of the language, thus if the semantics of the language are unclear, so
is the computers understanding. It is dicult for humans to adequately reason
over situations they dont understand, it is even more so for computers.
3.4 Conceptual Modeling

Conceptual modeling is the practice of creating models for the purpose of either
designing an artifact, or achieving a higher understanding of a certain domain.
Often these two overlap in a process referred to as Model Driven Architecture

(MDA). In MDA the main objective consists of creating high quality software,
made possible by extensive use of conceptual modeling techniques. The idea is
to create models of the domain and the to-be created application, after which
the software can automatically be generated from these models, in some cases
without human interference [12]. Clearly, for this process to succeed the model
must be formal and unambiguous, i.e. the semantics of the language must be
clear. MDA is most often used in an Information Systems (IS) context, but is
it so strange to view the biological mechanism of life as an IS? A very complex
and organically based, but an IS nonetheless. Replacing human made, silicon
based, chips with organic proteins and processor instructions with DNA tran-
scription and translation to proteins. It is often through making analogies with
systems we already comprehend, that we come to understand otherwise dicult
to grasp mechanisms. Currently, a very attractive, challenging line of research is
the personalized medicine context (have a look for instance at [13], where con-
crete applications of the IS-based working environment defended in this paper
are presented).
The rst documented eort to combine the practice of conceptual modeling
is [14] which proposes conceptual models for genomic data. Pastor [15][16] then
further elaborated on this initial work.
It is important to understand that using either approach; conceptual models
(CM) or ontologies is really not that dierent, as a matter of fact an ontology is
always present when creating a conceptual model. It is dened implicitly by the
model itself, while the other way around is not always true: not every ontology
has a visual representation allowing it to be named a conceptual model.
The universals versus particulars discussion is easily addressed by CMs: that
which is reected in the model must always be a universal, for instance a gene,
having the following attributes: HUGO id, chromosome. While its particulars,
for instance a gene that has the HUGO assigned id BRCA1, and which is
located on the human chromosome 17. These particulars are instances of the
CMs concepts, and usually exists only at runtime. Runtime being interpreted
broadly: both an executing object and a database tuple, stored persistently, are
considered runtime.
The GO expressiveness for conceptualizing relations among entities is not
rich enough. By being unable to capture certain knowledge adequately, the un-
controlled use of non-standard operators becomes a tempting, ad-hoc, solution.
Conceptual modeling oers a rich variety of relations: an aggregation is a weak
whole-part relation where the members can exist without the containing or en-
closing class, e.g. Staphylococcus epidermidis forms part of human skin ora, but
can survive without a human host. A composition is also a whole-part relation,
but stronger than an aggregation such that the whole does not exist without
its parts, e.g. a human individual can not exist without a brain. Further, in-
heritance allows in an intuitive way to identify hierarchies of concepts; a skin
cell is a specied type of cell, thus inherits properties of its super type. The
concept of a simple relation merely describes the abstract property of allowing
communication between two entities: for instance the communication between

neurons (this would be a reective association). In case expressiveness is still not
rich enough, the Object Constraint Language [17] allows for even ner specica-
tion by allowing the application of textual constraints to the models behavior.
4 Conclusions
Our goal in this work is to start a discussion on the application of Gene Ontology
to gene expression annotation, uncovering its aws and proposing an alternative
route. Capturing biological understanding is a huge challenge we face, and the
question is not whether we want to do it, but how do we do it. Specications of
conceptualizations are everywhere around us, and thus according to Gruber all
these correspond to the concept of an ontology. It is when we try and structure
knowledge into a computationally sound structure, where not everything can
qualify as an ontology anymore. Rigorous methods are needed, for a semanti-
cally sound ontology to emerge. The practice of conceptual modeling has been
long around in Information System development, and has proven very suitable
to capture domain knowledge in a controlled manner, both syntactically and
semantically sound; ultimately even leading to the automated generation and
validation of computer software. If we take the liberty of considering the biolog-
ical system of life as analogous to an Information System it is not easy to miss
the grand opportunities such a perspective provides.
References
1. Venter, J., et al.: The Sequence of the Human Genome. Science 291(5507), 1304
1351 (2000)
2. Gruber, T.: Principle for the Design of Ontologies Used for Knowledge Sharing.
In: Poli, R. (ed.) Formal Ontology in Conceptual Analysis and Knowledge Repre-
sentation. Kluwer Academic Publishers, Dordrecht (1993)
3. Gonzlez-Daz, H., Muo, L., Anadn, A., et al.: MISS-Prot: web server for self/non-self
discrimination of protein residue networks in parasites; theory and experiments in
Fasciola peptides and Anisakis allergens, Molecular Biosystems (2011) [Epub ahead
of print]
4. Hsu, C., Chen, C., Liu, B.: WildSpan: mining structured motifs from protein se-
quences. Algorithms in Molecular Biology 6(1), 6 (2011)
5. Tirrell, R., Evani, U., Berman, A., et al.: An ontology-neutral framework for enrich-
ment analysis. In: American Medical Informatics Association Annual Symposium,
vol. 1(1), pp. 797801 (2010)
6. Jung, J., Yi, G., Sukno, S., et al.: PoGo: Prediction of Gene Ontology terms for
fungal proteins. BMC Bioinformatics 11(215) (2010)
7. Khatri, P., Draghici, S.: Ontological analysis of gene expression data: current tools,
limitations, and open problems. Bioinformatics 21(18), 35873595 (2005)
8. Ashburner, M., Ball, C.A., Blake, J.A.: Gene Ontology: tool for the unication of
biology. Nature Genetics 25(1), 2530 (2000)
9. Smith, B., Williams, J., Schulze-Kremer, S.: The Ontology of the Gene Ontology.
In: American Medical Informatics Association Annual Symposium Proceedings,
vol. 1(1), pp. 609613 (2003)
10. Kumar, A., Smith, B.: Controlled vocabularies in bioinformatics: a case study in
the Gene Ontology. Drug Discovery Today: BIOSILICO 2(6), 246252 (2004)
11. Egaa Aranguren, M., Bechhofer, S., Lord, P., et al.: Understanding and using the
meaning of statements in a bio-ontology: recasting the Gene Ontology in OWL.
BMC Bioinformatics 8(57) (2007)
12. Pastor, O., Molina, J.C.: Model-driven architecture in practice: a software produc-
tion environment based on conceptual modeling. Springer, Heidelberg (2007)
13. Collins, F.S.: The Language of Life: DNA and the Revolution in Personalized
Medicine. Prole Books Ltd. (2010)
14. Paton, N.W., Khan, S.A., Hayes, A., et al.: Conceptual modeling of genomic in-
formation. Bioinformatics 16(6), 548557 (2000)
15. Pastor, O., Levin, A.M., Celma, M., et al.: Model Driven-Based Engineering Ap-
plied to the Interpretation of the Human Genome. In: Kaschek, R., Delcambre, L.
(eds.) The Evolution of Conceptual Modeling. Springer, Heidelberg (2010)
16. Pastor, O., van der Kroon, M., Levin, A.M., et al.: A Conceptual Modeling Ap-
proach to Improve Human Genome Understanding. In: Embley, D.W., Thalheim,
B. (eds.) Handbook of Conceptual Modeling. Springer, Heidelberg (2011)
17. Warmer, J., Kleppe, A.: Object Constraint Language: Getting Your Models Ready
for MDA, 2nd edn. Addison-Wesley Longman Publishing Co., Boston (2011)
Formal Ontologies, Exemplars, Prototypes
Marcello Frixione and Antonio Lieto
University of Salerno, Italy

{mfrixione,alieto}@unisa.it
Abstract. The problem of concept representation is relevant for knowledge

engineering and for ontology-based technologies. However, the notion of
concept itself turns out to be highly disputed and problematic in cognitive
science. In our opinion, one of the causes of this state of affairs is that the
notion of concept is in some sense heterogeneous, and encompasses different
cognitive phenomena. This results in a strain between conflicting requirements,
such as, for example, compositionality on the one side and the need of
representing prototypical information on the other. AI research in some way
shows traces of this situation. In this paper we propose an analysis of this state
of affairs, and we sketch some proposals for concept representation in formal
ontologies which take advantage from suggestions coming from cognitive
science and psychological research. In particular we take into account the
distinction between prototype and exemplar accounts in explaining prototypical
effects.
Keywords: ontologies, knowledge representation, reasoning, knowledge

engineering.
1 Introduction
Computational representation of concepts is a central problem for the development of
ontologies and for knowledge engineering1. Concept representation is a
multidisciplinary topic of research that involves such different disciplines as Artificial
Intelligence, Philosophy, Cognitive Psychology and, more in general, Cognitive
Science. However, the notion of concept itself results to be highly disputed and
problematic. In our opinion, one of the causes of this state of affairs is that the notion
itself of concept is in some sense heterogeneous, and encompasses different cognitive
phenomena. This results in a strain between conflicting requirements, such as, for
example, compositionality on the one side and the need of representing prototypical
1
It could be objected that ontologies have to do with the representation of the world, and not
with the representation of our concepts. This is surely true, but, as far as we are (also)
interested in our commonsense ontologies (i.e., in the representation of the world from the
standpoint of our everyday experience, contrasted, for example, with a scientific
representation of the world), then, in our opinion, we cannot ignore the problem of how
ordinary concepts are structured.
Formal Ontologies, Exemplars, Prototypes 211
information on the other. This has several consequences for the practice of knowledge
engineering and for the technology of formal ontologies.
In this paper we propose an analysis of this situation. The paper is organised as
follows. In section 2. we point out some differences between the way concepts are
conceived in philosophy and in psychology. In section 3. we argue that AI research in
some way shows traces of the contradictions individuated in sect. 2. In particular, the
requirement of compositional, logical style semantics conflicts with the need of
representing concepts in the terms of typical traits that allow for exceptions. In section
4 we review some attempts to resolve this conflict in the field of knowledge
representation, with particular attention to description logics. It is our opinion that a
mature methodology to approach knowledge representation and knowledge
engineering should take advantage from both the empirical results of cognitive
psychology that concern human abilities and from philosophical analyses. In this
spirit, in section 5 we individuate some possible suggestions coming from different
aspects of cognitive research: the distinction between two different types of reasoning
processes, developed within the context of the so-called dual process accounts of
reasoning; the proposal to keep prototypical effects separate from compositional
representation of concepts; the possibility to develop hybrid, prototype and exemplar-
based representations of concepts.
2 Compositionality vs. Prototypes

Within the field of cognitive science, the notion of concept is highly disputed and
problematic. Artificial intelligence (from now on AI) and, more in general, the
computational approach to cognition reflect this state of affairs. Conceptual
representation seems to be constrained by conflicting requirements, such as, for
example, compositionality on the one side and the need of representing prototypical
information on the other.
A first problem (or, better, a first symptom that some problem exists) consists in
the fact that the use of the term concept in the philosophical tradition is not
homogeneous with the use of the same term in empirical psychology [see 1-3].
Briefly, we could say that in cognitive psychology a concept is essentially intended as
the mental representations of a category, and the emphasis is on such processes as
categorisation, induction and learning. According to philosophers, concepts are above
all the components of thoughts. Even if we leave aside the problem of specifying what
thoughts exactly are, this requires a more demanding notion of concept. In other
words, some phenomena that are classified as conceptual by psychologists turn out
to be nonconceptual for philosophers. There are, thus, mental representations of
categories that philosophers would not consider genuine concepts.
The fact that philosophers consider concepts mainly as the components of thoughts
brought a great emphasis on compositionality, and on related features, such as
productivity and systematicity, that are often ignored by psychological treatments of
concepts. On the other hand, it is well known that compositionality is at odds with
prototypicality effects, which are crucial in most psychological characterisations of
concepts. Prototypical effects are a well established empirical phenomenon. However,
the characterisation of concepts in prototypical terms is difficult to reconcile with the
212 M. Frixione and A. Lieto
requirement of compositionality. According to a well known argument by Jerry Fodor

[4], prototypes are not compositional (and, since concepts in Fodor's opinion must be
compositional, concepts cannot be prototypes). In synthesis, Fodor's argument runs as
follows: consider a concept like PET FISH. It results from the composition of the
concept PET and of the concept FISH. But the prototype of PET FISH cannot result
from the composition of the prototypes of PET and of FISH. For example, a typical
PET is furry and warm, a typical FISH is greyish, but a typical PET FISH is not furry
and warm neither greyish.
3 Concept Representation in Artificial Intelligence

The situation sketched in the section above is in some sense reflected by the state of
the art in AI and, more in general, in the field of computational modelling of
cognition. This research area seems often to hesitate between different (and hardly
compatible) points of view. In AI the representation of concepts is faced mainly
within the field of knowledge representation (KR). Symbolic KR systems (KRs) are
formalisms whose structure is, in a wide sense, language-like. This usually involves
that KRs are assumed to be compositional.
In a first phase of their development (historically corresponding to the end of the
60s and to the 70s) many KRs oriented to conceptual representations tried to keep into
account suggestions coming from psychological research. Examples are early
semantic networks and frame systems. Both frames [5] and most semantic networks
allowed the possibility to characterise concepts in terms of prototypical information.
However, when AI practitioners tried to provide a stronger formal foundation to
concept oriented KRs, it turned out to be difficult to reconcile compositionality and
prototypical representations. As a consequence, they often choose to sacrifice the
latter. In particular, this is the solution adopted in a class of concept-oriented KRs
which had (and still have) wide diffusion within AI, namely the class of formalisms
that stem from the KL-ONE system [6-7] and that today are known as description
logics (DLs) [8]. Networks in this tradition do not admit exceptions to inheritance,
and therefore do not allow the representation of prototypical information. Indeed,
representations of exceptions can be hardly accommodated with other types of
inference defined on these formalisms, concept classification in the first place [9].
Since the representation of prototypical information is not allowed, inferential
mechanisms defined on these networks (e.g. inheritance) can be traced back to
classical logical inferences. From this point of view, such formalisms can be seen as a
revival of the classical theory of concepts, in spite of its empirical inadequacy in
dealing with most common-sense concepts.
4 Non-classical Concepts in Computational Ontologies

Of course, within symbolic, logic oriented KR, rigorous approaches exist, that allow
to represent exceptions, and that therefore would be, at least in principle, suitable for
representing non-classical concepts. Examples are fuzzy logics and non-monotonic
formalisms. Therefore, the adoption of logic oriented semantics is not necessarily
incompatible with prototypical effects. But such approaches pose various theoretical
and practical difficulties, and many unsolved problems remain.
In this section we overview some recent proposal of extending concept-oriented
KRs, and in particular DLs, in order to represent non-classical concepts.
Recently different methods and techniques have been adopted to represent non-
classical concepts within computational ontologies. They are based on extensions of
DLs and of standard ontology languages such as OWL. The different proposals that
have been advanced can be grouped in three main classes: a) fuzzy approaches, b)
probabilistic and Bayesan approaches, c) approaches based on non-monotonic
formalisms.
a) Following this direction, for as the integration of fuzzy logics in DLs and in
ontology oriented formalisms, see for example [10-11], Stoilos et al. [12] propose a
fuzzy extension of OWL, f-OWL, able to capture imprecise and vague knowledge, and
a fuzzy reasoning engine that lets f-OWL reason about such knowledge. In [13] a fuzzy
extension of OWL 2 is proposed, for representing vague information in semantic web
languages. However, it is well known [14] that approaches to prototypical effects based
on fuzzy logic encounter some difficulty with compositionality.
b) The literature offers also several probabilistic generalizations of web ontology
languages. Many of these approaches, as pointed out in [15], focus on combining the
OWL language with probabilistic formalisms based on Bayesian networks. In
particular, in [16] a probabilistic generalization of OWL is proposed, called Bayes-
OWL, which is based on standard Bayesian networks. Bayes-OWL provides a set of
rules and procedures for the direct translation of an OWL ontology into a Bayesian
network. A problem here could be represented by the translation from one form of
semantics (OWL based) to another one.
c) In the field of non-monotonic extensions of DLs, in [17] an extension of ALCF
system based on Reiters default logic is proposed. The same authors, however, point
out both the semantic and computational difficulties of this integration and, for this
reason, they propose a restricted semantics for open default theories, in which default
rules are only applied to individuals explicitly represented in the knowledge base. In
[18] an extension of DLs with circumscription is proposed. One of motivating
applications of circumscription is indeed to express prototypical properties with
exceptions, and this is done by introducing abnormality predicates, whose extension
is minimized. A different approach, investigated in [19], is based on the use of the
OWL 2 annotation properties (APs) in order to represent vague or prototypical,
information. The limit of this approach is that APs are not taken into account by the
reasoner, and therefore have no effect on the inferential behaviour of the system [13].
5 Some Suggestions from Cognitive Science

Though the presence of a relevant field of research, there is not, in the scientific
community, a common view about the use of non-monotonic and, more in general,
non-classical logics in ontologies. For practical applications, systems that are based
on classical Tarskian semantics and that do not allow for exceptions (as it is the case
of traditional DLs), are usually still preferred. Some researchers, as, for example,
Pat Hayes [20], argue that the non monotonic logics (and, therefore, the non
monotonic machine reasoning for Semantic Web) can be maybe adopted for local
uses only or for specific applications because it is unsafe on the web. The question
about which logics must be used in the Semantic Web (or, at least, until which
degree, and in which cases, certain logics could be useful) is still open.
The empirical results from cognitive psychology show that most common-sense
concepts cannot be characterised in terms of necessary/sufficient conditions.
Classical, monotonic DLs seem to capture the compositional aspects of conceptual
knowledge, but are inadequate to represent prototypical knowledge. But a non
classical alternative, a general DL able to represent concepts in prototypical terms
does not still emerge.
As a possible way out, we sketch a tentative proposal that is based on some
suggestions coming from cognitive science. Some recent trends of psychological
research favour the hypothesis that reasoning is not an unitary cognitive phenomenon.
At the same time, empirical data on concepts seem to suggest that prototypical effects
could stem from different representation mechanisms. In this spirit, we individuate
some hints that, in our opinion, could be useful for the development of artificial
representation systems, namely: (i) the distinction between two different types of
reasoning processes, which has been developed within the context of the so-called
dual process accounts of reasoning (sect. 5.1 below); (ii) the proposal to keep
prototypical effects separate from compositional representation of concepts (sect.
5.2); and (iii) the possibility to develop hybrid, prototype and exemplar-based
representations of concepts (sect. 5.3).
5.1 A Dual Process Approach
Cognitive research about concepts seems to suggest that concept representation does
not constitute an unitary phenomenon from the cognitive point of view. In this
perspective, a possible solution should be inspired by the experimental results of
empirical psychology, in particular by the so-called dual process theories of reasoning
and rationality [21-22]. In such theories, the existence of two different types of
cognitive systems is assumed. The systems of the first type (type 1) are
phylogenetically older, unconscious, automatic, associative, parallel and fast. The
systems of the type 2 are more recent, conscious, sequential and slow, and are based
on explicit rule following. In our opinion, there are good prima facie reasons to
believe that, in human subjects, classification, a monotonic form of reasoning which
is defined on semantic networks2, and which is typical of DL systems, is a task of the
type 2 (it is a difficult, slow, sequential task). On the contrary, exceptions play an
important role in processes such as non-monotonic categorisation and inheritance,
which are more likely to be tasks of the type 1: they are fast, automatic, usually do not
require particular conscious effort, and so on.
Therefore, a reasonable hypothesis is that a concept representation system should
include different modules: a monotonic module of type 2, involved in classification
2
Classification is a (deductive) reasoning process in which superclass/subclass (i.e., ISA)
relations are inferred from implicit information encoded in a KB. Categorization is an
inferential process through which a specific entity is assigned as an instance to a certain class.
In non-monotonic categorization class assignment is a non deductive inferential process, based
on typicality.
and in similar difficult tasks, and a non-monotonic module involved in the

management of exceptions. This last module should be a "weak" non monotonic
system, able to perform only some simple forms of non monotonic inferences (mainly
related to categorization and to exceptions inheritance). This solution goes in the
direction of a dual representation of concepts within the ontologies, and the
realization of hybrid reasoning systems (monotonic and non monotonic) on semantic
network knowledge bases.
5.2 A Pseudo-Fodorian Proposal
As seen before (section 2), according to Fodor, concepts cannot be prototypical

representations, since concepts must be compositional, and prototypes do not
compose3. On the other hand, in virtue of the criticisms to classical theory, concepts
cannot be definitions. Therefore, Fodor argues that (most) concepts are atoms, i.e., are
symbols with no internal structure. Their content is determined by their relation to the
world, and not by their internal structure and/or by their relations with other concepts
[26-27]. Of course, Fodor acknowledges the existence of prototypical effects.
However, he claims that prototypical representations are not part of concepts.
Prototypical representations allow to individuate the reference of concepts, but they
must not be identified with concepts. Consider for example the concept DOG. Of
course, in our minds there is some prototypical representation associated to DOG
(e.g., that dogs usually have fur, that they typically bark, and so on). But this
representation does not the coincide with the concept DOG: DOG is an atomic,
unstructured symbol.
We borrow from Fodor the hypothesis that compositional representations and
prototypical effects are demanded to different components of the representational
architecture. We assume that there is a compositional component of representations,
which admits no exceptions and exhibits no prototypical effects, and which can be
represented, for example, in the terms of some classical DL knowledge base. In
addition, a prototypical representation of categories is responsible for such processes
as categorisation, but it does not affect the inferential behaviour of the compositional
component.
It must be noted that our present proposal is not entirely Fodorian, at least in the
following three senses:
i. We leave aside the problem of the nature of semantic content of conceptual
representations. Fodor endorses a causal, informational theory of meaning, according
to which the content of concepts is constituted by some nomic mind-world relation.
3
Various attempts to conciliate compositionality and typicality effects have been proposed within
the field of psychology ([23-25]). However, when psychologists face the problem of
compositionality, they usually take into account a more restricted phenomenon with respect to
philosophers. They try to explain how concepts can be combined, in order to form complex
conceptual representations. But compositionality is a more general matter: what is needed is an
account of how the meaning of any complex representation (included propositional
representations) depends in a systematic way from the meaning of its components and from its
syntactic structure. This should allow to account, among other things, for the inferential
relationships (typically, of logical consequence) that exist between propositional representations.
From this point of view, psychological proposals are much more limited.
We are in no way committed with such an account of semantic content. (In any case,
the philosophical problem of the nature of the intentional content of representations is
largely irrelevant to our present purposes).
ii. Fodor claims that concepts are compositional, and that prototypical
representations, in being not compositional, cannot be concepts. We do not take
position on which part of the system we propose must be considered as truly
conceptual. Rather, in our opinion the notion of concept is spurious from the
cognitive point of view. Both the compositional and the prototypical components
contribute to the conceptual behaviour of the system (i.e., they have some role in
those abilities that we usually describe in terms of possession of concepts).
iii. According to Fodor, the majority of concepts are atomic. In particular, he
claims that almost all concepts that correspond to lexical entries have no structure.
We maintain that many lexical concepts, even though not definable in the terms
classical theory, should exhibit some form of structure, and that such structure can be
represented, for example, by means of a DL taxonomy.
5.3 Concepts in Cognitive Psychology
Within the field of psychology, different positions and theories on the nature of concepts
are available. Usually, they are grouped in three main classes, namely prototype views,
exemplar views and theory-theories (see e.g. [23, 28]). All of them are assumed to
account for (some aspects of) prototypical effects in conceptualisation, effects which
have been firstly individuated by Eleanor Rosch in her seminal works [29].
According to the prototype view, knowledge about categories is stored in terms of
prototypes, i.e. in terms of some representation of the best instances of the category.
For example, the concept CAT should coincide with a representation of a prototypical
cat. In the simpler versions of this approach, prototypes are represented as (possibly
weighted) lists of features.
According to the exemplar view, a given category is mentally represented as set of
specific exemplars explicitly stored within memory: the mental representation of the
concept CAT is the set of the representations of (some of) the cats we encountered
during our lifetime.
Theory-theories approaches adopt some form of holistic point of view about
concepts. According to some versions of the theory-theories, concepts are analogous
to theoretical terms in a scientific theory. For example, the concept CAT is
individuated by the role it plays in our mental theory of zoology. In other version of
the approach, concepts themselves are identified with micro-theories of some sort. For
example, the concept CAT should be identified with a mentally represented micro-
theory about cats.
These approaches turned out to be not mutually exclusive. Rather, they seem to
succeed in explaining different classes of cognitive phenomena, and many researchers
hold that all of them are needed to explain psychological data. In this perspective, we
propose to integrate some of them in computational representations of concepts. More
precisely, we try to combine a prototypical and an exemplar based representation in
order to account for category representation and prototypical effects (for a similar,
hybrid prototypical and exemplar based proposal, see [30]). We do not take into
consideration the theory-theory approach, since it is in some sense more vaguely
defined if compared the other two points of view. As a consequence, its

computational treatment seems at present to be less feasible.
5.3.1 Prototypes vs. Exemplars

Prototype and exemplar based approaches present significant differences. Exemplar-
based models, for example, assume that the same representations are involved in such
different tasks as categorization and identification (i.e., the recognition of a specific
instance: this is the Tower Bridge) [28]. This contrasts with the prototype models,
which assume that these cognitive processes involve different kinds of
representations. Furthermore, prototype models capture only on the cognitively
central features of a concept, while the exemplar models can represent in toto the
particular knowledge of a specific entity. For example, the prototypical representation
of the concept DOG is based on a subset of cognitively central and relevant traits
associated to dogs: e.g. they bark, they wag tail, and so on. Vice versa, the
representation of the exemplar Fido could contain such peripheral characteristics as,
for example, the information that Fido has got distemper. Another aspect of
divergence is represented by the treatment of the categorization process. In order to
solve this task, both prototype and exemplar-based models compute the degree of
similarity between a target representation on the one side, and the representation of a
prototype or of a set of exemplars on the other. The process works as follows: a
prototype/exemplar representation of a given category is retrieved from the memory
and compared with the target representation. On the basis of this comparison, the
process decides whether the object belongs to the category or not. However, despite
these similarities, important differences between the two approaches exist. According
to the prototype view, the computation of similarity is usually assumed to be linear: if
a property is shared by the target and the prototype, then the similarity between the
target and the prototype is increased, independently from the fact that other properties
are shared or not. According to the exemplar view, the computation of similarity is
assumed to be non-linear: a property shared by the target and the exemplar is relevant
and gives a contribution to the computation of similarity only if there are also other
properties that are shared between the two representations.
The dichotomy between prototype and exemplar based theories of categorization
did not emerge only in the field of psychology; rather, it has a counterpart also in such
disciplines as machine learning and automatic classification [31]. In particular, within
machine learning these two approaches have been adopted for the realization of
different classifiers: for example, the Nearest Prototype Classifier (NPC) is based on
prototypes, and the Nearest Neighbour Classifier (NNC) is based on exemplars [32].
Recently in this field different proposals of hybrid classifiers have been proposed, in
order to overcome the dichotomy between prototypes and exemplars, and to take
advantage from both approaches. In this spirit, prototypes and exemplars are not
considered as conflicting theories, but as two limit cases of the Instance Based
Learning technique used for categorization both by natural and artificial systems. In
facts, despite the differences put in evidence by the psychological literature,
prototypes and exemplars, taken together, can be considered different aspects of a
unique phenomenon: the typicality in categorization processes [23]. In our opinion,
such a hybrid approach could be fruitful to face the problem of representing typicality
within the field of formal ontologies.
References
1. DellAnna, A., Frixione, M.: On the advantage (if any) and disadvantage of the
conceptual/nonconceptual distinction for cognitive science. Minds & Machines 20, 2945
(2010)
2. Frixione, M., Lieto, A.: The computational representation of concepts in formal ontologies:
Some general considerations. In: Proc. KEOD 2010, Int. Conf. on Knowledge Engineering
and Ontology Development, Valencia, Spain, October 25-28 (2010)
3. Frixione, M., Lieto, A.: Representing concepts in artificial systems: a clash of
requirements. In: Proc. HCP 2011, pp. 7582 (2011)
4. Fodor, J.: The present status of the innateness controversy. J. Fodor, Representations
(1981)
5. Minsky, M.: A framework for representing knowledge, in Patrick Winston (a cura di), The
Psychology of Computer Vision (1975); Also in Brachman & Levesque (2005)
6. Brachman, R., Schmolze, J.G.: An overview of the KL-ONE knowledge representation
system. Cognitive Science 9, 171216 (1985)
7. Brachman, R., Levesque, H. (eds.): Readings in Knowledge Representation. Morgan
Kaufmann, Los Altos (1985)
8. Baader, F., Calvanese, D., McGuinness, D., Nardi, D., Patel-Schneider, P.: The
Description Logic Handbook: Theory, Implementations and Applications. Cambridge
University Press, Cambridge (2003)
9. Brachman, R.: I lied about the trees. The AI Magazine 3(6), 8095 (1985)
10. Gao, M., Liu, C.: Extending OWL by fuzzy Description Logic. In: Proc. 17th IEEE Int.
Conf. on Tools with Artificial Intelligence (ICTAI 2005), pp. 562567. IEEE Computer
11. Calegari, S., Ciucci, D.: Fuzzy Ontology, Fuzzy Description Logics and Fuzzy-OWL. In:
Masulli, F., Mitra, S., Pasi, G. (eds.) WILF 2007. LNCS (LNAI), vol. 4578, pp. 118126.
12. Stoilos, G., Stamou, G., Tzouvaras, V., Pan, J.Z., Horrocks, I.: Fuzzy OWL: Uncertainty
and the Semantic Web. In: Proc. Workshop on OWL: Experience and Directions (OWLED
2005). CEUR Workshop Proceedings, vol. 188 (2005)
13. Bobillo, F., Straccia, U.: An OWL Ontology for Fuzzy OWL 2. In: Rauch, J., Ra, Z.W.,
Berka, P., Elomaa, T. (eds.) ISMIS 2009. LNCS, vol. 5722, pp. 151160. Springer,
Heidelberg (2009)
14. Osherson, D.N., Smith, E.E.: On the adequacy of prototype theory as a theory of concepts.
Cognition 11, 237262 (1981)
15. Lukasiewicz, L., Straccia, U.: Managing uncertainty and vagueness in description logics
for the Semantic Web. Journal of Web Semantics 6, 291308 (2008)
16. Ding, Z., Peng, Y., Pan, R.: BayesOWL: Uncertainty modeling in Semantic Web
ontologies. In: Ma, Z. (ed.) Soft Computing in Ontologies and Semantic Web. Studies in
Fuzziness and Soft Computing, vol. 204. Springer, Heidelberg (2006)
17. Baader, F., Hollunder, B.: Embedding defaults into terminological knowledge
representation formalisms. J. Autom. Reasoning 14(1), 149180 (1995)
18. Bonatti, P.A., Lutz, C., Wolter, F.: Description logics with circumscription. In: Proc. of
KR, pp. 400410 (2006)
19. Klinov, P., Parsia, B.: Optimization and evaluation of reasoning in probabilistic description
logic: Towards a systematic approach. In: Sheth, A.P., Staab, S., Dean, M., Paolucci, M.,
Maynard, D., Finin, T., Thirunarayan, K. (eds.) ISWC 2008. LNCS, vol. 5318, pp. 213
20. Hayes, P.: Dialogue on rdf-logic. Why must the web be monotonic? (W3C). Link (2001),
http://lists.w3.org/Archives/public/www-rdf-logic/
2001Jul/0067.html
21. Stanovich, K.E., West, R.: Individual Differences in Reasoning: Implications for the
Rationality Debate? The Behavioural and Brain Sciences 23(5), 645665 (2000)
22. Evans, J.S.B.T., Frankish, K. (eds.): In Two Minds: Dual Processes and Beyond. Oxford
UP, New York (2008)
23. Murphy, G.L.: The Big Book of Concepts. The MIT Press, Cambridge (2002)
24. Margolis, E., Laurence, S. (eds.): Concepts: Core Readings. The MIT Press, Cambridge
(1999)
25. Laurence, S., Margolis, E.: Review. Concepts: where cognitive science went wrong.
British Journal for the Philosophy of Science 50(3), 487491 (1999)
26. Fodor, J.: Psychosemantics. The MIT Press/A Bradford Book, Cambridge, MA (1987)
27. Fodor, J.: Concepts: Where Cognitive Science Went Wrong. Oxford University Press,
Oxford (1998)
28. Machery, E.: Doing without Concepts. Oxford University Press, Oxford (2009)
29. Rosch, E.: Principles of categorization. In: Rosch, E., Lloyd, B. (eds.) Cognition and
Categorization, pp. 2748. Lawrence Erlbaum, Hillsdale (1978)
30. Gagliardi, F.: A Prototype-Exemplars Hybrid Cognitive Model of Phenomenon of
Typicality in Categorization: A Case Study in Biological Classification. In: Proc. 30th
Annual Conf. of the Cognitive Science Society, Austin, TX, pp. 11761181 (2008)
31. Witten, I.H., Frank, E.: Data Mining: Practical Machine Learning Tools and Techniques
with Java Implementations, 2nd edn., Kaufmann, San Francisco(2005)
32. Gagliardi, F.: The Need of an Interdisciplinary Approach based on Computational
Modelling in the Study of Categorization. In: Proc. of ICCM 2009, pp. 492493 (2009)
Unintended Consequences of Class-Based Ontological
Commitment
Roman Lukyanenko and Jeffrey Parsons
Faculty of Business Administration, Memorial University, St. Johns Canada

{roman.lukyanenko,jeffreyp}@mun.ca
Abstract. Domain ontologies can promote shared understanding of a domain

using standardized constructs to represent domain semantics. Building upon
this promise, libraries of domain-specific ontologies have been created.
However, we argue that adopting any particular domain ontology can in fact
hinder domain understanding and reduce the quality of data made available
through a shared ontology. This paper examines unintended consequences of
class-based ontological commitment and advocates instead an instance-and-
property ontological foundation. The proposed approach can better inform the
practice of information sharing and can, in participative domains, enable users
to contribute higher quality information with fewer constraints.
Keywords: Classification, Domain ontologies, Ontological commitment,

Instance-based modeling.
1 Introduction
Specific domain ontologies can offer a number of advantages in integrating and
managing data sources. Ontology is a philosophical study aimed at describing what
exists in a systematic way [1]. In a particular area of concern, a domain-specific
ontology prescribes possible constructs, rules and relationships. Thus, many consider
domain-specific ontologies as surrogates for the semantics of a domain [2].
Recently, increased attention to domain ontologies is fueled by the need to manage a
growing body of heterogeneous data sets, especially on the web [2-4]. Yet, what
appears to be a clear advantage of domain-specific ontologies the explicit
representation of domain semantics may in fact impede domain understanding and
distort the originally intended reality. This paper examines unintended consequences
of class-based ontological commitment and advocates instead an instance-and-
property ontological foundation that avoids the negative effects of class-based
ontologies and supports semantic interoperability in a broader sense.
Initially part of philosophy, ontological studies are embraced by the information
systems and computer science research based on the pragmatic goal of improving
communication between humans and machines. This focus suggests a potential
application of ontologies to the Semantic Web, which aims to move beyond syntactic
matches and support semantic interoperability [3, 5]. To achieve semantic inter-
operability, users and machines need to agree on common constructs and rules with
Unintended Consequences of Class-Based Ontological Commitment 221
which to understand and reason about domains. In the search for this common blueprint
of knowledge, domain-specific ontologies appear to offer an advantage: they contain a
structured snapshot of reality usually carefully engineered by domain experts. Thus,
ontological commitment implies an agreement between all data producers and users to
share common understanding of some domain of interest by adopting a formal set of
constructs, relationships and rules [6-7]. For example, when working within the natural
history domain, one may use the ETHAN (Evolutionary Trees and Natural History)
ontology [8-9]. ETHAN draws upon a combination of Linnaean taxonomy and
phylogenetic information to construct a set of classes and properties that form a
hierarchical tree of life. This ontology can be used to discover, integrate, store and
analyze ecological information for a variety of purposes [8].
While ontologies have the potential to facilitate semantically-enhanced information
transfer, we argue that the prevailing practice of imposing ontological structure on a
domain can impede domain understanding and result in information loss. In
particular, many ontologies have adopted RDF-compliant (the Resource Description
Framework) class-structure [see 4], in which individual information resource
instances are recorded as members of a priori-defined classes. Classes (which are
similar to categories, entity sets, kinds) are typically modelled as sets of
attributes/properties that ideally support inferences beyond properties required to
establish class membership [see 10]. Thus, class-based ontological commitment is a
requirement to express an ontology in terms of classes of phenomena and the
relationships among them. We further argue that class-based ontological commitment
causes loss of potentially valuable properties of the phenomena, thereby impeding
domain understanding and semantic interoperability. In contrast, we suggest an
instance-based ontological model that does not require classifying individual
resources. Instead, each autonomous unit of information (instance) can be described
in terms of attributes and the resulting attribute sets can be used to create classes of
interest based on ad-hoc utility. This approach is based on the instance-based data
model proposed by Parsons and Wand in the context of database design [see 11].
The remainder of the paper is organized as follows. The next section provides a
review of relevant ontological literature. Then we discuss theoretical foundation of
the new approach and offer a case study to illustrate specific deficiencies of the class-
based ontologies. The paper concludes with a discussion on the instance-based
ontological foundation and an outlook to the future.
2 Ontological Research in IS
The premise that ontologies can streamline knowledge engineering and improve
information transfer is being actively explored in the information systems and computer
science literature [12]. Much of the research focuses on domain-specific ontologies,
which typically act as content theories and describe classes, properties and relations for
a particular domain [see 6, 13]. In that sense, [o]ntologies are often equated
with taxonomic hierarchies of classes [14, p. 172]. Many class-based libraries of
domain-specific ontologies have been created on the Internet (e.g. the Protg Ontology
Library, http://protegewiki.stanford.edu/wiki/Protege_Ontology_Library;DAML, http://
www.daml.org/ontologies/). The relative success of ontologies in a number of
222 R. Lukyanenko and J. Parsons
application areas has led to a further rapid development of domain-specific ontologies,

creating an additional challenge of managing ontologies themselves [e.g. 15]. Much of
the current research has been dedicated to issues of integration [16], visualization,
evaluation [17-18], and improved use of domain-specific ontologies [8, 15, 19]. With
the increase in number of ontologies, the question of the impact of ontological
commitment to a specific ontology becomes important.
In contrast, general ontologies such as that of Bunge [20] or Sowa [21] have been
used to derive fundamental principles of systems analysis and domain modelling [13,
22-23], data quality [24-25], and database design [26].
While ontology development appears to be a prominent research subject, relatively
little attention has been paid to the impact of domain-specific ontologies on quality of
information in ontology-based information systems. Intuitively, both the choice of
ontology and specific constructs within the chosen one should have observable
implications. Thus, Orme et al.[18] warn: [o]ntology-specific information may be a
limiting factor in the development of future applications unless ontology data are
prepared correctly (p. 50). Burton-Jones et al. [17] used semiotic theory (study of
signs) to derive a suite of ontological quality metrics, such as lawfulness (correctness
of syntax), richness (breadth of syntax), comprehensiveness, accuracy, relevance,
semantic and social quality [for a full list see 2]. The comprehensiveness dimension
has been related to the number of classes and properties described by an ontology:
[l]arger ontologies are more likely to be complete representations of their domains,
and provide more knowledge to the agent [2, p. 92].
Wand and Weber have been concerned with developing fundamental principles of
optimal mapping between real-world phenomena and ontology [23, 27-28]. In
particular, they have examined the notion of expressive power and identified
construct overload, construct redundancy, and construct excess as factors that
diminish ontological expressiveness [27]. Here, we attempt to extend the general
argument in [23, 27-28] and examine consequences of the class-based ontological
models.
2 Consequences of Class-Based Ontological Commitment

Classification is a fundamental activity in which humans engage to manage the
perceptual complexity of real-world phenomena. As Raven et al. [29] declared: [m]an
is by nature a classifying animal. As information systems are representations of a
perceived real world, information sciences embraced the natural human tendency to
organize reality into classes as an important part of domain modelling. Since ontologies
are also viewed as semantic surrogates of reality, it appeared natural to model
ontological reality in terms of classes. For example, Decker et al. [4] define RDF
objects as instances of one or more classes using the type property (pp. 66-67).
Chandrasekaran et al.[12] claim identification of specific classes of objects and
relations that exist in some domain to be the main contribution of ontologies (p. 21).
To classify is to abstract from the diversity of the world by focusing on properties
that satisfy some utility [10, 30]. Humans need to categorize to manage the large
volume of information to which they are exposed on an ongoing basis [see, for
example, 31, p.11]. The principle of reducing cognitive load suggests that humans
would prefer to use as few categories as possible. From the cognitive load point of
view, the best categories are the most inclusive ones [32-33]. Yet, little useful
information can be inferred by classifying objects into general categories such as
object or living being, except that that they indicate some existence. As a result,
humans need to consider categories at finer levels of specificity. As categories
become conceptually smaller and include fewer individuals, they gain inferential
power. This can be explained using probability theory [e.g. 33]. Since there are fewer
birds than there are objects, a certain bird property has a greater chance of occurring
in a smaller category (e.g. birds) than in the more inclusive category (e.g. objects).
Once an individual is identified as an instance of a category, it is easier (with greater
probability) to infer additional (unobserved) properties for a smaller category [30].
Yet, since there are more smaller categories (e.g. duck) than inclusive ones (e.g.
object), maintaining them requires additional resources.
In the case of both humans and machines, classification means that certain
properties that are not of immediate interest are ignored. Herein is a fundamental
difference between human and computerized representations of reality. When humans
classify, they focus on relevant features but remain aware of other ones (e.g., they can
recall other features of an instance that are not associated with a particular category of
interest). Recent research shows that humans can hold a massive amount of details
for a long time without instructions to maintain any specific information [34]. This
information can be stored subconsciously and invoked in response to certain triggers.
While humans use a certain classification of the world, they remain aware of other
potential alternatives or accept them with new experiences. For example, in William
Blakes poem The Tyger a vivid picture of a dangerous predator is depicted. Survival
instincts cause humans to categorize large wild animals as dangerous. Yet, this does
not preclude us from considering Aunt Jennifer's Tigers by Adrienne Rich as symbols
of freedom and chivalry and wishing we could be prancing alongside them. Thus, in
the domain of poetry, the same class of tigers can have different properties of interest
in the mind of a poetry reader. As humans engage with their environment, they
continuously revise and adjust their class definitions. In contrast, strict adherence to a
predefined class structure means only individuals possessing a certain set of
properties will be permitted to be classified as members of a particular class. Thus, if
an ontology that defines tiger as dangerous needs to integrate an instance that is
characterized as meek, it may either reject classification, or ignore the meek property
and assume the dangerous one in the process of data integration. It can also lead to a
lower probability of class membership in those approaches that treat class boundaries
as fuzzy.
Proposition. Domain understanding is necessarily reduced every time a class is used
to conceptually represent instances.
The assumption of the class-based approach to data modeling is that individual
instances are always members of some (usually one) a priori defined class. Yet, since
many classes can be used to represent the same phenomena, it is unclear which class
is better. Choosing the wrong one means that the information stored will be
deficient with respect to perceived reality. Parsons and Wand proposed cognitive
guidelines for choosing classes that could be used for reasoning about classification,
and their violation indicates something is lost from a cognitive point of view
[30, p. 69; emphasis added]. Extending this idea further, we claim that using classes
to represent instances will always fail to fully capture reality, no matter how good
the chosen class is. Simply, no class is good enough to fully represent an individual
and whenever an attempt is made to do so, properties not defined by a class are
neglected or lost.
Proposition: An instance can never be fully represented by a class.
Any object has a potentially large number of features and no one class can capture
them all. The same object can belong to many classes, which means that individual
objects exist independent of any given classification. The relationship between
individuals and classes is well depicted in Bunges ontology [20, 23]. According to
Bunge the world is made of distinct things and things are characterized by their
properties. Humans perceive properties indirectly as attributes and classes can be
formed by grouping properties together.
Each instance is different from all others in some ways. As Bunge puts is, there
are no two identical entities [20]. Even the atoms and particles of the same element
are in some sense different because no two things can occupy the same state at the
same time [20]. In fact, on the basis of individual differences it is possible to
construct as many new classes as there are differences.
Typically, however, classes are formed based on the commonality of instances, not
their differences. Nevertheless, this does not preclude humans from considering, if
necessary, properties that are not part of the classification schema. For example, when
professors think about own students each student retains a plethora of individual
features. Some students may require more attention than others. The distribution of
attention for each student may also change over time. In contrast, a university domain
ontology typically defines a Student class using the same set of properties. Thus,
while humans are capable of both reasoning about similarity and difference, class-
based ontologies emphasize commonalities only. An important element of reality
individual differences is consistently neglected. Rigid classification-based
ontologies routinely miss potentially valuable instance-specific information.
Finally, human categorization is a dynamic process, during the course of which
class schemas may change. As shown from the discussion of the poetry domain,
humans can uncover new features of familiar classes with additional experience [35].
Yet, as emphasized by Uschold and Gruninger semantic interoperability demands
standardization [6]. This requires ontologies to have persistent and stable schemas.
Thus, Uschold and Gruninger introduce the concept of reusability, defined as the
formal encoding of important entities, attributes, processes and their inter-
relationships in the domain of interest [6, p.3]. Thus, storing instances in terms of
predefined classes makes it difficult to dynamically include new properties into class
definitions.
The implications of class-based ontologies are illustrated next using a simple case
study.
2.1 Case Study: Travel Ontology
To illustrate the implications of class-based ontological commitment, we use an

example of fictitious travel ontology (see Fig. 1). A number of travel ontologies have
been explored in information systems and computer science literature and the one
presented uses typical travel ontology constructs [36-38].
For simplicity, the proposed ontology consists of four classes: traveler, agent, trip
and supervisor, each with a set of properties. For example, the class definition of
traveler mean that any individual members of that class will be expected to have
corresponding properties customer id, name, passport no, nationality, date of birth,
email, password. It is possible that some values of the properties will be missing, but
in order to qualify as a traveler, a certain number of values known must be present.
Similarly, the class travel agent contains those properties that best describe agency
employees who assist customers in booking and management of trips (agent id, name,
supervisor id, date hired, email).
Each class has its own unique relations to other classes. For example, traveler
can request information about or take a trip. At the same time, an agent assists with
trip booking and maintains trips. Travelers may not have direct relationships with
agencys supervisors, while each agent reports to a particular supervisor. In each case
a class defines the set of intuitive and lawful relations with other constructs.
The presented ontology can be used to guide distributed application development
and automatically integrate data from multiple local agencies into a global one.
Traveler Trip
Customer ID takes Trip ID Creates,
Name Trip Cost Manages
Passport No Description
Nationality
DOB books
Email Supervisor
Password Agent reports to
Supervisor ID
Agent ID Name
Name Password
Supervisor ID Date Hired
Date Hired
Email
Fig. 1. Hypothetical travel agency ontology
Close examination of the travel ontology presented in Fig. 1 raises a number of

issues related to information transfer and domain understanding. In each case where a
class is defined, some information is lost. Consider the class traveler: the schema that
defines the class is focused on the most pertinent characteristics of typical tourists.
By the cognitive principles discussed above, it is unreasonable to load traveler class
with attributes that go beyond its natural scope. In other words properties such as
hobbies, pet preferences, education level, and favorite store may not describe traveler
class well. Most data sources dealing with tourism may not have values for such
properties. In fact, restricting the scope seems reasonable in order to maintain the
domain-specific focus.
Yet each time the scope is restricted, opportunities to collect potentially valuable
business data are missed. Some of the additional properties can be valuable to identify
business opportunities and offer a personalized customer experience. For example,

while choosing the trips, we may consider that one of the travelers is afraid of heights
and exclude CN Tower (Toronto, Canada) from the itinerary.
One can argue that some of the individuality can be accommodated using general
description in addition to the record, but general descriptions (e.g. comments fields)
are difficult to analyze and compare, especially in large datasets. This means that the
itinerary of the person who is afraid of heights cannot be automatically suggested for
a similar traveler at a later time. Thus, in addition to properties, valuable semantic
relations between individual records are potentially lost in class-based ontological
models.
No individual customer can be described using only the attributes of the traveler
class. In fact, it is entirely possible for an agent to use corporate discount and book a
trip with the agency he/she works for. This will make the same individual a traveler
and an agent at the same time. The information about the same individual will have to
be maintained in two or more places. This is known as proliferation of operations and
has been described by Parsons and Wand in the context of databases [26].
Proliferation of operations is inherent in class-based models of reality because
individuals can be described a potentially large number of classes. Yet, this is not
merely an issue of multiple classification support, but rather a broader difficulty of
accommodating individual differences using a deductive approach of a priori
classification. Any new person walking into a travel agency will differ from the
previous one in some way. Thus, using some predefined filter innately restricts ability
to reason about unique properties of an instance.
As seen from this example, a classification-based ontology necessarily leads to loss
of valuable information and thereby undermines domain understanding and semantic
interoperability.
3 Discussion and Conclusion

In this paper we offered a theoretical discussion on the implications of class-based
domain ontologies. We motivated the research by the need to achieve better domain
understanding, while maintaining semantic interoperability. From the discussion
above, it is clear that information loss is inherent in any class-based ontology. At the
same time, an argument can be made that the benefits offered by class-based
ontologies may compensate for the data deficiencies. To address this argument, we
advocate an instance-and-property ontological foundation, which avoids the negative
effects of class-based ontologies while supporting semantic interoperability in a
broader sense.
The instance-and-property ontological model draws upon Bunges ontology and
cognitive theories. Instead of creating a predefined set of classes, the focus of domain-
specific ontologies should be concerned with capturing individual instances of
information and any properties that may describe them. For example, in the travel
ontology a particular person is a unique instance. This person can be both a travel
agent and a passenger. The instance can also exist without being classified. For
example, an anonymous visitor to an online travel agency will not be qualified as a
customer, but a web log of a site visit indicates an existence of something. We may
already know something about this visitor, which may be of potential business use:
we may be interested in his/her IP address, click stream patterns [39], viewing time
[40], or comments he/she left on a website. Once several attributes are recorded, the
system can match them with pre-existing sets of identifying attributes for a
phenomena (such as a class of interest), and either infer a class or seek additional
attributes that could also be automatically deduced from those previously supplied.
The final attribute set can potentially match to a class (e.g. customer), or integrate
instances without classifying them. Doing so avoids inherent data quality deficiencies
of the class-based models. By shifting the focus from classification to identification of
instances and properties, fuller and semantically richer information about domains can
be collected without imposing a particular view and biasing the results.
The instance-based approach can also address the problem of representing
temporary changing information. For example, an individuals properties may change
overtime. Class membership, thus, becomes more dynamic and evolves with the
changing properties.
Instance-and-property ontologies can accommodate the growing semantic diversity
of the web. Discretionary data input is growing and increasingly large numbers of
websites generate content from direct user input. This is the premise behind the
practice of crowdsourcing, the volunteer participation of regular users in purpose-
driven projects online [41]. One type of crowdsourcing is citizen science. Online
citizen science projects, such as eBird (ebird.org) or iSpot (ispot.org.uk), attempt to
capture valuable insights of regular people to be used in academic research. It is
clearly difficult to a priori anticipate what kind of information non-experts can
provide, and creating unnecessary constraints can undermine potential gains from
such projects. Moreover, amateur observers are often unable to provide information in
compliance with the constructs and relations of a given ontology, especially if it is
based on scientific taxonomy (e.g. ETHAN). Being able to give voice to every citizen
of the Internet and easily manage that data is an emerging frontier of the web of the
future.
References
1. Lacey, A.R.: A dictionary of philosophy. Routledge, New York (1996)
2. Burton-Jones, A., Storey, V.C., Sugumaran, V., Ahluwalia, P.: A semiotic metrics suite for
assessing the quality of ontologies. Data & Knowledge Engineering 55, 84102 (2005)
3. Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American
Magazine, 2837 (2001)
4. Decker, S., Melnik, S., van Harmelen, F., Fensel, D., Klein, M., Broekstra, J., Erdmann,
M., Horrocks, I.: The Semantic Web: the roles of XML and RDF. IEEE Internet
Computing 4, 6373 (2000)
5. Guizzardi, G.: Theoretical foundations and engineering tools for building ontologies as
reference conceptual models. In: Semantic Web, pp. 310 (2010)
6. Uschold, M., Gruninger, M.: Ontologies: principles, methods, and applications.
Knowledge Engineering Review 11, 93155 (1996)
7. Gruber, T.R.: A translation approach to portable ontology specifications. Knowl.
Acquis. 5, 199220 (1993)
8. Parafiynyk, A., Parr, C., Sachs, J., Finin, T.: Proceedings of the Workshop on Semantic
e-Science. In: AAAI 2007 (2007)
9. Parr, C., Sachs, J., Parafiynyk, A., Wang, T., Espinosa, R., Finin, T.: ETHAN: the
Evolutionary Trees and Natural History Ontology. Computer Science and Electrical
Engineering. University of Maryland, Baltimore County (2006)
10. Parsons, J., Wand, Y.: Using cognitive principles to guide classification in information
systems modeling. Mis Quart. 32, 839868 (2008)
11. Parsons, J., Wand, Y.: Emancipating instances from the tyranny of classes in information
modeling. ACM Transactions on Database Systems 25, 228268 (2000)
12. Chandrasekaran, B., Josephson, J.R., Benjamins, V.R.: What Are Ontologies, and Why Do
We Need Them? IEEE Intelligent Systems 14, 2026 (1999)
13. Evermann, J., Wand, Y.: Ontology based object-oriented domain modelling: fundamental
concepts. Requir. Eng. 10, 146160 (2005)
14. Hansen, P.K., Mabogunje, A., Eris, O., Leifer, L.: The product develoment process
ontology creating a learning research community. In: Culley, S., WDK, W.D.-.-K. (ed.)
Design Management: Process and Information Issues. Professional Engineering for The
Institution of Mechanical Engineers, pp. 171186 (2001)
15. Smith, B., Ashburner, M., Rosse, C., Bard, J., Bug, W., Ceusters, W., Goldberg, L.J.,
Eilbeck, K., Ireland, A., Mungall, C.J., Leontis, N., Rocca-Serra, P., Ruttenberg, A.,
Sansone, S.-A., Scheuermann, R.H., Shah, N., Whetzel, P.L., Lewis, S.: The OBO
Foundry: coordinated evolution of ontologies to support biomedical data integration. Nat.
Biotech. 25, 12511255 (2007)
16. Kalfoglou, Y., Schorlemmer, M.: Ontology mapping: the state of the art. Knowl. Eng.
Rev. 18, 131 (2003)
17. Burton-Jones, A., Wand, Y., Weber, R.: Guidelines for Empirical Evaluations of
Conceptual Modeling Grammars. J. Assoc. Inf. Syst. 10, 495532 (2009)
18. Orme, A.M., Haining, Y., Etzkorn, L.H.: Indicating ontology data quality, stability, and
completeness throughout ontology evolution. Journal of Software Maintenance &
Evolution: Research & Practice 19, 4975 (2007)
19. Beck, T., Morgan, H., Blake, A., Wells, S., Hancock, J.M., Mallon, A.-M.: Practical
application of ontologies to annotate and analyse large scale raw mouse phenotype data.
BMC Bioinformatics 10, 19 (2009)
20. Bunge, M.A.: The furniture of the world. Reidel, Dordrecht (1977)
21. Sowa, J.F.: Knowledge representation: logical, philosophical, and computational
foundations. Brooks/Cole, Pacific Grove (2000)
22. Parsons, J., Wand, Y.: Using objects for systems analysis. Commun. ACM 40, 104110
(1997)
23. Wand, Y., Weber, R.: An Ontological Model of an Information-System. IEEE T. Software
Eng. 16, 12821292 (1990)
24. Wand, Y., Wang, R.Y.: Anchoring data quality dimensions in ontological foundations.
Commun. ACM 39, 8695 (1996)
25. Wand, Y., Monarchi, D.E., Parsons, J., Woo, C.C.: Theoretical Foundations for
Conceptual Modeling in Information-Systems Development. Decis. Support Syst. 15, 285
304 (1995)
26. Parsons, J., Wand, Y.: Emancipating Instances from the Tyranny of Classes in Information
Modeling. ACM Transactions on Database Systems 25, 228 (2000)
27. Wand, Y., Weber, R.: On the ontological expressiveness of information systems analysis
and design grammars. Inform. Syst. J. 3, 217237 (1993)
28. Wand, Y., Weber, R.: An Ontological Evaluation of Systems-Analysis and Design
Methods. Information System Concepts: An in-Depth Analysis 357, 79107 (1989)
29. Raven, P.H., Berlin, B., Breedlove, D.E.: The Origins of Taxonomy. Science 174, 1210
1213 (1971)
30. Parsons, J., Wand, Y.: Choosing classes in conceptual modeling. Commun. ACM 40, 63
69 (1997)
31. Markman, E.M.: Categorization and Naming in Children: Problems of Induction. MIT
Press, Cambridge (1991)
32. Murphy, G.L.: Cue validity and levels of categorization. Psychological Bulletin 91, 174
177 (1982)
33. Corter, J., Gluck, M.: Explaining basic categories: Feature predictability and information.
Psychological Bulletin 111, 291303 (1992)
34. Brady, T.F., Konkle, T., Alvarez, G.A., Oliva, A.: Visual long-term memory has a massive
storage capacity for object details. PNAS Proceedings of the National Academy of
Sciences of the United States of America 105, 1432514329 (2008)
35. Anderson, J.R.: The Adaptive Nature of Human Categorization. Psychol. Rev. 98, 409
429 (1991)
36. Vukmirovic, M., Szymczak, M., Ganzha, M., Paprzycki, M.: Utilizing ontologies in an
agent-based airline ticket auctioning system. In: 28th International Conference on
Information Technology Interfaces, Croatia, pp. 385390 (2006)
37. Chang, C., Miyoung, C., Eui-young, K., Pankoo, K.: Travel Ontology for
Recommendation System based on Semantic Web. In: The 8th International Conference on
Advanced Communication Technology, ICACT 2006, vol. 1, pp. 624627 (2006)
38. Gong, H., Guo, J., Yu, Z., Zhang, Y., Xue, Z.: Research on the Building and Reasoning of
Travel Ontology. In: Proceedings of the 2008 International Symposium on Intelligent
Information Technology Application Workshops, pp. 9497. IEEE Computer Society, Los
Alamitos (2008)
39. Park, J., Chung, H.: Consumers travel website transferring behaviour: analysis using
clickstream data-time, frequency, and spending. Service Industries Journal 29, 14511463
(2009)
40. Parsons, J., Ralph, P., Gallagher, K.: Using Viewing Time to Infer User Preference in
Recommender Systems. In: Proceedings of the AAAI Workshop on Semantic Web
Personalization held in conjunction with the 9th National Conference on Artificial
Intelligence (AAAI 2004), pp. 5263 (2004)
41. Doan, A., Ramakrishnan, R., Halevy, A.Y.: Crowdsourcing systems on the World-Wide
Web. Commun. ACM 54, 8696 (2011)
Preface to SeCoGIS 2011
This volume contains the papers presented at SeCoGIS 2011, the Fifth Inter-
national Workshop on Semantic and Conceptual Issues in GIS, held the 1st of
November in Brussels, Belgium.
Current information technologies have increased the production, collection,
and diusion of geographical and temporal data, thus favoring the design and
development of geographic information systems (GIS) and more generally speak-
ing spatio-temporal information systems (STIS). Nowadays, GISs are emerging
as a common information infrastructure, which penetrate into more and more
aspects of our society. This has given rise to new methodological and data en-
gineering challenges in order to accommodate new users requirements for new
applications. Conceptual and semantic modeling are ideal candidates to con-
tribute to the development of the next generation of GIS solutions. They allow
eliciting and capturing user requirements as well as the semantics of a wide
domain of applications.
The SeCoGIS workshop brings together researchers, developers, users, and
practitioners carrying out research and development in geographic information
systems. The aim is to stimulate discussions on the integration of conceptual
modeling and semantics into current geographic information systems, and how
this will benet the end users. The workshop provides a forum for original re-
search contributions and practical experiences of conceptual modeling and se-
mantic web technologies for GIS, fostering interdisciplinary discussions in all
aspects of these two elds, and will highlight future trends in this area. The
workshop is organized in a way to highly stimulate interaction amongst the
participants.
This edition of the workshop attracted papers from 15 dierent countries dis-
tributed all over the world: Brazil, Argentina, Chile, USA, Canada, France, Italy,
Spain, Germany, Belgium, The Netherlands, Austria, Macedonia FYROM, Mo-
rocco, and New-Zealand. We received 19 papers from which the Program Com-
mittee selected 6 papers, making an acceptance rate of 32 percent. The accepted
papers cover a wide range of issues, in particular consistency and integration,
rened spatial relationships and conceptual model transformation rules.
We hope that you nd the program and presentations benecial and enjoyable
and that during the workshop you had many opportunities to meet colleagues
and practitioners. We would like to express our gratitude to the program commit-
tee members and the external referees for their hard work in reviewing papers,
the authors for submitting their papers, and the ER 2011 organizing committee
for all their support.
July, 2011 Esteban Zimanyi

Roland Billen
Pierre Hallot

Referring Expressions in Location Based Services:
The Case of the Opposite Relation
Phil Bartie1, Femke Reitsma1, Eliseo Clementini2, and Simon Kingham1

1
Geography Department, University of Canterbury, Christchurch, New Zealand
2
Department of Electrical and Information Engineering, University of L'Aquila, LAquila, Italy
Abstract. Mobile devices and location based services enable digital and real
worlds to be integrated within our daily lives. The handling of natural language
dialogue raises several research challenges, including the ability to direct the
users attention to a particular feature in the field of view through the use of
suitable descriptions. To mimic natural language these referring expressions
should use attributes which include factors of the buildings appearance, and
descriptions of its location with reference to the observer or other known
buildings in view. This research focuses on one particular positional case used
in describing features in a field of view, that of the opposite spatial relation,
and discusses how this referring expression may be generated by modelling the
view from the observers location to the surrounding features.
Keywords: location based services, visibility modelling, spatial relations.
1 Introduction
Increasingly, digital and real worlds are becoming integrated within our daily lives,
with mobile devices and location based services being among the tools that enable
this to happen. One of the drawbacks has been that graphical interfaces distract the
user from their environment, and alternative interaction experiences are being
researched. Augmented Reality [1, 2] is one such innovation whereby digital
information is superimposed onto real world views. Speech interfaces are another
solution, whereby information may be retrieved using voice commands and speech
prompts [3, 4]. The work presented here discusses how speech interfaces may
reference items in the current view using natural language terms, with particular focus
on the use of the spatial preposition opposite as in were the house opposite the
bakery.
People use language to describe and share experiences about space and the objects
which occupy it [5]. These object descriptions are known in natural language research
as referring expressions and are used, for example, to draw someones attention to a
particular building in a cityscape [6]. Typically, the descriptions include a number of
physical attributes relating to the feature, such as its position relative to the observer
or other surrounding objects, so that the listener may identify the intended target. The
research area has particular relevance for the future of speech based interfaces for
Location Based Services (LBS), in both the generation of phrases to direct the users
232 P. Bartie et al.
attention, and in the parsing of phrases to determine which object is being

interrogated.
This paper discusses the positional case of opposite, and how a LBS may make use
of the term when forming referring expressions. To be able to define the case whereby
two buildings are considered opposite, the visibility from the observer to each building
needs to be determined, as does the view of a common reference point between the two
target buildings, for example a road. A model is proposed which makes use of an urban
Digital Surface Model (DSM) to estimate visibility, along with a number of examples of
how the term may be calculated and used when generating spatial descriptions.
Consideration is also given to the relations with surrounding entities to find the most
suitable reference candidates, and minimise the risk of confusion in cluttered
environments. Two models are presented which may be used to determine opposite
entities with respect to a linear feature and a regional feature. The research shows that
linear feature cases may be more easily modelled than regional cases.
2 Background
The range of LBS applications has diversified from basic navigational support into
areas of social networking and virtual city guides [4, 7]. User interfaces have tended
to have a graphical focus, but mobile speech recognition tools are improving to the
point where devices in the near future may incorporate a speech based mode allowing
users to operate in a hands-free and eyes-free way discretely, without the need to re-
focus attention from their environment [8]. Earlier research has shown that users are
able to carry out multiple tasks more easily if they are using a number of sensory
modalities [9].
System usability is very important for the success of LBS applications, and great
efforts are made to reduce the seam between the application and the user by closely
modelling the users viewpoint [10]. The ultimate goal would be for an LBS to pass
the spatial Turing test [11], whereby its instructions are indistinguishable from those
generated by a human. Steps towards this goal require that the LBS filter and translate
digital information into appropriate forms which match the users frame of reference
[12, 13].
2.1 Positional Information
The position of any feature in the urban landscape can be described relative to the
observer, or a secondary reference object. Relations are rarely described in metric
space (e.g. 123.7m at 54 degrees) but instead usually refer to topological space [14,
15] or projective space [16]. For example a paddling pool may be described as being
inside the park using a topological relations, or in front of the swings using a
projective relations. Equally a house may be described as on your left by
referencing the view experienced by an observer at a given location and orientation.
The topological relations between static features are permanent, which in urban
areas may include containment within a region (e.g. in a park), topographic feature
(e.g. on a hill, a slope, or in a valley), or adjacency to a linear feature (e.g. road, river,
rail). In contrast, projective relations are ternary comparisons between the primary
Referring Expressions in Location Based Services: The Case of the Opposite Relation 233
object, a reference object, and the observer [17]. This means that they are dynamic as
the users viewpoint is considered in each relations, therefore an ability to model
which Features of Interest (FOI) are in view is required to ensure only visible items
are referenced.
Fig. 1. Visual Exposure in Urban Environments
2.2 Visibility Modelling
Most Geographic Information Systems (GIS) offer the functionality to carry out
visibility modelling [18], with a catalogue of research including siting radio masts
[19], locating the most scenic or most hidden routes [20], landscape planning [21], as
a weapon surrogate in military exercises [22], and in examining spatial openness in
built environments [23].
Studies in the urban landscape have tended to be based on isovists [24], using in
particular Benedikts [25] interpretation and definitions. Essentially isovists describe
the space which is visible from a vantage point considering the form of the built
environment through the use of architectural plans which denote the building footprint
and position. However this model ignores building height, the topography of the land
surface, and the continuation of the lines of sight beyond the first intersection with a
building footprint. Therefore isovists depict lines which when traversed from the
vantage point offer a continuous view of the target, and disregard more distant
features.
Recently, 3D isovists [26] and visual exposure models [27, 28] using DSMs built
from LiDAR sources have been introduced for urban visibility modelling. These
DSMs include building and topographical form and may be used to determine how
much of a feature can be viewed from the surrounding space, enabling the creation of
surfaces to show in which direction an observer would need to move to view the
target more, or less, clearly. These techniques can be used to find visual corridors, or
visual ridges, and form a useful basis for considering feature visibility in the context
of LBS. The urban visual exposure model calculates the vertical extents visible for
each building cell of the DSM, by calculating the lowest visible point on the faade
from the intersection of foreground objects, as shown in Fig. 1.
From this the visible faade area, and the percentage of a feature on the skyline
may be deduced, along with other metrics. Once the model is able to determine which
features are visible, it is possible to then relate these to construct the positional part of
a referring expression. To translate the positional information into the users frame of
reference requires an egocentric projective spatial model as discussed in the next
section.
Fig. 2. A combined model of space using relative and intrinsic frames of reference
2.3 Egocentric Spatial Model
Natural language terminology relates space according to the observers frame of

reference, or that of other features in view. This involves turning the relations from
metric space into projective space using terms such as left of, right of, before,
after and between as presented by the 5-intersection model [16]. In addition a
quaternary projective relation model is required to include terms for above, below,
and coplanar [29].
Fig. 2 shows a combined model which uses these projective models for the space
in front of an observer, and a simplified intrinsic frame of reference for items behind
the user [30]. For two items to be considered opposite one another reference is
inferred to a common central space, or object. For example, the library is opposite
the park determines that from some viewing point both the library and park are
visible and facing towards each other from a common central region. The following
section explores these concepts of the inter-relationship between visibility and
projective relations with respect to the opposite relation.
3 The Opposite Relation

The spatial relation opposite is defined in Merriam-Websters dictionary as, set
over against something that is at the other end or side of an intervening line or
space [31]. Hence the interrelated visibility of three related physical entities are
required, such as the library, park and street of the previous example. For this reason
visual exposure modelling is required to report which objects may be used in the
relation. Two cases are examined here, firstly where the entity is represented as a one-
dimensional feature, such as a road or river, and secondly where it is represented as a
two-dimensional region, such as a park.
Fig. 3. The 'Opposite' Case for a Common Linear Feature
3.1 One-Dimensional Common Feature
The relation conveyed in the phrase the library is opposite the park, can be broken
down into the library is left of the road and the park is right of the road from a
viewpoint on the road. However this does not signify that the two objects are
opposite each other unless both are perceived to occur at similar positions along the
road. Consider Fig. 3 which shows a situation where a number of buildings surround a
park, and the observer is located on a road at Point 1. From this viewpoint the
observer is able to see Buildings A,B,C, and the upper part of D above hedges, but not
Buildings E, F and G which are out of view and therefore not included in any
referring expressions. When the observer faces Building C, it is valid to report that
both Buildings C and B are opposite the park. Here the term with reference to the
road is left out but inferred, and the phrase is equivalent to Building C is on the
other side of the road from the park. However, it would not be appropriate to define
Building A as opposite the park, as the two features do not share a similar location
along the linear road feature, yet the phrase opposite side of the road is still true.
The segments of the road labelled A1-A2, B1-B2 indicate the start and end of the
entity along the roads length, computed at the first and last intersections of a line
perpendicular to the direction of travel with the entity. To satisfy the opposite
condition the following must apply:
the observer must be able to view both entities from a single point (e.g., C and
Park);
the entities must occur at overlapping sections of the linear entity (e.g., C1-C2 and
P1-P2);
the observer must also be able to view the common linear entity in the overlap
region (e.g., road);
the entities must occupy beside left/right space when viewed from the overlapping
region.
Table 1. Calculating the Opposite relation for Entities and the Park from Observer Point 1
Entity Visible Overlap View Common Beside Result

Overlap Left/Right
A True False True True False
B True True True True True
C True True True True True
D True True False True False
E False False False False False
F False False False False False
G False False False True False
Following these rules Table 1 may be generated, indicating that B and C are
opposite the park when viewed from Point 1. Although part of D is visible above
hedges, the section of roadway between the building and the park is out of view
behind bushes, rendering the use of opposite as less appropriate to assist the users
visual search from the current location. However, the term could be used if
instructions considered the case as the user approaches, such as when you get to
Point 2 youll see D opposite the park.
When multiple features satisfy the opposite relation further consideration is
necessary to establish which would form the most suitable candidate. So from Point 2
buildings E, F and G come into view and may be considered as candidates for
describing the location of building D. A function is required to establish which of
these is most suitable, requiring knowledge of the candidates and consideration of the
overlap extent. In this case the overlap between D and E is minimal, and although F
has a larger overlap it would still make more sense to describe D as opposite the
Park, as these features share the greatest overlap and the Park is a very recognisable
feature.
As a further example, when the observer is at Point 2 looking for building G then
the park can no longer be considered opposite, however either building E or F could
be used. Factors including the saliency of the building, its visibility, distance from the
target, and the number of items between each should be considered. Assuming the
visibility of both E and F were high (clear views) then E would form the most logical
choice as it is the first item viewed from the roadside and most readily identifiable.
However if F was a visually prominent landmark, such as a church, then it would take
precedence despite being further from the target as its saliency allows it to form a
more useful descriptor.
Saliency is a measure of the prominence of a feature in the neighbourhood, and
there are methods to quantify such distinctiveness [32, 33]. Typically factors
including visual appearance and semantic interest are considered by comparing items
in the neighbourhood to establish the most easily recognisable and rare features. It is
of particular importance in choosing candidates for forming referring expressions, as
when targeting a building by describing it as opposite a tree it may be logically true,
but worthless if the entire street is filled with trees and all houses are opposite a tree.
Therefore, when constructing a referring expression, the number of other entities
which share a similar relation need to be considered, to minimise the confusion
caused by the statement.
Fuzzy classes may be used to establish the most attractive entity in an opposite
relation, by considering all alternatives and awarding class memberships between 0
and 1 according to a number of factors. The weighting between factors may be
adjusted according to the current task, for example car drivers may favour number of
items between as scanning opportunities are more limited while driving, whereas
pedestrians may favour saliency as they have more freedom to view the surroundings
and wish to locate the most prominent landmarks in a wider field of view.
Most suitable entity = f (V,S,N,D,O), where:
V visibility (degree of visibility of all items from a single observation point)
S saliency (prominent, minimise confusability)
N number of items between (measure of separation by entity count)
D distance apart (close items preferred)
O degree of overlap
A slightly modified set of rules are necessary when considering two-dimensional
common features as discussed next.
3.2 Two-Dimensional Common Features
For linear common features the entity overlaps, used to identify whether features are
opposite, were determined by considering the first and last intersections of a line
perpendicular to the linear feature with each entity (as shown in Fig. 3, e.g., A1-A2).
In cases where the common feature is a region, an alternative rule is required to
determine overlap, and consequently opposition.
When the observer occupies a space inside the common region, for example
standing in a square, then two features may be described as opposite one another by
considering the observer as a central point with a feature occupying the in front space,
and one in behind space. As an example, if the observer looks towards feature A as
shown in Fig. 4(i), then B can be classed as in the opposite direction, according to the
in front/behind relation outlined in Fig. 2. However, if the observer is outside of the
common region then the relations may be calculated according to a division of space
based on the Orientated Minimum Bounding Box (OMBB), as shown in Fig. 4(ii). In
this case the OMBB is drawn around the common region, and the centre point
determined. Lines are extrapolated from the centre point to the corner and edge
midway points of the bounding box, creating 8 triangular zones. For any two entities
to be considered opposite each other with respect to the square they must occupy
zones whose sum adds up to ten, according to the number system shown. Therefore
no matter where the observer is located the relation of A, B1 and the square would be
classed as opposite, assuming all entities were visible. Entities occupying a
neighbouring zone are also considered to be opposite, so that A, B2 and A, B3
would be describe as sharing an opposite relation with respect to the square. This
works for all common region shapes (e.g. lakes), as the algorithm is based on the
orientated bounding box.
Fig. 4. Using the term Opposite across a region
3.3 Additional Considerations for Usage
The concepts outlined so far have failed to include a measure of the appropriateness
of the inclusion of the term with respect to the observers viewing distance, and object
sizes. Instead they have looked to determine the most suitable candidate for the
relation. However at greater viewing distances, and for smaller items, it may be
harder for the observer to judge when two entities share an opposite relation and it
may be necessary to restrict the inclusion of the term in a referring expression
according to the percentage of the field of view occupied by the items. This approach
accommodates entity scale, such that a house may be described as opposite a bakery
from only close range, while a park may be described as opposite the hills from
greater distances.
Additionally when a referring expression is used in a more general description of a
region, and not to identify a particular target, consideration must be given to the
ordering of features in the relation. Jackendorf [5] makes the observation that not all
relations are symmetrical, and that the house is next to the bike makes less sense
than the bike is next to the house. When considering the opposite relation it
makes more sense to use the most salient feature as the reference object, such as turn
right after you see a hut opposite a lake, whereby the viewers attention should be
more naturally drawn to the lake, and the decision point confirmed once the hut has
been located.

When constructing descriptions of a feature it is useful to include spatial prepositions
to guide the users attention. This is particularly relevant when forming referring
expressions for use in speech based LBSs while exploring a city. The case of spatially
opposite an entity has been considered in this paper raising a number of
observations about how it may be determined and constructed from GIS datasets. The
research has shown that to ensure meaningful descriptions it is necessary to determine
whether features are visible to the user by calculating their visual exposure and
establish a common reference entity to define their relation. One-dimensional and
two-dimensional features have been examined for this purpose. Three-dimensional
entities have not yet been explored, but could be included in future work. They may
be of particular use when constructing descriptions for features on the side of a
building, such as the window opposite the balcony, to limit the vertical scan region.
When a number of possible candidates are found it is necessary to select the most
useful by determining its saliency and recognisability, to assist in guiding the users
attention and minimise risk of target confusion. Factors including its visibility,
distance, and the number of other similar items in the scene are considered. Future
work should examine the weighting of these inputs, to determine the most suitable
values for particular tasks. The models presented should be developed further through
user trials, and may then be adopted as part of a wider set of defined spatial relations
for use in urban LBS, and the geosemantic web.
References
1. Narzt, W., et al.: Augmented reality navigation systems. Universal Access in the
Information Society, 111 (2006)
2. Hollerer, T., et al.: Exploring MARS: Developing indoor and outdoor user interfaces to a
mobile augmented reality system. Computers and Graphics (Pergamon) 23(6), 779785
(1999)
3. Goose, S., Sudarsky, S., Zhang, X., Navab, N.: Speech-Enabled Augmented Reality
Supporting Mobile Industrial Maintenance. In: PERVASIVE Computing (2004)
4. Bartie, P.J., Mackaness, W.A.: Development of a speech-based augmented reality system
to support exploration of cityscape. Transactions in GIS 10(1), 6386 (2006)
5. Jackendoff, R.: Languages of the Mind. MIT Press, Cambridge (1992)
6. Dale, R., Reiter, E.: Computational interpretations of the Gricean maxims in the generation
of referring expressions. Cognitive Science 19(2), 233263 (1995)
7. Espinoza, F., et al.: GeoNotes: Social and Navigational Aspects of Location-Based
Information Systems. In: Abowd, G.D., Brumitt, B., Shafer, S. (eds.) UbiComp 2001.
8. Francioni, J.M., Jackson, J.A., Albright, L.: The sounds of parallel programs: IEEE (2002)
9. Allport, D., Antonis, B., Reynolds, P.: On the Division of Attention: a Disproof of the Single
Channel Hypothesis. Quarterly Journal of Experimental Psychology 24, 225235 (1972)
10. Ishii, H., Kobayashi, M., Arita, K.: Iterative design of seamless collaboration media.
Communications of the ACM 37(8), 8397 (1994)
11. Winter, S., Wu, Y.: The spatial Turing test. In: Colloquium for Andrew U. Franks 60th
Birthday. Geoinfo Series, Department for Geoinformation and Cartography, Technical
University Vienna, Vienna (2008)
12. Meng, L.: Ego centres of mobile users and egocentric map design. In: Meng, L., Zipf, A.,
Reichenbacher, T. (eds.) Map-based Mobile Services, pp. 87105. Springer, Berlin (2005)
13. Reichenbacher, T.: Adaptive egocentric maps for mobile users. In: Meng, L., Zipf, A.,
Reichenbacher, T. (eds.) Map-based Mobile Services, pp. 143162. Springer, Berlin
(2005)
14. Egenhofer, M.J., Herring, J.: A mathematical framework for the definition of topological
relationships (1990)
15. Clementini, E., Di Felice, P.: A comparison of methods for representing topological
relationships. Information Sciences-Applications 3(3), 149178 (1995)
16. Clementini, E., Billen, R.: Modeling and computing ternary projective relations between
regions. IEEE Transactions on Knowledge and Data Engineering 18, 799814 (2006)
17. Hernndez, D.: Relative representation of spatial knowledge: The 2-D case. In: Mark,
D.M., Frank, A.U. (eds.) Cognitive and linguistic aspects of geographic space, pp. 373
385. Kluwer Academic Publishers, Netherlands (1991)
18. De Smith, M.J., Goodchild, M.F., Longley, P.: Geospatial Analysis: A Comprehensive
Guide to Principles, Techniques and Software Tools. Troubador Publishing (2007)
19. De Floriani, L., Marzano, P., Puppo, E.: Line-of-sight communication on terrain models.
International Journal of Geographical Information Systems 8(4), 329342 (1994)
20. Stucky, J.L.D.: On applying viewshed analysis for determining least-cost paths on Digital
Elevation Models. International Journal of Geographical Information Science 12(8), 891
905 (1998)
21. Fisher, P.F.: Extending the applicability of viewsheds in landscape planning.
Photogrammetric Engineering and Remote Sensing 62(11), 12971302 (1996)
22. Baer, W., et al.: Advances in Terrain Augmented Geometric Pairing Algorithms for
Operational Test. In: ITEA Modelling and Simulation Workshop, Las Cruces, NM (2005)
23. Fisher-Gewirtzman, D., Wagner, I.A.: Spatial openness as a practical metric for evaluating
built-up environments. Environment and Planning B: Planning and Design 30(1), 3749
(2003)
24. Tandy, C.R.V.: The isovist method of landscape. In: Symposium: Methods of Landscape
Analysis. Landscape Research Group, London (1967)
25. Benedikt, M.L.: To take hold of space: isovists and isovist fields. Environment and
Planning B 6(1), 4765 (1979)
26. Morello, E., Ratti, C.: A digital image of the city: 3D isovists in Lynchs urban analysis.
Environment and Planning B 36, 837853 (2009)
27. Llobera, M.: Extending GIS-based visual analysis: the concept of visualscapes.
International Journal of Geographical Information Science 17(1), 2548 (2003)
28. Bartie, P.J., et al.: Advancing Visibility Modelling Algorithms for Urban Environments.
Computers Environment and Urban Systems (2010);
doi:10.1016/j.compenvurbsys.2010.06.002
29. Billen, R., Clementini, E.: Projective relations in a 3D environment. In: Raubal, M., Miller,
H.J., Frank, A.U., Goodchild, M.F. (eds.) GIScience 2006. LNCS, vol. 4197, pp. 1832.
30. Bartie, P., et al.: A Model for Egocentric Projective Spatial Reasoning based on Visual
Exposure of Features of Interest (forthcoming)
31. Merriam-Webster: Opposite (2010)
32. Raubal, M., Winter, S.: Enriching wayfinding instructions with local landmarks. In:
Egenhofer, M.J., Mark, D.M. (eds.) GIScience 2002. LNCS, vol. 2478, pp. 243259.
33. Elias, B.: Determination of landmarks and reliability criteria for landmarks (2003)
Cognitive Adequacy of Topological Consistency
Measures
Nieves R. Brisaboa1, Miguel R. Luaces1 , and M. Andrea Rodrguez2

1
Database Laboratory, University of A Coruna
Campus de Elvi
na, 15071 A Coruna, Spain
{brisaboa,luaces}@udc.es
2
Universidad de Concepcion, Chile
Edmundo Larenas 215, 4070409 Concepcion, Chile
andrea@udec.cl
Abstract. Consistency measures provide an indication on how much a

dataset satises a set of integrity constraints, which is useful for com-
paring, integrating and cleaning datasets. This work presents the notion
of consistency measures and provides an evaluation of the cognitive ad-
equacy of these measures. It evaluates the impact on the consistency
measures of dierent parameters (overlapping size, external distance, in-
ternal distance, crossing length, and touching length) and the relative
size of geometries involved in a conict. While a human-subject test-
ing supports our hypotheses with respect to the parameters, it rejects
the signicance of the relative size of geometries as a component of the
consistency measures.
Keywords: Topological similarity measure, inconsistency measures, spa-

tial inconsistency.
1 Introduction
A dataset is consistent if it satises a set of integrity constraints. These integrity
constraints dene valid states of the data and are usually expressed in a lan-
guage that also denes the data schema (logical representation). Consistency
measures provide an indication on how much a dataset satises a set of integrity
constraints. They are useful to compare datasets and to dene strategies for data
cleaning and integration. Traditionally, consistency in datasets has been a binary
property, the dataset is either consistent or not. At most, consistency measures
count the number of elements in a dataset that violate integrity constraints,
but the concept of being partially consistent does not exist. Spatial information
rises new issues regarding the degree of consistency because the comparison of
spatial data requires additional operators beyond the classical comparison oper-
ators (=, >, <, , , =). Geometries are typically related by topological or other
spatial relations, upon which dierent semantic constraints may be dened.

This work was partially funded by Fondecyt 1080138, Conicyt-Chile and by Min-
isterio de Ciencia e Innovaci
on (PGE and FEDER) refs. TIN2009-14560-C03-02,
TIN2010-21246-C02-01 and by Xunta de Galicia (Fondos FEDER), ref. 2010/17.

242 N.R. Brisaboa, M.R. Luaces, and M.A. Rodrguez
In a previous work [9], we dened a set of measures to evaluate the viola-

tion degree of spatial datasets with respect to integrity constraints that impose
topological relations on the semantics of spatial objects. These measures con-
textualize the relative importance of the dierence of the topological relation
between two geometries with respect to an expected topological relation by con-
sidering the size of geometries within the whole dataset. In this paper we carry
out a human-subject testing to evaluate all measures where we analyze not only
the degree of violation in itself, but also the impact of the relative size of objects
in the dataset as a component of the degree of violation. Three hypotheses were
analyzed: (1) The four parameters used by the measures (i.e., external distance,
internal distance, crossing segment, and overlapping size) are perceived by sub-
jects as factors of the degree violation. (2) The touching length of geometries in
touch, which is also not considered by the proposed measures, is not considered
by subjects as a factor of the degree of violation. (3) The size of geometries
involved in a conict, with respect to other objects in the dataset, is perceived
by subjects as a factor of the degree of violation.
The organization of the paper is as follows. Section 2 makes a revision of
related work. In particular it analyzes dierent approaches to comparing topo-
logical relations. Section 3 presents preliminary concepts and consistency mea-
sures rst dened in [9], while Section 4 describes the human-subject testing
and its main results. Final conclusions and future research directions are given
in Section 5.
2 Related Work
Related work addresses similarity measures of topological relations. Similar-
ity measures are useful to compare the topological relation between geome-
tries stored in a dataset with respect to an expected topological relation as
expressed by an integrity constraint. We distinguish qualitative from quantita-
tive approaches to comparing topological relations. A qualitative representation
of topological relations uses a symbolic representation of spatial relations, such
as the topological relations dened by Egenhofer and Franzosa [3] or by Randell
et al. [8]. Under this representation, a similarity measure compares topologi-
cal relations by the semantic distance between relations dened in a conceptual
neighborhood graph [7]. The disadvantage of comparing topological relations
from a qualitative perspective is that it does not make distinction between par-
ticular geometries. For example, it does not distinguish between two pairs of
geometries, both disjoint, but where in one case the geometries are very close
and in the other case the geometries are far apart. Even more, in most cases
when semantic distance is used, all edges in the conceptual graph will usually
have the same weight in the determination of the semantic distance.
A quantitative representation of topological relations is given in [1] by the dis-
tance and angle between the centroid of the objects. Using this representation,
similarity between topological relations is dened as the inverse of the dier-
ence between representations. Another study [4] denes ten quantitative mea-
sures that characterize topological relations based on metric properties, such as
Cognitive Adequacy of Topological Consistency Measures 243
length, area, and distance. The combination of these measures gives an indica-
tion of the topological relations and their associated terms in natural language
(such as going through and goes up to). The problem of using the previous mea-
sures for evaluating the degree of inconsistency is that although datasets handle
geometries of objects, constraints are expressed by qualitative topological rela-
tions, and therefore, only a symbolic representation of the expected topological
relations exists.
In the spatial context, only the work in [9] introduces some measures to com-
pare the consistency of dierent datasets. In this previous work, given an ex-
pected topological relation between any two objects with particular semantics,
a violation degree measure quanties how dierent is the topological relation
between the objects from the expected relation expressed by a topological con-
straint. While this previous work provides an evaluation with respect to semantic
distance, it does not evaluate the cognitive adequacy of the measures neither the
impact of the relative size of objects in the quantication of inconsistency.
3 Denition of Consistency Measures

In this work we concentrate on integrity constraints that impose topological re-
lations depending on the semantics of objects. Particularly, we extend the Topo-
logical Dependency (TD) constraints dened in [2] or the semantic constraints
in [5] to consider a wider range of constraints found in practise. The denitions
of topological relations are those in the Open Geospatial Consortium Simple
Feature Specication [6] and used in the subsequent specication of topological
dependency constraints.
x1 , g1 ) and R(
Let T be a topological relation, and P ( x2 , g2 ) be predicates rep-
resenting spatial entities with non-empty sequences of thematic attributes x 1 and
x
2 , and geometric attributes g1 and g2 , respectively. A conditional topological
dependency constraint is of the form:

x1 x x2 , g2 ) T (g1 , g2 ))
x1 , g1 ) R(
2 g1 g2 (P (
where g1 is either g1 , 1 [g1 ] or 2 [g1 , d], with d a constant and 1 and 2 geo-
metric operators that return a geometry. Geometry g2 is dened in the same way
than g1 where g1 is replaced by g2 . Also is an optional formula in conjunctive
normal form (CNF) dened recursively by:
(a) yz is an atomic formula, with y x 1 , z y2 , and a comparison operator

(=, =, >, <, ).
(b) T (g1 , g2 ) is an atomic formula, with T a topological relation.
(c) 1 [g1 ]c or 1 [g1 ]2 [g2 ] are atomic formula, with c a constant, a compar-
ison operator (=, =, >, <, ), and 1 , 2 geometric operators that return
real numbers (e.g., area, length, perimeter, and so on).
(d) An atomic formula is a CNF.
(e) (t1 t2 ) is a clause with t1 and t2 atomic formulas.
(f) A clause is a CNF.

(g) c1 c2 is a CNF formula with c1 and c2 clauses or CNF formulas.
Using the previous denitions and considering predicate county(idc, ids, g) and
state(ids, g), a CTD could be a county must be within the state to which it
belongs:
idc, ids, g1 , g2 (county(idc, ids, g1 ) state(ids, g1 ) Within(g1 , g2 ))
Let be an integrity constraint of the form 3 with topological relation T . A

pair of tuples P (u1 , s1 ) and P (
u2 , s2 ) is inconsistent if the antecedent in in-
stantiated by P ( u1 , s1 ) and P (
u2 , s2 ) is satised but the consequent not. We
dened in [9] a collection of measures to compute the violation degree for all
topological relations between surfaces. Two main components dene the degree
of violation: (1) the magnitude of the conict and (2) the relevance of the con-
ict. The magnitude of the conict measures the dierence between the relation
held by the two geometries and the expected relation between them. For exam-
ple, if two geometries must touch but they are disjoint, the magnitude of the
conict is proportional to the separation between the geometries. In the case
that two geometries must touch but they overlap, the magnitude of the conict
is proportional to the overlapping area between the geometries. On the other
hand, the relevance of the conict is determined using the relative size of the
objects.
We have considered ve dierent parameters to compute the magnitude of
the conict with respect to dierent topological relations: (1) the external dis-
tance between disjoint geometries, which has an impact on conicts risen by the
separation of geometries when they must intersect (i.e., equal, touch, overlap,
or within). (2) The internal distance between geometries when one is within
the other geometry, which has an impact on conicts when geometries must be
externally connected (i.e, they must touch or they must be disjoint). (3) The
overlapping size of geometries that are internally connected, which has an im-
pact on conicts when geometries must be externally connected (4) The crossing
length that represents the length of the minimum segment of a curve that crosses
another curve or a surface, which has an impact on conicts when geometries
must be externally connected. (5) The touching length between geometries repre-
sents the length of the common boundary between geometries. In the denition
of the violation degree measures, we have used the rst four parameters and we
have not used the touching length in any of the measures.
4 Empirical Validation of Consistency Measures

To validate the cognitive adequacy of our measures, we designed human-subject
tests oriented to evaluate both components of our measures: (i) the parameters
that measure the magnitude of conicts (external distance, internal distance,
overlapping size and crossing length) and (ii) the computation of the conict
relevance using the relative size of the objects. We wanted to evaluate whether
A and B must touch. A and B must be disjoint.
(a) (b)
Fig. 1. Comparison of the violation degree: (a) example of section 1 and (b) example
of section 2
these parameters have an impact on the violation degree perceived by subjects

and, therefore, if they are cognitively adequate to dene the violation degree of
CTDs. We also wanted to evaluate whether our decision to ignore the parameter
touching length was correct, that is wheter the touching length has an impact
on the magnitude of conict (e.g., geometries that should touch must but are
disjoint).
The following three hypotheses were studied:
H1 : External distance, internal distance, crossing length, and overlapping size
are perceived and used by subjects to evaluate the degree of violation of
CTDs.
H2 : Touching length is not considered by subjects to evaluate the degree of
violation of CTDs.
H3 : The relative size of the geometries that participate in the violation of CTDs
with respect to other objects in the dataset aects the perceived violation
degree. More precisely, the larger the geometries the larger the violation
degree.
The subjects of the test were 69 second year computer science students. The
test was performed at the beginning of a normal class. They were not given any
instructions in addition to those written in the test. Nine of the subjects were
eliminated because they did not complete the test or their answers showed a clear
misunderstanding of the questions. Students did not receive any compensation
for answering the test, which explains why some students did not answer all
questions.
The test begins with a set of gures describing the topological relations that
combine geometries with dierent dimensions (surfaces, curves and points).
These gures are the only reference to understand the meaning of each topolog-
ical relation. Then, a short paragraph explains that the objective of the test is
to evaluate the violation degree of the topological relations in the gures that
follow in the next pages. The instructions emphasize that the violation of the
expected topological relation was referred exclusively to the geometries clearly
identied in each gure with colors blue and yellow, explaining that any other
geometry coloured in black is correct.
The test consists of 3 sections. Section 1 includes 24 questions to check whether
the parameters used by our measures are those perceived by the subjects as a
A and B must touch
A B 0
Fig. 2. Example of section 3
factor of the violation degree (H1 and H2 ). Figure 1(a) shows a question of this
section. The task is to choose whether or not one of them shows a larger (>),
equal (=) or smaller (<) violation degree of an expected topological relation
among geometries A and B. Specically, we check that the larger the value of
the parameter that denes the magnitude of conicts in our measures, the larger
the perceived violation.
The questions in this section check the four parameters considered in our mea-
sures (i.e., external distance, internal distance, crossing length, and overlapping
size) as well as the inuence of the touching length between geometries. The
questions also represent a balanced selection of dierent topological relations
and types of geometries (mainly surfaces and curves, but also points).
Section 2 includes 14 questions similar to those in Section 1. The dierence is
that the gures now include black geometries that represent the context where
the violation occurs. Figure 1(b) shows a question of section 2. This section
is designed to prove the inuence of the context, that is, the inuence in the
perceived violation of the size of the two geometries in conict with respect to
the other geometries in the dataset (H3 ).
Section 3 shows each single gure in the questions in section 3. Fourteen of
them represent small blue and yellow geometries and large context geometries
and fourteen of them represent large blue and yellow geometries and small con-
text geometries. For each gure, the subjects were asked to provide a value of the
degree of violation between 0 and 100. The example given to the subjects (see
Figure 2) does not violate the expected topological relation and, consequently,
the assigned violation degree value is 0. We decided to use this example with
value 0 to avoid any inuence on the value given by subjects in case of a viola-
tion. This section is designed to validate our measures by evaluating whether or
not the violation degrees computed by our measures is in concordance with the
violation degrees given by the subjects. If there is a high correlation between the
scores provided by the subjects and the values obtained with our measures, we
can conclude that our measures are valid and that they reect the opinions of
the subjects.
We decided not to check all combinations of topological relations between ge-
ometries versus an expected topological relation because this would require 64
questions in the test. We assume that if a parameter (e.g. the external distance
between geometries) was perceived and used to decide a degree of violation be-
tween geometries that must touch but are disjoint, then it will be also perceived
and used to decide the degree of violation between two geometries that must
overlap but are disjoint. Similarly, we assume that if a parameter is perceived
and used for geometries of a particular dimension (e.g., surfaces), then it will be
also for geometries of other dimension (e.g., curves or points). Furthermore, we
did not include gures in the test where the expected relation is Equal.
A and B must be disjoint. A and B must be disjoint
(a) (b)
Fig. 3. Comparison of the violation degree: (a) a surface within another surface (b) a
point within another point
Table 1 shows the raw data obtained in the dierent questions of section 1. In
this table, Expected refers to the expected topological relation as expressed by a
CTD, Actual refers to the real relation between the geometries in the question,
Geometries refers to the type of geometries involved in the relation, Parameter
refers to the parameter evaluated by the test, + refers to the percentage of
answers that perceive a positive impact of the parameter on the violation degree,
= refers to the percentage of answers that do not perceive any eect of the
parameters on the violation degree, and refers to the percentage of answers
that give an inverse inuence of the parameter on the violation degree.
One can see that there is always around a 10% of subjects that answered
a dierent option than the one we expected. When some of the subjects were
asked about the reasons of their answers, many of them said it was a mistake. We
realize now that it was dicult for the subjects to keep the level of concentration
to mark correctly < or > on all the questions. The results prove beyond any
doubt that the parameters external distance, overlapped size and crossing length
are consistently used by the subjects to evaluate the violation degree (hypothesis
H1 ). We performed the Students t test to evaluate the signicance of our results
and we found that the average percentage of correct answers for the parameter
external distance was signicant at the 99% level. In the same way the results
showed that for the parameters crossing length and overlapping size the average
percentage we obtained is signicant at the 95% level.
Results regarding the parameter internal distance are more dicult to ana-
lyze. For questions 2 and 23 there was a large percentage of subjects (around
40%) that did not answer as we expected. Figure 3(a) shows question number
2. When asked why they answered this way, the subjects said that geometries
were more disjoint when the internal distance between them was larger. We be-
lieve that this was due to a misunderstanding of the topological relation Disjoint.
Table 1. Results section 1
# Expected Actual Geometries Parameter +%=%-%

1 Disjoint Overlaps surface surface Overlapping size 83 8 8
2 Disjoint Within surface surface Internal distance 48 28 23
3 Touches Overlaps surface surface Overlapping size 68 20 12
4 Touches Within surface surface Internal distance 62 22 17
5 Overlaps Disjoint surface surface External distance 87 3 10
6 Overlaps Touches surface surface Touching length 32 48 20
7 Overlaps Within surface surface Internal distance 53 40 7
8 Within Overlaps surface surface Overlapping size 68 17 15
9 Within Touches surface surface Touching length 20 65 15
10 Disjoint Overlaps curve curve Crossing length 68 23 8
11 Disjoint Overlaps curve curve Touching length 58 35 7
12 Disjoint Overlaps curve curve External distance 83 5 12
15 Disjoint Overlaps surface curve Touching length 40 52 8
16 Disjoint Overlaps surface curve Crossing length 83 8 8
17 Disjoint Overlaps surface curve Internal distance 45 45 10
19 Disjoint Overlaps surface curve External distance 87 12 7
20 Disjoint Overlaps surface curve Crossing length 68 23 8
21 Disjoint Overlaps surface curve External distance 72 18 10
23 Disjoint Overlaps surface point Internal distance 52 28 20
24 Disjoint Overlaps curve point External distance 67 27 7
Question 7 was another case where many subjects gave unexpected answers due
to the misunderstanding of the topological relation Overlaps. When asked why
they considered that both gures have the same degree of violation, many sub-
jects answered that in both cases there was no violation because when a geometry
is within another geometry they also overlap each other.
After eliminating questions 2, 7, and 23 where there was some misinterpre-
tation, the Students t-test shows that the average percentage is signicant at
the 85% level. This means that the internal distance parameter aects the per-
ception of consistency by subjects. However, further analysis must be performed
in the future to better understand why in some cases the internal distance is
considered important and in some cases not.
Finally, as H2 states, the touching length is not a useful parameter to evalu-
ate the degree of violation of a topological constraint. Only question 11 shows a
higher percentage of subjects that considered the impact of touching length im-
portant on the violation degree. However, as it can be seen in Figure 3(b), this
question was the only one where the geometries in each gure were not exactly
the same. Thus, there may be factors other than touching length involved in the
subjects answers.
The results for Section 2 indicate that 35%, 35% and 30% of the subjects
considered that the size of geometries in conict had a positive, equal or negative
impact on the violation degree, respectively. These results do not support our
hypothesis H3 , but they also do not support the alternative hypothesis that states
that the relative size has no impact or a negative impact on the violation degree.
Therefore, we cannot extract any conclusion over the inuence of the context in
the evaluation of the violation degree. These results are in concordance with the
results obtained in section 3.
Finally, for each question in Section 3, we computed the average score given
by the 60 subjects and the value of our measure. Then, we computed the Pearson
correlation between both series of values. The correlation coecient equals to
0.54. Given that this is a very small value, we excluded the relative weight
from the computation of our measures and we obtained a correlation coecient
of 0.84. This result supports the conclusion that we extracted from section 2.
We can conclude that the relative size of the geometries is not considered to be
important by the subjects. Or at least, that the subjects consider more important
the magnitude of the conicts than the relative size of the geometries with respect
to other objects in the dataset.
5 Conclusions
We obtained two types of conclusions from this work: some related to the def-
inition of the measures and other related to the methodology to evaluate these
measures. Overall, it is clear that the use of parameters such as external dis-
tance and overlapping size allows us to discriminate situations that a semantic
distance approach to comparing topological relations would otherwise overlook.
Unless we consider the particularity of the geometries, a pair of geometries hold-
ing the same topological relation will always have the same degree of violation
with respect to a dierent expected topological relation.
The results of the empirical evaluation indicate that the parameters that
dene our measures agree with the human perception of the violation degree. The
only one that was not fully conrmed was the internal distance, which requires
further evaluation. Contrary to our expectation, the results also indicate that
the relative size of geometries in conict with respect to other geometries in the
dataset has less impact on the evaluation of the violation degree than what we
expected. This is conrmed by the increase in the correlation of the scores given
by the users in Section 3 of the test when we eliminated the eect of the relative
size of geometries from the measures.
We conrmed that the design of the test is critical. There are two basic prob-
lems that need to be solved for future empirical evaluations: the diculty of the
task and the knowledge the subjects need about topological relations.
Regarding the diculty of the task, the questions in the test require a high
level of concentration. This explains the high number of mistakes we found in
the questions of section 1. On the other hand, in section 3 the task was easier
because only a score was requested. However, the subjects complained about the
diculty and many of them moved back and forward changing the scores while
answering the questions.
The problem of the knowledge about the topological relations is harder to
solve. Explaining the meaning of the topological relations before the test does
not guarantee that they use these denitions instead of their own interpretations.
For instance, some of the subjects considered that two surfaces that overlap,
also touch, or that two surfaces that are one within the other also overlap. The
only way to avoid this problem is to train the subjects in the meaning of the
topological relations. However, it may be dicult to do this without instructing
them in our view of the parameters that dene the measure of the violation
degree. Probably, the safest way to tackle this problem is to select the gures and
their relations very carefully to avoid that subjects misunderstand topological
relations.
References
1. Berreti, S., Bimbo, A.D., Vicario, E.: The computational aspect of retrieval by
spatial arrangement. In: Intl. Conference on Pattern Recognition (2000)
2. Bravo, L., Rodrguez, M.A.: Semantic integrity constraints for spatial databases.
In: Proc. of the 3rd Alberto Mendelzon Intl. Workshop on Foundations of Data
Management, Arequipa, Peru, vol. 450 (2009)
3. Egenhofer, M., Franzosa, R.: Point Set Topological Relations. IJGIS 5, 161174
(1991)
4. Egenhofer, M., Shari, A.: Metric details for natural-language spatial relations.
ACM Transactions on Information Systems 16(4), 295321 (1998)
5. Hadzilacos, T., Tryfona, N.: A Model for Expressing Topological Integrity Con-
straints in Geographic Databases. In: Frank, A.U., Formentini, U., Campari, I. (eds.)
GIS 1992. LNCS, vol. 639, pp. 252268. Springer, Heidelberg (1992)
6. OpenGis: Opengis Simple Features Specication for SQL. Tech. rep., Open GIS
Consortium (1999)
7. Papadias, D., Mamoulis, N., Delis, V.: Algorithms for querying spatial structure.
In: VLDB Conference, pp. 546557 (1998)
8. Randell, D., Cui, Z., Cohn, A.: A spatial logic based on regions and connection. In:
Nebel, B., Rich, C., Swarthout, W. (eds.) Principles of Knowledge Representation
and Reasoning, pp. 165176. Morgan Kaufmann, San Francisco (1992)
9. Rodrguez, M.A., Brisaboa, N.R., Meza, J., Luaces, M.R.: Measuring consistency
with respect to topological dependency constraints. In: 18th ACM SIGSPATIAL
Intl. Symposium on Advances in Geographic Information Systems, ACM-GIS 2010,
San Jose, CA, USA, pp. 182191 (2010)
The Neighborhood Conguration Model:
A Framework to Distinguish Topological
Relationships between Complex Volumes
Tao Chen and Markus Schneider
Department of Computer and Information Science and Engineering

University of Florida
Gainesville, FL 32611, USA
{tachen,mschneid}@cise.ufl.edu
Abstract. Topological relationships between spatial objects are con-

sidered to be important for spatial databases. They lead to topological
predicates, which can be embedded into spatial queries as join or se-
lection conditions. Before rushing into the implementation of topological
predicates, topological relationships between spatial objects must be rst
understood and claried. This requires a detailed study of a vast number
of possible spatial congurations at the abstract level, and as a result,
methods that are able to classify and identify as many as possible dier-
ent spatial congurations are needed. While a lot of research has already
been carried out for topological relationships in the 2D space, the investi-
gation in the 3D space is rather neglected. Developed modeling strategies
are mostly extensions from the popular 9-intersection model which has
been originally designed for simple 2D spatial objects. We observe that a
large number of topological relationships, especially the ones between two
complex 3D objects are still not distinguished in these models. Thus, we
propose a new modeling strategy that is based on point set topology. We
explore all possible neighborhood congurations of an arbitrary point in
the Euclidean space where two volume objects are embedded, and dene
corresponding neighborhood conguration ags. Then, by composing the
Boolean values of all ags, we uniquely identify a topological relationship
between two complex volume objects.
1 Introduction
Topological relationships like overlap, inside, or meet describe purely qualita-

tive properties that characterize the relative positions of spatial objects and are
preserved under ane transformations such as translation, scaling, and rota-
tion. The exploration of topological relationships between spatial objects is an
important topic in elds like articial intelligence, cognitive science, geographi-
cal information systems (GIS), linguistics, psychology, robotics, spatial database

This work was partially supported by the National Science Foundation under grant
number NSF-IIS-0915914.

252 T. Chen and M. Schneider
systems, and qualitative spatial reasoning. From a database and GIS perspective,
their development has been motivated by the need of formally dened topologi-
cal predicates as lter conditions for spatial selections and spatial joins in spatial
query languages and as a support for spatial data retrieval and analysis tasks.
The central conceptual approach, upon which almost all publications in this
eld have been based, is the 9-intersection model (9IM) [1]. This model checks
the nine intersections of the boundary, interior, and exterior of a spatial object
with the respective components of another spatial object for the topologically
invariant criterion of non-emptiness. Extensions have been proposed to obtain
more ne-grained topological predicates. However, the main focus has been on
spatial objects in the 2D space; the study of topological relationships between
spatial objects in the 3D space has been rare. An available strategy is to apply
9IM based models and to investigate the total number of relationships that can
occur in reality between spatial objects in the 3D space. However, the third di-
mension introduces more complicated topological situations between 3D spatial
objects. When directly applying the 9IM based models to 3D complex spatial
objects like volumes, they suer from a major problem, which we call the high
granularity problem. That is, the 9IM considers the interior, exterior, and bound-
ary point sets as the basic elements for empty and non-empty intersection tests,
which ignores the fact that the interior, exterior, and the boundary of a spatial
object are also complex spatial object parts, and may have multiple components.
Thus, the interaction between any pair of the basic elements from two spatial
objects can be complex, and empty or non-empty intersection results may not
be enough to describe such interactions. For example, the boundary of a volume
object is a closed surface object, which may have multiple components. Thus, the
interaction between the boundaries of two volume objects is equivalent to the in-
teraction between two complex surface objects, which can touch at a point, meet
at a face, cross each other, or have touch, meet, and cross interactions coexist
on one or more components. Since 9IM based models do not have the capability
to handle these interaction details for their basic elements, a large number of
topological relationships between complex volumes are not distinguished.
In this paper, we propose a new framework based on point set theory and
point set topology to model topological relationships between two complex vol-
ume objects. We overcome the problems raised on the 9IM by investigating the
interactions between two volumes at a much lower granularity. Instead of check-
ing the intersections of the interior, boundary, and exterior of two volumes, we
investigate the interaction of the two volumes within the neighborhood of any
point in the Euclidean space where the two volumes rest, which we call the
neighborhood conguration. We explore all possible neighborhood congurations,
and dene corresponding Boolean neighborhood conguration ags. By evalu-
ating and composing the values of the neighborhood conguration ags for a
given scenario with two complex volumes, we can obtain a binary encoding of
the topological relationship between the two volumes. We show that our model
yields more and thus a more ne-grained characterization of topological rela-
tionships between two complex volumes compared to 9IM.
The Neighborhood Conguration Model 253

A B = A B = A B =
A B = A B = A B =

A B = A B = A B =
Fig. 1. The 9-intersection matrix for topological relationships
Section 2 discusses related work about topological relationships. We propose

our neighborhood conguration model (NCM ) in Section 3, where we introduce
in detail the denition of neighborhood congurations, the exploration of all pos-
sible neighborhood congurations, and the encoding of a topological relationship
between two complex volumes. In Section 4, we compare our approach to the
9IM based models. Finally, Section 5 draws some conclusions.
2 Related Work
A special emphasis of spatial research has been put on the exploration of topo-
logical relationships (for example, overlap, inside, disjoint, meet) between spatial
objects. An important approach for characterizing them rests on the so-called
9-intersection model, which employs point set theory and point set topology [1].
The model is based on the nine possible intersections of the boundary (A),
interior (A ), and exterior (A ) of a spatial object A with the corresponding
components of another object B. Each intersection is tested with regard to the
topologically invariant criteria of emptiness and non-emptiness. The topological
relationship between two spatial objects A and B can be expressed by evaluating
the matrix in Figure 1. A total of 29 = 512 dierent congurations are possible
from which only a certain subset makes sense depending on the combination of
spatial data types just considered. Several extensions based on the 9IM exist. Ex-
amples are the dimensionality extensions in [2,3], the Voronoi-based extensions
in [4], and the extensions to complex spatial objects in [5].
A topic that has been partially formally explored at the abstract level deals
with topological relationships between simple 3D spatial objects. In [6], the au-
thor applies the 9-intersection model to simply-connected 3D spatial objects,
that is, simple 3D lines, simple surfaces (no holes), and simple volumes (no
cavities), in order to determine their topological relationships. A total of 8 topo-
logical relationships are distinguished between two simple volumes. Zlatanova
has also investigated the possible 3D topological relationships in [7] by develop-
ing a complete set of negative conditions. The 9-intersection model for 3D can
be extended with the dimensionality being considered. In [8], the values of the
matrix elements are extended. Besides the and symbols, the is used to
indicate the omitted specication for the resulting set at this position, and the
numbers (0, 1, 2, 3) refer to the dimensionality of the resulting set. Therefore,
unlike the 1:1 mapping between the matrix with the topological relationships in
the 9-intersection model, a matrix that contains a value represents a class of
topological relationships. As a result, the topological relationships are clustered
and manageable to the user. However, these 9IM based models suer from the
aforementioned high granularity problem due to the use of interior, exterior and
boundary sets as basic elements.
The above models in common apply set theory to identify topological relation-
ships. Thus, they can be categorized as point-set based topological relationships
models. There are also other approaches that do not employ the point-set theory.
The approach in [9] investigates topological predicates between cell complexes,
which are structures from algebraic topology. It turns out that, due to limita-
tions of cell complexes, the topological relationships between them are only a
subset of the derived point-set based topological relationships. The topological
relationships between 3D spatial objects that consist of a series of cell complexes
can be described by the combination of relationships between those cells [10].
The Dimensional Model (DM ) [11] is a model that is independent of the 9-
intersection model. It denes dimensional elements on a spatial object, and all
the dimensional elements contribute to the nal result. Three levels of details
for the topological relationships are developed for dierent application purposes.
The dimension model can distinguish some cases, especially meet cases that the
9-intersection model cannot identify. However, since it leaves the abstract topo-
logical space where only point sets are used, it is not clear how the dimensional
elements can be constructed.
3 The Neighborhood Conguration Model (NCM)

In the following sections, we introduce in detail our new modeling strategy
for topological relationships between 3D complex volumes. Section 3.1 gives an
overview of our modeling strategy. We explore all possible neighborhood cong-
urations for a given scenario of two spatial volume objects in Section 3.2. Finally,
in Section 3.3, we show how the topological relationships can be identied and
encoded with the neighborhood conguration ags.
3.1 Overview
In this paper, we are interested in complex volumes that may contain cavities
or multiple components. A formal denition of complex volume objects can be
found in [12], which models volumes as special innite point sets in the three-
dimensional Euclidean space. Our approach is also based on point set theory and
point set topology. The basic idea is to evaluate the values of a set of Boolean
neighborhood conguration ags to determine the topological relationships be-
tween two volumes. Each neighborhood conguration ag indicates the existence
or non-existence of a characteristic neighborhood conguration of the points in
a given scenario. The neighborhood conguration of a point describes the own-
erships of the points that are near the reference point. If the existence of a
neighborhood conguration is detected, then the corresponding neighborhood
conguration ag is set to true. For example, for a scenario that involves two
volumes A and B, if there exists a point p whose neighboring points all belong
to both A and B, then the corresponding neighborhood conguration ag ex-
ist nei in overlap (see Denition 1(1)) is set to true. Later, this neighborhood
conguration ag contributes to the determination of the topological relation-

ships between A and B.
3.2 Exploring Neighborhood Conguration Information
In this section, we explore all neighborhood congurations. We begin with some

needed topological and metric concepts. Let R be the set of real numbers, R+ =
{x R | x > 0}, and R3 be the three-dimensional Euclidean space. We assume
the existence of a Euclideandistance function d : R3 R3 R with d(p, q) =
d((x1 , y1 , z1 ), (x2 , y2 , z2 )) = (x1 x2 )2 + (y1 y2 )2 + (z1 z2 )2 . Then for any
point p R3 and r R+ , the set Nr (p) = {q R3 | d(p, q) r} is called the
closed ball with radius r and center p. Let denote a small positive value ( 0);
we call the closed ball N (p) the (closed) neighborhood of point p. We can think
of the neighborhood around p as a tiny closed ball containing all points in R3
that are nearest to p.
With the necessary topological concepts introduced, we now explore the pos-
sible neighborhood congurations of points in a scenario that involves two vol-
ume objects. Let us assume two volumes A and B that are point sets in R3
(A R3 , B R3 ). Then given a point p R3 , any point q in its neighbor-
hood N (p) (q N (p)) has one of the following four possible ownerships: (i)
q Aq / B, (ii) q / A q B, (iii) q A q B, and (iv) q / Aq / B.
As a result, we can describe the ownership of a neighborhood by combining the
ownerships of all points in it. We call this ownership description of a neigh-
borhood the neighborhood conguration. With the four possible ownerships of a
single point, we can obtain a total of 24 1 = 15 possible ownership combina-
tions for a neighborhood (the case where none of the four ownerships exists in
a neighborhood is not possible). In other words, 15 neighborhood congurations
are possible for any point in R3 where A and B are embedded. As a result, based
on Denition 1 we can dene 15 corresponding neighborhood conguration ags
for a scenario that involves A and B.
Denition 1. Let A, B R3 , p R3 , and N (p) be a neighborhood of p with a

tiny radius . We rst dene four ownership ags for p:
(A, B, p) x N (p) : x A x B
(A, B, p) x N (p) : x A x
/B
(A, B, p) x N (p) : x
/ Ax B
(A, B, p) x N (p) : x
/ Ax /B
Then we dene the following 15 neighborhood conguration ags for a scenario

involves two objects A and B:
(1) exist nei in overlap(A, B)

p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(2) exist nei in op1 (A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
AB A B p p A
p p p p B B B B
pA Ap pA p
(1) (2) (3) (4) (5) (6) (7) (8)
A A A p p A p
p p B B B B B
B p pA pA pA pA A
(9) (10) (11) (12) (13) (14) (15)
Fig. 2. The drawing of the 15 neighborhood congurations for point p
(3) exist nei in op2 (A, B)

p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(4) exist nei in ext(A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(5) exist nei contain overlap op1 (A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(6) exist nei contain overlap op2 (A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(7) exist nei contain overlap ext(A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(8) exist nei contain op1 op2 (A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(9) exist nei contain op1 ext(A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(10) exist nei contain op2 ext(A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(11) exist nei contain op1 op2 ext(A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(12) exist nei contain op2 overlap ext(A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(13) exist nei contain op1 overlap ext(A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(14) exist nei contain op1 op2 overlap(A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
(15) exist nei contain op1 op2 overlap ext(A, B)
p R3 : (A, B, p) (A, B, p) (A, B, p) (A, B, p)
The above 15 neighborhood conguration ags identify all possible interactions

between two spatial volumes A and B in R3 at any single point. We demonstrate
the validity of these neighborhood conguration ags by creating drawings for
the corresponding neighborhood congurations in Figure 2. For example, if ag
(8) yields true (Figure 2(8)), then it means that there exists a point whose
neighborhood consists of points that are only from the rst operand object A
and points that are only from the second operand object B. The value true of
(111111001100001) (111111011110011) (111111001110001)

(a) (b) (c)
Fig. 3. Examples of topological relationship scenarios and their corresponding topo-

logical relationship encodings
this ag (exist nei contain op1 op2 ) further indicates the existence of a meeting
on face topological relationship between two volume objects A and B.
3.3 Topological Relationship Encoding with Neighborhood

Conguration Flags
In the previous section, we have introduced 15 neighborhood conguration ags
for two complex volume objects embedded in the Euclidean space R3 . These ags
capture all topological situations for two volumes at all points in the Euclidean
space R3 . In other words, we have identied the topological relationships between
two volumes at a very low granularity level, which involves a small neighborhood
of a point. Thus, to determine the topological relationships between two volumes,
we just need to collect the values of all 15 neighborhood conguration ags. First,
let F denote an array that stores the values of all 15 neighborhood conguration
ags that are dened in the previous section. Further, we assume the ordering
of the ags stored in F is the same as in Denition 1. Denition 2 denes the
topological relationship encoding for two volume objects.
Denition 2. Let A, B be two volume objects in R3 (A, B R3 ), and let FV

denote the function that encodes the topological interaction between two volumes
with respect to the ith neighborhood conguration ags value (1 i 15). Then
we have:

0 if F [i] yields false for A and B
FV (A, B, i) =
1 if F [i] yields true for A and B
Thus, we can use a 15 bit binary array to encode the topological relationship
between A and B. The denition for the topological relationship encoding TRE
is given as:
TRE (A, B) = (FV (A, B, 0) FV (A, B, 1) ... FV (A, B, 14))
Denition 2 introduces a 15 bits binary representation for the topological re-

lationships between two volume objects. Figure 3 presents three examples of
the topological relationship encodings. The encoding in Figure 3a indicates that
9 topological relationship ags yield true for the scenario involving A and B,
which are exist nei in overlap, exist nei in op1, exist nei in op2, exist nei in ext,
exist nei contain overlap op1, exist nei contain overlap op2, exist nei contain
op1 ext, exist nei contain op2 ext, and exist nei contain op1 op2 overlap ext. To
demonstrate the validity of the encoding, we have marked the corresponding
points pi that validates the true value of ag F [i]. In Figure 3b, three addi-
tional ags, which are exist nei contain op1 op2, exist nei contain op1 op2 ext,
and exist nei contain op1 op2 overlap, become true due to the points p8 , p11 ,
and p14 respectively. Therefore, Figure 3 presents three dierent topological re-
lationships that can be distinguished by our encoding, which are overlap encoded
by 111111001100001, overlap with meet on face encoded by 111111011110011,
and overlap with meet on edge encoded by 111111001110001.
As a result, we obtain a total of 215 = 32768 possible topological relationship
encoding values, which implies a total of 32768 possible topological relationships
between two volume objects. However, not all encoding values represent valid
topological relationships. We call a topological relationship encoding valid for
two volumes if, and only if, it can be derived from a real world scenario that
involves two volume objects. For example, there does not exist a real world
scenario with the topological relationship encoding 000000000000000. Thus, the
open questions are now (i) which are the valid topological relationship encod-
ings for two complex volumes, (ii) which are the valid topological relationship
encodings for two simple volumes, and (iii) what their numbers are. However,
due to space limitation, our goal is only to propose the basic modeling strategy
in this paper; thus, we leave these questions open.
4 The Comparison of NCM with 9IM Based Models

Our neighborhood conguration model and the 9-intersection based models share
an important basis, which is point set theory and point set topology. This basis
is important because it enables the modeling strategies to stay in the abstract
topological space where only point sets are used and the discrete representation
of a spatial object is not relevant. As a result, models based on point sets are more
general than other models that leave the abstract topological space. No matter
what data representation of a spatial object is used, the models based on the
point sets will always work. On the other hand, models based on one particular
representation of spatial objects may not work or may yields dierent results on
another representation of the same spatial objects. For example, the dimensional
model [11] (DM) is based on the dimensional elements of spatial objects, which
determines the corner points of a region object as 0D elements. It highly depends
on the representation of a spatial object, and it yields dierent results for a circle
with a smooth boundary and a circle with its boundary approximated with
a set of connected segments. Therefore, in this section, we only compare our
model with the 9IM model, and show that we can distinguish more topological
relationships between two volume objects.
According to [6], 8 topological relationships are distinguished between two
simple 3D volume objects. Figure 4 shows the 8 congurations and their cor-
responding 9IM matrices. To demonstrate that our model can also distinguish

0 0 1 0 0 1 1 1 1 1 0 0
9IM 0 0 1 0 1 1 1 1 1 1 1 0
1 1 1 1 1 1 1 1 1 1 1 1
NCM (011100001100000) (011100011110000) (111111001100001) (101101100101000)

1 0 0 1 1 1 1 1 1 1 0 0
9IM 1 0 0 0 1 1 0 0 1 0 1 0
1 1 1 0 0 1 0 0 1 0 0 1
NCM (101101000100000) (110110101000100) (110110001000000) (100100100000000)
Fig. 4. The 8 topological relationships between two volumes that can be distinguished
with both 9IM and NCM
B

1 1 1 1 1 1 1 1 1 1 1 1
9IM 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1
NCM (111111011110011) (111111011110001) (111111101101001) (111111111111001)
Fig. 5. The 4 topological relationships that can be distinguished with NCM but not
9IM
these 8 topological relationships, we also list our topological relationship en-

coding for each conguration in Figure 4. We observe that for all 8 topological
relationships the topological relationship encodings are also dierent.
Moreover, the 9IM model only picks up the dominating topological relation-
ships such as overlap, and ignores other topological relationship factors that may
also exist at the same time, e.g. meet at a face. However, since we start with a
very small neighborhood of each point, we are able to capture more ne-grained
topological relationships. In Figure 5, we have listed 4 topological relationships
that can be distinguished with our NCM model but are all identied simply as
overlap in the 9IM model. Apart from the overlap relationship between A and
B, the topological relationships like A meets B on a face from the outside (rst
and second scenario in Figure 5), A meets B on a face from the inside of B
(third scenario in Figure 5), and A has a component inside B and touches B on
a face (fourth scenario in Figure 5) are all distinguished in our model.
Therefore, we can conclude that our NCM model is more powerful than 9IM
based models in terms of dierentiating topological relationships between two
volume objects, especially complex volumes.
In this paper, we have introduced a novel framework for distinguishing topolog-

ical relationships between two volume objects. Our approach is based on point
set theory and point set topology, and by identifying the neighborhood congu-
rations of all points, we can encode and distinguish the topological relationships.
We have also made a comparison between our model and the popular 9IM model
in an informal manner, and have shown that we can distinguish more topolog-
ical relationships than the 9IM can. However, we were not able to explore all
topological relationships that our model can distinguish in a systematical way
due to space limitation. Thus, in the future, our goal is to nd the answer to the
open questions that we mentioned at the end of Section 3.3, and further extend
our model to other complex 3D spatial objects like surfaces and lines.
References
1. Egenhofer, M.J., Herring, J.: A Mathematical Framework for the Denition of
Topological Relationships.. In: Int. Symp. on Spatial Data Handling, pp. 803813
(1990)
2. Clementini, E., Felice, P.D., Oosterom, P.: A Small Set of Formal Topological
Relationships Suitable for End-user Interaction. In: 3rd Int. Symp. on Advances in
Spatial Databases, pp. 277295 (1993)
3. McKenney, M., Pauly, A., Praing, R., Schneider, M.: Dimension-rened Topological
Predicates. In: 13th ACM Symp. on Geographic Information Systems (ACM GIS),
pp. 240249 (2005)
4. Chen, J., Li, C., Li, Z., Gold, C.: A Voronoi-based 9-intersection Model for Spatial
Relations. International Journal of Geographical Information Science 15(3), 201
220 (2001)
5. Schneider, M., Behr, T.: Topological Relationships between Complex Spatial Ob-
jects. ACM Trans. on Database Systems (TODS) 31(1), 3981 (2006)
6. Egenhofer, M.J.: Topological Relations in 3D. Technical report (1995)
7. Zlatanova, S.: On 3D Topological Relationships. In: 11th Int. Conf. on Database
and Expert Systems Applications (DEXA), p. 913 (2000)
8. Borrmann, A., van Treeck, C., Rank, E.: Towards a 3D Spatial Query Language for
Building Information Models. In: Proceedings of the Joint International Conference
for Computing and Decision Making in Civil and Building Engineering (2006)
9. Pigot, S.: Topological Models for 3D Spatial Information Systems. In: International
Conference on Computer Assisted Cartography (Auto-Carto), pp. 368392 (1991)
10. Guo, W., Zhan, P., Chen, J.: Topological Data Modeling for 3D GIS. Int. Archives
of Photogrammetry and Remote Sensing 32(4), 657661 (1998)
11. Billen, R., Zlatanova, S., Mathonet, P., Boniver, F.: The Dimensional Model: a
Framework To Distinguish Spatial Relationships. In: Int. Symp. on Advances in
Spatial Databases, pp. 285298 (2002)
12. Schneider, M., Weinrich, B.E.: An Abstract Model of Three-Dimensional Spatial
Data Types. In: 12th ACM Symp. on Geographic Information Systems (ACM GIS),
pp. 6772 (2004)
Reasoning with Complements
Max J. Egenhofer
National Center for Geographic Information and Analysis

School of Computing and Information Science
University of Maine
Boardman Hall, Orono, ME 04469-5711, USA
max@spatial.maine.edu
Abstract. This paper develops a method to determine consistenly the

integration of spatial integrity specifications, particularly for the case when two
constraints, c1 and c2, are applied between three classes A, B, C (i.e., A c1 B
and B c2 C), as such scenarios give rise to an implied consistency constraint c3
that holds between A and C. To determine c3, the mere composition reasoning
with c1 and c2 is often insufficient, as it lacks consideration of the interferes
that come through c1s and c2s complements. Two augmentation methods are
introduced, one with a constraints complement to yield the specified constraint
between all pairs of members of A and C, the other as the least upper bound of
c1 and c2 with the constraints poset of possible transitions between constraints.
Keywords: Spatial reasoning, conceptual modeling, integrity constraints,

topological relations, consistency.
1 Introduction
Associations between and aggregations of spatial objects are often specified by
integrity constraints to ensure consistent semantics. The consideration of spatial
relations as part of such integrity constraints offers a focus that is innate to the
modeling and analysis of geospatial semantics. Such spatial relations may be applied
at the instance level (e.g., Orono is inside the State of Maine) or in an ontology or a
conceptual schema at the class level (e.g., islands are surrounded by waterbodies).
The spatial relations used are typically qualitative spatial relations, which abstract
away the myriad of quantitative detail, while they capture comprehensively some of
the most critical traits of how individuals are related to each other. This paper focuses
on the consistency of such spatial integrity specifications, particularly for the case
when two constraints, c1 and c2, are applied between three classes A, B, C (i.e., A c1
B and B c2 C), as such scenarios give rise to an implied consistency constraint c3 that
holds between A and C.
The mere specification of a spatial relation at the class level is typically
insufficient, as it does not quantify the relation. Therefore, associations are often
supplemented with their cardinalities, specifying the relations as n:m (with n and m
typically taking on values of ZZ 2 ). For relation specified between classes A and B,
such cardinality specifications yield multiple (each instance of class A may be
262 M.J. Egenhofer
related to 0, 1, or many instances of class B), singular (each instance of class A has
exactly one instance of class B), or optional (each instance of class A may be
related to one instance of class B) associations and aggregations. The use of such
annotations has become standard practice in conceptual schema design for spatial
applications [1,2,9,10] to model spatial properties at the class level, but without
extensive quantification it often still lacks the ability to capture the intended
semantics fully. A comprehensive classification of constraints on relations has
identified a set of 17 abstract class relations [7,8], which apply to associations,
specifying concisely how a specific binary relation (e.g., a topological relation) must
be distributed among the participating objects in order to yield a valid representation.
For instance, an island cannot exist without a surrounding water body, which requires
that each island has a surroundedBy relation with respect to a waterbody (captured by
a left-total specification). Such spatial integrity constraints may be nested. For
instance, the additional constraint that any lake on an island must be inside a single
islanda constraint that is left total and injectiveimplies that there is also the
topological relation surroundsWithoutContact between the lake on the island and the
waterbody in which the island is located. This paper addresses how to determine
correctly not only the implied spatial relation, but also the implied abstract class
relation.
The remainder of the paper is structured as follows: Section 2 briefly summarizes
the 17 abstract class relations. Section 3 introduces the specification of the
complement constraint and Section 4 includes complement constraint into the
derivation of compositions. The paper closes with conclusions in Section 5.
2 Integrity Constraints and Topological Integrity Constraints

This paper bases the modeling of spatial integrity constraints on the results of two
complementary models: (1) the abstract class relations to capture how instances of an
association must be related in order to form a valid implementation of a conceptual
data model, and (2) the binary topological relations between regions. The integrity
constraint model builds on the work by Donnelly and Bittner [3], and Ms [7,8].
Donnelly and Bittner introduced three base constraints to capture totality of a relation
(Eqs. 1a-c) and a fourth constraint for non-total relations (Eqn. 1d).
D&B
R some (A,B):=xy(Inst(x,A) Inst(y,B) r(x,y)) (1a)
all-1 (A,B):=x(Inst(x,A) y(Inst(y,B) r(x,y)))
R D&B (1b)
R D&B
all-2 (A,B):=y(Inst(y,B) x(Inst(x,A) r(x,y))) (1c)
R D&B
all-all (A,B):=xy(Inst(x,A) Inst(y,B) r(x,y)) (1d)
Ms [7] augmented this set with another two constraints, refining the non-total
specification to address definiteness, such as the injective relation left-definite
(Eqs. 2a and 2b).
R Left-D (A,B):=x,y,z(Inst(x,A) Inst(y,B) Inst(z,A)
(2a)
r(x,y) r(z,y) x=z) R some
D&B
(A,B)
R Right-D (A,B):=x,y,z(Inst(x,A) Inst(y,B) Inst(z,B)
(2b)
r(x,y) r(x,z) y=z) R some
D&B
(A,B)
Reasoning with Complements 263
In combination these six base constraints yield 17 abstract class relations as

combinations of left-definite (LD), right-definite (RD), left-total LT), and right-total
(RT) (Figure 1). Although the naming conventions assigned may suggest otherwise,
no two different constraints apply to a single configuration. For instance, if a
constraint is classified as LD, then none of the other constraints that carry LD in their
name (i.e., LD.RD, LD.LT, LD.RT, LD.RD.LT, LD.RD.RT, LD.LT.RT, and
LD.RD.LT.RT) is possible. The universal consistency constraintthat is the
exclusive disjunction of all 17 abstract class relationsis denoted by .
R Left-D R Right-D R D&B

all-1 R D&B
all-2 R D&B
all-all
D&B
R some
LD
x
RD x
LT x
RT x
LD.RD x x
LD.LT x x
LD.RT x x
RD.LT x x
RD.RT x x
LT.RT x x
LT.RT-all x
LD.RD.LT x x x
LD.RD.RT x x x
LD.LT.RT x x x
RD.LT.RT x x x
LD.RD.LT.RT x x x x
some x
Fig. 1. Specification of the 17 abstract class relations [7] in terms of six base constraints: x
means a required base constraint, while stands for a negative constraint. For instance, LD
fully develops to R LD (A,B):=R Left-D (A,B) R Right-D (A,B) R all-1 (A,B) R all-2 (A,B)
D&B D&B
The relations to which the abstract class relations are applied is the set of eight
topological relations between two regions (Figure 2), which derives from the 4-
intersection [6]. The universal topological relation as the disjunction of all eight
relations is referred to by .
disjoint meet overlap equal coveredBy inside covers contains
Fig. 2. The eight topological relations between two regions in IR 2 with the relations labels
264 M.J. Egenhofer
Both relation models share at the meta-level a number of properties.

The 17 abstract class relations and the eight region-region relations in IR 2 are
jointly exhaustive and pairwise disjoint. This property implies that for any two
instancesof a compatible typeexactly one of the 17 constraints and exactly one
of the eight region-region relations applies. Therefore, any disjunction of integrity
constraints or of topological relations is exclusive (denoted by ).
Both sets feature an identity relation (LD.RD.LT.RT and equal).
In both sets, each abstract class relation and each topological relation has a
converse relation. If converses map onto themselves the relations are symmetric.
Both sets feature a complete composition table [4,8], which captures the result of
combining two relations over the same object. None of the 17x17 and 8x8
compositions results in an empty relation.
Both composition tables follow the axioms of a relation algebra, in particular the
composition with the respective identity relation is idempotent, and the converses
of compositions are compositions of converse relations, taken in reverse order.
3 Complements of Topological Integrity Constraints

If an association holds between two different classes A and B and the relation that
links the two classes is from a set of relations that are jointly exhaustive and pairwise
disjoint, then all instances of the two classes form a complete bipartite graph. In a
bigraph the vertices can be divided into two disjoint sets A and B such that every edge
connects a vertex in A with a vertex in B. A bigraph is complete if every vertex in A
has an edge to every edge in B. Such a complete bigraph is specified by the integrity
constaint LT.RT-all (Figure 3a). For instance, two simply-connected, hole-free
regions embedded in IR 2 are always related by exactly one of the eight topological
region-region relations [6]. Therefore, the universal topological relations applies by
default as the constraint LT.RT-all (Figure 3b).
(a) (b)
Fig. 3. (a) The complete bigraph formed by the LT-RT-all relation between all instances of
class A and class B and (b) the constraint that any disc-like regions embedded in IR 2 must be
related by exactly one of the eight topological region-region relations to another disc-like
region B
Associations typically specify the entities relation only with respect to its host .
For example, building ( inside coveredBy )RD.LT landParcel captures each
buidlings relation with the one land parcel that it is built on (excluding such special
cases a building being partially built on a neighboring lot or a buildings footprint
extending over an entire land parcel). The integrity constraint RD.LT also captures
that each building must have the relation with resepct to a land parcel (because the
constraint is left-total), that there are also land parcels that have no building on it
(because the constraint is not right-total), and that a land parcel may have multiple
buildings on it (because the constraint is not left-definite). It does not include,
however, a specification of the relation and the integrity constraint with all other land
parcels than the buildings host. Such a relation exists, however between each
building and each land parcel other than the buildings host. For instance, if building
a1 is coveredBy landParcel b1, and b1 meets land parcel b2, then building a1 and
landParcel b2 would either be disjoint or they would meet. On the other hand, if
building a2 is inside landParcel b1, then a2 would be disjoint from b2 without an
option that a2 and b2 meet.
The complement of a topological integrity constraint captures the topological
relations that must hold between all instances of the related classes other than the
hosts. As a topological integrity constraint, the complement has a topological
component and an integrity constraint. Its topological component follows from the
relations compositions [4]. For building ( inside coveredBy )RD.LT landParcel the
topological complement is building ( disjoint meet ) landParcel. It applies to all
buildings, therefore, the complement constraint must be left-total. Only if all
buildings were inside their respective host parcel the topological complement would
be unambiguously disjoint.
With respect to the land parcels, the integrity constraint is ambiguous as well, as
three different scenarios may occur: (1) all buildings are on one land parcel, and there
exists a second land parcel (without a building on it); (2) all buildings are on one land
parcel, and there exist at least another two land parcels (each without a building); and
(3) buidlings are on more than one land parcel. In the first case the complement of
RD.LT is RD.LT (Figure 4a), while in the second case RD.LTs complement is the
mere left-total constraint LT (Figure 4b). For the third case the complement of RD.LT
is left-total and right-total, yielding the constraint LT.RT. So the constraint building
(disjoint meet)LT.RTRD.LTLT landParcel is the complement of the constraint
(inside coveredBy)RD.LT (Figure 4c).
(a) (b) (c)
Fig. 4. Complement constraints for RD.LT: (a) LT, (b) RD.LT, and (c) LT.RT
266 M.J. Egenhofer
In order to derive the complement for each of the 17 abstract class relations, the
bigraph of each constraint was represented by an ordered pair of strings of the
vertices degrees [string1; string2]string1 stands for the source, and string2 for the
target. The sequence of the degrees within a string is immaterial. For instance, the two
graphs in Figure 4b are captured by the two strings [1,1; 2,0] and [1,1; 0,2]. These two
graphs are isomorphic, as captured by the same source strings and same target strings.
For any of the 17 constraints, its complete bigraph serves as the base for determining
its complement. The number of vertices in the source determines the degree of each
vertex in the complete bigraphs target, while the number of vertices in the target
determines the degree of each vertex in the complete bigraphs source. The
complement of a constraint c, denoted by c , is then the difference between the
degree strings of its complete bigraph and the constraints degree string. For example,
the degree string of the constraint depicted in Figure 4a is [1,1; 2,0,0], and the degree
string of its complete bigraph is [3,3; 2,2,2]. The complement of [1,1; 2,0,0] is then
[3-1,3-1; 2-2,2-0,2-0], that is [2,2; 0,2,2].
The complements of all 17 abstract class relations (Figure 5) were derived from all
respective bigraphs up to cardinality 5. No additional complements were found
beyond cardinality 4. Completeness will be proven in the future.
c c c c
LD.RD LT.RT RD.RT LD.RD.RT, RD.RT, LT.RT
LD LT.RT LT RD.LT,LT, LT.RT
RD LT.RT RT LD.RT,RT, LT.RT
some LT.RT LD.RD.LT.RT LD.RD.LT.RT, LT.RT
LD.RD.LT LD.RD.LT, LD.LT, LT.RT LD.LT.RT LD.LT.RT, LT.RT
LD.RD.RT LD.RD.RT, RD.RT, LT.RT RD.LT.RT RD.LT.RT, LT.RT
LD.RT LD.RT, RT, LT.RT LT.RT \ LT.TR-all
RD.LT RD.LT, LT, LT.RT LT.RT-all
LD.LT LD.RD.LT, LD.LT, LT.RT LT.RT-all
Fig. 5. The complements c to the 17 abstract class relations c (plus, for completeness, the
empty constraint)
Four constraints (LD.RD, LD, RD, and some) have a unique, non-trivial
complement. LT.RT-all (which forms the complete bigraph) has the empty graph as
its complement. On the other end of the spectrum is complement to LT.RT, which is
the universal constraint relation , except for LT-RT-all. The remaining eleven
constraints complements are each of cardinality 3, always including LT.RT.
4 Reasoning with Complements of Topological Integrity

Constraints
The composition inferences over topological integrity constraints appear to be straight

forward, given the compositions of abstract class relations [8] and the compositions of
the binary topological relations [4]. Given two topological integrity constraints t1c1
and t2 c2 , where t1 and t2 are a topological region-region relation and c1 and c2 are
an abstract class relation, Ms showed how to produce their composition as the

Cartesian product of the class relation composition and the topological relation
composition (t1 ; t2)(c1 ;c2) t1c1 ; t2 c2 . This inference, however provides only a lower
bound for the inferred topological integrity constraint as it unaccounts for any
additional inferences that may result from the complements. For instance, calculating
the composition meet some ; containsLD.RD.LT.RT containsLD.RD.LT.RT as the mere Cartesian
product of the the class relation composition and the topological relation composition
yields A disjoint some C . There may be, however, additional instances of A and C that
are disjoint without being related to another region through a meet-contains chain. For
instance, if there is an region d such that aA disjoint d and d covers cC , then there
exists an additional relation between A and C, which may turn the constraint
A disjoint some C into the stronger constraint A disjoint LT C or A disjoint RT C .
The additional relation results from considering one of the complement relations. If
additional disjoint relations are found, then the constraint could become even
stronger, either A disjoint LT.RT C or A disjoint LT.RT-all C .
4.1 Compositions with Complements
Accounting fully for the complement relations turns the calculation of the
composition of two topological integrity constraints into a multi-step process. Two
topological integrity constraints t1c1 and t2 c2 yield the composition of the actual
relations (Eqn. 3a) as well as the three compositions involving their complements
t1c1 and t2 c2 (Eqs. 3b-d).
t3c3 (t1 ; t2)(c1 ; c2) t1c1 ; t2 c2 (3a)
t4 c4 (t1 ; t2)(c1 ; c2 ) t1c1 ; t2 c2 (3b)
t5 c5 (t1 ; t2)(c1 ; c2 ) t1c1 ; t2 c2 (3c)
t6 c6 (t1 ; t2)(c1 ; c2) t1c1 ; t2 c2 (3d)

There is no guarantee, however, the complement compositions always enhance the
base inference. For example, the composition of meet some and containsLD.RD.LT.RT ,
which yields disjoint some , is complemented by three compositions with complements
(Eqs. 4a-c). Since each topological complement inference results in this case in the
universal topological relation , no conclusive inferences can be made.
LT.RTLT.RT-all (( \ meet);( \ contains))LT.RT;(LD.RD.LT.RTLT.RT)
(4a)
meet some ; contains LD.RD.LT.RT
RDsomeRD.RTRT (meet ; ( \ contains))some ; (LD.RD.LT.RTLT.RT)
(4b)
meet some ; containsLD.RD.LT.RT
LT.RT (( \ meet) ; contains)LT.RT ; LD.RD.LT.RT meet some ; containsLD.RD.LT.RT (4c)
In case that all a A form a partition of space, the topological complement of meet
can only be disjoint (rather than \ meet ). This restriction yields one more
constrained complement compositions (Eqs. 5c), while the other three complement
268 M.J. Egenhofer
compositions remain inconclusive (Eqs. 5a and 5b). For the time being only
conclusive complement composition inferences will be used. The role of inconclusive
inferences will be explored in the future.
LT.RTLT.RT-all (disjoint ; ( \ contains))LT.RT ; (LD.RD.LT.RTLT.RT) (5a)
RDsomeRD.RTRT (disjoint ; ( \ contains))some ; (LD.RD.LT.RTLT.RT) (5b)
disjoint LT.RT (disjoint ; contains)LT.RT ; LD.RD.LT.RT (5c)
4.2 Constraint Augmentation with Complements
The next step is the attempt to augment a base inference (e.g., Eqn. 3a) with the result
of a conclusive complement composition (e.g., Eqn. 5c). The topological integrity
constraint t3c3 is the base, and class relation c3 may be augmented if any of the
three compositions with the complements results in the topological relation t3 as well
(i.e., t3=t4 or t3=t5 or t3=t6). In such cases, the augmented class relation is then the
result of combining the corresponding class relation with c3 (Eqn. 6).
c3 e ci t3=ti46 (6)
For the composition of meet some with contains LD.RD.LT.RT the composition of the
complement of meet some with contains LD.RD.LT.RT (Eqn. 5c) has the same resulting
topological relation disjoint; therefore, disjoint some may be augmented
by disjoint LT.RT . Since LT.RT is the complement of the class relation some (Figure 5),
the augmentation of these two class relations ( some e LT.RT ) yields LT-RT-all for
the topological relation disjoint (Eqn. 7).
disjoint LT.RT-all meet some ; containsLD.RD.LT.RT (7)
4.3 Constraint Augmentation from Transitions
The augmentation to LT-RT-all is the strongest result of an integration as the resulting

composition forms a complete bigraph. Other augmentations are also possible
whenever the class relations over the same topological relation are not complements.
Since an augmentation of the base relation essentially means the addition of at least
one edge to the class relations graph one can derive all possible transitions that are
due to the addition of one or more edges. Not all of the 17x17 possible transitions are
feasible, however. For instance, one cannot add another edge to the graph of LT.RT-
all, because it is already a complete bigraph. On the other hand, if one finds a
transition from A to B, then the reverse transition from B to A will be infeasible with
the addition of an edge.
Five conflicts govern which of the 289 transitions are impossible. While these
conflicts are not multually exclusiveseveral potential transitions respond to multiple
conflictsall five a necessary in order to derive the set of feasible transitions (i.e.,
those transitions that do not respond to any of the five conflicts).
Cardinality conflict: The binary class relation A 2 c2 B2 cannot result from the
addition of a relation to the binary class relation A1 c1 B1 if c1 and c2 require
different counts of instances. For example, RLD.RD.LT.RT requires that that the
cardinalities (#) of A and B are the same, while RRD.LT.RT requires that
#( A) > #( B) . Ms [7] determined cardinality constraints for seven class relations
(5, 6, 9, 10, 13, 14, 15), whose 49 combinations create 24 cardinality conflicts.
Definiteness-totality conflict: Transitions from a relation that is a-definite.b-total
( a,b {left,right} ) cannot yield a relation that contains a-definite.b-total, because
the definite property cannot be retained when adding an edge to it).
Definiteness increase: The addition of a relation to a class relation that is not a-
definite (a {left,right}) cannot turn that relation into an a-definite class relation.
Totality decrease: The addition of a relation to an a-total class relation
(a {left,right}) cannot turn it into a class relation that lacks the a-total property.
Complete-graph conflict: LT.RT-all is a complete bigraph, so that the addition of
another edge is impossible.
Out of the 289 transitions, only 80 are feasible, among them nine transitions between a
class relation an itself (LD.RD, LD, RD, some, RD.LT, LD.LT, LT, RT, LT.RT). Such
idempotent transitions have no effect on the augmentation of a derived base relation.
Among the remaining 71 transitions are 44 atomic transitions (i.e., they cannot be
obtained from successive combinations of other transitions) and 27 that can be obtained
by two or more successive application of an atomic transition. The feasibility of all 44
transitions was confirmed by constructing for each transition two corresponding bigraphs
that differ only by the addition of one edge. All feasible transitions are comprehensively
captured by the transition graph (Figure 6), a directed conceptual neighborhood graph [5]
in the form of a partially-ordered set, with LD.RD as the bottom element and LT.RT-all
as the top element. The augmentation of a class relation with another one is then the least
upper bound of these two relations within the transition poset (i.e., the least element that
is common to the two class relations that participate in the augmentation). This property
also shows that augmentation is commutative as c ci equals ci c .
Fig. 6. The transition graph of the 17 class relations when adding an edge to a relation
5 Conclusions
In order to guarantee consistency in the specification with spatial integrity constraints,
not only the soundness of compositions of must be considered, but also the
270 M.J. Egenhofer
compositions with the constraints complements. For Mss 17 abstract class relations
[7] we derived their complements, and developed two methods of augmenting spatial
integrity constraints. The first method, which applies when composition and
complement composition are complementary, leads to the complete graph. For the
second method that applies to any pair of the 17 abstract class relations, we developed
the transition poset, a type of conceptual neighborhood graph that captures transitions
between class relations when adding an additional edge to the bigraph of a constraint.
Acknowledgments. This work was partially supported by partially supported by the

National Science Foundation under NSF grant IIS1016740. Discussions with Stefan
Ms are gratefully acknowedged.
References
1. Belussi, A., Negri, M., Pelagatti, G.: An ISO TC 211 Conformant Approach to Model
Spatial Integrity Constraints in the Conceptual Design of Geographical Databases. In:
Roddick, J., Benjamins, V.R., Si-said Cherfi, S., Chiang, R., Claramunt, C., Elmasri, R.A.,
Grandi, F., Han, H., Hepp, M., Lytras, M.D., Mii, V.B., Poels, G., Song, I.-Y., Trujillo,
J., Vangenot, C. (eds.) ER Workshops 2006. LNCS, vol. 4231, pp. 100109. Springer,
Heidelberg (2006)
2. Borges, K., Laender, A., Davis, C.: Spatial Data Integrity Constraints in Object Oriented
Geographic Data Modeling. In: Bauzer Medeiros, C. (ed.) 7th International Symposium on
Advances in Geographic Information Systems, pp. 16. ACM, New York (1999)
3. Donnelly, M., Bittner, T.: Spatial Relations Between Classes of Individuals. In: Cohn,
A.G., Mark, D.M. (eds.) COSIT 2005. LNCS, vol. 3693, pp. 182199. Springer,
Heidelberg (2005)
4. Egenhofer, M.: Deriving the Composition of Binary Topological Relations. Journal of
Visual Languages and Computing 5(2), 133149 (1994)
5. Egenhofer, M.: The Family of Conceptual Neighborhood Graphs for Region-Region
Relations. In: Fabrikant, S.I., Reichenbacher, T., van Kreveld, M., Schlieder, C. (eds.)
GIScience 2010. LNCS, vol. 6292, pp. 4255. Springer, Heidelberg (2010)
6. Egenhofer, M., Franzosa, R.: Point-Set Topological Relations. International Journal of
Geographical Information Systems 5(2), 161174 (1991)
7. Ms, S.: Reasoning on Spatial Semantic Integrity Constraints. In: Winter, S., Duckham,
M., Kulik, L., Kuipers, B. (eds.) COSIT 2007. LNCS, vol. 4736, pp. 285302. Springer,
Heidelberg (2007)
8. Ms, S.: Reasoning on Spatial Relations between Entity Classes. In: Cova, T.J., Miller,
H.J., Beard, K., Frank, A.U., Goodchild, M.F. (eds.) GIScience 2008. LNCS, vol. 5266,
9. Pelagatti, G., Neri, M., Belussi, A., Migliorini, S.: From the Conceptual Design of Spatial
Constraints to their Implementation in Real Systems. In: Agrawal, D., Aref, W., Lu, C.-T.,
Mokbel, M., Scheuermann, P., Shahabi, C. (eds.) 17th ACM SIGSPATIAL International
Symposium on Advances in Geographic Information Systems, pp. 448451. ACM, New
York (2009)
10. Tryfona, N., Hadzilacos, T.: Logical Data Modeling of SpatioTemporal Applications:
Definitions and a Model. In: Eaglestone, B., Desai, B., Shao, J. (eds.) International
Database Engineering and Applications Symposium, pp. 1423. IEEE Computer Society,
Los Alamitos (1998)
Towards Modeling Dynamic Behavior with
Integrated Qualitative Spatial Relations
Stefan Mitsch, Werner Retschitzegger, and Wieland Schwinger
Johannes Kepler University Linz, Altenbergerstr. 69, 4040 Linz, Austria

firstname.lastname@jku.at
Abstract. Situation awareness and geographic information systems in

dynamic spatial systems such as road trac management (RTM) aim
to detect and predict critical situations on the basis of relations be-
tween entities. Such relations are described by qualitative calculi, each
of them focusing on a certain aspect (e. g., topology). Since these calculi
are dened isolated from each other, dependencies between then are not
explicitly modeled. We argue, that a taxonomycontaining a plethora
of special cases of inter-calculi dependenciescan only be dened in a
consistent manner, if evolution of entities and the relations of calculi
are grounded in a unied model. In this paper, we dene such a unied
model, which is used to derive a taxonomy of inter-calculi dependency
constraints contained in an ontology utilizing various spatial calculi. The
applicability of this approach is demonstrated with a case study in RTM,
and concluded with lessons learned from a prototypical implementation.
1 Introduction
Situation Awareness in Dynamic Spatial Systems. Situation awareness
and geographic information systems (GIS) are gaining increasing importance in
dynamic spatial systems such as road trac management (RTM). The main goal
is to support human operators in assessing current situations and, particularly, in
predicting possible future ones in order to take appropriate actions pro-actively.
The underlying data describing real-world entities (e. g., tunnel) and their spatial
relations (e. g., inside, near), which together dene relevant situations (e. g., a
trac jam inside and near the boundary of a tunnel), are often highly dynamic
and vague. As a consequence reliable numerical values are hard to obtain, which
makes qualitative modeling approaches better suited than quantitative ones [17].
Dynamic Behavior in Qualitative Spatial Calculi. Recently, ontology-
driven situation awareness techniques [1],[6] and qualitative approaches to mod-
eling the dynamic behavior of spatial systems [3] have emerged as a basis for
predicting critical situations from relations between objects. Such relations are
expressed by employing multiple relation calculi, each of them focusing on a cer-
tain aspect, such as topology [8], [20], size [13], or distance [15]. These calculi

This work has been funded by the Austrian Federal Ministry of Transport, Innovation
and Technology (BMVIT) under grant FIT-IT 829598.

272 S. Mitsch, W. Retschitzegger, and W. Schwinger
are often temporalized by means of Conceptual Neighborhood Graphs (CNGs,

[9]) and dominance spaces [10], [11], imposing constraints on the existence of
direct transitions between relations. The domain-independent nature of calculi
and their focus on a particular aspect of relationship (e. g., topology), however,
results in dependencies between calculi being not explicitly modeled (e. g., topo-
logical transitions imply transitions in the distance between object boundaries).
In a pioneering work on qualitative distance, Clementini stresses the importance
of interdependency between calculi as follows: the meaning of close depends not
only on the actual relative position of both objects, but also [on] their relative
sizes and other scale-dependent factors [5].
A Unied Model for Inter-calculi Dependencies. Ontology-based ap-
proaches to dynamic spatial systems utilizing multiple calculi tackle the inte-
gration of these calculi by providing dedicated modeling primitives, for instance
in terms of so-called axioms of interaction [3] and relation interdependencies [2].
Since these approaches, however, completely abstract from the underlying con-
tinuous space, a taxonomy exhaustively describing inter-calculi dependencies is
still missing. We argue, that such a taxonomycontaining a plethora of special
cases of inter-calculi dependenciescan only be dened in a consistent manner,
if evolution of spatial primitives (e. g., regions) and the relations of calculi are
grounded in a unied model. In order to dene such a unied model for mo-
tion and scaling of spatial primitives and their eects in terms of transitions
in topology, size, and distance, we base on Galtons approach to constructing a
homomorphic image of the full space of possible region-pairs [11].
Structure of the Paper. In the next section, the focus of this work is detailed
as the basis for discussing relevant related work. In Sect. 3, a unied model for
spatial calculi is presented along with a case study in the domain of RTM. The
model is the basis for an ontology briey sketched in Sect. 4. Finally, Sect. 5
concludes the paper with lessons learned from a prototypical implementation.
2 Related Work
In this section, we discuss related work on modeling the dynamic behavior of
spatial systems with qualitative spatial reasoning approaches, focusing on those
approaches in the domain of GIS. In this discussion, we follow the common on-
tological distinction (cf. the SNAP/SPAN approach [14]) often applied in GIS
[12] , [23] between the states of a system describing relations between entities
from a snapshot point-of-view, and the evolution between these states in terms
of occurrents, such as events and actions. Causal relations between states and
occurrents [12] comprise (i) qualication constraints dening preconditions for
states (i. e., states enable or disable other states, e. g., being smaller enables be-
ing a part), and for occurrents (i. e., states allow or prevent occurrents, e. g.,
having very close boundaries enables becoming externally connected), whereas
Integrated Qualitative Calculi 273
(ii) frame constraints dene eects of occurrents1 (i. e., occurrents cause other
occurrents, e. g., motion causes two objects becoming disrelated). In this paper,
we focus on qualication constraints for states and occurrents, since these are
the primary source of inter-calculi dependencies.
Many qualitative spatial reasoning approaches (e. g., [7], [10], [11], [21]) pro-
vide or utilize a single qualitative spatial calculus modeling a particular aspect,
and naturally, encode qualication constraints in CNGs (i. e., each relation is a
qualication constraint for its neighboring relations). A slightly broader view is
applied in GIS [8], informally discussing states, in particular the size of objects,
as qualication constraints for relations. The same constraint is used in a mod-
eling framework for dynamic spatial systems [4] as qualication constraint on
the transitions between relations. Arbitrary qualication constraints spanning
multiple qualitative spatial calculi are explicitly supported in Bhatts approach
to modeling the dynamic behavior of spatial systems [3] in the form of so-called
axioms of interaction. However, this modeling approach lacks a taxonomy of
states and constraints. As a consequence, both must be provided by users of this
modeling framework, instead of being integrated within its ontology.
Focusing on the integration of multiple calculi, Gerevini and Renz [13] discuss
interdependencies between the Region Connection Calculus (RCC) and their
Point Algebra for describing size relations. These interdependencies describe
qualication constraints for states (i. e., relations) of one calculus in terms of
states of the other. For example, a relation TPP (tangential proper part) of
RCC entails a size relation < (i. e., the contained entity must be smaller than
the containing one). Using the same calculi (RCC and size), Klippel et al. [18]
investigated the impact of dierent size relationships on the relation transitions
in RCC induced by motion events, and the cognitive adequacy of these changes.
Since the interdependencies between topological and size relations are rather
obvious, providing a formal integration model, however, has not been the focus.
Clementini et al. [5] present several algorithms for combining distance and
orientation relations from a compositional point-of-view (e. g., these algorithms
compute the composition of distance relations, given a known orientation rela-
tion). In contrast, we focus on interpreting relations of a particular calculus as
qualication constraints for relations and/or transitions in other calculi.
In summary, existing works lack a model of space and of spatial primitive
pairs, preventing consistent integration of multiple calculi with major evolution
causes (motion, scaling, orientation, shape, cf. [8]). In the next section, we discuss
such a model along three spatial calculi modeling important aspects like topology
(RCC, [20]), distance of boundaries [15], and size [13].
3 Inter-calculi Dependencies in Spatial Calculi

In qualitative spatial reasoning, as introduced above, a multitude of dierent
spatial calculi has been proposed. Although each of these calculi focuses on a
1
Ooccurrents initiating and terminating states (e. g., becoming very close initiates
being very close) are not considered here, since they are modeled in CNGs.
particular aspect of the real world, some of their relations implicitly model other
aspects as well (i. e., these relations restrict the relations that can hold and the
transitions that can occur in another calculus). For instance, a topological non-
tangential proper part relation (NTPP) between two objects does not only dene
that a particular object is contained in another one, but also implicitly denes
that the contained object must be smaller than the containing one [13]. Addi-
tionally, real-world evolution abstracted to transitions in one calculus might be
modeled in more detail in another calculus. For example, a topological transition
from being disconnected (DC) to being externally connected (EC) in RCC is mod-
eled from a distance viewpoint [15] with a sequence of relations and transitions,
comprising transitions from being very far (VF) over far (F) and close (C) to be-
ing very close (VC). We make such assumptions explicit by combining exisiting
calculi with qualication constraints modeling inter-calculi dependencies.
In order to dene such qualication constraints in a consistent manner and
account for a plethora of dierent special cases, a mapping between relations
and the underlying spatial primitives including their numerical representation
is needed. For example, let us consider relations describing the spatial distance
between object boundaries. Since the boundary of an object implicitly denes
its size and center, the options concerning the distance between the boundaries
of two objects can only be narrowed by taking into account information about
their topological relationship, relative size, and distance of their centers: If one
object is known to be a proper part of the other one, a rather small object being
located at the center of a large object is regarded to be very far from the large
objects boundaries, whereas the same object with a large distance to the center
would result in the boundaries being considered to be very close. The boundaries
of two nearly equally-sized objects would be considered very close as well.
As the basis for determining the above sketched variety of special cases making
up inter-calculi dependencies, we base upon Galtons approach [11] to deriving a
two-dimensional image of relations from the CNG of RCC, since this approach
covers the full space of possible region-pairs. In such a two-dimensional image,
the topological relations between two spheres are encoded, using the radii r1 and
r2 of the spheres along the x-axis (x = r1/(r1 + r2)) and the distance d between
their centers on the y-axis (d/2(r1 + r2)). The relations DC (disconnected), EC
(externally connected), PO (partly overlapping), TPP (tangential proper part) and
its inverse TPPi, NTPP (non-tangential proper part) and its inverse NTPPi, as well
as EQ (equals) are dened in terms of these two measures in (1).
DC 0.5 < y < 1 EC y = 0.5
PO |0.5 x| < y < 0.5 EQ x = 0.5 y = 0
(1)
TPP 0 < y = 0.5 x TPPi 0 < y = x 0.5
NTPP y < 0.5 x NTPPi y < x 0.5
The resulting image of possible relations in RCC between intervals in R, cir-
cular regions in R2 , and spheres in R3 is depicted in Fig. 12 . Besides reecting
2
This is dierent from Galton[11], since we normalize both the x- and y-axis metric
with the sum of the radii to obtain a symmetric image.

+'"'%)'()&%"

,'#$ '-'.--$

$&!#%*

Fig. 1. Combined image of topology, distance of boundaries, and size (cf. [11])
the CNG of RCC (neighboring relations in the CNG are neighboring regions,
lines, or points), this image encodes two interesting aspects of evolution: (i) the
implications of motion and scaling, and (ii) the dominance relationship between
relations (e. g., EQ being a point indicates that it can hold for a time instant,
whereas those relations being denoted by regions must hold for a time interval).
Considering the impact of evolution, a point in this gure denoting a particu-
lar relation of RCC moves along the x-axis when one of the spheres changes its
size with respect to the size of the other sphere (i. e., due to scaling), whereas
its movement along the y-axis is caused by motion of the centers (which in turn
is either due to motion of an entire sphere, or scaling). For example, consider
the black dot labelled Holds(rcc (o, o ), N T P P i, s) in the sector NTPPi, denot-
ing that o contains o : in terms of size and distance, this dot means that o is
approximately twice the size of o (cf. 0.67 on the x-axis), and that their centers
are near each other. If o shrinks, the black dot moves along the x-axis to the left,
until o can no longer fully contain o , leading to an overlap relation (represented
by the dot moving from NTPPi into PO). During this scaling, at a single time
instant the boundary of o touches the boundary of o , represented by the dot
passing the line labeled TPPi (i. e., o is a tangential proper part of o). If o shrinks
even further, it will eventually be contained in o (i. e., the dot will move into
TPP). Now consider that the centers of o and o coincide (i. e., their distance is
zero): the same scaling event will then traverse EQ instead of TPPi, PO, and TPP.
We now dene such a space representing relations as points for each of the
employed positional relation calculi (distance of boundaries and size). To begin
with, we discuss the integration of size, since the x-axis in Fig. 1 already expresses
size relationships in terms of the ratio of interval radii r1/(r1+r2). The mapping
to a qualitative size calculus is straightforward: a ratio below 0.5 corresponds to
smaller (<), above 0.5 to larger (>) and one of exactly 0.5 to equal size (=).
Less obvious is the integration of the distance between boundaries. As a start-
ing point, we informally dene that two objects are very close whenever the
boundaries meet, which is the case along the lines labeled EC, TPP, and TPPi,
as well as at the point EQ. To both sides of these lines and around the point
of topological equality, we dene a region where the boundaries are still very
close to each other (e. g., 10%3 o in distance and size as used in Fig. 1). Since
we must consistently encode the CNG (represented by the sequence VF-F-C-VC),
to each side of VC a region C must follow, which itself neighbors to regions F.
Finally, regions VF are positioned at the outermost and innermost sectors of the
image, neighboring only to regions F. Considering PO in conjunction with VC, it
becomes obvious why our metrics are normalized. Let o be much larger than o
(r1 r2) and o overlap with o : their boundaries certainly should be regarded to
be very close to each other, since in comparison to the size of o the distance be-
tween their boundaries is quite small (analogous assumptions hold for r1 r2).
This means, that our image should be symmetric with respect to size equality
(x = 0.5), which cannot be achieved using an unnormalized metric. In (2) be-
low, we dene the distance relation VC with respect to x = r1/(r1 + r2) and
y = d/2(r1 + r2). With analogous formalizations, C, F, and VF can be dened.
VC 0.45 < y 0.55 0.45 x y 0.55 x x 0.55 y x 0.45 (2)
Case Study in the Domain of Road Trac Management. We demonstrate

the applicability of the integrated model by means of a hypothetic case study in
the domain of road trac management, which is made up of a situation evolution
along various trac entities, cf. Table 1. The entities are represented by trac
signs, and their spatial extent along the highway (direction from right to left) is
indicated by surrounding boxes. The situation evolution comprises a trac jam
tj that starts growing due to capacity overload at a highway on-ramp onr in
the middle of road works rwk. Shortly after, an accident acc occurs at the end of
the trac jam, which soon is contained within the further growing trac jam.
In order to reach the accident acc, an ambulance amb later passes through the
trac jam tj. In Table 1, the overall evolution of this situation is depicted as
arrows representing evolution of relations in terms of their transitions in icons of
the two-dimensional model introduced above. In order to represent trac objects
in our model, their occupied regions on a highway are modeled as intervals in
R. Next to each icon, Table 1 provides an informal description of the relation
evolution between the entities. Summing up the case study, we have illustrated
our approach by applying it to a scenario involving various dierent aspects
3
This measure has simply been chosen due to ease of presentation. It has neither been
determined nor tested using cognitive studies.
Table 1. Case study of situation evolution in terms of relation transitions

Informal evolution description Icon

1. Trac jam grows. In the beginning, the area of road works (1: )
is much larger than the traffic jam. Since the traffic jam grows, it thereafter
extends beyond the area of road works, so causing transitions in topology, dis-
tance, and size. At the same time it remains externally connected to the on-ramp
(2: ).
2. Accident occurs. Next, an accident occurs at the end of the traffic jam,
further reducing traffic flow. Since the trac jam (3: ) is still growing,
it soon completely contains the accident. In contrast, the accident and the area
of road works are both stationary, resulting in no evolution between them (4:
).
3. Ambulance drives towards accident. Finally, an ambulance drives to-
wards the nearly-equally sized accident (5: ), indicated by the arrow
pointing downwards along the horizontal center and ending at EC). On its way
to the accident, the ambulance enters the much larger trac jam (6: ).
Thus, their boundaries are considered to become very far from each other even
though the ambulance is within the traffic jam.
of evolution: (i) scaling in comparison to stationary objects with and without

leading to relation transitions, (ii) non-evolution between two stationary, non-
scaling entities, and (iii) motion of a non-scaling entity with respect to a scaling,
and to a stationary, non-scaling one. The inter-calculi dependencies of Fig. 1 are
extracted as qualication constraints into an ontology in the next section.
4 An Ontology of Inter-calculi Dependencies
Since we focus on the dynamic behavior of spatial systems, we express the

inter-calculi dependencies summarized above in Fig. 1 in an ontology on the
basis of the Situation Calculus [22] providing explicit support for modeling
change between states in the form of occurrents. Change in the Situation Cal-
clus is manifested in the properties of entities and the relations between them
(e. g., a trac jams position can change, or its distance relation to an acci-
dent). In the terminology of the Situation Calculus, entities are continuants
O = {o1 , o2 , . . . , on }, whereas their properties and relations to other entities in a
particular situation are referred to as uents = {1 (o1 ), 2 (o2 ), . . . , n (on )}.
We use in accordance with [3] relational uents r relating two continuants to
each other using denotation sets = {1 , 2 , . . . , n } and a ternary predicate
Holds denoting that a uent holds a particular value in a particular situation:
for instance, Holds(phircc8(o, o ), EQ, s) describes that the objects o and o are
topologically equal in situation s. Changed uents are the result of occurrents
= {1 (o1 , 2 (o2 , . . . , n (on } [3]. Qualication constraints for occurrents can
be dened using axioms of the form P oss((o), s) Holds((o1 ), , s), denoting
that is possible in situation s, when a uent of entities o1 holds a particular
value in s. For example, being of small size might be a precondition for growing,
as stated by (o O)(s S)P oss(grow(o), s) Holds(size(o), small, s).
Utilizing the Situation Calculus, we dene qualication constraints for relation
transitions (occurrents) on the basis of relational uents, cf. Def. 1.
Denition 1 (Inter-calculi qualication constraint). In accordance with

[3] let transitions between relations be occurrents tran(, o, o ), meaning that o
and o transition to the relation . An inter-calculi qualication constraint can
then be formulated in the Situation Calculus as an action precondition axiom [22]
of the syntactic form given in (3), meaning that a transition to 1 is possible, if
a relation 2 of another spatial calculus currently holds between o and o .
(o, o O)(s S)P oss(tran(1 , o, o ), s) Holds(spatial (o, o ), 2 , s) (3)
In Ex. 1, we provide a sample inter-calculi transition qualication constraint that

formalizes the preconditions of the transition between DC and EC in terms of the
states of relational uents dening qualitative size and distance relationships.
Example 1. A transition from DC to EC in RCC is possible, if (trivially) DC from

RCC holds, from a distance point-of-view VC holds, and from a size point-of-
view any relation holds (summarized by the light-gray region VC that borders EC
and spans all size relations in Fig. 1).
(o, o O)(s S)P oss(tran(EC, o, o ), s) Holds(rcc8 (o, o ), DC, s)

(4)
Holds(dist (o, o ), V C, s) Holds(size , 1 , s)where 1 {<, =, >}
As a proof-of-concept, we implemented the conceptual neighborhood structure of

RCC, spatial distance of boundaries, and size, as well as the above-dened con-
straints in SWI-Prolog and used the FSA planner [16] implementing GOLOG
(Reiters Situation Calculus programming language [22]) to synthesize sequen-
tial plans comprising the necessary relation transitions in order to reach a future
goal situation from a current one. The lessons learned from this prototypical
implementation and directions for further work are summarized below.
5 Critical Discussion and Further Work

Synthesized Plans Reect Commonsense Understanding of Evolution.
The synthesized plans, without inter-calculi qualication constraints, reect some
implementation-dependent choice of the planner between independent
transitions being possible at the same time (e. g., in our test runs, the order
of transitions in the plan corresponded with the order of relations in the ini-
tial situation denition). Considering the additional inter-calculi qualication
constraints, these transitions are no longer independent and, hence, the synthe-
sized plans are consistent with commonsense understanding of the evolution of
entities.
Generalization in Terms of Calculi and Spatial Primitives. Existing
topological and positional calculi (e. g., Egenhofers approach [7]) can be inte-
grated into the model by dening for each relation of the calculus a mapping
to the x- and y-coordinate measures of our model. For example, the relation
inside modeled as 4-intersection
describes a relation between two ob-
jects o and o , where the intersection of the interiors of o and o is not empty,
the intersection of the boundary of o and the interior of o is not empty, whereas
the intersection of the interior of o and the boundary of o , as well as the inter-
section of their boundaries are empty. In terms of our model, for such a relation
the distance between the centroids of o and o must be smaller than the dif-
ference between their radii (d < r2 r1), hence the following must hold true:
d/2(r1 + r2) < 0.5 r1/(r1 + r2) (i. e., inside is NTPP of RCC). In order
to integrate additional spatial aspects not being representable with the spatial
primitives employed above (e. g., orientation of entities towards each other), a
generalization (e. g., in terms of higher-dimensional images) of the presented
abstraction in terms of radii and center distance of spatial primitives is still nec-
essary (e. g., considering orientation vectors). Likewise, in order to support the
multitude of dierent spatial primitives found especially in GIS (e. g., regions,
lines, points, as well as fuzzy approaches with broad boundaries) going beyond
the intervals, regions, and spheres utilized above, metrics for comparing spatial
primitives of dierent sorts must be dened (e. g., a line passing a region [7]).
Encoding of the Ontology with Semantic Web Standards. Since current
Semantic Web standards, in particular OWL 2, formalize ontologies using a
decidable fragment of rst-order logic, an interesting further direction is to dene
a mapping of the ontology excerpt expressed in terms of the Situation Calculus
into the concepts of OWL 2. For this, it can be based on prior work in terms of
description logic rules [19] integrating rules and OWL. As a result, an integration
with Semantic-Web-based GIS would be an interesting option.
References
1. Baumgartner, N., Gottesheim, W., Mitsch, S., Retschitzegger, W., Schwinger, W.:
BeAware!situation awareness, the ontology-driven way. International Journal of
Data and Knowledge Engineering 69(11), 11811193 (2010)
2. Baumgartner, N., Gottesheim, W., Mitsch, S., Retschitzegger, W., Schwinger, W.:
Situation Prediction NetsPlaying the Token Game for Ontology-Driven Situation
Awareness. In: Parsons, J., Saeki, M., Shoval, P., Woo, C., Wand, Y. (eds.) ER
3. Bhatt, M., Loke, S.: Modelling Dynamic Spatial Systems in the Situation Calculus.
Spatial Cognition and Computation 8, 86130 (2008)
4. Bhatt, M., Rahayu, W., Sterling, G.: Qualitative Simulation: Towards a Situation
Calculus based Unifying Semantics for Space, Time and Actions. In: Proc. of the
Conf. on Spatial Information Theory, Ellicottville, NY, USA (2005)
5. Clementini, E., Felice, P.D., Hern andez, D.: Qualitative Representation of Posi-
tional Information. Articial Intelligence 95(2), 317356 (1997)
6. Cohn, A.G., Renz, J.: Qualitative Spatial Representation and Reasoning. In: Hand-
book of Knowledge Representation, pp. 551596. Elsevier, Amsterdam (2008)
7. Egenhofer, M.: A Reference System for Topological Relations between Compound
Spatial Objects. In: Proc. of the 3rd Intl. Workshop on Semantic and Conceptual
Issues in GIS, Gramado, Brazil, pp. 307316. Springer, Heidelberg (2009)
8. Egenhofer, M.: The Family of Conceptual Neighborhood Graphs for Region-Region
Relations. In: Proc. of the 6th Intl. Conf. on Geographic Information Science,
Zurich, Switzerland, pp. 4255. Springer, Heidelberg (2010)
9. Freksa, C.: Conceptual neighborhood and its role in temporal and spatial reasoning.
In: Proc. of the Imacs International Workshop on Decision Support Systems and
Qualitative Reasoning, pp. 181187 (1991)
10. Galton, A.: Towards a Qualitative Theory of Movement. In: Proc. of the Intl. Conf.
on Spatial Information Theory: A Theoretical Basis for GIS. Springer, Heidelberg
(1995)
11. Galton, A.: Continuous Motion in Discrete Space. In: Proc. of the 7th Intl. Conf. on
Principles of Knowledge Representation and Reasoning, Breckenridge, CO, USA,
pp. 2637. Morgan Kaufmann, San Francisco (2000)
12. Galton, A., Worboys, M.: Processes and Events in Dynamic Geo-Networks. In:
Rodrguez, M.A., Cruz, I., Levashkin, S., Egenhofer, M.J. (eds.) GeoS 2005. LNCS,
13. Gerevini, A., Nebel, B.: Qualitative spatio-temporal reasoning with RCC-8 and
allens interval calculus: Computational complexity. In: Proc. of the 15th Eureo-
pean Conf. on Articial Intelligence, Lyon, France, pp. 312316. IOS Press, Ams-
terdam (2002)
14. Grenon, P., Smith, B.: SNAP and SPAN: Towards Dynamic Spatial Ontology.
Spatial Cognition & Computation: An Interdisciplinary Journal 4(1), 69104 (2004)
15. Hern andez, D., Clementini, E., Felice, P.D.: Qualitative Distances. In: Kuhn, W.,
Frank, A.U. (eds.) COSIT 1995. LNCS, vol. 988, pp. 4557. Springer, Heidelberg
(1995)
16. Hu, Y., Levesque, H.J.: Planning with Loops: Some New Results. In: Proc. of
the ICAPS Workshop on Generalized Planning: Macros, Loops, Domain Control,
Thessaloniki, Greece (2009)
17. Ibrahim, Z.M., Tawk, A.Y.: An Abstract Theory and Ontology of Motion Based
on the Regions Connection Calculus. In: Proc. of the 7th Intl. Symp. on Abstrac-
tion, Reformulation, and Approximation, Whistler, Canada, pp. 230242. Springer,
Heidelberg (2007)
18. Klippel, A., Worboys, M., Duckham, M.: Conceptual Neighborhood BlindnessOn
the Cognitive Adequacy of Gradual Topological Changes. In: Proc. of the Workshop
on Talking about and Perceiving Moving Objects: Exploring the Bridge between
Natural Language, Perception and Formal Ontologies of Space, Bremen, Germany,
19. Krotzsch, M., Rudolph, S., Hitzler, P.: Description Logic Rules. In: Proc. of the
18th European Conf. on Articial Intelligence, pp. 8084. IOS Press, Amsterdam
(2008)
20. Randell, D.A., Cui, Z., Cohn, A.G.: A Spatial Logic based on Regions and Connec-
tion. In: Proc. of the 3rd Intl. Conf. on Knowledge Representation and Reasoning.
Morgan Kaufmann, San Francisco (1992)
21. Reis, R., Egenhofer, M., Matos, J.: Conceptual Neighborhoods of Topological Re-
lations between Lines. In: Ruas, A., Gold, C. (eds.) Proc. of the 13th Intl. Symp.
on Spatial Data Handling (2008)
22. Reiter, R.: Knowledge in Action: Logical Foundations for Specifying and Imple-
menting Dynamical Systems. The MIT Press, Cambridge (2001)
23. Worboys, M., Hornsby, K.: From Objects to Events: GEM, the Geospatial Event
Model. In: Egenhofer, M.J., Freksa, C., Miller, H.J. (eds.) GIScience 2004. LNCS,
Transforming Conceptual Spatiotemporal Model into
Object Model with Semantic Keeping
Chamseddine Zaki, Myriam Servires, and Guillaume Moreau
LUNAM Universit, cole Centrale Nantes, CERMA UMR CNRS 1563

{chamseddine.zaki,myriam.servieres,
guillaume.moreau}@cerma.archi.fr
Abstract. Our work is developed in the context of spatiotemporal data

modeling and more particularly of urban data modeling. Our goal is to propose
a methodology describing the overall process of urban data modeling from the
design phase to the implementation in an information system. For that, we
propose, within a GIS, an approach based on a conceptual model specific to
spatiotemporal data modeling MADS, and on an ODBMS for storing and
manipulating data. MADS uses spatial and temporal types that are more precise
than those of programming languages on which are based ODBMS. MADS is
semantically richer than the object model, and the purpose of this paper is to
present the transformation rules of this conceptual model into an object model
that keeps (as close as possible) its semantics.
Keywords: Spatiotemporal Modeling, Conceptual Models, ODBMS,

Transformation of models, programming language, GIS.
1 Introduction
Our work takes part of a generic approach proposal to efficiently deal with urban data
within a GIS. Currently, the major shortcomings of a GIS are in the spatiotemporal
data design and in the incomplete coverage of the temporal dimension and multi-
representation of data. For that, we propose a GIS based on the MADS conceptual
model (Modeling of Application Data with Spatio-temporal features) [1], [2] and on
an ODBMS (Object Database Management System) db4o (DataBase For Objects) [3]
for storing and manipulating data.
MADS is a conceptual model dedicated to spatiotemporal data modeling [1]. It is
based on the Entity-Relation (EA) formalism. However to take advantage of the
semantics offered by the MADS model and to achieve its coupling with a GIS, we
perform its transformation into an object model. For that, a key step in creating
structures (generic classes) simulating the MADS concepts in the object language is
necessary. This step is followed by the definition of mapping rules (algorithms) that
allow the translation of specific conceptual schemas defined by MADS into the
corresponding object language.
We emphasize that, in our approach, we are specifically interested in the use of
ODBMS. ODBMS store the objects in Object Databases that are more flexible than
282 C. Zaki, M. Servires, and G. Moreau
relational databases. In these ODBMS, data objects are treated the same way as in the
programming language and access to data is by reference. With these models, we
can store and access any type of data without using (or improving) specific
manipulation languages like SQL. We believe that this gives advantages in the
formulation and understanding of requests (indeed, the way in which the data will be
handled is, in our case, planned by the conceptual schemas). Among the ODBMS we
used db4o [3]. It is a free ODBMS based on the Java programming language that
provides facilities for backing up any data type (even complex) in a uniform,
automatic and transparent way. Db4o uses simple mechanisms for manipulating data
based on methods of Java language. But on the other side the basic concepts offered
by the programming language (on which the db4o is based) are less expressive than
those of MADS. So semantic preservation verification methods are automatically
implemented, on different levels, during the transformation from conceptual to
physical model (programming language) to ensure the preservation of the semantics
imposed by the designer when creating conceptual MADS schemas.
In other words, we propose the design of spatiotemporal applications to be made
according to MADS schemas whose formal specifications, undergo later a series of
systematic transformations towards operative object programs. The scripts generation,
and the Object Database creation are viewed as sequences of the transformations.
In the rest of this paper, we will present in section 2 a background of conceptual
spatiotemporal models. Then in section 3 we will present the general procedure for
implementing our conception based on MADS into an object paradigm. We will detail
the transition rules to express the thematic, spatial and temporal characteristics of
MADS schemas into an object language. We will conclude this paper and give some
perspectives of our work in the last section.
2 Background
Our state of art focuses on spatiotemporal data design models since they are, for our
approach, the most important part that will monitor the processing of information. For
this reason, we seek a semantically rich model that allows a good modeling of the
spatiotemporal data and of applications. The implementation of this model and the
adjustment of semantics during the implementation is the part of our approach that we
will detail later in this article. A conceptual data model (especially for urban
spatiotemporal data) must be able to offer users a wealth of expression to meet their
diverse needs and also enable them to implement readable and easy to understand data
schemes. In order to properly model spatiotemporal data, some requirements, besides
those related to traditional data modeling, must be taken into account during the
design phase. In fact, the conceptual model should allow modeling of spatial and
temporal dimensions (modeling the objects and events that occur in a field of study,
along with their interactions) as well as the temporal evolution of objects (history
tracking) [2], [4].
Several spatiotemporal modeling approaches that take into account these
requirements have already been proposed [5]. Most of them are based on modeling
techniques like EA and Object-Oriented (OO) used for traditional data modeling.
Transforming Conceptual Spatiotemporal Model into Object Model 283
Among OO techniques we can cite STUML "Spatio-Temporal UML [6] and

Perceptory [7], which are based on UML (Unified Modeling Language) [8].
Perceptory, for example, provides support (as icons) for spatiotemporal properties.
Spatial and temporal properties can be used simultaneously, and can be assigned to
classes and attributes. Its main weak point is that it does not assign spatial nor
temporal properties to associations between the objects of a conceptual model.
Among the models of the EA approach we have MADS [1]. MADS allows the
representation of real world entities as objects and associations. It supports
orthogonality between the structural, spatial and temporal dimensions. MADS has
interesting features like inheritance, effective temporal and historical data manipulation,
and uniform handling of spatiotemporal data. It has intuitive and very readable visual
notations to represent spatial and temporal concepts clearly, as well as a specific
language to query the data model (For a more detailed description of MADS, the reader
may refer to [2]). This model is considered as one of the best spatiotemporal design
models in various studies ([3], [5], [9]). We decided to use MADS as the basic
conceptual model for our approach.
However, MADS has been implemented with relational and object relational
database [10] but has not been properly coupled to a GIS yet. Implementation
attempts [11] consist of joint use of GIS (respectively ArcView and MapInfo) and a
relational database (ACCESS), but these authors did not formally propose solutions to
the problem of semantic loss in this implementation (e.g. ACCESS cannot handle
intervals and temporal relations that are part of MADS concepts) [2]. We also precise
that natively, MADS does not distinguish clearly between objects and events. For this
purpose, we have proposed in [12], some improvements to this model in order to
explicitly take into consideration the representation and the modeling of events as
well as their interactions and their implementations in the object model.
For the implementation of MADS we used an ODBMS. ODBMS provide object
persistence and take advantage of all the benefits of the object paradigm (frequently
used in MADS). The addition of new data types to this category of DBMS is both
easy and beneficial to our approach that is based on the semantically rich MADS
model (whose specifications are not considered in any actual DBMS). Indeed, by
using an ODBMS (from the second generation) as db4o for example, adding, saving
and manipulating any type of data is done with a single language, without having to
use nor extend any other data manipulation languages like SQL for instance.
3 Transformation Rules: Implementation of MADS in an Object

Environment
To take advantage of the semantics of the MADS model we implement it into an
object model using Java as a programming language. This is also justified by the fact
that Java is the programming language for db4o. The transformation methodology of
MADS in an OO framework is summarized as:
Transformation of the generic conceptual model: This first phase consists on
translating the spatial and temporal types of MADS into generic Java classes. For
this reason, we exploit existing Java libraries and we create new classes when they
do not already exist. This first phase is to be done once and for all. The java classes
created are called basic classes, and they will be the same no matter what is the
considered case study.
Transformation of the conceptual schema: While the first phase deals with the
creation of basic classes, the second deals with the application schemas and
consists in transforming each MADS conceptual schema into an equivalent Java
program. This is achieved through the exploitation of the basic Java classes created
in the first phase. In this second phase, for each given conceptual schema modeling
a specific application, a corresponding structure (java program) is automatically
created. The program resulting from this transformation is created using the rules
of model transformation (described in the next paragraphs).
The orthogonality of the concepts and of the spatial and temporal dimensions of the
MADS model allows us to conduct separate studies of transformation for these
concepts and dimensions. Thus we begin by transforming the general concepts of
MADS and then we present the transformation of spatial and temporal dimensions.
3.1 Transformation of General Concepts
MADS offers the usual concepts of extended entity-relationship models: classes,

associations and generalization / specialization links. Classes and associations can
have methods, attributes and primary keys. Attributes can be simple or complex
(composed of other attributes) and they are characterized by a double cardinality
(minimum, maximum) to distinguish the fact that they can be mono-valued or multi-
valued (multiple values), optional or mandatory.
Transformation of Classes: The class is the fundamental concept of any object
technology. This concept both exists in Java and in MADS. Our first transformation
rule is to replace each class in the MADS conceptual schema MADS by a Java class.
Transformation of Attributes: The domain of an attribute is the collection of
possible values for this attribute. It can be simple, object or complex type. MADS
defines a set of simple data types (Float, Integer, Boolean, String, etc.) which can be
assigned to attributes. These types will be directly converted into equivalent classes
provided by the Java platform. Thus, a mono-valued attribute of simple type will be
directly transformed into an attribute in java with the same name and with the type
that matches his type declared in MADS.
Table 1 shows the transformation into Java of a Building MADS class containing
several attributes of different types. In this example the attribute number is a mono-
valued attribute of the simple type Integer that is transformed into a java attribute of
the same name and type. In addition to simple data types, attributes in MADS can be
objects of user-defined classes. The transformation of a mono-valued attribute of type
object is similar to the transformation of an object of simple type. (See the
transformation of the attribute fireplace in Table 1).
MADS allows the definition of complex attributes formed of a group of attributes.
Sub-attributes, that are elements of the complex attribute, have the same
characteristics of the direct attributes of the class and can be mono-valued or multi-
valued, simple or complex, etc. In our proposal, any complex mono-valued attribute
becomes an instance of a new class declared inside the main class in order to simulate
this attribute. Java allows creating classes within bounding classes. These inner
classes will have a reference to the bounding class, and access to all its members
(fields, methods, other inner classes). In addition, they cannot be declared outside the
bounding class. (See the transformation of roofing in an inner-class in Table 1).
MADS allows an attribute to take more than one value and provides several types
of collections to support this. MADS modeling of this multi-valued attribute is
achieved by assigning a maximum cardinality equal to n. MADS defined collections
are list, set and bag [2]. However, Java also offers the use of collections, and defines
the Collection, Set, List and TreeList classes. Thus, we propose to establish a
correspondence between the concepts: collection, set, bag and list of MADS and java
basic classes: Collection, HashSet, ArrayList and TreeList, respectively.
Subsequently, a MADS multi-valued attribute is translated into Java by an attribute
having an equivalent collection type and same name (see the transformation of the
attribute owner in Table 1). Although the maximum cardinality of an attribute
indicates whether the attribute is multi-valued or mono-valued, the minimum
cardinality specifies whether it is optional or mandatory. When the minimum
cardinality is equal to zero then the attribute is optional, otherwise it is mandatory. In
our proposal, the optional (mono or multi-valued) attributes of MADS are treated the
same way as multi-valued attributes and are mapped to java collections. The only
difference is that in this second case, additional constraints must be enforced. In fact,
we must verify their existence right while accessing the data. If the attribute is
optional and mono-valued, then another check is required (method created and called
automatically) to insure before accessing the value of the attribute that the attribute is
instantiated (see the transformation of the attribute otherName in Table 1).
Table 1. Examples of transformation of MADS attributes to Java
MADS conceptual schema Java code (parts)

public class Building { // constructor...
Integer number;
Fireplace fireplace; // method set (), get ()...
Roofing roofing;
class Roofing {
String form;
Integer tent; }
List<String> owner = new ArrayList <String>();
List<String> otherName = new ArrayList
<String>(); }
Transformation of Relations between Classes. Different types of relationships may

exist between MADS classes. In this article we only address the transformation of the
most used relationships: association and generalization.
The association is a relationship linking two or many classes. Each class
participating in an association plays a role. A line linking this class and the
association models this role. It is characterized by a double cardinality that specifies
the minimum and maximum number of relationships that an object of this class can
have. An association relationship in MADS is transformed into a Java class (we have
chosen to make this correspondence since our target database is an object database
and hence access to objects is done "by reference"). If the association contains
attributes, then the transformation rules are the same as those of the Class concept.
In addition to the attributes defined in the association, we add new attributes (or lists
of attributes) to reference the object of classes involved in this association.
For the classes participating in the association, we also add references to the class
that simulates the association. The minimum and maximum cardinalities of each role
linking a class to the association specify the data structure we are going to use to store
the references (to the instances of class denoting the association). This structure will
be chosen in accordance with the rules used to transform an attribute with a minimum,
and a maximum cardinality. In other words, for a class participating in an association,
this association can be simulated by an attribute with a cardinality equal to the
cardinality of the role that links the class to the association.
Table 2 shows the transformation of the association Contains linking Plot and
Building. The cardinalities of rules indicate that a plot may contain many buildings
and a building is included in one plot. That will give us the java classes: Plot,
Building and Contains. Building contains an attribute of type "Contains". Plot
contains n records (grouped in collection of type ArrayList) to objects of class
"Contains". "Contains" contains two references to Plot and Building.
The "generalization relationship" is one of the fundamental concepts of object
technology. It allows creation of specific classes that inherit attributes and methods of
other classes. The concept of generalization between classes and associations of
MADS is directly translated into the mechanism of inheritance between classes in
Java. Table 2 presents an example of the transformation of this relation.
Table 2. Example of transformation of MADS relations to Java

public class Plot {
List <Contains> contient = new ArrayList <
Contains >(); }
public class Building {
Contains estContenu ; }
public class Contains {
Plot plot ;
Building Building; }
public class Public_builging extends Building{...}
public class Private_builging extends Building{...}
3.2 Transformation of MADS Spatial Dimension
MADS offers spatial data types (Point, Line, etc.) [2] to denote the shape of objects.
These spatial types can be assigned to classes, attributes and associations.
In Java, we took advantage of the existence of the spatial library "JTS" [13] which
takes into account and enforce all the suggestions defined by the OGC (Open
Geospatial Consortium) [14]. Nevertheless, the spatial types of MADS are more
detailed than those of the JTS, but, for the moment, we still decided to make a direct
correspondence between the spatial types of MADS and the JTS classes. Indeed there
are in MADS some types that have no equivalent in JTS, as for example "SimpleGeo"
and "OrientedLine". In our transformation (Fig.1) we have not created classes for
these types but we did match them with the closest JTS classes. (The creation of an
exact equivalent of all MADS spatial types is feasible. It will be done by
adding some new classes on JTS and it is one of our perspectives).
Fig. 1. Correspondences between the spatial types of MADS and JTS classes
Nevertheless, the transformation of the spatial dimension in MADS schemas

depends on whether this spatiality is assigned to the class, association or attributes.
Transformation of Spatiality for Classes and Associations: The spatiality is
attributed to a class (or association) by adding it one of the MADS spatial types. To
transform a spatial class in Java, the solution consists of transforming the spatiality of
the class into a spatial mono-valued attribute called SpatialFeature. This attribute
will have as type the JTS class that corresponds to the spatiality of the MADS class.
Table 3 gives an example of transformation of the spatiality of class "Building".
We note that the associations between two spatial classes can have topological
constraints (contains, is contained, touches, overlaps, etc). A topological constraint is
transformed into a static method that validates the constraint in the Java class
simulating the association.
Transformation of the Spatiality for the Attributes: It is treated the same way as a
thematic attribute of a not-simple type. The not-simple type in this case, is the JTS
class watching the spatial attribute type defined in the MADS conceptual schema.
In addition, MADS allows to describe continuous fields. A continuous field
describes the values of an attribute over the geometry of an object type. Thus, the
concept of "Space-varying attributes" are introduced in MADS and represented using
the function icon f () [2], [10]. Indeed, a space-varying attribute is an attribute whose
value depends on a spatial location no matter its type (int, string, etc.) or its
characteristics (mono-valued, multi-valued).
A space-varying attribute will be simulated as a multi-valued and complex object
that contains two sub-attributes. The first is a spatial sub-attribute that can be of type
point (when the domain of values to be calculated is continuous) or of type surface (in
the other case). The second sub-attribute (of the same type as the space variable
attribute) is used to retrieve the calculated value corresponding to the spatial location
(first sub-attribute). For its transformation (see the transformation of attribute
lighting in Table 3), a space-varying attribute becomes an instance of a new class

declared inside the main class in order to simulate this attribute. (This inner class
contains a Map java structure that has the function domain as key and the type of
the space-varying attribute as the value of this key. In addition the inner class contains
some methods for adding and retrieving information).
Table 3. Example of transformation of MADS spatial concepts to Java

import com. Vividsolutions .jts .geom.Polygon;
Polygon spatialFeature;
Polygon parking;
Lighting lighting ;
class Lighting {
private Map <Polygon, Integer> value ;
// methods set() et get () } }
3.3 Transformation of Temporal MADS Dimension
MADS temporal types are used to design precise dates (instants, intervals, etc.), the
lifecycle of objects or the temporal evolution of spatial and thematic attributes.
These temporal types can be assigned to classes, attributes and associations. They
are organized in a temporal hierarchy (see [2]) that has no direct equivalent in the core
classes of Java. Indeed, no existing Java time libraries can take into account the
general complex and life cycle types of MADS. This is why we have created this
structure and we have developed generic classes to simulate all the MADS temporal
types. However, if powerful enough datatypes were introduced in the java language, it
would be easy to use them.
The classes we have created are semantically equivalent and have the same names
as MADS temporal types ("Instant", "Interval", "SimpleTime", etc.). Once these
classes are created, the second step is to transform into Java the MADS conceptual
schema using these temporal types. This transformation depends on the fact that
temporality is assigned to the class, to the association or to the attributes.
Temporality for Classes and Associations: By assigning a temporal type to a class
or an association, we keep track of the lifecycle of instances of this class or
association.
Tracking the lifecycle of instance is to indicate, its scheduling, creation, deletion or
deactivation date. Each object can take at a given date, one of the following four
statuses: planned, active, suspended or destroyed. The active period of an object is the
temporal element associated to the active status in its life cycle [10].
The transformation of the temporality of a class or association (Table 4) is similar
to the transformation of a complex multi-valued attribute named "LifeCycle" and
having as sub-attributes:
Attribute "status" which takes one of values: planned, active, suspended or
destroyed
A temporal attribute of the same type as the class (or association).
The associations between two temporal classes can have synchronized constraints (the
active period of the first class is for example before, after, during, starts with, etc. the
second). A synchronized constraint is transformed into a static method that validates
the constraint in the Java class simulating the association.
Table 4. Example of transformation of MADS temporal concept to Java

List <lifecycle> lifecycle = new ArrayList <Lifecycle> ;
class LifeCycle{
String status;
Interval time; // verification methods } }
Temporality at the Attributes Level: An attribute defined in a class (or association)

of a MADS schema with a temporal type is translated into Java with an attribute of
the generic java type corresponding to its temporal type.
In addition, the attributes in MADS, independently of their types (spatial, thematic,
etc.) and their characteristics (mono-valued, multi-valued, optional, required) can be
dynamic. In other words, the values of these attributes may change (possibly
following a function) over time, and these changes will be saved. Changes in attribute
values can be continuous, discrete or stepwise.
From a structural point of view, an attribute that varies over time is seen as a
complex multi-valued attribute. Sub-attributes of this complex attribute are a "value"
of the same type as the complex attribute, and a time element "time" of type "Interval"
if the temporal variability is stepwise and of type "Instant" in the other cases
(continuous and discrete). Thus, the transformation of a time-varying attribute is
similar to the transformation of a space-varying attribute, but moreover, we add new
methods to check constraints relative to this type (methods used to verify, for
example, that the values of the attribute "time" are different if the type of time is
"Instant", or that they are disjoint if the type of time is "Interval").
In order to test the capacity of our proposed modeling methodology in a real case, we
have applied it on a case study whose objective was to analyze pedestrian walkways in
urban areas. This example has provided answers to the problem of the influence of
microclimate and comfort conditions on pedestrian behavior related to the practice of
walking in urban areas. In fact we have created a conceptual schema to represent this
case study and through the transformation roles of MADS conceptual schemas into
object code, we were able to preserve the semantic richness of the original model and to
highlight the ability of our model to manage and manipulate spatial and
temporal queries. For a description of this example, the reader may refer to [12].
4 Conclusions
In this paper, we have presented our method for implementing MADS into Java. In
fact, structural concepts and the spatial and temporal dimension of MADS are
presented and implemented in structures directly manipulated by bd4o. Our
implementation allows preserving the semantic richness of the conceptual model as

well as the direct access and storage of any type of data by db4o. Moreover, this
transformation facilitates querying and visualizing objects from a GIS.
An important utility of our approach is the design template directed and framed the
treatment. The conceptual scheme in our approach controls the data and adds a
powerful framework to the methods with which data will be manipulated. In other
words, our conceptual schemes rather model spatiotemporal applications. Then the
implementation of the conceptual model in db4o allows having an object environment
that ensures uniform storage and manipulation of data without the need to use or
improve other data manipulation languages (like SQL).
As a perspective of this work, we aim to enrich the conceptual aspect MADS to
enable the modeling of 3D spatial data as well as data with fuzzy or uncertain
spatiality and temporality. Transformation of these concepts in Java is also planned.
References
1. Parent, C., Spaccapietra, S., Zimnyi, E., et al.: Modeling /Spatial Data in the MADS
Conceptual Model MADS. In: Spatial Data Handling 1998 Conference Proceedings,
Vancouver, BC, Canada, pp. 138150 (1998)
2. Parent, C., Spaccapietra, S., Zimnyi, E.: Conceptual Modeling for Traditional and Spatio-
Temporal Applications: the MADS Approach. Springer, New York (2006)
3. Db40, http://www.db4o.com
4. Zimanyi, E., Minout, M.: Preserving Semantics When Transforming Conceptual Spatio-
temporal Schemas. In: Chung, S., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp.
5. Pelekis, N., Theodoulidis, B., Kopanakis, I., Theodoridis, Y.: Literature review of spatio-
temporal database models. Knowledge Engineering Review 19(3), 235274 (2004)
6. Price, R.J., Tryfona, N., Jensen, C.S.: Extended SpatioTemporal UML: Motivations,
Requirements and Constructs. Journal on Database Management, Special Issue on
UML 11(4), 1427 (2000)
7. Bedard, Y.: Visual Modeling of Spatial Databases Towards Spatial Extensions and UML.
Geomatica 53(2), 169186 (1999)
8. Fowler, M., Scott, K.: UML Distilled - Applying the Standard Object Modeling Language.
Addison-Wesley, Reading (1998); ISBN 0-201-65783-X
9. Moisuc, B., Gensel, J., Davoine, P.A.: Designing adaptive spatio-temporal information
systems for natural hazard risks with ASTIS. In: Carswell, J.D., Tezuka, T. (eds.) W2GIS
10. Minout, M.: Modlisation des Aspects Temporels dans les Bases de Donnes Spatiales -
thse de doctorat: Universit Libre de Bruxelles (2007)
11. Souleymane, T., DeSdeMarceau, M.H., Parent, C.: COBALT: a design tool for
geographic and temporal data application. In: Proceedings of the 6th AGILE Conference
(2003)
12. Zaki, C., Zekri, E., Servires, M., Moreau, G., Hegron, G.: Urban Spatiotemporal Data
Modeling: Application to the Study of Pedestrian Walkways. In: Intelligent Spatial
Decision Analysis (ISDA 2010), Inner Harbor, Baltimore, Maryland, USA (2010)
13. JTS, http://www.vividsolutions.com/jts/JTSHome.htm
14. OGC, http://www.opengeospatial.org/standards/sfa
Preface to FP-UML 2011
The Unified Modeling Language (UML) has been widely accepted as the standard
object-oriented language for modeling various aspects of software and information
systems. The UML is an extensible language in the sense that it provides mechanisms
to introduce new elements for specific domains; these include business modeling,
database applications, data warehouses, software development processes, and web
applications. Also, UML provides different diagrams for modeling different aspects
of a software system. However, in most cases, not all of them need to be applied.
Further, UML has grown more complex over the years, and new approaches are
needed to effectively deal with these complexities. In general, we need heuristics and
design guidelines that drive the effective use of UML in systems modeling and
development.
The Seventh International Workshop on Foundations and Practices of UML (FP-
UML'11) will be a sequel to the successful BP-UML'05 - FP-UML'10 workshops held
in conjunction with the ER'05 - ER'10 conferences, respectively. The FP-UML
workshops are a premier forum for researchers and practitioners around the world to
exchange ideas on the best practices for using UML in modeling and systems
development. For FP-UML11, we received papers from nine countries: Poland,
Bosnia and Herzegovina, France, Germany, Israel, Mexico, Spain, Tunisia, and
United States. While the papers addressed a wide range of issues, the dominant topic
was model-driven architectures, including the various challenges related to
transformations and the complexities resulting from multi-model specifications.
The Program Committee selected three papers to include in the program. The first
paper by Brdjanin and Maric shows how associations in class diagrams can be
generated from activity diagrams. The second paper by Reinhartz-Berger and Tsoury
compares two core asset modeling methods, Cardinality-Based Feature Modeling and
Application-Based Domain Modeling, and discusses their benefits and limitations in
terms of specification and utilization capabilities. Finally, the third paper by Marth
and Ren introduces the Actor-eUML model for concurrent programming and
formalizes the mapping between actors in the Actor model and Executable UML
agents by unifying the semantics of actor behavior and the hierarchical state machine
semantics of Executable UML agents.
We thank the authors for submitting their papers, the program committee members
for their hard work in reviewing papers, and the ER 2011 organizing committee for all
their support.
July 2011 Guido L. Geerts

Matti Rossi

On Automated Generation of Associations
in Conceptual Database Model
Drazen Brdjanin and Slavko Maric
University of Banja Luka, Faculty of Electrical Engineering

Patre 5, 78000 Banja Luka, Bosnia and Herzegovina
{bdrazen,ms}@etfbl.net
Abstract. This paper considers the semantic capacity of object ows

and action nodes in UML activity diagram for the automated generation
of class associations in UML class diagram representing the conceptual
database model. Based on the results of an analysis of action nodes re-
garding the number of dierent types of input and output objects as well
as the weight of object ows, the formal transformation rules for the gen-
eration of object-object associations are dened and some experimental
results of the corresponding ATL implementation are provided.
Keywords: Activity Diagram, Class Diagram, Conceptual Database

Model, Transformation Rule, UML, ATL.
1 Introduction
The UML activity diagram (AD) is a widely accepted business modeling notation
[1]. Several papers [2,3,4,5,6] take AD as the basis for (automated) conceptual
data modeling, but with modest achievements in building the class diagram (CD)
which represents the conceptual model. Emphasizing the insuciently explored
semantic capacity of AD for automated conceptual model design [5], these at-
tempts have mainly resulted in (automated) generation of respective classes for
extracted business objects [2,3,4,5,6] and business process participants [4,5,6], as
well as a limited set of participant-object associations [4,5,6].
This paper considers the semantic capacity of object ows and action nodes in
AD for automated generation of class associations in the target CD representing
the initial conceptual database model (CDM). We performed an extensive anal-
ysis related to: (i) the nature of action nodes regarding the number of dierent
types of input and output objects, and (ii) the weight of object ows. Based
on its results, the formal transformation rules for the generation of object-object
associations are dened and the experimental results of the corresponding ATL
implementation, applied to a generic business model, are provided.
The rest of the paper is structured as follows. The second section introduces
preliminary assumptions and denitions that will be used throughout the paper.
In the third section we present the analysis of the semantic capacity of AD and
dene the formal transformation rules. ATL implementation is partly provided
in the fourth section. The fth section presents an illustrative example. Finally,
the sixth section concludes the paper.

On Automated Generation of Associations in Conceptual Database Model 293
2 Preliminaries
2.1 Detailed Activity Diagram
We assume that each business process in the given business system is modeled by
corresponding detailed AD (DAD) which represents activities at least at complete
level (the related UML metamodel excerpt from the UML superstructure [7] is
shown in Fig. 1 (up)), i.e.
each step (action, activity, etc.) in the realization of the given business pro-
cess is represented by a corresponding action node and will be shortly re-
ferred to as activity in the rest of the paper;
each activity is performed by some business process participant (it can be
external, e.g. buyer, customer, etc., or internal, e.g. worker, working group,
organization unit, etc.) represented by a corresponding activity partition,
usually called swimlane. In the rest of the paper, a business process partici-
pant is shortly referred to as participant ;
each activity may have a number of inputs and/or outputs represented by
object nodes. In the rest of the paper they are referred to as input objects
and output objects, respectively;
objects and activities are connected with object ows. An object ow is
a kind of activity edge which is directed from an input object toward the
corresponding activity (input object ow ) or from an activity toward the
corresponding output object (output object ow ); and
each object ow has a weight attribute, whose value is by default one. The
object ow weight represents the minimum number of tokens that must tra-
verse the edge at the same time. We assume that constant weight represents
not minimum, but the exact number of objects required for the activity if
they are input objects, or the exact number of created objects in the activity
if they are output objects. An unlimited weight (*) is used if the number of
input/output objects is not constant.
Denition 1. Let P, A, O, F be sets of participants, activities, objects and ob-

ject ows in some business process, respectively. The detailed activity dia-
gram, denoted by DAD(P, A, O, F ), is an AD with the following properties:
(1) each activity (a) is performed by only one participant (p), i.e.
p P, a A | a node(p) inP artition(a) = {p};
(2) each input object ow (if ) is an object ow directed from exactly one input
object (io) toward exactly one activity (a), i.e.
io O, a A, if FI F | if outgoing(io) if incoming(a)
source(if ) = {io} target(if ) = {a};
(3) each output object ow (of ) is an object ow directed from exactly one ac-
tivity (a) toward exactly one output object (oo), i.e.
a A, oo O, of FO F | of outgoing(a) of incoming(oo)
source(of ) = {a} target(of ) = {oo}.
294 D. Brdjanin and S. Maric
Fig. 1. UML metamodel excerpt used for representation of DAD (up) and CDM (down)
Denition 2. A generated input object (gio) is an input object created in

the given process (object which also constitutes the output object from another
activity in the same process), i.e.
gio OG O of FO | target(of ) = {gio}.
Denition 3. An existing input object (eio) is an input object which is not
created in the given process but in some other process, i.e.
eio OX O of FO | target(of ) = {eio}.
2.2 Conceptual Database Model

We use a CD to represent the CDM. The related UML metamodel excerpt from
the UML infrastructure [8] is shown in Fig. 1 (down).
Denition 4. Let E and R be sets of classes and their associations, respectively.
The conceptual database model, denoted by CDM(E, R), is a CD with the
following properties:
(1) each entity set is modeled by a corresponding class of the same name, whose
each ownedAttribute (modeled by the Property metaclass) corresponds to
an attribute of the given entity set, and
(2) each relationship is modeled by a corresponding class association of the same

name, whose two memberEnd attributes (modeled by the Property metaclass)
represent source and target association ends with the appropriate multi-
plicity corresponding to respective relationship cardinalities.
Proposed transformation rules in existing approaches for automated CDM design

are illustrated in Fig. 2. According to [2,3,4,5,6] each object o O and each
participant p P are directly mapped into corresponding classes eO EO (rule
TO ) and eP EP (rule TP ), respectively. Hence, E = EO EP .
Existing approaches [4,5,6] dene rules (denoted by TPO ) only for automated
generation of participant-object associations (associations between classes repre-
senting participants and objects) based on the activities performed on objects.
Creation of participant-object associations (with cardinality 1:*) was suggested
for each triplet participant, activity, object. Making a distinction between ex-
isting and generated input objects implies that participant-object associations
should be created not for all objects, but only for output objects and generated
input objects. However, a deeper analysis and corresponding formal rules are
outside the scope of this paper and will be focus of our further research.
In this paper we dene the set of transformation rules (denoted by TOO ) aimed
at generating object-object associations.
3 Formal Rules for object-object Associations

As suggested in [3], associations between classes representing business objects
could be generated based on activities having both input and output objects by
direct mapping of such activities to the respective associations, but they dont
explicitly propose any rule for the generation of multiplicities of association ends.
Before formally dening the transformation rules for automated generation
of object-object associations, we will classify activities based on the number of
dierent types of input and output objects. There are several possible situations
(Fig. 3) and these are as follows: (i) single input - single output (SISO) activities,
(ii) multi input - single output (MISO) activities, (iii) single input - multi output
(SIMO) activities, and (iv) multi input - multi output (MIMO) activities.
Fig. 2. Mapping of DAD into CDM

Fig. 3. Classication of activities: (a) SISO, (b) MISO, (c) SIMO, and (d) MIMO
SISO Activities. SISO cases and the corresponding transformation rules are
illustrated in Fig. 4.
Regardless of whether the input object (IO) is existing (EIO) or generated
(GIO), each output object (OO) depends on as many IOs as is the weight of
the given input object ow. In this way, if the weight of the input object ow
equals 1, then the OO depends on exactly one IO and the multiplicity of the
respective source association end is exactly 1. If the input weight equals *,
then the OO depends on many IOs and the multiplicity of the respective source
association end is *. If the input weight is literal n which is greater than one,
then the OO depends on exactly n IOs (like personal data containing data about
two cities, where the rst city represents the place of birth, while the second city
represents the place of residence). In that case we have exactly n associations,
where each association has the source end multiplicity equal to 1.
If the input object(s) is/are existing object(s), i.e. EIO, then the target end
multiplicity (which corresponds to the OO) of each association always equals
* and doesnt depend on the weight of the output object ow, because even
Fig. 4. Illustration of transformation rules for SISO activities

in cases when the output weight is exactly 1, with time, the same EIO may
be used in the creation of many OOs.
If the input object(s) is/are generated object(s), i.e. GIO, then the target
end multiplicity depends only on the weight of the output object ow. If the
output weight is exactly 1, then exactly one OO depends on input GIO(s)
and the target end multiplicity should be exactly 1. Otherwise, the target end
multiplicity should be *, because more than one OO depend on input GIO(s).
Rule 1. (Object-object associations for SISO activities) Let a A be a

SISO activity having input object(s) io OG OX and creating output object(s)
oo OO , where if FI and of FO represent corresponding input and output
object ows whose weights are denoted by wif and wof , respectively. Transforma-
siso
tion rule TOO maps the SISO tuple io, if, a, of, oo into set Rsiso
OO (a) containing
exactly n N associations between classes eIO and eOO corresponding to the
given input and output objects, respectively:
siso def siso siso

TOO : DAD(P, A, O, F ) CM(E, R) ROO (a) = TOO io, if, a, of, oo

Rsiso
(j) (j)
OO (a) = rOO R j = 1, . . . , n rOO = TOO io, if, a, of, oo
def

TOO io, if, a, of, oo = rOO name(rOO ) = name(a)

memberEnd(rOO ) = {source, target} |
type(source) = eIO multiplicity(source) = ms

type(target) = eOO multiplicity(target) = mt ,
where the corresponding source and target association end multiplicities and the
total number of associations are as follows

, wif = , wof = 1 io OX 1, wif {1, }
ms = mt = n= .
1, otherwise 1, otherwise wif , otherwise
MISO Activities. Each MISO activity has input objects of more than one
type and it creates output objects of exactly one type. Since all input objects
are required for the start of the activity, we assume that the output object(s)
depend(s) on all these input objects, i.e. output object(s) is/are directly related
to each of the input objects. For example, an activity which results in creating
an invoice takes data about sold goods and shipping details as well. This implies
siso
that SISO transformation rule TOO should be independently applied to each
input object(s) - output object(s) pair of MISO activity.
Rule 2. (Object-object associations for MISO activities) Let a A be a

MISO activity having m N dierent types of input objects io1 , io2 , . . . , iom
OG OX and creating the output object(s) oo OO , where if1 , if2 , . . . , ifm
FI and of FO constitute the corresponding input and output object ows,
respectively. Let M(a) = {iok , ifk , a, of, oo, 1 k m} be the set of SISO
miso
tuples for the given activity a A. Transformation rule TOO maps the M(a)
miso
set into the ROO (a) set of corresponding associations for the given activity:
miso def
TOO : DAD(P, A, O, F ) CM(E, R) Rmiso
OO (a) = TOO
miso
M(a)
def
Rmiso siso
(k) (k)
OO (a) = ROO (a), ROO (a) = TOO iok , ifk , a, of, oo .
1km
miso
The TOO transformation rule is a general rule relevant for all single output
activities, since a SISO activity is just a special case of MISO activities (m = 1).
SIMO Activities. A SIMO activity has input objects of exactly one type and
creates output objects of more than one dierent types. Since the given activity
is to result in the creation of all output objects, we assume that each output
object is directly related to the given input object(s). This implies that SISO
siso
transformation rule TOO should be independently applied to each input object(s)
- output object(s) pair of a SIMO activity.
Rule 3. (Object-object associations for SIMO activities) Let a A be
a SIMO activity having input object(s) io OG OX and creating n N
dierent types of output objects oo1 , oo2 , . . . , oon OO , where if FI and
of1 , of2 , . . . , ofn FO represent the corresponding input and output object ows,
respectively. Let M(a) = {io, if, a, ofk , ook , 1 k n} be the set of SISO tu-
simo
ples for the given activity a A. Transformation rule TOO maps the M(a) set
simo
into the ROO (a) set of corresponding associations for the given activity:
simo def
TOO : DAD(P, A, O, F ) CM(E, R) Rsimo OO (a) = TOO
simo
M(a)
def
Rsimo siso
(k) (k)
OO (a) = ROO (a), ROO (a) = TOO io, if, a, ofk , ook .
1kn
MIMO Activities. A MIMO activity has m N dierent types of input objects

and creates output objects of n N dierent types. Since direct application of the
siso
TOO transformation rule to all SISO tuples would result in the creation of m n
associations, it is recommended to transform the MIMO activity into a set of
concurrent SIMO and/or MISO activities which could enable the application of
simo miso
the TOO and/or TOO transformation rules, respectively. Such transformation
could decrease the total number of associations generated for MIMO activities.
Therefore, assuming that all activities in the given DAD belong to MISO
(including SISO as a special case) and/or SIMO activities, the total set of object-
object associations is given with

ROO = Rsimo
OO (a) Rmiso
OO (a).
aAsimo aAmiso
4 Implementation
We use ATL1 [9] to implement formal transformation rules in the Topcased
environment [10]. Due to the space limitations, implementation is just partly
presented.
1 ATLAS Transformation Language.
The main transformation rule, implemented as a matched rule, recognizes the

context of each activity and invokes rules for creation of associations.
Object-object associations are created by invocation of called rule SISO (List-
ing 1) for each SISO tuple io, iof, ac, oof, oo, where io, iof, oof and oo represent
the corresponding input object, input object ow, output object ow and out-
put object for the given activity ac, respectively. The proper n-arity of created
associations is ensured by iteration through the sequence of literals recursively
generated by helper gC(). For example, if the input weight equals *, then the
sequence will be {-1} and only one association will be created, while in the case
when the input weight equals 3, the sequence will be {3, 2, 1} and exactly
three associations will be created. Each object-object association is created by

the invocation of the TOO called rule, which implements the TOO rule.
siso
Listing 1. Implementation of transformation rule TOO
helper def : gC (s:Sequence(Integer)) : Sequence(Integer) =
if (s.last()>1) then thisModule.gC((s.append(s.last()-1))) else s endif;
rule SISO (io:uml!Element, iof:uml!Element, ac:uml!Element,
oof:uml!Element, oo:uml!Element)
{
using { ct:Sequence(Integer) = thisModule.gC(Sequence {iof.weight.value}); }
do { for (c in ct) { thisModule.TOO(io,iof,ac,oof,oo); }}
}
rule TOO (io:uml!Element, iof:uml!Element, ac:uml!Element,
oof:uml!Element, oo:uml!Element)
{ to
d : uml!Association ( name<-ac.name, ownedEnd<-Sequence{os,od} ),
os : uml!Property ( name<-source, type<-thisModule.resolveTemp(io,d),
upperValue<-us, lowerValue<-ls ),
od : uml!Property ( name<-target, type<-thisModule.resolveTemp(oo,d),
upperValue<-ut, lowerValue<-lt ),
us : uml!LiteralUnlimitedNatural
(value<-if iof.weight.value=-1 then -1.toInteger() else 1 endif),
ls : uml!LiteralInteger (value<-if iof.weight.value=-1 then 0 else 1 endif),
ut : uml!LiteralUnlimitedNatural
(value<- if (oof.weight.value<>1 or io.incoming.isEmpty())
then -1.toInteger() else 1 endif),
lt : uml!LiteralInteger
(value<- if (oof.weight.value<>1 or io.incoming.isEmpty())
then 0 else 1 endif)
do { thisModule.cd.packagedElement <- d; }
}
5 Illustrative Example
The implemented generator has been applied to the generic DAD given in Fig. 5
(up). There are two participants (P1 and P2) in the given process. SIMO activity
A, performed by P1, has one existing input object of the E1 type. Each execution
of this activity results in the creation of two objects of the GA1 type and one
object of the GA2 type. Both GA1 objects constitute the generated input objects
in MISO activity B (performed by P2), which also has two existing input objects
Fig. 5. Generic DAD (up) and corresponding automatically generated CDM (down)
of the E2 type. Each execution of activity B results in the creation of a number

of GB objects and all of them, together with the GA1 and GA2 objects, constitute
generated input objects in MISO activity C which creates one GC object.
After the execution of the ATL module and visualization in the Topcased en-
vironment, we have the CD representing the initial CDM given in Fig. 5 (down).
The visualization result implies that the implemented generator has created all
associations in accordance with the formal transformation rules.
The rst group of associations are object-object associations created for all ac-
tivities having existing input objects and output objects: <E1,e1,A,oa1,GA1>,
<E1,e1,A,oa2,GA2> and double association <E2,ea,B,ob,GB>. The second group
contains object-object associations created for all activities having generated in-
put objects and output objects: double <GA1,iba1,B,ob,GB> association, double
<GA1,ica1,C,oc,GC> association, <GB,icb,C,oc,GC> and <GA2,ica2,C,oc,GC>.
Other associations are participant-object associations created for participants
and output objects (<P1,A,GA1>, <P1,A,GA2>, <P2,B,GB> and <P1,C,GC>), as
well as for participants and generated input objects (<P2,B,GA1>, <P1,C,GA1>,
<P1,C,GA2> and <P1,C,GB>).
6 Conclusion
This paper has considered the semantic capacity of object ows and action nodes
in AD for automated generation of associations in CD representing the CDM.
We have performed an analysis related to: (i) the nature of action nodes based
on the number of dierent types of input and output objects, and (ii) the weight
of object ows. By introducing the classication of activities into SISO, MISO,
SIMO and MIMO activities and making a distinction between existing and gen-
erated input objects, we have dened formal transformation rules for generation
of object-object associations. We have also provided some experimental results
of corresponding ATL implementation applied to a generic business model.
In comparison with the few existing approaches, preliminary experimental re-
sults imply that proposed transformation rules signicantly increase the already
identied semantic capacity of AD for automated CDM design, since the existing
approaches propose creation of associations for activities having both input and
output objects, but dont propose any explicit rule for automated generation of
association cardinalities.
Further research will focus on the full identication of the semantic capacity of
AD for automated CDM design, formal denition of transformation rules (par-
ticularly for participant-object associations) and the evaluation on real business
models.
References
1. Ko, R., Lee, S., Lee, E.: Business process management (BPM) standards: A survey.
Business Process Management Journal 15(5), 744791 (2009)
2. Garcia Molina, J., Jose Ortin, M., Moros, B., Nicolas, J., Troval, A.: Towards
use case and conceptual models through business modeling. In: Laender, A.H.F.,
Liddle, S.W., Storey, V.C. (eds.) ER 2000. LNCS, vol. 1920, pp. 281294. Springer,
Heidelberg (2000)
3. Suarez, E., Delgado, M., Vidal, E.: Transformation of a process business model to
domain model. In: Proc. of WCE 2008, IAENG 2008, pp. 165169 (2008)
4. Brdjanin, D., Maric, S.: An example of use-case-driven conceptual design of re-
lational database. In: Proc. of Eurocon 2007, pp. 538545. IEEE, Los Alamitos
(2007)
5. Brdjanin, D., Maric, S., Gunjic, D.: ADBdesign: An approach to automated initial
conceptual database design based on business activity diagrams. In: Catania, B.,
Ivanovic, M., Thalheim, B. (eds.) ADBIS 2010. LNCS, vol. 6295, pp. 117131.
6. Brdjanin, D., Maric, S.: Towards the initial conceptual database model through
the UML metamodel transformations. In: Proc. of Eurocon 2011, pp. 14. IEEE,
Los Alamitos (2011)
7. OMG: Unied Modeling Language: Superstructure, v2.2. OMG (2009)
8. OMG: Unied Modeling Language: Infrastructure, v2.2. OMG (2009)
9. Jouault, F., Allilaire, F., Bezivin, J., Kurtev, I.: ATL: A model transformation
tool. Science of Computer Programming 72(1-2), 3139 (2008)
10. TOPCASED Project: Toolkit in OPen-source for Critical Application & SystEms
Development, v3.2.0, http://www.topcased.org
Specification and Utilization of Core Assets:
Feature-Oriented vs. UML-Based Methods
Iris Reinhartz-Berger and Arava Tsoury
Department of Information Systems,

University of Haifa, Haifa 31905, Israel
iris@is.haifa.ac.il, aravabt@gmail.com
Abstract. Core assets are reusable artifacts built to be used in different software
products in the same family. As such, core assets need to capture both
commonality that exists and variability that is allowed in the product family
(line). These assets are later utilized for guiding the creation of particular valid
products in the family. Feature-oriented and UML-based methods have been
proposed for modeling core assets. In this work, we suggest a framework for
analyzing and evaluating core assets modeling methods. We use this framework
for comparing two specific methods: feature-oriented CBFM and UML-based
ADOM. We found similar performance in modifying core assets in the two
methods and some interesting differences in core assets utilization.
Keywords: variability, software product line engineering, domain analysis,

UML, feature-orientation.
1 Introduction
Core assets are reusable artifacts built to be used in more than one product in the
family (line) [1]. They are mainly utilized for creating particular product artifacts that
satisfy specific requirements of software products (applications). Two commonly
used ways to specify and model core assets are through feature-oriented [3, 5] and
UML-based methods [4, 10]. While feature-oriented methods support specifying core
assets as sets of characteristics relevant to some stakeholders and the relationships and
dependencies among them, UML-based methods extend UML 2 metamodel or more
commonly suggest profiles for handling core asset specification in different diagram
types. In order to examine the capabilities of these kinds of modeling methods and
their differences, we identified four main utilization and specification activities,
namely (1) guidance, or reuse, which provides aids for creating product artifacts from
core assets; (2) product enhancement, as exists while adding application-specific
elements to satisfy the requirements in hand; (3) product validation with respect to the
corresponding domain knowledge as specified in the core assets; and (4) core asset
modification, which handles introducing changes or elaborations to existing core
assets. All these activities refer to commonality and variability aspects of the given
family of software products [11], [12]. Commonality mainly specifies the mandatory
elements or features of the product line, i.e., the elements or the features that identify
Specification and Utilization of Core Assets: Feature-Oriented vs. UML-Based Methods 303
the product family and all products that belong to that family must include them.
However, commonality may refer also to optional elements which may add some
value to the product when selected, but not all the products that belong to the family
will include them. It can also refer to dependencies among (optional) elements that
specify valid configurations. Variability [8] is usually specified in terms of variation
points, which identify locations at which variable parts may occur, variants, which
realize possible ways to create particular product artifacts at certain variation points,
and rules for realizing variability (e.g., in the form of open and closed variation
points, binding times, and selection of variants in certain variation points).
We examined how advanced information systems students, who studied a domain
engineering course, performed the four aforementioned utilization and specification
activities, separately referring to commonality and variability aspects. For this
purpose, we used two particular methods: Cardinality-Based Feature Modeling
(CBFM) [3], which is a feature-oriented method, and Application-based DOmain
Modeling (ADOM), which is defined through a UML 2 profile [10]. We chose these
two particular methods due to their extended expressiveness in their categories [9]
and we found that modification of core assets in the two methods results in quite
similar performance. Regarding utilization, UML-based ADOM outperformed
feature-oriented CBFM in commonality aspects of both guidance and product
validation, while CBFM outperformed ADOM in product enhancement and
variability aspects of product validation.
The remainder of this paper is organized as follows. Section 2 introduces our
framework for analyzing the specification and utilization aids of core assets modeling
methods, while Section 3 briefly introduces CBFM and ADOM. Section 4 describes
the evaluation we have performed, discussing the research questions, settings, results,
and threats to validity. Finally, Section 5 concludes and refers to future research
directions.
2 The Core Assets Specification and Utilization Framework

Core assets and product artifacts rely in two separate layers: core assets, which are the
basis for production or development of products in a product line, reside at a more
abstract layer than product artifacts. Figure 1 shows these two layers, along with their
artifacts and main activities. The core assets specification activities include creation
and modification. Creation of core assets can be done by extracting knowledge from
particular product artifacts, constructing analogy from other core assets (in parallel
domains), or reviewing and studying the domain of interest. Modification takes core
assets in a certain domain and introduces changes in order to enlarge the domain
scope, specify newly discovered constraints, fix inaccuracies or errors, and so on.
A typical scenario of core assets utilization includes three steps. First, the core
asset is used for guiding the creation of a particular product artifact. This step includes
reusing the common kernel of the domain as captured in the core asset and choosing
particular available variants. Then, the product artifact is enhanced, adding
application-specific elements in order to satisfy the specific requirements of the
product to be developed. Finally, the specification of the enhanced product is checked
with respect to the core asset, in order to avoid violation of the domain constraints
specified in the core asset or the accompanying production plan [2].
304 I. Reinhartz-Berger and A. Tsoury
Fig. 1. A Framework for Analyzing Core Assets Specialization and Utilization
The above framework is used in the paper to examine core assets specification and
utilization in two methods, which are presented next.
3 CBFM and ADOM

The Cardinality-Based Feature Modeling (CBFM) approach [3] builds, as other
feature-oriented methods, on FODA's feature diagrams [5]. The nodes in these
diagrams are features, i.e., end-user characteristics of systems or distinguishable
characteristics of concepts that are relevant to some stakeholders of the concepts.
Features can be decomposed into sub-features and the edges represent dependencies
between features. Commonality is specified via mandatory and optional features or
sub-features. Guidance is partially supported via XOR and OR constructs or via
explicit textual constraints and composition rules. CBFM extends FODA's feature
diagrams with five main aspects: (1) cardinality, which denotes how many clones of a
feature can be included in a concrete product; (2) feature groups, which enable
organizing features and defining how many group members can be selected at certain
points; (3) attribute types, indicating that attribute values can be specified during
configuration; (4) feature model references, which enable splitting a feature diagram
into different diagrams; and (5) OCL constraints, which enable describing different
types of relationships and dependencies between features. As feature-oriented
methods in general and CBFM in particular do not explicitly support product
enhancement, we used a blank feature with three dots as its name for specifying the
ability to add application-specific elements in certain points (e.g., in "open" variation
points that enable addition of application-specific variants).
Figure 2(a) is a part of a CBFM model of the Virtual Office (VOF) domain that
describes peripherals. A peripheral, which is a device attached to a host computer and
is dependent on the host, is characterized by its physical location and possibly by its
model and manufacturer, all of which are of type String. Possible variants of
peripherals are fax machines, printers, scanners, and others. A fax machine, for
example, is characterized by a phone number, possible paper sizes, and possible
produced image qualities.
A possible utilization of the above core asset is for creating a specific brokers'
application, which has a single peripheral, called All-in-One that consists of a fax
machine, a printer, and a scanner. The first step is choosing the mandatory and
relevant optional paths in the feature diagram of the core asset. The only mandatory
path in the VOF domain is that to Physical Location of Peripheral, but several
relevant optional paths exist, e.g., the paths to Model, to Manufacturer, and so on.
Application-specific features can be added in this domain only under the Peripheral
feature group. Finally, in the third step of product validation, the product artifact, i.e.,
the brokers' application, is validated with respect to the core asset of the VOF domain.
In particular, this step includes checking that the cardinality constraints are satisfied.
Fig. 2. Partial peripheral models in (a) CBFM and (b) ADOM (class diagram)
The application-based DOmain Modeling (ADOM) defines a profile for

specifying commonality and variability aspects of core assets [10]. Figure 3 depicts
the main stereotypes and tagged values used in ADOM's profile, namely: (1)
multiplicity, which specifies the range of product elements that can be classified as
the same core element1, (2) variation point, which indicates locations where
variability may occur, including rules to realize the variability in these locations, (3)
variant, which refers to possible realizations of variability and is associated to the
corresponding variation points, (4) requires and (5) excludes, which determine
dependencies between elements (and possibly between variation points and variants).
To exemplify the ADOM method, Figure 2(b) describes the peripheral concept of
the VOF domain in terms of a class diagram. The peripheral is defined as a mandatory
variation point with different possible variants, namely fax machines, printers, and
scanners. When utilizing this core asset for creating particular product artifacts, like
the brokers' application, the optional and mandatory elements from the core asset, as
1
For clarity purposes, four commonly used multiplicity groups are defined on top of this
stereotype: optional many, where min=0 and max= , optional single, where min=0 and
max=1, mandatory many, where min=1 and max= , and mandatory single, where
min=max=1. Nevertheless, any multiplicity interval constraint can be specified using the
general stereotype multiplicity min=m1 max=m2.
well as the relevant variants, are first selected and adapted to the application in hand.
The adaptation starts with providing these elements with specific names that best fit
the given application, besides the domain names that appear as stereotypes in the
application model. Note that the same specific (application) element may be
stereotyped by several core asset elements to denote that it plays multiple roles in the
domain. All-in-One, for example, will be simultaneously stereotyped as Fax Machine,
Printer, and Scanner. Nevertheless, when selecting particular variants in a certain
variation point, the name of the variation point does not appear as a stereotype. Thus,
All-in-One will not be stereotyped as Peripheral, but just as Fax Machine, Printer, and
Scanner. Then, the application model is enhanced by adding application specific
elements, which can be completely new elements or elements that are created from
(open) variation points without reusing particular variants. Respectively, completely
new elements are visualized as elements without stereotypes, while variation point-
derived elements are decorated with the variation point names as their stereotypes. In
any case, these elements cannot violate the domain constrains, which are validated
using the application stereotypes as anchors to the domain.
Fig. 3. The UML profile at the basis of ADOM
Note that there is a very significant difference between the utilization of core assets
in CBFM and their utilization in ADOM. While CBFM reuses core assets mainly by
configuring them to the particular needs of a given application, ADOM enables
specialization of core assets and addition of details in the model level (denoted M1 in
the MOF framework [7]). However, the usage of multiple diagram types in ADOM
may raise consistency and comprehension difficulties that need to be examined. The
next section described a preliminary experiment in this direction.
4 Experimenting with CBFM and ADOM Specification and

Utilization
In order to experiment with the capabilities of CBFM and ADOM to specify and
utilize core assets, we gave advanced undergraduate and graduate information
systems students at the University of Haifa, Israel core assets of the VOF domain in
either CBFM or ADOM. We asked the students to perform some modification tasks
on the models and to create models of specific product artifacts according to given
requirements. We did not refer to core assets creation in our study, due to the nature
of our subjects and the complication of such task that mainly originates from the
diversity of the required sources. Instead, we contented with modification tasks for
examining core assets specification. Nevertheless, while creating the particular
product artifacts, the students were implicitly asked to reuse portions of the core
assets and to add application-specific elements. They were also asked to list
requirements that cannot be satisfied in the given domain, since they somehow
violates the core assets specification. Respectively, we phrased the following four
research questions: (1) The specifications of which method are more modifiable (i.e.,
easy to be modified) and to what extent? (2) The specifications of which method are
more guidable and to what extent? (3) The specifications of which method help
enhance particular product artifacts and to what extent? (4) The specifications of
which method help create valid product artifacts and to what extent?
4.1 Study Settings
Due to the difficulties to carry out such experiments on real developers in industrial
settings [6], the subjects of our study were 18 students who took a seminar course on
domain engineering during the winter semester of the academic year 2010-2011. All
the subjects had previous knowledge in systems modeling and specification, as well
as initial experience in industrial projects. During the course, the students studied
various domain engineering techniques, focusing on CBFM and ADOM and their
ability to specify core assets and utilize them for creating valid product artifacts. The
study took place towards the end of the course as a class assignment, which worth up
to 10 points of the students' final course grades.
The students were divided into four similarly capable groups of 4-5 students each,
according to their knowledge in the studied paradigms (feature-oriented vs. UML-
based), previous grades, and degrees (bachelor vs. master students). Each group got a
CBFM or ADOM model of the entire VOF domain and a dictionary of terms in the
domain. The ADOM model included a use case diagram and a class diagram, while
the CBFM model included two related feature diagrams (using feature model
references). Two groups got modification tasks, while the two other groups got
utilization tasks (see the exact details on the experiment setting in Table 1).
Table 1. Experiment design
Group # Method Task # of students

A CBFM Modification 5
B ADOM Modification 5
C CBFM Utilization 4
D ADOM Utilization 4
As noted, the modification tasks mainly required extensions to the core asset and
not inventing new parts from scratch. An example of a modification task in the study
is:
For checking devices two strategies are available: distance-based and attribute-
based. In the distance-based strategy the application locates the nearest available
devices for the task in hand ... In the attribute-based strategy, the employee needs to
supply values to different relevant parameters of the device, such as the paper size
and the print quality for printers and the paper size and the image quality for fax
machines. Each application in VOF domain must support the distance-based strategy,
but may support both strategies.
The utilization tasks required creating valid portions of a brokers' application in the
domain, according to a predefined list of requirements, and listing the parts of the
requirements that cannot be satisfied with the given core assets. An example of
requirements in these tasks is:
While operating a peripheral in the brokers' application, notifications are sent to both
employees (via emails) and log files. Furthermore, when performing a task on a
device, three main checks are performed: accessibility, feasibility, and profitability.
All tasks referred to both commonality and variability aspects, and three experts
checked that these questions can be answered via the two models separately. After the
experiment took place, we conducted interviews with the students about their answers
in order to understand what leads them to answer as they did, what their difficulties
were, and how they reached their conclusions.
4.2 Study Results
We used predefined solutions for evaluating the students' outcomes. Due to

differences in the grammars of ADOM and CBFM, normalized scores were calculated
in which the achieved scores were divided by the desired scores. We grouped the
elements according to their sources in the suggested framework: modification,
guidance, product enhancement, and product validation. The modification, guidance,
and product validation groups were further divided into commonality and variability
aspects2. The results are presented in Table 2. Since the number of students in each
group was very small (4-5), we could not perform statistical analysis and, thus, we did
not phrase null hypotheses from the research questions. Instead, we pointed out
problems, advantages, and disadvantages which were revealed while checking the
students' outcomes and interviewing them.
Table 2. Results achieved in the modification and utilization tasks
Core Assets Core assets Utilization

Specification
Modification Guidance Product Product Validation
Group Comm. Var. Comm. Var. Enhancement Comm. Var.
CBFM 0.59 0.57 0.45 0.64 0.68 0.12 0.5
ADOM 0.57 0.56 0.69 0.62 0.47 0.25 0
The scores in the core assets modification category, of both commonality and
variability-related issues, were very similar in the two modeling methods, with slight
advantages in favor of CBFM. Nevertheless, some sources of difficulties to perform this
task were identified in the students' interviews. First, while CBFM promotes
2
This separation is irrelevant for product enhancement, which deals with application-specific
additions.
hierarchical specifications in the form of trees, ADOM is basically non-hierarchical and

its models may include multiple elements at the top level. Thus, tasks that involve
modification of elements that reside at the same sub-tree in the CBFM model were
easier to be performed following CBFM method, while cross cutting aspects were easier
to be done in ADOM. An important example of this conclusion is the specification of
dependencies between elements. In CBFM some of these dependencies are inherently
specified in the tree structure, while in ADOM these dependencies had to use several
"requires" dependencies each. Indeed, the dependency specification in ADOM yields
more complex models than in CBFM. Furthermore, ADOM requires explicitly
specifying meta-information, such as the stereotypes and the tagged values. Some of the
students did not use this meta-information and built on the large expressiveness of
UML. Another source of difficulty in ADOM was updating different types of diagrams,
namely use case and class diagrams, for the same tasks. This led to confusion whether
the update needs to be made only on the use case diagram, only on the class diagram, or
on both. Consequently, some inconsistencies between these diagrams in the obtained
modified models were found.
In CBFM, the main difficulty in core assets modification was to understand group
cardinality. This may be due to the fact that group cardinality in CBFM is interpreted
according to the location of the feature group in the feature diagram and not globally
in the context of the entire application. This is also the case in ADOM, but ADOM
enables explicit specification as tagged values of the corresponding variation points.
Another observation regarding CBFM is that introduction of new elements was very
difficult to be performed, and the main source of this difficulty was identifying the
exact locations at which these elements need to be integrated in the tree structure. The
tendency was to add new features in lower locations than required in the tree, maybe
since low level elements seemed more detailed. Finally, the usage of feature model
references was not performed well, probably because of inexperience of the subjects
in the advanced features of the CBFM method.
Regarding core assets utilization, we found similar scores in variability aspects of
core assets guidance. However, ADOM outperformed CBFM in commonality-related
issues of guidance (0.69 vs. 0.45) and in commonality-related issues of product
validation (0.25 vs. 0.12), while CBFM outperformed ADOM in product enhancement
issues (0.68 vs. 0.47) and in variability-related issues of product validation (0.5 vs. 0).
Analyzing the sources of difficulties, we first found that the existence of inheritance
relations in ADOM helped understand the hierarchical structure in general and the exact
attributes of low level elements in particular. For example, the students utilizing CBFM
had difficulties in understanding that fax machines, scanners, and printers, which are all
peripherals, exhibit also physical locations and manufacturers. This was better
understood by the students who had the ADOM model and, thus, their performance in
commonality-related issues of guidance was better. Furthermore, in CBFM, the
students experienced difficulties in creating several instances of the same core asset
element. During their interviews, the students claimed that the multiplicity specification
of members in feature groups was very confusing. They thought that these multiplicities
constrain up to a single variant in the whole application, while their actual meaning is up
to a single variant in each instance of their feature group (i.e., in each realization of the
corresponding group).
Regarding product enhancement, students utilizing the ADOM model believed that
they are not allowed to add elements which are not specified in the core asset of the
domain. Thus, they pointed on the corresponding requirements as violating the
domain constraints rather than application-specific additions. This result may be
attributed to the relatively rich notation of UML and ADOM with respect to CBFM:
the students mainly relied on the VOF specification as expressed in the ADOM model
and tended not to extend it with new requirements.
In both methods, the main source of difficulties in questions that refer to
commonality-related issues of product validation was comprehension of dependencies
between elements. In particular, traceability of OCL constraints was found as a very
difficult task. Since ADOM enables (through UML) visual specification of some OCL
constraints with {or} and {xor} constructs, the students utilizing ADOM succeeded a
little bit more in this category.
Finally, only one task referred to variability-related issues in product validation.
The violation in this task referred to a dependency between two variants. None of the
students who utilized ADOM found this violation, while half of the students who
utilized CBFM found it. We believe that the difference in this case is due to relatively
crowd specifications in ADOM with respect to CBFM: for finding the violation, the
class diagram, which included the variation point, the possible variants, and the
exhibited attributes, had to be consulted. The corresponding specification in CBFM
was much simpler and involved hierarchical structure of features. However, since
only one task referred to this aspect, we cannot state any more general conclusions.
4.3 Threats to Validity
The main threats to validity are of course the small numbers of subjects (18 overall),
the nature of the subjects (students and not experienced developers and domain
engineers), and the relatively simplified tasks and models. In order to overcome these
threats we took the following actions. First, the students had to fill pre-questionnaires
that summarized their level of knowledge and skills. They were trained throughout the
course with the modeling methods and reached a high level of familiarity with these
methods. Moreover, we used additional information regarding the subjects, such as
their grades, degrees, and previous knowledge, in order to divide them into similarly
capable groups. Since we could not perform a statistical analysis due to the low
number of subjects, we conducted interviews with the subjects in order to get more
insights to the achieved results. We further motivated the students to produce
qualitative outcomes by giving them up to 10 points to their final grades according to
their performance in the assignment. Second, we carefully chose the domain and
specified the corresponding models so that they will refer to different domain
engineering-related challenges. Three experts checked the models and their equivalent
expressiveness before the experiment. However, we aim at keeping the models
simple, yet realistic, so that the subjects will be able to respond in reasonable time.
Third, we conducted a comparative analysis between existing feature-oriented and
UML-based methods. The methods used in the experiment were selected based on
this analysis (the main reasons for this choice are mentioned in [9]).
5 Summary and Future Work

Utilization and specification of core assets is important when dealing with software
product line engineering. In this paper, we analyzed the main difficulties in
performing these tasks in two methods from different leading modeling paradigms:
CBFM, which is a feature-oriented method, and ADOM, which is based on a UML 2
profile. We found similar results in specifying, or more accurately modifying, core
assets in the two methods, while some difficulties and problems in core assets
utilization were encountered in the two modeling paradigms. Despite the low number
of subjects, we tried to provide some explanations to these problems, analyzing the
subjects' outcomes and interviews.
Only further studies, both empirical and theoretical ones, may confirm or
disconfirm whether our results can be generalized to more experienced subjects, more
complicated models and tasks, and other modeling methods. In particular, we intend
to compare the expressiveness, comprehensibility, and specification and utilization
capabilities of different product line engineering methods and to conduct similar
experiments on larger classes of domain engineering students.
References
1. Bachmann F., Celments, P., C.: Variability in Software Product Lines. Technical Report
CMU/SEI-2005-TR-012 (2005),
http://www.sei.cmu.edu/library/abstracts/reports/05tr012.cfm
2. Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. Addison-
Wesley, Reading (2002)
3. Czarnecki, K., Kim, C.H.P.: Cardinality based feature modeling and constraints: A
progress report. In: Proceedings of the OOPSLA Workshop on Software Factories (2005)
4. Halmans, G., Pohl, K., Sikora, E.: Documenting Application-Specific Adaptations in
Software Product Line Engineering. In: Bellahsne, Z., Lonard, M. (eds.) CAiSE 2008.
5. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, A.: Feature-Oriented Domain Analysis
(FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, Software Engineering
Institute, Carnegie Mellon University (1990)
6. Kitchenham, B.A., Lawrence, S., Lesley, P., Pickard, M., Jones, P.W., Hoaglin, D.C.,
Emam, K.E.: Preliminary Guidelines for Empirical Research. IEEE Transactions on
Software Engineering 28(8), 721734 (2002)
7. OMG. Meta Object Facility (MOF) Specification version 2.4,
http://www.omg.org/spec/MOF/2.4/Beta2/PDF/
8. Pohl, K., Bckle, G., van der Linden, F.: Software Product Line Engineering: Foundations,
Principles, and Techniques. Springer, New York (2005)
9. Reinhartz-Berger, I., Tsoury, A.: Experimenting with the Comprehension of Feature-
Oriented and UML-Based Core Assets. In: Halpin, T., Nurcan, S., Krogstie, J., Soffer, P.,
Proper, E., Schmidt, R., Bider, I. (eds.) BPMDS 2011 and EMMSAD 2011. LNBIP,
10. Reinhartz-Berger, I., Sturm, A.: Utilizing Domain Models for Application Design and
Validation. Information and Software Technology 51(8), 12751289 (2009)
11. Sinnema, M., Deelstraa, S.: Classifying Variability Modeling Techniques. Information and
Software Technology 49(7), 717739 (2007)
12. Svahnberg, M., Van Gurp, J., Bosch, J.: A Taxonomy of Variability Realization
Techniques. Software Practice & Experience 35(8), 705754 (2005)
Actor-eUML for Concurrent Programming
Kevin Marth and Shangping Ren
Illinois Institute of Technology

Department of Computer Science
Chicago, IL USA
martkev@iit.edu
Abstract. The advent of multi-core processors oers an opportunity

to increase the usage of Executable UML. Researchers are advocating
the division of software systems into a productivity layer and an e-
ciency layer to shield mainstream programmers from the complexities
of parallelism. Such separation of application and platform concerns is
the foundation of Executable UML. To leverage this opportunity, an ap-
proach to Executable UML must address the complexity of the UML
standard and provide a formal model of concurrency. In this paper, we
introduce the Actor-eUML model and formalize the mapping between
actors in the Actor model and Executable UML agents (active objects)
by unifying the semantics of actor behavior and the hierarchical state
machine (HSM) semantics of Executable UML agents. The UML treat-
ment of concurrency is simplied, and the Actor model is extended to
enable a set of actor behaviors to specify the HSM for an Executable
UML active class.
1 Introduction
Multi-core processors have entered the computing mainstream, and many-core
processors with 100+ cores are predicted within this decade. The increasing
hardware parallelism and the absence of a clear software strategy for exploiting
this parallelism have convinced leading computer scientists that many practicing
software engineers cannot eectively program state-of-the-art processors [8]. We
believe that a basis for simplifying parallel programming exists in established
software technology, including the Actor model [1] and Executable UML. The
advent of multi-core processors has galvanized interest in the Actor model, as
the Actor model has a sound formal foundation and provides an intuitive parallel
programming model. To leverage the Actor model, software systems should be
specied in a language that provides rst-class support for the Actor model and
exposes its rather abstract treatment of parallelism. A leading parallel research
program has advocated dividing the software stack into a productivity layer
and an eciency layer [7]. Parallel concerns are addressed in the eciency layer
by expert parallel programmers, and the productivity layer enables mainstream
programmers to develop applications while being shielded from the parallel hard-
ware platform. This separation of application concerns (productivity layer) and
platform concerns (eciency layer) is the foundation of Executable UML.

Actor-eUML for Concurrent Programming 313
Fortunately, the Actor model and Executable UML are readily unied. In this
paper, we introduce the Actor-eUML model and formalize the mapping between
actors in the Actor model and agents (active objects) in Executable UML by uni-
fying the semantics of actor behavior and the hierarchical state machine (HSM)
semantics of Executable UML agents. Simply stated, an Executable UML agent
is an actor whose behavior is specied as a HSM. To facilitate the denition of
unied semantics for Actor-eUML, we simplify the UML treatment of concur-
rency and extend the Actor model to enable a set of actor behaviors to specify
the HSM for an Executable UML active class. Section 2 presents an overview
of the Actor-eUML model. Section 3 presents the operational semantics of the
Actor-eUML model. Section 4 concludes the paper.
2 Overview of the Actor-eUML Model

2.1 Related Work
The separation of application and platform concerns is embodied in the Model-
Driven Architecture (MDA) [5]. Executable UML uses proles of the Unied
Modeling Language [11] to support the MDA and enable the specication of an
executable platform-independent model (PIM) of a software system that can be
translated to a platform-specic implementation (PSI) using a model compiler.
Several approaches to Executable UML exist [4][6][9], and each approach enables
a software system to be specied using the following process.
The software system is decomposed into domains (concerns).
Each domain is modeled in a class diagram using several classes.
Each class has structural and behavioral properties, including associations,
attributes, operations, and a state machine.
A formal action language is used to specify the implementation of operation
methods and state machine actions.
In both xUML [4] and xtUML [9], only simple state machines are supported,
and many HSM features are not available. In contrast, all standard UML HSM
features are supported in Actor-eUML, with the exception of features that imply
concurrency within a HSM. The foundational subset for Executable UML models
(fUML) [12] precisely species the semantics of the UML constructs considered
to be used most often. As such, the fUML specication does not address all state
machine features and explicitly does not support state machine features such as
call events, change events, and time events.
The Actor-eUML model has a formal concurrency model (the Actor model),
while existing approaches to Executable UML lack a formal treatment of con-
currency beyond the operational requirement for the modeler and/or the model
compiler to synchronize the conceptual threads of control associated with active
class instances. Some HSM features, such as deferring certain messages when
an actor is in a given state, have been implemented in actor-based program-
ming languages using reective mechanisms that modify the behavior of the
mail queue for an actor [10], but these actor-based languages lack full-featured
HSM support.
314 K. Marth and S. Ren
2.2 Hierarchical State Machines in Actor-eUML
The Actor-eUML model promotes HSM usage because state-based behavior is

fundamental to object-based programming. Hierarchical states facilitate pro-
gramming by dierence, where a substate inherits behavior from superstates
and denes only behavior that is specic to the substate. A design invariant
can be specied once at the appropriate level in a state hierarchy, eliminat-
ing redundancy and minimizing maintenance eort. Standard UML supports a
variant of Harel statecharts [3] that enables behavior to be specied using an
extended HSM that combines Mealy machines, where actions are associated with
state transitions, and Moore machines, where actions are associated with states.
Actor-eUML supports internal, external, local, and start transitions as specied
in standard UML and provides the following support for events and states.
Events. As in the Actor model, agents in Actor-eUML communicate using only

asynchronous message passing. A message received by an agent is dispatched to
its HSM as a signal - a named entity with a list of parameters. Actor-eUML
supports three kinds of HSM events:
a signal event that occurs when a signal is dispatched,

a time event that occurs when a timer expires after a specied duration, and
a change event that occurs when a Boolean expression becomes true.
Events are processed serially and to completion. Although there can be massive
parallelism among agents, processing within each agent is strictly sequential.
States. A state in an Actor-eUML HSM has several features: an optional name,

entry actions, exit actions, transitions, deferred events, and a nested state ma-
chine. Entry actions and exit actions are executed when entering and exiting
the state, respectively. Deferred events are queued and handled when the state
machine is in another state in which the events are not deferred. A state in a
state machine can be either simple or composite. A composite state has a nested
state machine.
In standard UML, a composite state can have multiple orthogonal regions,
and each region has a state machine. Orthogonal regions within a composite
state introduce concurrency within a HSM, since the state machine within each
region of a composite state is active when the composite state is active. Stan-
dard UML also supports a do activity for each state that executes concurrently
with any do activity elsewhere in the current state hierarchy. The Actor model
avoids concurrency within an actor. To align with the Actor model, Actor-eUML
does not allow concurrency within a HSM and consequently does not support
do activities or orthogonal regions. In practice, orthogonal regions are often
not independent and share data. The UML standard states that orthogonal re-
gions should interact with signals and should not explicitly interact using shared
memory. Thus, replacing orthogonal regions in Actor-eUML by coordinated peer
agents is appropriate.
2.3 Simplied Concurrency in Actor-eUML

To align the Actor-eUML model with the Actor model, it is necessary to elim-
inate HSM features that introduce concurrency within an active object, but
additional simplication is required to complete the alignment. The treatment
of concurrency in standard UML is heterogeneous and complex. An active object
(i.e. agent) has a dedicated conceptual thread of control, while a passive object
does not. The calls to operations for active classes and passive classes can be
either synchronous or asynchronous, and it is possible to combine operations and
a state machine when dening the behavior of an active class. An active object
in standard UML can be either internally sequential or internally concurrent,
depending upon whether it has a state machine and whether the state machine
uses operation calls as state machine triggers. A passive object can also be either
internally sequential or internally concurrent, since each operation of a passive
class is dened to be sequential, guarded, or concurrent.
It is apparent that the multiple interacting characteristics of the features
of active and passive classes add complexity to the treatment of concurrency
in standard UML. The treatment of concurrency in existing Executable UML
approaches (including fUML) is simpler, but it is still possible to have multiple
threads of control executing concurrently within an agent. Actor-eUML further
streamlines the treatment of concurrency.
A passive class can dene only synchronous, sequential operations.
A passive object is encapsulated within one agent, and an agent interacts
with its passive objects only through synchronous operation calls.
Agents interact only through asynchronous signals sent to state machines.
An active class can dene operations, but a call to an agent operation is
simply notation for an implicit synchronous signal exchange with the agent.
A call to an agent operation sends a signal with the same signature to the HSM
for the agent and blocks the caller until the signal is processed and a reply signal
is received. Thus, any communication with an agent is a signal event that is
interleaved serially with other HSM events in the thread of control for the agent.
This treatment of agent interaction ensures that agents are internally sequential
and avoids the complexities of concurrent access to the internal state of an agent.
With these simplications, the Actor-eUML concurrency model aligns with the
Actor model and is safer than multi-core programming models that require the
programmer to explicitly synchronize concurrent access to shared memory.
2.4 Actors in Actor-eUML

The Actor model [1] is a formal theory of computation and concurrency based on
active, autonomous, encapsulated objects that communicate exclusively through
asynchronous message passing. The Actor model has a sound mathematical foun-
dation but is also inuenced by implementation concerns and the laws of physics.
The Actor model acknowledges that messages can encounter bounded but in-
determinate delays in transmission and can therefore be delivered out of order.

Fig. 1. An Actor in the Actor Model [1]
As illustrated in Fig. 1, in response to each message received from its abstract

mailbox (external queue), an actor X can:
create a nite number of new actors,
send a nite number of messages to other actors, and
select the behavior used to process the next message.
The Actor model is characterized by inherent concurrency among actors. An
actor is allowed to pipeline the processing of messages by selecting the behavior
used to process the next message and actually dispatching the next message for
processing before the processing of the current message has completed. However,
pipelined actor behaviors cannot share internal state, and the Actor model does
not require message pipelining. The ability to pipeline messages is not compatible
with HSM semantics, as the exit and entry actions for a transition must execute
before the next transition can be triggered, so actors in the Actor-eUML model
that realize HSM behavior do not attempt message pipelining. However, other
actors in the Actor-eUML model can use message pipelining.
An actor can send messages to its own mailbox, but a message an actor
sends to itself is interleaved with messages received from other actors and is
not guaranteed to be the next message dispatched. This consideration and the
requirement that an actor consume a message with each behavior change lead
to a continuation-passing style that uses cooperating auxiliary actors to process
a single client message. This style of programming adds conceptual overhead
for programmers who nd it confusing and adds implementation overhead that
cannot always be eliminated by smart compilers and sophisticated schemes aimed
at minimizing the performance impact of actor creation and communication.

Fig. 2. An Actor in the Actor-eUML Model
The Actor-eUML model retains the essence of the pure Actor model while
adding capabilities that simplify actor programming and enable HSM behavior
to be expressed directly and conveniently. As illustrated in Fig. 2, the actor
interface to its abstract mailbox has been extended with two internal queues:
a working queue (queuew ) for internal messages used while processing a single
external message, and a defer queue (queued ) used to defer messages based on
the current state in a HSM. The external queue (queuee ) that receives messages
sent to an actor has been retained. When a message is dispatched from queuee ,
the message is moved to queuew and then dispatched for processing by the next
behavior. As the behavior executes, messages can be added to queuew . When the
behavior completes, the message at the head of queuew is dispatched to the next
behavior. If the queuew is empty when a behavior completes, the next message
is dispatched from queuee . A message dispatched from queuew can be deferred
to queued . The messages in queued are moved to queuew to revisit them.
The additional internal queues enable a single actor to completely process a
client message without creating and communicating with auxiliary actors and
also facilitate the expression of HSM behavior. Each state in a HSM is mapped
to an actor behavior, and a signal is delegated from the current state to its
parent state by adding the signal to queuew and then selecting the behavior for
its parent state as the next behavior. A sequence of start, entry, and exit actions
is executed during a state transition by adding specialized messages to queuew
and then selecting the behavior of the next state in the sequence. A signal that is
deferred in the current state is added to queued . Deferred messages are revisited
after a state transition by moving the messages from queued to queuew .
3 Actor-eUML Semantics
The Actor-eUML model denes the following actor primitives, where B is a
behavior, M is a message, and V is a list of parameter values. The call B(V)
returns a closure, which is a function and a referencing environment for the non-
local names in the function that binds the nonlocal names to the corresponding
variables in scope at the time the closure is created. The closure returned by the
call B(V) captures the variables in V, and the closure expects to be passed M as
a parameter when called subsequently.
actor-new(B, V): create a new actor with initial behavior B(V).
actor-next(Ai , B, V): select B(V) as the next behavior for actor Ai .
actor-send(Ai , M): send M to the tail of queuee for actor Ai .
actor-push(Ai , M): push M at the head of queuew for actor Ai .
actor-push-defer(Ai , M): push M at the head of queued for actor Ai .
actor-move-defer(Ai ): move all messages in queued to queuew for actor Ai .
The {actor-new, actor-next, actor-send} primitives are inherited from the
Actor model, and the {actor-push, actor-push-defer, actor-move-defer}
primitives are extensions to the Actor model introduced by the Actor-eUML
model. When transforming a PIM to a PSI, a model compiler for an Actor-
eUML implementation translates the HSM associated with each active class to a
target programming language in which the actor primitives have been embedded.
At any point in a computation, an actor is either quiescent or actively process-
ing a message. The term actor4 (Ai , Q, C, M ) denotes a quiescent actor, where
Ai uniquely identies the actor, Q is the queue for the actor, C is the closure used
to process the next message dispatched by the actor, and M is the local memory
for the actor. The queue Q is a 3-tuple Qe , Qw , Qd , where Qe is the external
queue where messages sent to the actor are received, Qw is the work queue used
when processing a message M dispatched by the actor, and Qd is used to queue
messages deferred after dispatch. At points in a computation, a component of
Q can be empty and is denoted by Q . The term actor5 (Ai , Q, C , M, E S)
denotes an active actor and extends the actor4 term to represent a computation
in which statement list S is executing in environment E. An active actor has a
null C, denoted by C .
A transition relation between actor congurations is used to dene the Actor-
eUML operational semantics, as in [2]. A conguration in an actor computation
consists of actor4 , actor5 , and send terms. The send(Ai , M) term denotes a
message M sent to actor Ai that is in transit and not yet received. The speci-
cation of structural operational semantics for Actor-eUML uses rewrite rules to
dene computation as a sequence of transitions among actor congurations.
Rules (1) and (2) dene the semantics of message receipt. A message M sent
to actor Ai can be received and appended to the external queue for actor Ai
when the actor is quiescent (1) or active (2). The send term is consumed and
eliminated by the rewrite. The message receipt rules illustrate several properties
explicit in the Actor model. An actor message is an asynchronous, reliable, point-
to-point communication between two actors. The semantics of message receipt
are independent of the message sender. Each message that is sent is ultimately
received, although there is no guarantee of the order in which messages are
received. A message cannot be broadcast and is received by exactly one actor.
send(Ai , M) actor4 (Ai , Qe , Qw , Qd , C, M )

actor4 (Ai , Qe :M, Qw , Qd , C, M ) (1)
send(Ai , M) actor5 (Ai , Qe , Qw , Qd , C , M, E S)

actor5 (Ai , Qe :M, Qw , Qd , C , M, E S) (2)
Rules (3) and (4) dene the semantics of message dispatch. In rule (3), the
quiescent actor Ai with non-empty Qe and empty Qw initiates the dispatch of
the message M at the head of Qe by moving M to Qw . In rule (4), the quiescent
actor Ai completes message dispatch from Qw and becomes an active actor by
calling the closure C to process M in the initial environment Ec associated with
C. The message dispatch rules enforce the serial, run-to-completion processing of
messages and the demand-driven relationship between Qe and Qw in the Actor-
eUML model. An actor cannot process multiple messages concurrently, and a
message is dispatched from Qe only when Qw is empty.
actor4 (Ai , M:Qe , Q , Qd , C, M ) actor4 (Ai , Qe , M, Qd , C, M ) (3)
actor4 (Ai , Qe , M:Qw , Qd , C, M )

actor5 (Ai , Qe , Qw , Qd , C , M, EC (call C M)) (4)
Rules (5), (6), and (7) dene the semantics of the actor-new, actor-next, and
actor-send primitives, respectively. In rule (5), the active actor Ai executes the
actor-new primitive to augment the conguration with an actor4 term that
denotes a new actor An with empty Q, uninitialized local memory (M ), and
initial behavior closure C = B(V). In rule (6), the active actor Ai executes the
actor-next primitive to select its next behavior closure C = B(V) and becomes
a quiescent actor. In rule (7), the active actor Ai executes the actor-send prim-
itive to send the message M to actor Aj , where both i = j and i = j are
well-dened.
actor5 (Ai , Q, C , M, E actor-new(B, V); S)

actor5 (Ai , Q, C , M, E S) actor4 (An , Q , Q , Q , C, M ) (5)
actor5 (Ai , Q, C , M, E actor-next(Ai , B, V); S)

actor4 (Ai , Q, C, M ) (6)
actor5 (Ai , Q, C , M, E actor-send(Aj , M); S)

actor5 (Ai , Q, C , M, E S) send(Aj , M) (7)
Rules (8), (9), and (10) dene the semantics of the actor-push,
actor-push-defer, and actor-move-defer primitives, respectively.
actor5 (Ai , Qe , Qw , Qd , C , M, E actor-push(Ai , M); S)
actor5 (Ai , Qe , M:Qw , Qd , C , M, E S) (8)
actor5 (Ai , Qe , Qw , Qd , C , M, E actor-push-defer(Ai , M); S)

actor5 (Ai , Qe , Qw , M:Qd , C , M, E S) (9)
actor5 (Ai , Qe , Qw , Qd , C , M, E actor-move-defer(Ai ); S)

actor5 (Ai , Qe , Qw :reverse(Qd ), Q , C , M, E S) (10)
The actor primitives intrinsic to the Actor-eUML model are the foundation for
other abstractions useful in realizing an implementation of HSM behavior. The
following HSM abstractions are typically dened as macros in the target pro-
gramming language. The HSM abstraction macros implement HSM behavior
using exclusively the Actor-eUML primitives actor-push and actor-next and
the internal work queue Qw , in combination with parameter passing between ac-
tor behaviors. The HSM abstraction macros facilitate a direct translation from
a HSM specication to its implementation.
The HSM-state-start macro realizes the start transition for a state.
The HSM-state-entry macro realizes the entry actions for a state.
The HSM-state-exit macro realizes the exit actions for a state.
The HSM-state-reset macro returns the HSM to its current state prior to
delegating a signal up the HSM hierarchy without consuming the signal.
The HSM-state-next macro delegates a signal to a superstate.
The HSM-state-transition macro realizes a local or external transition
from a source state to a target state.
The HSM-state-transition-internal macro realizes an internal transition
in a state.
The actor-push-defer and actor-move-defer primitives implement deferred
signals within a HSM, and the actor-send primitive is used to send an asyn-
chronous signal from the HSM for an agent to the HSM for a target agent.
A reference implementation of the Actor-eUML model and the associated
HSM abstraction macros has been developed in Common Lisp, conrming that
a direct and ecient realization of the model is practical. A C++ implementation
of the Actor-eUML model is also in development and will be the target language
for a model compiler, enabling software engineers to specify Executable UML
models oriented to the problem space that abstract the programming details of
the Actor-eUML model in the solution space. However, the mapping from the
UML agents in the problem space to the Actor-eUML actors in the solution space
is direct, reducing the semantic distance between a UML specication and its
realization and ensuring that UML specications are founded on a formal model
of concurrency that provides a logically sound and intuitive basis for reasoning
about parallel behavior and analyzing run-time performance.
4 Summary and Conclusion
The advent of multi-core processors signaled a revolution in computer hardware.

We believe that it is possible to program multi-core and many-core processors by
using an evolutionary approach that leverages established software technology,
notably the Actor model and Executable UML. The Actor model has a sound
formal foundation and provides an intuitive and safe concurrent programming
model. Executable UML consolidates and standardizes several decades of experi-
ence with object-based programming. Unifying the Actor model and Executable
UML in the Actor-eUML model provides a concurrency model that exploits
massive inter-agent parallelism while ensuring that agent behaviors retain the
familiarity and simplicity of sequential programming. The HSM is the founda-
tion of agent behavior in Actor-eUML. The Actor-eUML model streamlines the
UML concurrency model, eliminates HSM features that imply intra-agent con-
currency, and introduces conservative extensions to the structure and behavior
of message dispatch in the Actor model. A denition of the operational seman-
tics of the actor primitives provided by the Actor-eUML model was presented,
and a reference implementation of the Actor-eUML model is available.
References
1. Agha, G.: Actors: A Model of Concurrent Computation in Distributed Systems.
MIT Press, Cambridge (1986)
2. Agha, G., Mason, I.A., Smith, S.F., Talcott, C.L.: A Foundation for Actor Com-
putation. Journal of Functional Programming, 172 (1997)
3. Harel, D.: Statecharts: A Visual Formalism for Complex Systems. Science of Com-
puter Programming 8(3), 231274 (1987)
4. Mellor, S.J., Balcer, S.J.: Executable UML: A Foundation for Model-Driven Ar-
chitecture. Addison-Wesley, Reading (2002)
5. Mellor, S.J., Kendall, S., Uhl, A., Weise, D.: MDA Distilled. Addison-Wesley, Read-
ing (2004)
6. Milicev, D.: Model-Driven Development with Executable UML. Wiley, Chichester
(2009)
7. Patterson, D., et al.: A View of the Parallel Computing Landscape. Communica-
tions of the ACM 52(10), 5667 (2009)
8. Patterson, D.: The Trouble with Multi-Core. IEEE Spectrum 47(7), 2832 (2010)
9. Raistrick, C., Francis, P., Wright, J., Carter, C., Wilkie, I.: Model Driven Archi-
tecture with Executable UML. Cambridge University Press, Cambridge (2004)
10. Tomlinson, C., Singh, V.: Inheritance and Synchronization with Enabled Sets.
SIGPLAN Notices 24(10), 103112 (1989)
11. Object Management Group: UML Superstructure Specication, Version 2.1.2,
http://www.omg.org/docs/formal/07-11-02.pdf
12. Object Management Group: Semantics of a Foundational Subset for Executable
UML Models (fUML), Version 1.0, http://www.omg.org/spec/FUML
Preface to the Posters and Demonstrations
This volume also contains the papers presented at Posters and Demonstrations
session of the 30th International Conference on Conceptual Modeling, held on
October 31 to November 3, 2011 in Brussels.
The committee decided to accept 9 papers for this session. We hope that
you nd the contributions benecial and enjoyable and that during the session
you had many opportunities to meet colleagues and practitioners. We would
like to express our gratitude to the program committee members for their work
in reviewing papers, the authors for submitting their papers, and the ER 2011
organizing committee for all their support.
July 2011 Roland Billen

Brussels Pierre Hallot

An Eclipse Plugin for Validating Names
in UML Conceptual Schemas
David Aguilera, Ra
ul Garca-Ranea, Cristina G
omez, and Antoni Olive
Department of Service and Information System Engineering

BarcelonaTech Universitat Politècnica de Catalunya
Barcelona, Spain
{daguilera,cristina,olive}@essi.upc.edu,
raul.garcia-ranea@est.fib.upc.edu
Abstract. Many authors agree on the importance of choosing good

names for conceptual schema elements. Several proposals of naming guide-
lines are available in the literature, but the support oered by current
CASE tools is very limited and, in many cases, insucient. In this demon-
stration we present an Eclipse plugin that implements a specic proposal
of naming guidelines. The implemented proposal provides a guideline for
every kind of named element in UML. By using this plugin, the modelers
can automatically check whether the names they gave to UML elements
are grammatically correct and generate a verbalization that can be anal-
ysed by domain experts.
Keywords: Naming Guidelines, Eclipse, Conceptual Schemas.
1 Introduction
Names play a very important role on the understandability of a conceptual
schema. Many authors agree that choosing good names for schema elements make
conceptual schemas easier to understand for requirements engineers, conceptual
modelers, system developers and users [5,6].
Choosing good names is one of the most complicated activities related to
conceptual modeling [8, p.46]. There have been several proposals of naming
guidelines for some conceptual schema elements in the literature [3,7] but, as
far as we know, few CASE tools support this activity. One example is [2], which
controls that the capitalization of some elements is correct, like classes should
start with a capital letter.
In this demonstration, we present an Eclipse plugin that adds naming valida-
tion capabilities to the UML2Tools framework. This plugin can assist modelers
during the naming validation process of named elements in UML, following the
complete naming guidelines presented in [1].
2 Overview of the Naming Guidelines

There are several naming guidelines available in the literature on how to name
conceptual schema elements. We implemented the proposal presented in [1]

324 D. Aguilera et al.
because it is complete: for each kind of element to which a modeler may give a
name in UML, it provides a guideline on how to name it. As an example, two
guidelines are summarized in the following:
Guideline for Entity Types
G1f The name of an entity type should be a noun phrase whose head is a countable
noun in singular form. The name should be written in the Pascal case.
G1s If N is the name of an entity type, then the following sentence must be gram-
matically well-formed and semantically meaningful:
An instance of this entity type is [a|an] lower 1 (N )
Guideline for Boolean Attributes
G2f The name A should be a verb phrase in third-person singular number, in the
Camel case.
G2s The following sentence must be grammatically well-formed and semantically
meaningful:
[A|An] lower (E) lower (withOrNeg 2 (A)) [, or it may be unknown].
where the last optional fragment is included only if min is equal to zero.
As stated in [1], a name given by a conceptual modeler complies with the guide-
line if: a) it has the corresponding grammatical form Gf , and b) the sentence
generated from the pattern sentence Gs and the given name is grammatically
well-formed and semantically meaningful.
event event event GENERAL CONSTRAINTS

EndOfSale NewSale * NewSaleLineItem * Buys context Product inv identiedByItsName:
Product.allInstances()->isUnique(name)
0..1 quantity: Integer
Ends Involves context Shop inv isIdentiedByItsName: ...
1 1 context Sales inv is identied by its shop and date and
time: ...
Sales context SaleLineItem inv is identied by the sale that
* SaleLineItem contains it and the bought product item: ...
isComplete: Boolean = False
date: Date quantity: Integer context Sales inv contains only product items available
at its shop: ...
time: Time * context ProductItem inv has a positive price: ...
* References context SaleLineItem inv hasAPositiveQuantity: ...
Has context NewSaleLineItem inv has a positive quantity: ...
1 1 1
Shop ProductItem OPERATION CONTRACTS
context NewSaleLineItem::effect()
name: String price: Money pre the sale is not complete:
opensAllDay: Boolean[0..1] quantityOnHand: Integer not sales.isComplete
pre there is enough stock:
*
quantity >= productItem.quantityOnHand
* post a sale line item has been created:
Product datatype sli.oclIsNew() and sli.oclIsTypeOf(SaleLineItem)
Money and sli.quantity := quantity
name: String post the quantity on hand has decreased in quantity:
description: String value: Real productItem.quantityOnHand :=
perishable: Boolean currency: String productItem.quantityOnHand@pre - quantity
Fig. 1. Example of a conceptual schema with some names violating their guidelines
1
lower (N ) is a function that gives N in lower case and using blanks as delimiters.
2
withOrNeg (A) extends A with the insertion of the negative form of the verb of A.
Eclipse Plugin for Validating Names in UML Schemas 325
Figure 1 shows an example where some names, which are highlighted, violate
their naming guidelines. The next section describes how to use the developed
Eclipse plugin to detect those errors.
3 Naming Validation Plugin for Eclipse

Eclipse is an open, extensible development environment (IDE) written in Java.
It is a small kernel with a plugin loader surrounded by hundreds of plugins [4].
Eclipse, in combination with the UML2Tools plugin, can manage UML les and
permits modelers to dene conceptual schemas.
We conceived our tool as an Eclipse plugin that extends the UML2Tools
framework by adding two main functionalities. The rst one checks if the names
of the schema follow the grammatical form dened in their corresponding guide-
lines. The second functionality verbalizes the schema in a document.
Fig. 2. Screenshot of Eclipse showing those names that violate their guidelines
Figure 2 shows a screenshot of the rst functionality in action. By selecting

the Package and then clicking on menu Verbalize Check Names, our tool
checks the whole conceptual schema looking for errors. If the modeler selected a
few elements instead of the package, only those elements are checked instead of
Fig. 3. Screenshot of the conguration window

326 D. Aguilera et al.
the whole schema. If one or more names are incorrect, the errors are shown in a
new Eclipse view.
The second functionality introduces schema verbalization. Our tool generates
a PDF le containing the pattern sentences dened in the naming guidelines
and the names of the selected elements. Some aspects of the resulting document
can be congured by using the conguration window shown in Fig. 3. In order
to generate the document, the modeler has to click on Verbalize Verbalize.
Figure 4 shows the verbalization of the schema of Fig. 1 after correcting the
errors previously detected. Then, the modeler or a domain expert may check
the document and detect whether the generated sentences are grammatically
well-formed and semantically meaningful.
Fig. 4. Screenshot of the resulting document with the schema verbalization
Acknowledgements. Our thanks to the people in the GMC research group. This
work has been partly supported by the Ministerio de Ciencia y Tecnologa un-
der TIN2008-00444 project, Grupo Consolidado, and by BarcelonaTech Universitat
Politècnica de Catalunya, under FPI-UPC program.
References
1. Aguilera, D., Gomez, C., Olive, A.: A complete set of guidelines for naming UML
conceptual schema elements (submitted for publication, 2011)
2. ArgoUML: ArgoUML, http://argouml.tigris.org
3. Chen, P.: English sentence structure and entity-relationship diagrams. Inf. Sci.
29(2-3), 127149 (1983)
4. Clayberg, E., Rubel, D.: Eclipse Plug-ins. Addison-Wesley, Reading (2008)
5. Deissenboeck, F., Pizka, M.: Concise and consistent naming. Softw. Qual. Con-
trol 14, 261282 (2006)
Eclipse Plugin for Validating Names in UML Schemas 327
6. Meyer, B.: Reusable Software: the Base object-oriented component libraries.

Prentice-Hall, Englewood Clis (1994)
7. Meziane, F., Athanasakis, N., Ananiadou, S.: Generating natural language speci-
cations from UML class diagrams. Requir. Eng. 13(1), 118 (2008)
8. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.: Object-oriented
modeling and design. Prentice-Hall, Englewood Clis (1991)
KEYRY: A Keyword-Based Search Engine over
Relational Databases Based on a Hidden Markov
Model
Sonia Bergamaschi1, Francesco Guerra1, Silvia Rota1 , and Yannis Velegrakis2

1
Università di Modena e Reggio Emilia, Italy
firstname.lastname@unimore.it
2
University of Trento, Italy
velgias@disi.unitn.eu
Abstract. We propose the demonstration of KEYRY, a tool for translating key-

word queries over structured data sources into queries in the native language of
the data source. KEYRY does not assume any prior knowledge of the source con-
tents. This allows it to be used in situations where traditional keyword search
techniques over structured data that require such a knowledge cannot be applied,
i.e., sources on the hidden web or those behind wrappers in integration systems.
In KEYRY the search process is modeled as a Hidden Markov Model and the List
Viterbi algorithm is applied to computing the top-k queries that better represent
the intended meaning of a user keyword query. We demonstrate the tools capa-
bilities, and we show how the tool is able to improve its behavior over time by
exploiting implicit user feedback provided through the selection among the top-k
solutions generated.
1 Introduction
The vast majority of existing keyword search techniques over structured data relies
heavily on an a-priori creation of an index on the contents of the database. At run time,
the index is used to locate in the data instance the appearance of the keywords in the
query provided by the user, and then associate them by finding possible join paths. This
approach makes the existing solutions inapplicable in all the situations where the con-
struction of such an index is not possible. Examples include databases on the hidden
web, or behind wrappers in integration systems. To cope with this issue we have devel-
oped KEYRY (from KEYword to queRY) [2], a system that converts keyword queries
into structured queries expressed in the native language of the source, i.e., SQL. The
system is based only on the semantics provided by the source itself, i.e., the schema,
auxiliary semantic information that is freely available, i.e., public ontologies and the-
sauri, a Hidden Markov Model (HMM) and an adapted notion of authority [4]. Using
this information, it builds a ranked list of possible interpretations of the keyword query
in terms of the underlying data source schema structures. In practice, the tool computes
only the top-k most prominent answers and not the whole answer space. One of the
features of KEYRY is that the order and the proximity of the keywords in the queries
play a central role in determining the k most prominent interpretations.

This work was partially supported by project Searching for a needle in mountains of data
http://www.dbgroup.unimo.it/keymantic.

KEYRY: A Keyword-Based Search Engine Over Relational Databases 329
KEYRY
Metadata Repository
Keyword Matcher
Keyword query Query history Source metadata

Parser
actors Avatar
movie?
actors TABLE actor Query Generator
movie TABLE movie
Avatar ATTRIBUTE movie.title
Query
HMM Matcher Path Selector
Builder
Wrapper
Metadata Query
Data Source
Sam Worthington, Extractor Manager SELECT * FROM movie
Zoe Saldana, JOIN actor ON ...
Sigourney Weaver, ...
Fig. 1. KEYRY functional architecture
Apart from the obvious use case of querying hidden web sources, KEYRY finds two
additional important applications. First, it allows keyword queries to be posed on infor-
mation integration systems that traditionally supports only structured queries. Second,
it can be used as a database exploration tool. In particular, the user may pose some
keyword query, and the system will generate its possible interpretations on the given
database. By browsing these interpretations, i.e., the generated SQL queries, the user
may obtain information on the way the data is stored in the database.
2 KEYRY at a Glance
Interpreting a keyword query boils down to the discovery of a bipartite assignment of
keywords to database structures. In some previous work we have studied the problem
from a combinatorial perspective [1] by employing the the Hungarian algorithm [3].
The tool we demonstrate here is instead based on a Hidden Markov Model. A detailed
description of the methodology can be found on our respective research paper [2]. A
graphic illustration of the different components of the tool can be found in Figure 1.
The first step when a keyword query has been issued is to associate each keyword
to some database structure. That structure may be a table name, a class, an attribute, or
an actual value. Each assignment of the keywords to database structures is a configura-
tion. The computation of the different configurations is done by the Keyword Matcher
component. A configuration describes possible meanings of the keywords in the query.
Given the lack of access to the instance data that we assume, finding the configurations
and subsequently the interpretations of a keyword query and selecting k most promi-
nent is a challenging task. Consider for instance the query movie Avatar actors over
a relational database collecting information about movies. The query may be intended
to find actors acting in the movie Avatar which means that the keywords movie and
actors could be respectively mapped into the tables movie and actor while Avatar
could be a value of the attribute title of the table movie. Different semantics are
also possible, e.g. Avatar could be an actor or a character, or something else.
The Keyword Matcher is the main component of the system. It implements a Hiden
Markov Model (HMM), where the observations represent the keywords and the states
the data source elements. The main advantages of this representation are that the HMM
330 S. Bergamaschi et al.
takes into account both the likelihood of single keyword-data source element associa-
tions, and the likelihood of the match between the whole keyword sequence in the query
to the data source structure. In this way, the assignment of a keyword to a data source
element may increase or decrease the likelihood that another keyword corresponds to a
data source element. In order to define a HMM, the values of a number of parameters
need to be specified. This is usually done using a training algorithm that, after many
iterations, converges to a good solution for the parameter values. Therefore, finding a
suitable dataset for training the HMM is a critical aspect for the effective use of HMM-
based approaches in real environments. In our scenario, the parameters are initialized
by exploiting the semantic information collected in the Metadata Repository (explained
below), providing that way keyword search capabilities even without any training data,
as explained in more details in our paper [2].
To obtain more accurate results, the HMM can be trained, i.e. the domain-
independent start-up parameters may be specialized for a specific data source thanks
to the users feedbacks. We train KEYRY with a semi-supervised approach that ex-
ploits both the feedbacks (when available) implicitly provided by the users on the sys-
tem results as supervised data and the query log as unsupervised data. By applying the
List Viterbi algorithm [5] to an HMM, the top-k state sequences which have the high-
est probability of generating the observation sequence are computed. If we consider
the user keyword query as an observation sequence, the algorithm retrieves the state
sequences (i.e., sequences of HMM states representing data source terms) that more
likely represent the intended meaning of the user query.
The HMM Matcher can present the computed top-k configurations to the user who,
in turn, selects the one that better represents the intended meaning of his/her query. This
allows the tool to reduce the number of queries to be generated (the ones related to the
configuration selected) and to train the HMM parameters.
Given a configuration, the different ways that the data structures on which the key-
words have been mapped can be connected, need to be found (e.g., by discovering join
paths). A configuration alongside the join paths describe some possible semantics of the
whole keyword query, and can be expressed into some query in the native query language
of the source. Such queries are referred to as interpretations. As an example, consider the
configuration mentioned above in which the keywords movie and actor are mapped into
the tables movie and actor, respectively, while the keyword Avatar to the title of
the table movie, may represent the actors that acted in the movie Avatar, or the movies
where acted actors of the movie Avatar, etc., depending on the path selected and the ta-
bles involved. The path computation is the main task of the Query Generator module.
Different strategies have been used in the literature to select the most prominent one,
or provide an internal ranking based on different criteria, such as the length of the join
paths. KEYRY uses two criteria: one is based on the shortest path and the other is using
the HITS algorithm [4] to classify the relevance of the data structures involved in a path.
The tasks of generating the various configurations and subsequently the different
interpretations are supported by a set of auxiliary components such as the Metadata
Repository that is responsible for the maintenance of the metadata of the data source
structures alongside previously executed user queries. KEYRY has also a set of Wrap-
pers for managing the heterogeneity of the data sources. Wrappers are in charge of
KEYRY: A Keyword-Based Search Engine Over Relational Databases 331
extracting metadata from data sources and formulating the queries generated by
KEYRY in the native source languages.
3 Demonstration Highlights
In this demonstration we intend to illustrate the use of KEYRY and communicate
to the audience a number of important messages. The demonstration will consist
of a number of different application scenarios such as querying the IMDB database
(www.imdb.com), the DBLP collection (dblp.uni-trier.de) and the Mondial database
(http://www.dbis.informatik.uni-goettingen.de/Mondial). We will first show the behav-
ior of KEYRY without any training. We will explain how the metadata of the sources
is incorporated into our tool and how heuristic rules allow the computation of the main
HMM parameters. We will run a number of keyword queries against the above sources
and explain the results. These queries are carefully selected to highlight the way the tool
deals with the different possible mappings of the keywords to the database structures.
The participants will also have the ability to run their own queries. Furthermore, we will
consider the parameters obtained by different amounts of training and we will compare
the results to understand how the amount of training affects the final result.
The important goals and messages we would like to communicate to the partici-
pants though the demo are the following. First, we will demonstrate that keyword-based
search is possible even without prior access to the data instance, and is preferable from
formulating complex queries that require skilled users who know structured query lan-
guages and how/where the data is represented in the data source. Second, we will show
that using a HMM is a successful approach in generating SQL queries that are good
approximations of the intended meaning of the keyword queries provided by the user.
Third, we will illustrate how previously posed queries are used to train the search en-
gine. In particular, we will show that the implicit feedback provided by the user se-
lecting an answer among the top-k returned by the system can be used for supervised
training. We will also demonstrate that, even in the absence of explicit users feedbacks,
the results computed by the tool may still be of high enough quality. We will finally
demonstrate that each user query may be associated to several possible interpretations
which can be used to reveal the underline database structure.
References
1. Bergamaschi, S., Domnori, E., Guerra, F., Lado, R.T., Velegrakis, Y.: Keyword search over
relational databases: a metadata approach. In: Sellis, T.K., Miller, R.J., Kementsietsidis, A.,
Velegrakis, Y. (eds.) SIGMOD Conference, pp. 565576. ACM, New York (2011)
2. Bergamaschi, S., Guerra, F., Rota, S., Velegrakis, Y.: A Hidden Markov Model Approach to
Keyword-based Search over Relational Databases. In: De Troyer, O., et al. (eds.) ER 2011
Workshops. LNCS, vol. 6999, pp. 328331. Springer, Heidelberg (2011)
3. Bourgeois, F., Lassalle, J.-C.: An extension of the Munkres algorithm for the assignment prob-
lem to rectangular matrices. Communications of ACM 14(12), 802804 (1971)
4. Li, L., Shang, Y., Shi, H., Zhang, W.: Performance evaluation of hits-based algorithms. In:
Hamza, M.H. (ed.) Communications, Internet, and Information Technology, pp. 171176.
IASTED/ACTA Press (2002)
5. Seshadri, N., Sundberg, C.-E.: List Viterbi decoding algorithms with applications. IEEE
Transactions on Communications 42(234), 313323 (1994)
VirtualEMF: A Model Virtualization Tool
Caue Clasen, Frederic Jouault, and Jordi Cabot

AtlanMod Team (INRIA, Ecole des Mines de Nantes, LINA) France
{caue.avila clasen,frederic.jouault,jordi.cabot}@inria.fr
Abstract. Specication of complex systems involves several heteroge-

neous and interrelated models. Model composition is a crucial (and
complex) modeling activity that allows combining dierent system per-
spectives into a single cross-domain view. Current composition solutions
fail to fully address the problem, presenting important limitations con-
cerning eciency, interoperability, and/or synchronization. To cope with
these issues, in this demo we introduce VirtualEMF: a model composi-
tion tool based on the concept of a virtual model, i.e., a model that do
not hold concrete data, but that redirects all its model manipulation
operations to the set of base models from which it was generated.
1 Introduction
Complex systems are usually described by means of a large number of interre-
lated models, each representing a given aspect of the system at a certain ab-
straction level. Often, the system view a user needs does not correspond to a
single model, but is a cross-domain view in which the necessary information is
scattered in several models. This integrated view is provided by the means of
model composition which is, in its simplest form, a modeling process that com-
bines two or more input (contributing) models into a single output (composed)
model. Model composition can be very challenging, due to the heterogeneous
nature of models and the complex relationships that can exist between them.
Composition has been extensively studied from various perspectives: its formal
semantics [2], composition languages [3], or also targeting dierent families of
models (UML [1], Statecharts [4], database models [5], . . . ). A commonality of
the vast majority of approaches is the fact that the composed model is generated
by copying/cloning information from its contributing models, what poses some
important limitations in terms of synchronization (updates in the composed
model are not propagated to the base ones, or the other way round), creation
time (copying many elements is time consuming, and composition must be re-
executed every time contributing models are modied), and memory usage (data
duplication can be a serious bottleneck when composing large models).
In this demo we present VirtualEMF: a model composition tool that allows
overcoming these limitations by applying the concept of virtual models, i.e.,
models that do not hold concrete data (as opposed to concrete models), but
that access and manipulate the original contributing data contained in other
models. The tool was built on top of Eclipse/EMF1 .
1
Eclipse Modeling Framework : http://www.eclipse.org/modeling/emf/

VirtualEMF: A Model Virtualization Tool 333
2 Virtual (Composed) Models

In short, a virtual model is a model whose (virtual) elements are proxies to
elements contained in other models. It provides to tools/users the illusion of
working with a regular model while, in fact, all access and manipulation requests
are transparently redirected to the set of models from which it was generated
(completely integrating contributing model elements into the composed model).
Model virtualization brings the following properties to model composition:
Interoperability: virtual models are handled as normal models and there-
fore they can be exchanged between standard modeling tools;
Synchronization: virtual and contributing models share the same element
instances. Thus, updates are automatically propagated in both directions;
Faster creation time: no information cloning is required, and as elements
are synchronized, generation is executed only once;
Less memory usage: as virtual models do not contain concrete data, no
extra memory is used.
Modeling Tool A Modeling Tool B

Composition
Metamodel
Virtual Composed Model VMab
read/write
Virtual Composition conforms to
inter-model
relationships
Contributing Correspondence Contributing composition
Model Ma Model Model Mb input/output
Fig. 1. Model virtualization artefacts
Fig. 1 introduces the main idea of model virtualization and the involved arte-
facts. Tools (editors, analysis and transformation tools,. . . ) see and use the vir-
tual model as a normal model. The virtual model delegates modeling operations
to its set of contributing models, locating referenced element(s), and translating
them into virtual elements to be used by the tool. Contributing elements are
composed at runtime, on an on-demand basis.
Contributing elements (and their properties) can be composed/translated into
virtual elements in dierent manners. Some may be ltered; others, simply re-
produced. Another possibility is when contributing elements are related to each
other and the virtual element is a combination of them (e.g. as in merge or
override relationships). A correspondence model links contributing elements and
identies which translation rule should be used for composing each element.
A virtual composed model conforms to the same composition metamodel a
concrete composed model would. This composition metamodel states the core
concepts that can populate the composed model.
334 C. Clasen, F. Jouault, and J. Cabot
3 The VirtualEMF Tool

The VirtualEMF tool is an Eclipse plug-in built on top of EMF in order to
support the transparent usage of virtual models by EMF-based tools. Here we
provide a brief explanation on how to create and use virtual models.
To create a virtual model, users must provide, besides the contributing models
to be virtualized (and their metamodels), three elements:
1. A composition metamodel that species the virtual model concepts. It
can be manually dened or be the result of a separate composition process;
2. A correspondence model (dened with the AMW2 tool) containing vir-
tual links that relate contributing elements and specify how they should be
composed (i.e. which translation rule is to be applied to them);
3. A .virtualmodel le specifying the physical location of the resources in-
volved in the virtual composition process (see Fig. 2).
VMab.virtualmodel
compositionMetamodel = {\MMab.ecore}
contributingMetamodels = {\MMa.ecore, \MMb.ecore}
contributingModels = {\Ma.xmi, \Mb.xmi}
correspondenceModel = {\MatoMb.amw}
Fig. 2. A sample virtual model le
The .virtualmodel le extension is automatically associated in Eclipse with

our specic virtual model handler. Therefore, the loading of a virtual model
involves only providing this le as input to any EMF-based tool (e.g., double-
clicking a .virtualmodel le will automatically trigger VirtualEMF, that loads
the virtual model in the standard model viewer). No extra information is re-
quired, as the actual data used by the virtual model is retrieved from contribut-
ing models and the correspondence model denes how to combine them.
VirtualEMF renes the full set of operations available for a regular model.
Thus, usage is also completely transparent (as in Fig. 3). When virtual ele-
ments are accessed, VirtualEMF checks which are the referenced contributing
element(s), if they are virtually linked, and then translates it(them) accordingly
(e.g. with f ilter, merge, override, inherit, or associate rules). If no virtual link
is specied for a contributing element, it is simply reproduced.
During the demo it will be presented how virtual models are created and used
with VirtualEMF, which are its main elements, and how users can dene them.
This will be shown through several step-by-step examples, with dierent types
of models and specifying dierent kinds of relationships between them. Finally
we will present a set of experiments used to prove that our approach fulls the
desired properties mentioned in section 2.
2
AtlanMod Model Weaver : http://www.eclipse.org/gmt/amw/
VirtualEMF: A Model Virtualization Tool 335
Fig. 3. A virtual model (composition of a UML class model with a relational database
model, where the latter derives from the former and virtual associations are used to
display traceability links between them) handled in two dierent EMF tools: Sample
Ecore Editor (left) and MoDisco Model Browser (right)
4 Conclusion
Model virtualization is a powerful mechanism that provides a more ecient
model composition process, while maintaining perfect synchronization between
composition resources. This demo presents VirtualEMF3 , our model virtualiza-
tion tool. The tool is extensible and supports dierent types of virtual links
and new semantics for them. As further work we intend to explore new types
of inter-model relationships, and to use state-of-the-art matching techniques to
automatically identify relationships and generate the correspondence model. Sev-
eral experiments have been conducted to prove the scalability of our solution.
References
1. Anwar, A., Ebersold, S., Coulette, B., Nassar, M., Kriouile, A.: A Rule-Driven
Approach for composing Viewpoint-oriented Models. Journal of Object Technol-
ogy 9(2), 89114 (2010)
2. Herrmann, C., Krahn, H., Rumpe, B., Schindler, M., V olkel, S.: An Algebraic View
on the Semantics of Model Composition. In: Akehurst, D.H., Vogel, R., Paige, R.F.
(eds.) ECMDA-FA. LNCS, vol. 4530, pp. 99113. Springer, Heidelberg (2007)
3. Kolovos, D., Paige, R., Polack, F.: Merging Models with the Epsilon Merging Lan-
guage (EML). In: Wang, J., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006.
4. Nejati, S., Sabetzadeh, M., Chechik, M., Easterbrook, S., Zave, P.: Matching and
Merging of Statecharts Specications. In: ICSE 2007, pp. 5464. IEEE Computer
5. Rahm, E., Bernstein, P.A.: A survey of approaches to automatic schema matching.
The VLDB Journal 10, 334350 (2001)
3
VirtualEMF website: www.emn.fr/z-info/atlanmod/index.php/VirtualEMF
Towards a Model-Driven Framework for Web
Usage Warehouse Development
Paul Hern
andez, Octavio Glorio, Irene Garrig
os, and Jose-Norberto Maz
on
Lucentia DLSI University of Alicante, Spain

{phernandez,oglorio,igarrigos,jnmazon}@dlsi.ua.es
Abstract. Analyzing the usage of a website is a key issue for a company

to improve decision making regarding the business processes related to
the website, or the evolution of the own website. To study the Web usage
we need advanced data analysis tools which require the development of
a data warehouse to structure data in a multidimensional model. In this
paper, we describe two possible scenarios that could arise and we claim
that a model-driven approach would be useful for obtaining a multidi-
mensional model in a comprehensive and structured way. This model
will drive the development of a data warehouse in order to enhance the
analysis of Web usage data: the Web usage warehouse.
Web usage analysis is the process of nding out what users are looking for on
the Internet. This information is extremely valuable for understanding how a
user walks through a website in, thus supporting decision making process.
Commercial tools for Web usage data analysis have some drawbacks: (i) sig-
nicant limitations performing advanced analytical tasks, (ii) uselessness when
trying to understand navigational patterns of users, (iii) inability to integrate
and correlate information from dierent sources, or (iv) unawareness of the con-
ceptual schema of the application. For example, one of the most known analy-
sis tools is Google Analytics (http://www.google.com/analytics) which has
emerged as a major solution for Web trac analysis, but it has a limited drill-
down capability and there is no way of storing data eciently. Worse still, the
user does not own the data, Google does.
There are several approaches [3,4] that dene a multidimensional schema in or-
der to analyze the Web usage by using the Web log data. With these approaches,
once the data is structured, it is possible to use OLAP or data mining techniques
to analyze the content of the Web logs, tackling the aforementioned problems.
However, there is a lack of agreement about a methodological approach in order
to detect which would be the most appropriate facts and dimensions: some of
them let the analysts decide the required multidimensional elements, while oth-
ers decide these elements by taking into consideration a specic Web log format.
Therefore, the main problem is that the multidimensional elements are infor-
mally chosen according to a specic format, so the resulting multidimensional

This work has been partially supported by the following projects: SERENIDAD
(PEII-11-0327-7035) from Castilla-La Mancha Ministry, and MESOLAP (TIN2010-
14860) from the Spanish Ministry of Education and Science.

Towards a Model-Driven Framework for Web Usage Warehouse Development 337
model may be incomplete. Regarding current Web engineering approaches, to

the best of our knowledge, none of them [2,1] provide mechanisms for dening
a multidimensional model at the same time that the rest of the website in or-
der to represent the Web usage. To overcome these drawbacks, a model-driven
framework for developing a Web usage warehouse is proposed considering two
dierent scenarios (see Fig. 1).
Fig. 1. Model-driven framework for Web usage warehouse development
In our rst scenario (Web usage warehouse within model-driven Web engi-
neering), several conceptual models have to be dened when designing a website
(navigation model, user model, data model, etc.). However, none of these models
are intended to represent and understand the Web usage. Therefore, multidimen-
sional concepts (facts, dimensions, hierarchies, etc.) should be identied within
the conceptual models of a given application in order to build a Web usage
warehouse in an integrated and structured manner. Due to the fact that concep-
tual models of websites may not be available or out-of-date, within our second
scenario (Web usage warehouse from Web log data), a Web usage warehouse is
developed without requiring these conceptual models, but using Web log les.
To this aim, a Web log metamodel is dened which contains the elements and
the semantics that allow building a conceptual model from Web log les, which
represents, in a static way, the interaction between raw data elements (i.e. the
client remote address) and usage concepts (i.e. session, user).
References
1. Ceri, S., Fraternali, P., Bongio, A.: Web modeling language (WebML): a modeling
language for designing web sites. Computer Networks 33(1-6), 137157 (2000)
2. Garrigos, I.: A-OOH: Extending web application design with dynamic personaliza-
tion (2008)
3. Joshi, K.P., Joshi, A., Yesha, Y.: On using a warehouse to analyze web logs. Dis-
tributed and Parallel Databases 13(2), 161180 (2003)
4. Lopes, C.T., David, G.: Higher education web information system usage analysis
with a data webhouse. In: Gavrilova, M.L., Gervasi, O., Kumar, V., Tan, C.J.K.,
Taniar, D., Lagan a, A., Mun, Y., Choo, H. (eds.) ICCSA 2006. LNCS, vol. 3983,
CRESCO: Construction of Evidence Repositories
for Managing Standards Compliance
Rajwinder Kaur Panesar-Walawege1,2, Torbjrn Skyberg Knutsen1,2 ,

Mehrdad Sabetzadeh1 , and Lionel Briand1,2
1
Simula Research Laboratory, Lysaker, Norway
2
University of Oslo, Oslo, Norway
{rpanesar,mehrdad,briand}@simula.no, torbjsk@ifi.uio.no
Abstract. We describe CRESCO, a tool for Construction of Evidence

REpositories for Managing Standards COmpliance. CRESCO draws on
Model Driven Engineering (MDE) technologies to generate a database
repository schema from the evidence requirements of a given standard,
expressed as a UML class diagram. CRESCO in addition generates a web-
based user interface for building and manipulating evidence repositories
based on the schema. CRESCO is targeted primarily at addressing the
tool infrastructure needs for supporting the collection and management
of safety evidence data. A systematic treatment of evidence information
is a key prerequisite for demonstration of compliance to safety standards,
such as IEC 61508, during the safety certication process.
Keywords: Safety Certication, Conceptual Modeling, MDE, IEC 61508.
1 Introduction
Safety critical systems are typically subject to safety certication based on recog-
nized safety standards as a way to ensure that these systems do not pose undue
risks to people, property, or the environment. A key prerequisite for demonstrat-
ing compliance to safety standards is collecting structured evidence in support
of safety claims. Standards are often written in natural language and are open to
subjective interpretation. This makes it important to develop a precise and ex-
plicit interpretation of the evidence requirements of a given standard. In previous
work [4,3], we have proposed conceptual modeling for formalizing the evidence
requirements of safety standards. This approach on the one hand helps develop
a shared understanding of the standards and on the other hand, provides a basis
for the automation of various evidence collection and management tasks.
In this paper, we describe CRESCO, a exible tool infrastructure for creat-
ing repositories to store, query, and manipulate standards compliance evidence.
Additionally, CRESCO generates a web-based user interface for interacting with
these repositories. Our work was prompted by an observed need during our col-
laboration with companies requiring IEC 61508 compliance. In particular, we
observed that little infrastructure support has been developed to date to sup-
port management of safety evidence based on a specic standard. This issue has

CRESCO: Construction of Evidence Repositories 339
also been noted in the literature as an important gap in the safety certication
process [2,5]. While CRESCO is general and can be used in conjunction with
dierent standards, we ground our discussion in this paper on IEC 61508, which
is a key standard for safety certication of programmable electronic systems.
In the rest of this paper, we will describe the key components of CRESCO.
For the actual demonstration, we will follow, and expand where necessary, our
presentation in this paper. Specically, the demo will begin with motivational
material similar to this papers introduction and augmented with snippets of
the conceptual model in [4]. We then go on to describe the overall architecture
of the tool, as shown in Figure 1. In the next step, we will use a combination of
pre-recorded and live demonstrations to illustrate the main functions of the tool,
discussed in Sections 2. Finally, as we outline in Section 3, our demonstration
will provide information about the tools implementation based on our existing
documentation [1], and give details about availability.
2 Tool Overview
Users can interact with CRESCO in two roles: the administrator and general
user. The administrator is responsible for importing the conceptual model into
CRESCO, running the transformations and setting up and starting the web
server. Once the server is started, the general users typically experts from the
supplier company or certication body can add, view and manipulate the data
in the database. In this section we provide an overview of the main components
of CRESCO as shown in Figure 1(a).
Administrator Users
(a) (b)
CRESCO User Interaction
Transformation User Interface
Browser
Model-to-Model View Layer
UML Class Transformation 6: dynamic 1: user request
Diagram HTML page
Consistency Check
Web Server
Logic Layer
5: dynamic
UML Metamodel ORM Model HTML page
2: user request
Object-Relational Mapping
Model-to-Text Persistence Server-side Script
Transformation Layer
3: persistence
ORM Metamodel 4: result set layer command
Relational Database Database
Fig. 1. Components of CRESCO and How the User Interacts With It
2.1 Generation of Database Schema and UI
The generation of the database and the user interface code involves two steps: a
model-to-model (M2M) transformation and a model-to-text (M2T) transforma-
tion. The M2M transformation takes as input a conceptual model of a standard
340 R.K. Panesar-Walawege et al.
in the form of a UML class diagram [6]. This model can be created in any UML
tool and then imported into CRESCO. An in-depth description of the concep-
tual model is beyond the scope of this demonstration paper further details are
available in [4]. The M2M transformation makes use of the UML meta-model [6]
and a meta-model for an object-relational mapping (ORM) that we have created
see [1]. This ORM meta-model enables the storage (in a relational database) of
objects that have been created based on a UML class diagram. The ORM meta-
model includes a database schema (with tables, columns, foreign keys, etc) and
object-oriented concepts, mainly generalization. The M2M transformation iter-
ates over the conceptual model and transforms it into a model that corresponds
to the ORM meta-model.
The user interface is generated
from the ORM model created during
the M2M transformation. The M2T
transformation iterates over the ele-
ments of the ORM model and gener-
ates the database implementation as
well as all the code for accessing and
updating the database via a web in-
terface. The generated code is a com-
bination of server-side Java code and
Fig. 2. CRESCO User Interface
HTML (see Section 3). Figure 1(b)
shows how the user interaction is pro-
cessed via the generated code. Figure 2 shows the user interface generated. The
left hand pane lists all the tables that have been generated and the right hand
pane is used to manipulate the rows in a selected table. The New button shown
is used to add a new row into the selected table. Figure 2 shows the table for the
concept of Agent, who is an entity that carries out an activity required during
system development. An Activity is a unit of behavior with specic input and
output Artifacts. Each activity utilizes certain Techniques to arrive at its de-
sired output and requires certain kind of Competence by the agents performing it.
The agent itself can be either an individual or an organization and is identied
by the type of role it plays. In CRESCO, one can: (1) create instances of concepts
such as Agent, Activity, Artifact, (2) ll out their attributes, (3) and establish
the links between the concept instances. For illustration, we show in Figure 2,
the addition of an agent record into the Agent table.
2.2 Consistency Checking

The consistency check is a means of verifying that the state of the database is
in accordance with the multiplicity constraints dened in the conceptual model.
The consistency check is derived from the multiplicities of UML associations. We
have chosen not to preserve the multiplicities in the database schema, where all
associations are represented as many-to-many. This exibility is required so that
we can tolerate inconsistencies during the construction of the database. Trying
to maintain consistency at all time would be intrusive, as this would enforce
CRESCO: Construction of Evidence Repositories 341
an unnecessary order on how the evidence items have to be entered. While our
choice allows more freedom for the user when adding entries in the database,
it also calls for the implementation of a consistency checker, to verify that the
data in the database is in accordance with the constraints dened in the UML
class diagram. For example, an Activity must have at least one Agent who is
responsible for carrying out this activity (dened in the Agentcarriesoutactivity
table shown in Figure 2). Such constraints are checked by CRESCOs consistency
checker and any violations are highlighted to the user for further investigation.
3 Implementation and Availability

CRESCO is implemented in Eclipse for Java Enterprise Edition. We use two plu-
gins, one for Kermeta that is used for the M2M transformations and the other is
MOFScript for the M2T transformations. The M2M and M2T code are approx.
800 and 1500 lines, respectively. The total number of lines of code generated de-
pends on the size of the input conceptual model. For the IEC 61508 model, the
resulting code was in excess of 20,000 lines. Hence, signicant manual eort can
be saved by applying CRESCO. We use Apache Derby as the underlying database
which is accessed by the Java code via Hibernate. The user interface for populat-
ing the database is via the web and we use Apache Tomcat as the web server and
JavaServer Pages, Apache Struts and JavaScript to present and manipulate the
objects residing in the database as well as to provide the navigation of the user in-
terface. For our demonstration, we will present the import process of the concep-
tual model, the execution of the the two transformations and the user-interaction
with the web-based user-interface. Due to space restrictions, we do not describe
the technologies underlying CRESCO. See [1] for details and references. CRESCO
is freely available at http://home.simula.no/~rpanesar/cresco/.

We presented CRESCO a tool for the generation and manipulation of
evidence repositories for demonstrating standards compliance during certica-
tion. CRESCO provides a centralized repository for keeping diverse data which,
in the current state of practice, is often not collected systematically and needs to
be extracted and amalgamated during certication. Our goal was to show feasi-
bility via a coherent combination of existing open-source technologies. While our
current tool provides a exible infrastructure for managing compliance evidence,
further work is required to turn it into a tool that can be deployed in a produc-
tion environment. In particular, we are considering adding more sophisticated
query facilities such that complex queries can be posed as well as professional
reporting facilities in order to extract data from the database to create reports
that can be directly given to the certication body.
342 R.K. Panesar-Walawege et al.
References
1. Knutsen, T.: Construction of information repositories for managing standards com-
pliance evidence (2011) Master Thesis, University of Oslo,
http://vefur.simula.no/~ rpanesar/cresco/knutsen.pdf
2. Lewis, R.: Safety case development as an information modelling problem. In: Safety-
Critical Systems: Problems, Process and Practice, pp. 183193. Springer, Heidelberg
(2009)
3. Panesar-Walawege, R.K., Sabetzadeh, M., Briand, L.: Using UML proles for sector-
specic tailoring of safety evidence information. In: De Troyer, O., et al. (eds.) ER
2011 Workshops. LNCS, vol. 6999, Springer, Heidelberg (2011)
4. Panesar-Walawege, R.K., Sabetzadeh, M., Briand, L., Coq, T.: Characterizing the
chain of evidence for software safety cases: A conceptual model based on the iec
61508 standard. In: ICST 2010, pp. 335344 (2010)
5. Redmill, F.: Installing IEC 61508 and supporting its users nine necessities. In: 5th
Australian Workshop on Safety Critical Systems and Software (2000)
6. UML 2.0 Superstructure Specication (August 2005)
Modeling Approach for Business Networks with
an Integration and Business Perspective
Daniel Ritter and Ankur Bhatt
SAP AG, Technology Development Process and Network Integration,

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
{daniel.ritter,ankur.bhatt}@sap.com
http://www.sap.com
Abstract. Business Network Management (BNM) allows enterprises to

manage their application integration and partner networks by making
technical integration, business and social aspects visible within a net-
work view and set them into context to each other. This allows various
personas, like business user, integration expert and IT support to ana-
lyze, operate and develop business processes by collaborating on these
contexts. Dening a model sucient to represent the BNM domain with
dierent layers of abstraction, from business to technical views and per-
spectives of network-structured data requires a standard, human- and
machine readable notation. Modeling of real-world technical and busi-
ness artifacts is widely addressed by UML [5], SCA [4] which cover parts
of these requirements for BNM. However, none of them accounts for the
combined business and technical nature of most enterprises, nor of the
semantic network and data linking aspects. In this paper, we present de-
sign decisions for a model based on BPMN 2.0, that is sucient for BNM
and represents inter-related business and technical perspectives within
the enterprise network.
Keywords: Business Network, Modeling Approach, BPMN 2.0.
1 Introduction
Nowadays, enterprises participate in value chains of suppliers and customers
while competing in business networks rather than being isolated. To remain
competetive, e.g. by quickly implementing new process variants or proactively
identify aws within existing processes, enterprises need visibility into their busi-
ness network, the relevant applications and the processes. Business Network
Management is the capability of managing intra and inter enterprise networks.
2 Modeling a Business Network

A model for business network needs to represent the existing enterprise informa-
tion models like process, integration, applications, and to interrelate them into
a network of linked data. The model shall serve as a visual representation and

344 D. Ritter and A. Bhatt
exchange format, thus requiring a human and computer readable notation. It

shall allow aggregation of and drill-into network entities with extension points
for information models. The notation has to be a well-established standard cov-
ering requirements for representing the business network. For technical aspects
SCA [4] and UML [5] provide a solid foundation and are both human readable.
SCA denes Components and Wires to represent a network and out-performes
UML by explicitely dening Services and References with various bindings. This
is similar to Pools, i.e. Participants, and Flows with BPMN 2.0 ConversationDi-
agrams and service extention point package (see M. Owen et al [1]). For group-
ing of ows, BPMN denes Conversations, SubConversations, resp., while SCA
allows for component nesting with Composites. However, the requirement to vi-
sualize and link to real-world entities like applications and semantically relate
the context end-to-end, e.g. from process to system is possible in BPMN. The
perspectives are represented with specializations of BPMN Participant and Mes-
sageFlow while linked via ParticipantAssociation and a new extension FlowAs-
sociation. Thus using BPMN 2.0 as foundation allows all personas to work with
the same model, and serve as a standardized exchange format. BPMN is a stan-
dard for dening, visualising and exchanging business procedures within and
across enterprises and is widely used within disciplines like BPM. Business net-
works pose additional challenges on the model, like structural support for large
networks, which need to be addressed with extentions to BPMN 2.0.
3 Conclusions
In this paper, we presented the design desicions to use BPMN for a network
domain, BNM. We discuss the requirements for a model in this domain and
show that a network model can be based on BPMN 2.0 while extending it for
network specic entities and attributes. The specic extensions to BPMN 2.0
are discussed in detail in [2].
Acknowledgments. We thank Ivana Trickovic for support on BPMN 2.0 and

Gunther Rothermel for guidance and sponsorship.
References
1. Owen, M., Stuecka, R.: BPMN und die Modellierung von Gesch aftsprozessen.
Whitepaper, Telelogic (2006)
2. Ritter, D., Ackermann, J., Bhatt, A., Homann, F. O.: Building a Business Graph
System and Network Integration Model based on BPMN. In: 3rd International
Workshop on BPMN, Luzern (accepted, 2011)
3. Specication of Business Process Modeling Notation version 2.0 (BPMN 2.0),
http://www.omg.org/spec/BPMN/2.0/PDF
4. Service Component Architecture (SCA), http://www.osoa.org/display/Main/
Service+Component+Architecture+Home
5. Unied Modeling Language (UML), http://www.uml.org/
Mosto: Generating SPARQL Executable
Mappings between Ontologies,
Carlos R. Rivero, Inma Hern

andez, David Ruiz, and Rafael Corchuelo
University of Sevilla, Spain

{carlosrivero,inmahernandez,druiz,corchu}@us.es
Abstract. Data translation is an integration task that aims at pop-

ulating a target model with data of a source model, which is usually
performed by means of mappings. To reduce costs, there are some tech-
niques to automatically generate executable mappings in a given query
language, which are executed using a query engine to perform the data
translation task. Unfortunately, current approaches to automatically gen-
erate executable mappings are based on nested relational models, which
cannot be straightforwardly applied to semantic-web ontologies due to
some dierences between both models. In this paper, we present Mosto,
a tool to perform the data translation using automatically generated
SPARQL executable mappings. In this demo, ER attendees will have an
opportunity to test this automatic generation when performing the data
translation task between two dierent versions of the DBpedia ontology.
Keywords: Information Integration, Data Translation, Semantic-web

Ontologies, SPARQL executable mappings.
1 Introduction
Data translation is an integration task that aims at populating a target model

with data of a source model, which is becoming a major research task in the
semantic-web context [5,12]. Mediators are pieces of software that help perform
this task, which rely on mappings that relate source and target models [4].
To reduce integration costs, some techniques automatically generate a set of
uninterpreted mappings, a.k.a. correspondences, which must be interpreted to
perform the data translation task [4]. They are hints that usually relate a source
entity with a target entity, although they may be more complex [4]. The main
issue regarding correspondences is that there is not a unique interpretation of
them, i.e., dierent approaches interpret correspondences in dierent ways [2].

Supported by the European Commission (FEDER), the Spanish and the An-
dalusian R&D&I programmes (grants TIN2007-64119, P07-TIC-2602, P08-TIC-
4100, TIN2008-04718-E, TIN2010-21744, TIN2010-09809-E, TIN2010-10811-E, and
TIN2010-09988-E).

An implementation and examples regarding this paper are available at:
http://tdg-seville.info/carlosrivero/Mosto

346 C.R. Rivero et al.
Executable mappings encode an interpretation of correspondences in a given

query language [6,11]. These mappings are executed by means of a query engine
to perform the data translation task. The main benet of using these mappings
is that, instead of relying on ad-hoc programs that are dicult to create and
maintain, a query engine performs the data translation task [6].
In the bibliography, Ressler et al. [10] devised a visual tool to specify hand-
crafted SPARQL executable mappings. However, it is well-known that hand-
crafted executable mappings increase integration costs [8]. Furthermore, there
are a number of visual tools to specify correspondences between source and tar-
get models, such as Clio, Muse, or Clip [1,6,9]. After specifying the correspon-
dences, these tools automatically generate a set of executable mappings based
on them. Unfortunately, these tools focus on nested relational models, and they
are not straightforwardly applicable to semantic-web ontologies due to a number
of inherent dierences between them [7,11].
In this paper, we present Mosto, a tool to perform the data translation task
between OWL ontologies using automatically generated SPARQL executable
mappings. To the best of our knowledge, this is the rst tool to automatically
generate executable mappings in the semantic-web context. To describe it, we use
a demo scenario integrating two dierent versions of the DBpedia ontology [3].
This paper is organised as follows: Section 2 describes the system, and Sec-
tion 3 deals with the demo that ER attendees will have the opportunity to test.
2 Mosto
In this section, we present Mosto, our tool to perform the data translation task
between two OWL ontologies by means of SPARQL executable mappings. Per-
forming this task in our tool comprises four steps, namely: 1) Selecting source
and target ontologies; 2) Specifying restrictions and correspondences; 3) Gen-
erating SPARQL executable mappings; and 4) Executing SPARQL executable
mappings. These steps are described in the rest of the section.
The rst step deals with the selection of source and target ontologies to be
integrated. In our demo scenario (cf. Figure 1), we integrate DBpedia ontol-
ogy v3.2 with DBpedia ontology v3.6, which are shown in a tree-based notation
in which classes, data properties and object properties are represented by cir-
cles, squares and pentagons, respectively. Note that subclasses are represented
between brackets, e.g., dbp:Artist is subclass of dbp:Person is represented as
dbp:Artist [dbp:Person] . In addition, the domain of a property is represented
by nesting the property in a class, and the range is represented between < and
>, e.g., the domain of dbp:director is dbp:Film and its range is dbp:Person.
After selecting the ontologies, Mosto extracts a number of implicit restrictions,
which are restrictions that are due to the modelling language of source and target
ontologies, in our case, the OWL ontology language.
In the second step, the user species explicit restrictions in the source and
target ontologies, and correspondences between them. Explicit restrictions are
necessary to adapt existing ontologies to the requirements of a specic scenario,
Mosto: Generating SPARQL Executable Mappings between Ontologies 347
Source (version 3.2) Target (version 3.6)

V1
dbp:Person dbp:Person
V2
dbp:Artist [dbp:Person] dbp:Artist [dbp:Person]
dbp:academyAward <dbp:Award>
V3
dbp:Actor [dbp:Artist] dbp:Actor [dbp:Artist]
dbp:academyawards <xsd:anyURI> V4 R1
dbp:Award
V5
dbp:Work dbp:Work
V6 V 8
dbp:starring <dbp:Person>
dbp:Film [dbp:Work]
dbp:imdbId <xsd:string> V7 dbp:Film [dbp:Work]
dbp:starring <dbp:Person> dbp:imdbId <xsd:string>
V9
dbp:director <dbp:Person> dbp:director <dbp:Person>
Resulting SPARQL executable mappings
M1 // Correspondence V 1 M 2 // Correspondence V4 M3 // Correspondence V 8
CONSTRUCT { CONSTRUCT { CONSTRUCT {
?p rdf:type dbp :Person . ?w rdf:type dbp :Award . ?w rdf :type dbp :Work .
} WHERE { ?a rdf:type dbp :Person . ?p rdf :type dbp :Person .
?p rdf:type dbp :Person . ?a rdf:type dbp :Artist . ?w dbp :starring ?p .
} ?a rdf:type dbp :Actor . } WHERE {
?w dbp:academyAward ?w . ?w dbp :starring ?p.
} WHERE { ?w rdf :type dbp :Work .
?a dbp:academyawards ?w . ?w rdf :type dbp :Film .
?a rdf:type dbp :Person . ?p rdf :type dbp :Person .
?a rdf:type dbp :Artist . }
?a rdf:type dbp :Actor .
}
Fig. 1. Evolution in DBpedia (demo scenario)
e.g., R1 is an explicit restriction by which dbp:academyAward has a minimal

cardinality of one with respect to dbp:Award. Correspondences are represented
as arrows in Figure 1, e.g., V8 is a class correspondence that relates dbp:starring
object property in both source and target ontology versions. Note that Mosto al-
lows to load previously dened restrictions and/or correspondences, or to visually
generate new restrictions and/or correspondences according to user preferences.
In the third step, Mosto generates a set of SPARQL executable mappings
using (implicit and explicit) restrictions and correspondences. The technique to
automatically generate these mappings is described in [11], which is based on
clustering those source restrictions, target restrictions and other correspondences
that we must take into account to produce coherent target data when performing
the data translation task. Note that, if we use each correspondence in isolation
to translate data, we may produce incoherent target data, e.g., correspondence
V8 cannot be used in isolation since we do not know how to translate the do-
main and range of dbp:starring. Therefore, our technique clusters V1 , V5 and V8 ,
which translate the domain and range of dbp:starring, respectively. In addition,
every cluster is transformed into a SPARQL executable mapping that encode an
interpretation of correspondences. Figure 1 shows three examples of SPARQL
executable mappings generated with our tool: M1 , M2 and M3 are the resulting
executable mappings of correspondences V1 , V4 and V8 , respectively.
348 C.R. Rivero et al.
Finally, in the fourth step, Mosto is able to perform the data translation task
by executing the previously generated SPARQL executable mappings over the
source ontology to produce instances of the target ontology. Note that, thanks
to our SPARQL executable mappings, we are able to automatically translate the
data from a previous version of an ontology to a new version.
3 The Demo
In this demo, ER attendees will have an opportunity to use Mosto to test the
automatic generation of SPARQL executable mappings using our demo scenario,
which integrates dierent versions of the DBpedia ontology. We will show how
the addition or removal of correspondences and restrictions aect the resulting
executable mappings. Furthermore, we will perform the data translation task
using these mappings, and check whether resulting target data are as expected.
Expected evidences in our demo scenario are the following, namely: 1) the time
to generate executable mappings is less than one second; 2) Mosto facilitates the
specication of restrictions and correspondences in complex scenarios; and 3)
the resulting target data are coherent with expected results.
References
1. Alexe, B., Chiticariu, L., Miller, R.J., Tan, W.C.: Muse: Mapping understanding
and design by example. In: ICDE, pp. 1019 (2008)
2. Bernstein, P.A., Melnik, S.: Model management 2.0: manipulating richer mappings.
In: SIGMOD, pp. 112 (2007)
3. Bizer, C., Lehmann, J., Kobilarov, G., Auer, S., Becker, C., Cyganiak, R., Hellmann,
S.: DBpedia - a crystallization point for the web of data. J. Web Sem. (2009)
4. Euzenat, J., Shvaiko, P.: Ontology matching. Springer, Heidelberg (2007)
5. Fagin, R., Kolaitis, P.G., Miller, R.J., Popa, L.: Data exchange: semantics and
query answering. Theor. Comput. Sci. 336(1), 89124 (2005)
6. Haas, L.M., Hern andez, M.A., Ho, H., Popa, L., Roth, M.: Clio grows up: from
research prototype to industrial tool. In: SIGMOD, pp. 805810 (2005)
7. Motik, B., Horrocks, I., Sattler, U.: Bridging the gap between OWL and relational
databases. J. Web Sem. 7(2), 7489 (2009)
8. Petropoulos, M., Deutsch, A., Papakonstantinou, Y., Katsis, Y.: Exporting and in-
teractively querying web service-accessed sources: The CLIDE system. ACM Trans.
Database Syst. 32(4) (2007)
9. Rao, A., Braga, D., Ceri, S., Papotti, P., Hern andez, M.A.: Clip: a tool for map-
ping hierarchical schemas. In: SIGMOD, pp. 12711274 (2008)
10. Ressler, J., Dean, M., Benson, E., Dorner, E., Morris, C.: Application of ontology
translation. In: Aberer, K., Choi, K.-S., Noy, N., Allemang, D., Lee, K.-I., Nixon,
L.J.B., Golbeck, J., Mika, P., Maynard, D., Mizoguchi, R., Schreiber, G., Cudre-
Mauroux, P. (eds.) ASWC 2007 and ISWC 2007. LNCS, vol. 4825, pp. 830842.
11. Rivero, C.R., Hern andez, I., Ruiz, D., Corchuelo, R.: Generating SPARQL exe-
cutable mappings to integrate ontologies. In: Jeusfeld, M., et al. (eds.) ER 2011.
12. Shadbolt, N., Berners-Lee, T., Hall, W.: The semantic web revisited. IEEE Int.
Sys. 21(3), 96101 (2006)
The CSTL Processor: A Tool for Automated Conceptual
Schema Testing
Albert Tort, Antoni Oliv, and Maria-Ribera Sancho
Universitat Politcnica de Catalunya Barcelona Tech

{atort,olive,ribera}@essi.upc.edu
Abstract. In this demonstration paper, we present the CSTL Processor, a tool to

support the validation of two fundamental quality properties of conceptual
schemas (correctness and completeness) by testing. The CSTL Processor
supports the management, execution and automatic computation of the verdicts
of test cases which formalize stakeholders needs and expectations.
Keywords: Conceptual modeling, Validation, Quality, Automated testing,

UML/OCL.
1 Introduction
Two fundamental quality properties of conceptual schemas are correctness (i.e. all the
defined knowledge is true for the domain) and completeness (i.e. all the relevant
knowledge is defined in the conceptual schema) [1]. The validation of these properties
is still an open challenge in conceptual modeling [2].
In [3], we proposed a novel environment for testing conceptual schemas. The main
purpose of conceptual schema testing is the validation of conceptual schemas according
to stakeholders needs and expectations. Conceptual schemas can be tested if (1) the
conceptual schema is specified in an executable form, and (2) a representative set of
concrete scenarios are formalized as test cases.
In this paper, we present the CSTL Processor [4], a tool that supports the execution
of test sets written in the Conceptual Schema Testing Language (CSTL) [3]. The
CSTL Processor makes the proposed testing environment feasible in practice.
This tool may be used in different application contexts in which UML/OCL
conceptual schemas may be tested. The CSTL Processor supports test-last validation
(in which correctness and completeness are checked by testing after the schema
definition) or test-first development of conceptual schemas (in which the elicitation
and definition is driven by a set of test cases). Our testing environment proposes the
use of automated tests [5], which include assertions about the expected results that
may be automatically checked. This is an essential feature in order to allow regression
testing [5].
In the next section, we present the CSTL Processor and its components. In
Section 3, we reference example applications which will be illustrated in the
demonstration and complementary case studies, tutorials and documentation.
350 A. Tort, A. Oliv, and M.-R. Sancho
Fig. 1. The CSTL Processor testing environment
2 The CSTL Processor

The CSTL Processor is a research prototype which works as a standalone application
and supports the specification, management and execution of automated tests of
executable conceptual schemas.
In the implemented release used in the demonstration presented in this paper,
schemas are defined in UML/OCL. An extended USE [6] syntax is used to specify the
conceptual schemas under test in an executable form. Automated conceptual test
cases are written in the Conceptual Schema Testing Language (CSTL). Test cases
consist of sequences of expected Information Base (IB) states (which may change
through the occurrence of events) and assertions about them.
The main features of the CSTL Processor are: (1) The definition of executable
conceptual schemas under test; (2) the definition and management of CSTL test
programs; (3) the execution of the test set and the automated computation of its
verdicts, including reports of error and failing information; and (4) the automatic
analysis of testing coverage according to a basic set of testing adequacy criteria.
Figure 1 shows the main components of the CSTL Processor environment. The
execution of conceptual schemas is done by the Information Processor, while the
execution of test programs is done by the Test Processor. Moreover, automatic
coverage analysis for a basic set of test adequacy criteria is provided by the Coverage
Processor. In the following, we briefly present each main tool component.
2.1 The Information Processor
The information processor is able to setup IB states by creating, deleting and

changing entities, attributes and associations. It also evaluates OCL expressions of
test assertions. We implemented the information processor extending the USE [6]
core in order to be able to deal with several new language features such as derived
attributes, default values, multiplicities in attributes, domain events, temporal
constraints, initial integrity constraints and generalization sets.
The CSTL Processor: A Tool for Automated Conceptual Schema Testing 351
Fig. 2. Test execution screenshot
2.2 The Test Processor
The test processor implements the execution of the test cases and consists of the
presentation manager, the test manager and the test interpreter.
The test manager stores the CSTL programs in order to make it possible to execute
the test set at any time. When the conceptual modeler requests the execution of the
test programs, the test manager requests the test interpreter to execute them. The test
manager also keeps track of the test results and maintains test statistics.
The test interpreter reads and executes CSTL programs. For each test case, the
interpreter sets up the common fixture (if any), executes the statements of each test
case and computes the verdicts. The interpreter invokes the services of the
information processor to build the IB states according to each test case and check the
specified assertions.
The presentation manager provides means for writing CSTL test programs and for
displaying the results of their execution. Built-in editors are provided for the
definition of the conceptual schema, its methods and the test programs. Moreover,
after each execution of the test set, test programs verdicts are displayed. Figure 2
shows a screenshot of the verdicts presentation screen. The test processor indicates
the number of the lines where test cases have failed and gives an explanation of the
failure in natural language.
2.3 The Coverage Processor
The Coverage Processor provides automatic coverage analysis according to a basic

set of test adequacy criteria which guarantees the relevance and the satisfiability of
the defined schema elements. It consists of the preprocessor, the coverage database,
and the adequacy criteria analyzer. The implemented criteria allows to automatically
analyze which base types, derived types, valid type configurations and event
occurrences have been tested in at least one valid execution of a test case.
352 A. Tort, A. Oliv, and M.-R. Sancho
The preprocessor initializes the coverage database, which maintains the set of
covered elements for each test adequacy criterion. The test interpreter communicates
information about the tests execution to the adequacy criteria analyzer which is the
responsible of updating the coverage database according to the defined criteria.
After the execution of all test programs, the adequacy criteria analyzer queries the
coverage database in order to obtain the sets of covered and uncovered elements for
each criterion and computes statistical information about the coverage results.
3 Case Studies, Examples and Documentation

The CSTL Processor has been developed in the context of Design Research [7]. The
tool has been experimentally used in the testing of the conceptual schema of two e-
commerce systems (osCommerce [8] and Magento), in the test-driven development of
the schema of a bowling game system [9] and in the reverse engineering development
of the schema of the osTicket System [10]. Moreover, it is being used in a
requirements engineering course, in which groups of master students are challenged
to develop the conceptual schema of a new information system assisted by the tool.
Video tutorials with the examples which will be used in the demonstration session
may be found in the project website [4]. Additional information and resources such as
source files, screenshots and complementary documentation may also be found in [4].
References
1. Lindland, O.I., Sindre, G., Solvberg, A.: Understanding Quality in Conceptual Modeling.
IEEE Software 11(2), 4249 (1994)
2. Oliv, A.: Conceptual Modeling of Information Systems. Springer, Berlin (2007)
3. Tort, A., Oliv, A.: An approach to testing conceptual schemas. Data Knowl.Eng. 69(6),
598618 (2010)
4. Tort, A.: The CSTL Processor project website,
http://www.essi.upc.edu/~atort/cstlprocessor
5. Janzen, D., Saiedian, H.: Test-Driven Development: Concepts, Taxonomy, and Future
Direction. Computer 38(9), 4350 (2005)
6. Gogolla, M., Bohling, J., Richters, M.: Validating UML and OCL Models in USE by
Automatic Snapshot Generation. Software & Systems Modeling 4(4), 386398 (2005)
7. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design science in information systems
research. Mis Quarterly, 75105 (2004)
8. Tort, A.: Testing the osCommerce Conceptual Schema by Using CSTL. Research Report
UPC (2009), http://hdl.handle.net/2117/6289
9. Tort, A.: Development of the conceptual schema of a bowling game system by applying
TDCM. Research Report UPC (2011), http://hdl.handle.net/2117/11196
10. Tort, A.: Development of the conceptual schema of the osTicket system by applying
TDCM. Research Report UPC (2011), http://hdl.handle.net/2117/12369
A Tool for Filtering Large Conceptual Schemas
Antonio Villegas, Maria-Ribera Sancho, and Antoni Olive
Department of Service and Information System Engineering

Polytechnic University of Catalonia
Barcelona, Spain
{avillegas,ribera,olive}@essi.upc.edu
Abstract. The wealth of knowledge the conceptual schemas of many

real-world information systems contain makes them very useful to their
potential target audience. However, the sheer size of those schemas makes
it dicult to extract knowledge from them. There are many information
system development activities in which people needs to get a piece of
the knowledge contained in a large conceptual schema. We present an
information ltering tool in which a user focuses on one or more entity
types of interest for her task at hand, and the tool automatically lters
the schema in order to obtain a reduced conceptual schema including a
set of entity and relationship types (and other knowledge) relevant to
that task.
Keywords: Large Schemas, Filtering, Entity Types, Importance.
1 Introduction
The conceptual schemas of many real-world information systems are too large to
be easily managed or understood. There are many information system develop-
ment activities in which people needs to get a piece of the knowledge contained
in a conceptual schema. For example, a conceptual modeler needs to check with
a domain expert that the knowledge is correct, a database designer needs to
implement that knowledge into a relational database, a software tester needs to
write tests checking that the knowledge has been correctly implemented in the
system components, or a member of the maintenance team needs to change that
knowledge. Currently, there is a lack of computer support to make conceptual
schemas usable for the goal of knowledge extraction.
Information ltering [3] is a rapidly evolving eld to handle large information
ows. The aim of information ltering is to expose users only to information that
is relevant to them. We present an interactive tool in which the user species
one or more concepts of interest and the tool automatically provides a (smaller)
subset of the knowledge contained in the conceptual schema that is likely to be
relevant. The user may then start another interaction with dierent concepts,
until she has obtained all knowledge of interest. We presented the theoretical
background behind this tool in [4,5].

354 A. Villegas, M.-R. Sancho, and A. Olive
2 The Filtering Process

In this section we describe how a large conceptual schema can be ltered using
the method implemented by our tool, which corresponds to the demonstration we
intend to perform. The main idea is to extract a reduced and self-contained view
from the large schema, that is, a ltered conceptual schema with the knowledge
of interest to the user. Figure 1 presents the three steps of our ltering process.
Fig. 1. Method overview
The rst step consists in preparing the required information to lter the large
schema according to the specic needs of the user. Basically, the user focus on
a set of entity types she is interested in and our method surrounds them with
additional related knowledge from the large schema. Therefore, it is mandatory
for the user to select a non-empty initial focus set of entity types of interest.
During the second step our method computes the required metrics to automat-
ically select the most interesting entity types to extend the knowledge selected
in the focus set of the rst step. The main goal of these metrics is to discover
those entity types that are relevant in the schema but also that are close (in
terms of structural distance over schema) to the entity types of the focus set.
We presented a detailed denition of such metrics in [4].
Finally, the last step receives the set of most interesting entity types selected
in the previous step and puts it together with the entity types of the focus set
in order to create a ltered conceptual schema with the entity types of both
sets. The main goal of this step consists in ltering information from the orig-
inal schema involving entity types in the ltered schema. To achieve this goal,
the method explores the relationships and generalizations/specializations in the
original schema that are dened between those entity types and includes them
in the ltered schema to obtain a connected schema.
3 The Filtering Tool

Our ltering tool is developed as a web client that interacts with a web service
following the SOAP protocol. The ltering web service we have developed makes
use of a modied version of the core of the USE tool [2] to load and maintain
the knowledge of the large schema the user wants to explore. In our demonstra-
tion the large schema to lter consists of a subset of the HL7 V3 schemas [1]
containing more than 2,500 entity types from healthcare domains [5].
A Tool for Filtering Large Conceptual Schemas 355
Fig. 2. Request of a user to our ltering tool
Figure 2 depicts the main components that participate in a user request to our
ltering tool. The user writes in the search eld the names of the entity types she
is interested in. Our web client automatically suggests names while the user is
writing to simplify that task and to help her discovering additional entity types.
In the example of Fig. 2 the user focuses on the entity types ActAppointment
and Patient. Once the request is complete our web client processes the focus
set and uses the ltering API of the web service through a SOAP call. The
web service analyses the request and constructs the related ltered conceptual
schema following the ltering process described in the previous section.
Figure 3 shows the components of the response. The reduced schema pro-
duced by our web service is an XMI le containing 8 entity types. In order to
increase the understandability of the schema we make use of an external service
(http://yuml.me) to transform the ltered schema from a textual representa-
tion to a graphical one. As a result, the user can rapidly comprehend from the
schema of Fig. 3 that SubjectOfActAppointment connects the entity types Ac-
tAppointment and Patient, which means that in the HL7 V3 schemas a patient
is the subject of a medical appointment. Subsequently, the user can start again
the cycle with a new request if required.
4 Summary
We have presented a tool to assist users to deal with large conceptual schemas
that allows to focus on a set of entity types of interest and automatically ob-
tains a reduced view of the schema in connection with that focus. Our imple-
mentation as a web service provides interoperability and simplies the inter-
action with users. A preliminary version of the ltering tool can be found in
http://gemece.lsi.upc.edu/filter.
Our immediate plans include the improvement of our tool by adding a more
dynamic view of the ltered schema instead of the static image obtained by
the present external service. As a result, we are introducing more interactive
features such as selection of schema elements and new ltering interactions from
that selection.
356 A. Villegas, M.-R. Sancho, and A. Olive
Fig. 3. Response of our ltering tool to the user
Acknowledgements. This work has been partly supported by the Ministe-

rio de Ciencia y Tecnologia and FEDER under project TIN2008-00444/TIN,
Grupo Consolidado, and by Polytechnic University of Catalonia under FPI-UPC
program.
References
1. Beeler, G.W.: HL7 version 3 an object-oriented methodology for collaborative
standards development. International Journal of Medical Informatics 48(1-3), 151
161 (1998)
2. Gogolla, M., B uttner, F., Richters, M.: USE: A UML-based specication environ-
ment for validating UML and OCL. Science of Computer Programming (2007)
3. Hanani, U., Shapira, B., Shoval, P.: Information ltering: Overview of issues, research
and systems. User Modeling and User-Adapted Interaction 11(3), 203259 (2001)
4. Villegas, A., Olive, A.: A method for ltering large conceptual schemas. In: Parsons,
J., Saeki, M., Shoval, P., Woo, C., Wand, Y. (eds.) ER 2010. LNCS, vol. 6412, pp.
5. Villegas, A., Olive, A., Vilalta, J.: Improving the usability of HL7 information models
by automatic ltering. In: IEEE 6th World Congress on Services, pp. 1623 (2010)
Preface to the Industrial Track
The aim of the ER11 Industrial Track was to serve as a forum for high quality pre-
sentations on innovative commercial software, systems, and services for all facets of
conceptual modeling methodologies and technologies as described in the list of topics
of the ER 2011 conference. We strongly believe that bringing together researchers and
practitioners is important for the progress and success of research on conceptual mod-
eling. We do hope that this track will become stronger year by year and will serve as an
excellent opportunity to discuss current practices and modern and future market trends
and needs.
The 2011 edition formed two interesting sessions on advanced and novel conceptual
model applications.
The first session included three papers on business intelligence applications. The first
two papers present tools than assist the data warehouse designer. QBX is a case tool that
facilitates data mart design and deployment. TARGIT BI Suite assists the designer to
add associations between measures and dimensions to a traditional multidimensional
cube model and facilitates a process where users are able to ask questions to a busi-
ness intelligence system without the constraints of a traditional system. The third paper
presents a tool that implements an entity resolution method for topic-centered expert
identification based on bottom-up mining of online sources.
The second session included three papers on emerging industrial applications of con-
ceptual modeling. The first paper presents a model-driven solution toward the provision
of secure messaging capabilities to the financial services industry through the stan-
dardization of message flows between industry players. The second paper presents the
underlying scientific theories, methodology, and software technology to meet the re-
quirements of high quality technical documentation. The third paper presents a real
case of using business semantics management for integrating and publishing research
information on an innovation information portal.
We hope that you will enjoy the industrial track proceedings and find useful infor-
mation and motives to extend your research to new horizons. We would like to express
our gratitude to all authors who submitted papers and talk proposals, the members of
the program committee for their help and efforts in organizing this track, and the ER
2011 organizing committee and ER steering committee for all their support.
July 2011 Alkis Simitsis

Hans Van Mingroot

QBX: A CASE Tool for Data Mart Design
Antonino Battaglia1 , Matteo Golfarelli2 , and Stefano Rizzi2

1
Theorematica S.p.A., Rome, Italy
a.battaglia@theorematica.it
2
DEIS - University of Bologna, Italy
{matteo.golfarelli,stefano.rizzi}@unibo.it
Abstract. QBX is a CASE tool for data mart design resulting from a
close collaboration between academy and industry. It supports designers
during conceptual design, logical design, and deployment of ROLAP data
marts in the form of star/snowake schemata, and it can also be used
by business users to interactively explore project-related knowledge at
dierent levels of abstraction. We will demonstrate QBX functionalities
focusing on both forward and reverse engineering scenarios.
1 Introduction and Motivation
The continuous market evolution and the increasing competition among com-
panies solicit organizations to improve their ability to foresee customer demand
and create new business opportunities. In this direction, data warehouses have
become an essential element for strategic analyses. However, data warehouse sys-
tems are characterized by a long and expensive development process that hardly
meets the ambitious requirements of todays market. This is one of the main
causes behind the low penetration of data warehouse systems in small-medium
rms, and even behind the failure of whole projects [4].
A data warehouse is incrementally built by designing and implementing one
data mart at a time; so, one of the directions to increase the eciency of the
data warehouse development process is to automate design of single data marts.
Several techniques for automating some phases of data mart design have been
proposed in the literature (e.g., [2] for conceptual design, [5] for logical design,
[3] for physical design, [6] for designing the ETL process), and some research
prototypes of CASE tools have been developed (e.g., [1]). On the other hand,
commercial tools such as Oracle Warehouse Builder are oriented to a single
platform and should be considered as design wizards rather than CASE tools.
In this paper we introduce QBX, a CASE tool resulting from a close collab-
oration between academy and industry; in particular, industrial partners took
care of the executive design and implementation of the tool. QBX includes two
separate components: QB-Xpose (read cube-expose) and QB-Xplore (read cube-
explore). The rst is used by designers for conceptual design, logical design, and
deployment of ROLAP data marts in the form of star/snowake schemata; the
design process is further streamlined by letting QBX read from and write to the

QBX: A CASE Tool for Data Mart Design 359
Fig. 1. Simplied component diagram for QB-Xpose
metadata repositories of the Mondrian and Microstrategy multidimensional en-

gines. The second is accessed via browser by business users and technical experts
to interactively explore project-related knowledge at dierent levels of abstrac-
tion, ranging from technical documentation to glossaries of terms and concepts
based on the business users vocabulary.
2 Architecture
As already mentioned, QBX includes two integrated software tools.
QB-Xpose gives designers an eective support by automating conceptual and
logical design of data marts, and by making deployment on ROLAP platforms
easier. It was implemented based on Eclipse [7], an open source project pro-
viding an extensible development platform. The QB-Xpose components were
developed in accordance with the Eclipse plug-in contract using three comple-
mentary frameworks: Eclipse Modeling Framework (EMF), Graphical Editing
Framework (GEF), and Graphical Modeling Framework (GMF). Figure 1 shows
the main components of QB-Xpose and their dependencies. Three components
implement the model-view-controller design pattern: QBXtool.Model uses the
EMF and is responsible for managing the QBX model; QBXtool.Edit and QBX-
tool.Diagram use the EMF and the GMF, and play the roles of the controller and
of the viewer, respectively. QBXtool.Logical supports logical design, while QBX-
tool.Mondrian and QBXtool.Microstrategy manage the conversion of the QBX
meta-model to/from the Mondrian and Microstrategy meta-models.
QB-Xplore enables business users to interactively browse and annotate the
project documentation, both at business and technical levels. QB-Xplore is a
web application implemented using the Google Web Toolkit. The underlying
model was built using the EMF to achieve higher eciency when exchanging
information with QB-Xpose.
3 Functional Overview
From a methodological point of view, QBX supports both classical scenarios of
data mart design [8]:
Demand-driven approach, where designers draw their data mart starting
from user requirements, possibly by composing existing hierarchies and
360 A. Battaglia, M. Golfarelli, and S. Rizzi
reusing conformed dimensions. Establishing a mapping with the source op-

erational schema is postponed to the ETL design phase.
Supply-driven approach, where a data mart schema is semi-automatically
derived from the schema of a source operational database. User requirements
help designers choose facts, dimensions, and measures. Mappings between
the data mart schema and the source schema make ETL design simpler.1
A basic feature of QBX is that of using conceptual schemata for multidimensional

design. Conceptual modeling provides a high level of abstraction in describing
the multidimensional repository, aimed at achieving independence of implemen-
tation issues. It is widely recognized to be the necessary foundation for building
a database that is well-documented and fully satises user requirements; usu-
ally, it relies on a graphical notation that facilitates writing, understanding, and
managing conceptual schemata by both designers and business users. The con-
ceptual model adopted by QBX is the Dimensional Fact Model (DFM) [2]. The
DFM was born in the academic context and it has been widely experimented in
the industrial world; its main goals are to lend eective support to conceptual
design, to make communication possible between designers and end-users with
the goal of formalizing requirement specications, to build a stable platform for
logical design, and to provide clear and expressive design documentation. The
DFM gives a graphical and intuitive representation of facts, measures, and di-
mensions; dimensional, descriptive, and cross-dimensional attributes; optional
and multiple arcs; convergences; shared, incomplete, and recursive hierarchies;
additivity; temporal scenarios.
The adoption of a conceptual model breaks design into two distinct but inter-
related phases, that are largely independent of the features of the OLAP engine
chosen for deployment:
1. Conceptual Design. This phase maps user requirements into a conceptual

schema of the data mart, that is, a platform-independent, non-ambiguous,
comprehensive representation of the facts for decision support that gives a
multidimensional picture of the data mart content to both designers and
business users. In a supply-driven approach, conceptual design is automated
by choosing relevant facts on a source operational database schema and
letting QBX draw hierarchies using the approach in [2]. In a demand-driven
approach, a conceptual schema is created from scratch by manually drawing
hierarchies and reusing conformed dimensions.
2. Logical Design. Starting from a conceptual schema, QBX implements a large
set of best practices to create an optimized logical schema for the data mart,
that is, a set of star/snowake schemata. The resulting logical schema can
be ne-tuned based on the expected data volume and on the designers
preferences.
1
This function will be made available starting from release 2.0. In case two or more
databases are used to feed the data mart, QBX derives the data mart schema from
the schema of the operational data store (ODS) that integrates the source databases.
Database integration is out of the scope of QBX.
Requirements Design Options
Designer QBXpose QBXplore

CONCEPTUAL LOGICAL
DESIGN DESIGN Project
Conceptual Schema Logical Schema Documentation
WEB
BROWSER
DEPLOYMENT
Logical Schema Operational Data Volume

Data Mart
DB
OLAP Business User

Meta-data Technical Expert
Fig. 2. Forward engineering with QBX
QBXpose QBXplore
Project
Conceptual Schema Logical Schema Documentation
WEB
BROWSER
IMPORT
Data Mart
OLAP Business User

Meta-data Technical Expert
Fig. 3. Reverse engineering with QBX
In this forward engineering scenario (sketched in Figure 2), logical design is

followed by a third phase:
3. Deployment. Based on both a conceptual and a logical schema, QBX gen-
erates SQL code for the underlying relational DBMS and writes the corre-
sponding meta-data on the chosen OLAP engine (either Microstrategy or
Mondrian in this release). Since the expressiveness of the DFM (in terms
of multidimensional constructs) is wider than the ones of the meta-models
of both Microstrategy and Mondrian, the actual structure of the deployed
schemata depends on the capabilities of the OLAP engine selected. Similarly,
QBX adapts the syntax of the generated SQL statements to the one of the
adopted DBMS.
Further QBX functionalities include:
Reverse engineering. To enable designers and business users to enjoy a more
expressive view of an existing data mart, QBX can also be employed to
362 A. Battaglia, M. Golfarelli, and S. Rizzi
acquire metadata from an OLAP engine and translate them into a DFM
conceptual schema. This scenario is sketched in Figure 3.
Logical design preferences. To enable a ner tuning of logical schemata,
designers can express a set of preferences about logical design, including
e.g. how to deal with degenerate dimensions, shared hierarchies, and cross-
dimensional attributes.
Data volume. QBX enables designers to specify the data volume for a data
mart, in terms of expected cardinalities for both facts and attributes. This
is done manually in a demand-driven scenario, automatically in a supply-
driven scenario. When a data volume has been specied, designers can ask
QBX to optimize ROLAP schemata from the point of view of their storage
space.
Fig. 4. Conceptual design with QBX
Fig. 5. Logical design with QBX

Project-related knowledge. QB-Xpose automatically creates the documenta-

tion for data marts, including fact schemata, conformed dimensions, glos-
saries, and data volumes. This technical documentation, that can be
published on the web and easily browsed via QB-Xplore, is only a part of
the project knowledge, that also includes the business descriptions of terms
and concepts appearing in reports and analyses. This precious information
can be collected from domain experts during requirement analysis using QB-
Xpose, or it can be progressively acquired in the form of annotations made
by business users using QB-Xplore.
4 Demonstration Scenarios
The demonstration will focus on both forward and reverse engineering scenarios.
In the forward engineering scenario, we will adopt a demand-driven approach
to interactively draw a conceptual schema (Figure 4), showing how QB-Xpose
automatically checks for hierarchy consistency in presence of advanced constructs
of the DFM. Then, we will let QB-Xpose generate alternative logical schemata
using dierent design preferences, and critically compare the results (Figure 5).
Finally, we will let QB-Xpose create a comprehensive documentation for the
project.
In the reverse engineering scenario, the relational schema and metadata of
an existing data mart will be imported from the Mondrian engine, and the
eectiveness of their translation to the DFM will be discussed.
References
1. Golfarelli, M., Rizzi, S.: WAND: A CASE tool for data warehouse design. In: Proc.
ICDE, pp. 79 (2001)
2. Golfarelli, M., Rizzi, S.: Data warehouse design: Modern principles and methodolo-
gies. McGraw-Hill, New York (2009)
3. Golfarelli, M., Rizzi, S., Saltarelli, E.: Index selection for data warehousing. In: Proc.
DMDW, pp. 3342 (2002)
4. Ramamurthy, K., Sen, A., Sinha, A.P.: An empirical investigation of the key de-
terminants of data warehouse adoption. Decision Support Systems 44(4), 817841
(2008)
5. Theodoratos, D., Sellis, T.: Designing data warehouses. Data & Knowledge Engi-
neering 31(3), 279301 (1999)
6. Vassiliadis, P., Simitsis, A., Georgantas, P., Terrovitis, M., Skiadopoulos, S.: A
generic and customizable framework for the design of ETL scenarios. Information
Systems 30(7), 492525 (2005)
7. Vv. Aa.: Eclipse. http://www.eclipse.org/platform/ (2011)
8. Winter, R., Strauch, B.: A method for demand-driven information requirements
analysis in data warehousing projects. In: Proc. HICSS, pp. 13591365 (2003)
The Meta-Morphing Model Used in TARGIT BI Suite
Morten Middelfart1 and Torben Bach Pedersen2

1
TARGIT A/S
2
Aalborg University Department of Computer Science
morton@targit.com, tbp@cs.aau.dk
Abstract. This paper presents the meta-morphing model and its practical appli-
cation in an industry strength business intelligence solution. The meta-morphing
model adds associations between measures and dimensions to a traditional multi-
dimensional cube model, and thus facilitates a process where users are able to ask
questions to a business intelligence (BI) system without the constraints of a tradi-
tional system. In addition, the model will learn the users presentation preferences
and thereby reduce the number of interactions needed to present the answer. The
nature of meta-morphing means that users can ask questions that are incomplete
and thereby experience the system as a more intuitive platform than state-of-art.
1 Introduction
According to leading industry analyst, Gartner, ease of use has surpassed functionality
for the first time as the dominant business intelligence platform buying criterion [5].
This change represents a shift from prioritizing the IT departments need to standardize
to prioritizing the ability for casual users to conduct analysis and reporting.
Ease of use, in the decision processes that managers and employees go through, has
been the focal point in the development of TARGIT BI Suite since its early version in
1995. However, different from other solutions that seek the same objective, TARGIT
has methodically applied the CALM philosophy [1], which seeks to create synergy
between humans and computers as opposed to using computers simply as a tool to create
efficiency. In the CALM philosophy, the entire organization is divided into multiple
observe-orient-decide-act (OODA) loops and computing is applied to make users cycle
these loops as fast as possible, i.e., with as few interactions as possible. The patented
meta-morphing [4], described in the following section, allows users to analyze data by
stating their intent, and thus facilitates users cycling OODA loops with few interactions.
2 The Meta-Morphing Model

The meta-morphing model is an extension of the cube model traditionally used in a
data warehouse where associations between measures and dimensions, as well as, pre-
sentation preferences are included. As a prerequisite for the meta-morphing model, we
assume that the data has been organized in measures (numerical data) and dimensions
(entities for which measures will be listed, e.g., time periods, products, etc.), and that
these measures and dimensions are organized in one or more cubes. Whether the cube
structures are materialized or virtual is irrelevant to the functionality.

The Meta-Morphing Model Used in TARGIT BI Suite 365
Fig. 1. The meta-morphing model
The meta-morphing model, shown in Figure 1, facilitates the following four steps:
1. A question is parsed into a set of one or more measures or dimensions.
2. If the question is incomplete (meaning that it has either only dimension(s) or mea-
sures(s)) then an association with the most relevant measure (if question had only
a dimension) or dimension (if question had only a measure) is created.
3. A query based on the associated measures and dimensions is executed on the cube.
4. The preferred presentation of the returned data is selected given by either the users
preferences (earlier behavior) or if no previous experience exists an expert system
will determine the presentation based on the size and shape of the returned data. The
returned dataset is displayed to the user with the presentation properties identified.
Example: A user submits the question I would like to see customers.
Step 1. parses all words in the sentence representing the questions (Figure 1(b)), and
these words are subsequently matched against the meta-data of the data warehouse (Fig-
ure 1(a)). If a word in the sentence is not matched in the meta-data it is simply thrown
away. The output from Step 1 will be a set of dimensions and/or measures; and if the
set is empty, the meta-morphing process is simply terminated. In our example, the only
word that will remain from this parsing is customers.
Step 2. compensates for the problem of the users question containing only measures
or dimensions. In a traditional system, asking incomplete questions like I would like
to see customers or Show me revenue would at best return a list of customers (the
members of the customer dimension) or the sum of revenue for all data in the data
warehouse. By creating an association between measures and dimensions (Figure 1(c)),
the system will learn the individual users behavior based on what he clicks, e.g., if he
366 M. Middelfart and T.B. Pedersen
clicks to select revenue and customers at the same time, then an association between
revenue and customers will be created. Therefore, the answer to both questions will be
a list of customers with their respective revenue. Associations are also created while
the user loads any analysis, meaning that he does not need to actively pose a question
including the association. This means that the user will simply feel that he is receiving
information in the way he is used to. In the event that a user has never seen or asked
for a given relationship, the meta-morphing process will look into which dimension or
measure the user most often uses, and then create an association that is used most often,
i.e., the measure or dimension from the association with the highest Used Count (see
Figure 1(c)). The output of Step 2 is a combination of measures and dimensions.
Step 3. is, given the output of Step 2, a trivial query in the data warehouse retrieving
revenue for each member on the customers dimension. The output of this step is a
dataset as well as the dimensions and measures used to provide it.
Step 4. preferences are created for each user given the way they would normally see
an answer given its dimension/measure combination, e.g., customer/revenue is usually
displayed as a pie-chart (see Figure 1(d)), profit per country is usually displayed as
a bar-chart, etc. Given the experience with the users preferences that are collected
whenever the user sees or formats a piece of information, the dataset received from
Step 3 is formatted and displayed to the user. In the event that no preferences have been
collected for the user, an expert system will inspect the dataset and make a call for
the best presentation object (pie, bar, geographic map, table, etc.), this expert system is
based on input from a TARGIT BI domain expert. In our example, the returned revenue
for each customer will be presented as a pie chart based on the data in Figure 1(d).
Using the meta-morphing model, users are able to pose incomplete questions that
will still return relevant answers, while at the same time save the users a number of in-
teractions in formatting the dataset returned since these are already known to the system.
In other words, the user will be guiding the system with his intent, and the computer
will provide him with the best fitting output based on the his individual preferences.
Another interesting aspect of meta-morphing is that it will allow the user to ask
questions in human language as opposed to a database query language, which will al-
low a much more natural intuitive feel to the application that exploits the process. In
particular, with regards to speech recognition, the parsing of question to meta-data in
Step 1 will mean that the recognition will be enhanced simply from the fact that fewer
words will be in the vocabulary, as opposed to a complete language. The combination
of meta-morphing and speech is also a patented process [3].
3 Meta-Morphing in the TARGIT BI Suite
The TARGIT BI Suite is recognized by analysts as being one of the leading global
business intelligence platforms with more than 286,000 users World-wide. Although no
specific usability study has been conducted, the TARGIT BI Suite has been surveyed
by leading industry analysts to have a unique strength in its ease of use achieved by
reducing the number of interactions that a user needs to conduct in order to make deci-
sions [5]. The so-called few clicks approach has been demonstrated to allow users to
easily interpret the datasets displayed using automatically generated explanations [2].
In the TARGIT BI Suite, the meta-morphing process is integrated such that users
have the option of activating it dynamically in three different scenarios: guided ana-
lytics called Intelligent Analysis, a quick drag-drop function called TARGIT This, and
finally, an analytical link to all dashboards and reports known as Hyper-Related OLAP.
Intelligent Analysis allows users to compose sentences similar to our example in the
previous section by clicking on meta-data in a semi-structured environment. Once a
question is posed, the process using the meta-morphing model can be activated.
TARGIT This is a drop-area to which either a dimension or a measure can be dropped,
and upon release of the item dropped, the process using the meta-morphing model
will commence with the question I would like to analyze [measure or dimension].
Hyper-Related OLAP is perhaps where the most powerful results are achieved by the
meta-morphing process. Hyper-Related OLAP allows the user to click any figure in
the TARGIT BI Suite in order to analyze it. Since any figure presented on a business
intelligence platform is a measure surrounded by dimensions (either as grouping or
criteria), the process using the meta-morphing model can be activated by a single click
at any figure, with the question I would like to analyze [measure]. This gives the user
a starting point for analyzing any figure whenever he sees something he wants to inves-
tigate further. This functionality significantly reduces the time and interactions needed
from whenever a problem is observed to when an analysis can be conducted in order to
reach a decision with subsequent action. In other words, Hyper-Related OLAP directly
assists the users in cycling their individual OODA loops with fewer interactions.
4 Conclusion
This paper presented the meta-morphing model and showed its practical application
in an industry strength business intelligence solution. It was specifically demonstrated
how the meta-morphing model will allow users to freely pose questions in human lan-
guage, including in speech, and subsequently receive a presentation of the answer in
accordance with their preferences. It was demonstrated how the meta-morphing model
can contribute with greater ease of use by reducing the number of interactions needed in
data analysis. Moreover, it was demonstrated how meta-morphing can reduce the time
and interactions for users cycling an observation-orientation-decision-action loop.
Acknowledgments. This work was supported by TARGIT A/S, Daisy Innovation and
the European Regional Development Fund.
References
1. Middelfart, M.: CALM: Computer Aided Leadership & Management. iUniverse (2005)
2. Middelfart, M., Pedersen, T.B.: Using Sentinel Technology in the TARGIT BI Suite.
PVLDB 3(2), 16291632 (2010)
3. Middelfart, M.: Presentation of data using meta-morphing. United States Patent 7,779,018
(Issued August 17, 2010)
4. Middelfart, M.: Method and user interface for making a presentation of data using meta-
morphing. United States Patent 7,783,628 (Issued August 24, 2010)
5. Sallam, R.L., Richardson, J., Hagerty, J., Hostmann, B.: Magic Quadrant for Busi-
ness Intelligence Platforms, www.gartner.com/technology/media-products/
reprints/oracle/article180/article180.html (April 28, 2011)
The Demonstration
Scenario 1: We use structured meta-morphing in the TARGIT BI Suite to compose the

question I would like to analyze Revenue and subsequently click the Go button
(Figure 2).
Fig. 2. Composing the question via structured meta-morphing
Fig. 3. Analysis screen resulting from structured meta-morphing

Based on experience with the users preferences for presenting the measure Revenue,
a complete analysis (with the measure Revenue displayed over a set of dimensions:
Customer Country, Item, and Period, including their presentation preferences:
map, pie-, and bar chart) is presented (Figure 3).
Fig. 4. Composing the question using the TARGIT This feature
Fig. 5. Analysis screen resulting from TARGIT This

Scenario 2: We drag the dimension Customer and drop it on the TARGIT This
drop area in the TARGIT BI Suite (Figure 4).
Based on experience with the users preferences the customer dimension is presented
with the measure Revenue, and given the users presentation preferences the output is
presented in a table (Figure 5). The system automatically adds a descending sorting to
the table and an option for selecting on the time dimension (criteria option above the
table).
Tool Support for Technology Scouting Using
Online Sources
Elena Tsiporkova and Tom Tourwe
Sirris - ICT & Software Engineering Group

A. Reyerslaan 80, 1030 Brussels, Belgium
{elena.tsiporkova,tom.tourwe}@sirris.be
Abstract. This paper describes a prototype of a software tool imple-

menting an entity resolution method for topic-centered expert identi-
cation based on bottom-up mining of online sources. The tool extracts
and unies information extracted from a variety of online sources and
subsequently builds a repository of user proles to be used for technology
scouting purposes.
1 Introduction
Many rms are nowadays looking for opportunities to adopt and implement a
formal, structured and focused approach for the identication and acquisition
of new technology, and to develop technology based product and service inno-
vations. This is usually referred to as technology scouting and is understood as
an organised approach for identifying technological needs, gaps and opportuni-
ties, and then nding solutions outside the ocial borders of the enterprise. It
is very often applied when: 1) a technical problem needs to be solved quickly
due to some change in the competitive landscape; 2) an organisation is looking
for opportunities to move into a new market with limited involvement of inter-
nal resources; 3) or specic new skills need to be acquired without increasing
internal resource overhead.
The role of the technology scout will therefore include searching for oppor-
tunities and leads within a certain technological domain, evaluating leads, and
creating the link between a lead and company strategy. A technology scout needs
to utilize an extensive and varied network of contacts and resources, and stay
on top of emerging trends and technologies.
With the rise of the social web and the advent of linked data initiatives a
growing amount of data is becoming publicly available: people communicate on
social networks, blogs and discussion forums, research events publish their online
programmes including article abstracts and authors, websites of technological
conferences and exhibitions advertise new products and technologies, govern-
ments and commercial organisations publish data, and the linked open data
cloud keeps on growing. An enormous potential exists for exploiting this data
by combining it and extracting intelligence from it for the purpose of technology
scouting. However, there are currently no adequate tools available to support the

372 E. Tsiporkova and T. Tourwe
work of the technology scouts and although a large pool of data is available on
the web, it is often gathered manually, a time intensive, tedious and error-prone
process, due to the fact that the data is not centralised, is available in dierent
formats, can be outdated or contradictory, etc.
In this paper, we describe a prototype of a software tool for topic-centric
expert identication from online sources. We present the rationale and the con-
crete approach applied in the realisation of the tool. The main novelty of our
approach lies in the fact that it is based on the bottom-up, application-driven
and incremental creation of the repository, as opposed to the more commonly
considered top-down approach.
2 Rationale
Identifying experts is by far not a new topic and it has been gradually gaining
interest in the recent years [1,2,3,4]. However, there are certain shortcomings
associated with the existing approaches e.g. lack of focus on realistic applications,
limited to a single source, targeting too large scale, poor resolution and accuracy,
high information redundancy, etc.
The problem of nding experts is very often approached top-down with re-
spect to both application and scale, meaning that often a certain method or
technology is developed without a clear idea of the potential application in mind
and by default coverage comes before accuracy. Many works on the topic focus
mainly on the elaboration and application of advanced information retrieval,
machine learning and reasoning techniques (see [5,6,7,8,9,10]), while consider-
ing rather synthetic applications as research collaboration or enterprise expert
search([11,12,13]). Some other recent contributions [14,15] in the area of inte-
grating web data consider a set of challenging research topics as data cleansing,
proling, and entity resolution, but suer from the same lack of focus on concrete
and realistic applications.
In terms of scale, the problem of nding experts is usually tackled by mining
vast online data sources as e.g. Wikipedia and CiteSeer (see Jung et al. [2]), in
order to gather a suciently large data repository containing information about
persons, articles, social links, etc. This has the advantage of achieving high cov-
erage of the experts active in a certain domain and relatively complete expert
proles in space and time. Unfortunately, such large data collections contain
a substantial proportion of noisy data (contradictions, duplicates, ...) and the
achieved degree of accuracy cannot be estimated in a reliable way. Accuracy is
most commonly measured by precision and recall. Precision is the ratio of true
positives, i.e. true experts in the total number of found expert candidates, while
recall is the fraction of true experts found among the total number of true ex-
perts in a given domain. However, determining the total number of true experts
in a given domain is not feasible. Furthermore, for applications as technology
scouting the current activity and location of certain experts is more important
than their career evolution within an extensive time span. In general, for appli-
cations delivering data for business decision making purposes the reliability of
the information at the current time period is crucial.
Tool Support for Technology Scouting Using Online Sources 373
We propose below an expert nding approach for the purpose of technology

scouting applications. The approach implements an entity resolution method
which allows reliable disambiguation of authors of scientic articles. Initially,
data sources closely aligned with the topic of interest are considered in order
to create the initial expert repository. This is further extended by integrating
several dierent types of linked data sources e.g. Google Scholar and DBLP.
Subsequently, to facilitate the entity resolution algorithm, LinkedIn (or other
appropriate source) is used as an auxiliary data source to determine if two au-
thors with similar names, or with the same name but dierent aliations, are
the same person or not.
3 Approach
The types of expert-related information identied as relevant to technology
scouting applications are as follows: 1) actors in the eld: leading researchers
and experts, as well as companies, research institutes, universities; 2) technology-
related publications: scientic and popularised publications, presentations and
keynotes, press releases and technology blogs; 3) research activities: past and
ongoing research projects and collaborations, organisation and participation in
research events, etc. Relationships between the dierent data entries need also to
be identied and made explicit, e.g. formal and informal expert networks, identi-
ed through joint publications, joint organisation of events, social networks such
as LinkedIn and Twitter, professional and educational history.
Following the reasoning in the foregoing section, we approach the problem
of identifying the main actors in a certain technological domain bottom-up by
rst identifying online sources to mine, targeted to the application domain in
question. These serve as seeds for the further incremental growth of our expert
repository. The main rationale behind the seed approach is that dierent expert
communities use dierent communication channels as their primary mean for
communicating and disseminating knowledge, and thus dierent types of sources
would be relevant for nding experts on dierent topics.
Thus if we want to identify currently active researchers in a particular domain,
as for example in software engineering, we can assume such experts regularly
publish in top-quality international conferences, such as for example The In-
ternational Conference on Software Engineering (http://icse-conferences.org/).
Such conferences nowadays have a dedicated website which details their pro-
gram, i.e. the set of accepted papers that will be presented, together with their
authors and titles, often grouped in sessions. We consider such a website as the
initial seed for our approach: we extract information about the topics presented,
e.g. the titles and abstracts (if available) of presented papers and the session
in which they are presented, and about who is presenting, e.g. author names,
aliation, e-mail addresses, etc.
A drawback of this approach of having a front end which is very tightly aligned
to the topic of interest is that a dedicated tool needs to be developed each time
a new seed source is considered for mining. This imposes certain limitations on
the level of automation that can be achieved.
The initial set of experts is rather limited: one author typically only pub-
lishes one paper at a particular conference, probably collaborates with a broader
set of people besides his co-authors for this particular paper, and is poten-
tially interested in more topics and domains than the ones addressed in this
paper. To extend the gathered information, we consider additional sources us-
ing the extracted information as a seed. We search for every author and co-
author on Google Scholar (http://scholar.google.com) and the DBLP website
(http://www.informatik.uni-trier.de/ley/db/) to identify additional published
material, resulting in a broader set of co-authors and a broader set of topics
of interest. Although the completeness of the information improves, the level of
accuracy decreases as more noise occurs: dierent authors might share a name,
one authors name might be spelled dierently (e.g.Tourwe, T. versus Tom
Tourwe) in dierent papers, dierent aliations might occur for a seemingly
unique author, etc.
In order to clean the data, we again consider additional sources, such as
LinkedIn or ScienticCommons (http://en.scienticcommons.org/) for example.
People use LinkedIn to list past and present work experience, their educational
background, a summary of their interests and activities, etc. In addition, in-
formation about peoples professional network is available. We exploit all this
information to merge and disambiguate the extracted data, e.g. we use work
experience data to merge authors with dierent aliations, and we separate au-
thors with the same name by matching the list of LinkedIn connections with the
list of co-authors.
The raw data contains a simple enumeration of keywords reecting to some
extent the topics addressed by a single author. These have been obtained after
processing the extracted textual information for each expert (e.g. article title
and abstract, session title, aliation, etc.) in two steps:
Part-of-speech tagging: The dierent words in the total text collection for
each author are annotated with their specic part of speech using the Stan-
ford part-of-speech tagger ([16]). Next to the part of speech recognition, the
tagger also denes whether a noun is plural, whether a verb is conjugated,
etc.
Keyword retention: The annotated with part of speech text is subsequently
reduced to a set of keywords by removing all the words tagged as articles,
prepositions, verbs, and adverbs. Practically, only the nouns and the ad-
jectives are retained and the nal keyword set is formed according to the
following simple algorithm:
1. adjective-noun(s) keywords: a sequence of an adjective followed by a
noun or a sequence of adjacent nouns is considered as one compound
keyword e.g. supervised learning;
2. multiple nouns keywords: a sequence of adjacent nouns is considered as
one compound keyword e.g. mixture model;
3. single noun keywords: each of the remaining nouns forms a keyword on
its own.
The above process is rather crude and generates an extensive set of keywords,
without any relationship between them and without guarantee that all of the
Tool Support for Technology Scouting Using Online Sources 375
retained keywords are relevant to the topic of interest. To attain more accurate
and more concise annotation of expert proles with interrelated domain-specic
keywords, a conceptual model of the domain of interest, such as a taxonomy or
an ontology, can be used. In our software engineering example, this would allow
to derive that the keywords user stories and prioritisation are both related
to the requirements concept. This in turn would allow to cluster dierent
authors on dierent levels of abstraction, e.g. around higher-level research do-
mains, such as requirements engineering or around specic research topics such
as agile requirements elicitation. Note that after such formal classication, the
data can potentially be cleaned even more, as one author with two seemingly
unrelated sets of topics of interest potentially should be split into two authors,
or two separate authors with perfectly aligned topics that were not unied in
a previous cleaning step could be merged now this additional information has
become available.
Ontologies for many dierent domains are being developed, e.g. an exhaustive
ontology for the software engineering domain has been developed in [17]. An
alternative approach is to derive a taxonomy using additional sources, such as
the Wikipedia category structure or the Freebase entity graph.
An additional advantage of the construction of a formal semantic model of the
domain of interest is that this enables the use of automatic text annotation tools
for analysing extensive expert-related textual information in order to enrich the
expert proles with domain-specic keywords that are not explicitly present in
the original documents.
4 Demo
The tool platform proposed above is currently in an initial development stage.
A concrete use case scenario will be prepared for the demonstration session in
order to illustrate dierent functionalities e.g. keyword generation for user pro-
ling, particular disambiguation features, domain modelling through taxonomy
building, etc.
5 Conclusion
A software tool which serves as a proof-of-concept for topic-centered expert
identication based on bottom-up mining of online sources is presented. The
realised approach is still work in progress and obviously, the gathered data only
covers parts of the data needed for technology scouting purposes. We consider
to further extend and complemented it with information obtained from research
project databases (e.g. the FP7 database), online patent repositories (e.g. US
Patent Oce, Google Patents) or technological roadmaps.
References
1. Balog, K., de Rijke, M.: Finding similar experts. In: Proceedings of the 30th Annual
International ACM SIGIR Conference on Research and Development in Informa-
tion Retrieval, pp. 821822. ACM, New York (2007)
2. Jung, H., Lee, M., Kang, I., Lee, S., Sung, W.: Finding topic-centric identied
experts based on full text analysis. In: 2nd International ExpertFinder Workshop
at the 6th International Semantic Web Conference ISWC 2007 (2007)
3. Zhang, J., Tang, J., Li, J.: Expert nding in a social network. In: Advances in
Databases: Concepts, Systems and Applications, pp. 10661069 (2010)
4. Stankovic, M., Jovanovic, J., Laublet, P.: Linked Data Metrics for Flexible Expert
Search on the Open Web. In: Antoniou, G., Grobelnik, M., Simperl, E., Parsia, B.,
Plexousakis, D., De Leenheer, P., Pan, J. (eds.) ESWC 2011. LNCS, vol. 6644, pp.
5. Boley, H., Paschke, A.: Expert querying and redirection with rule responder. In:
2nd International ExpertFinder Workshop at the 6th International Semantic Web
Conference ISWC 2007 (2007)
6. Fang, H., Zhai, C.X.: Probabilistic models for expert nding. Advances in Infor-
mation Retrieval, 418430 (2007)
7. Zhang, J., Tang, J., Liu, L., Li, J.: A mixture model for expert nding. In: Washio,
T., Suzuki, E., Ting, K.M., Inokuchi, A. (eds.) PAKDD 2008. LNCS (LNAI),
8. Balog, K., Azzopardi, L., de Rijke, M.: A language modeling framework for expert
nding. Information Processing & Management 45, 119 (2009)
9. Hofmann, K., Balog, K., Bogers, T., de Rijke, M.: Contextual factors for nd-
ing similar experts. Journal of the American Society for Information Science and
Technology 61, 9941014 (2010)
10. Tung, Y., Tseng, S., Weng, J., Lee, T., Liao, A., Tsai, W.: A rule-based CBR
approach for expert nding and problem diagnosis. Expert Systems with Applica-
tions 37, 24272438 (2010)
11. Sriharee, N., Punnarut, R.: Constructing Semantic Campus for Academic Collab-
oration. In: 2nd International ExpertFinder Workshop at the 6th International
Semantic Web Conference ISWC 2007, pp. 2332 (2007)
12. Pavlov, M., Ichise, R.: Finding experts by link prediction in co-authorship networks.
In: 2nd International ExpertFinder Workshop at the 6th International Semantic
Web Conference ISWC 2007, pp. 4255 (2007)
13. Jung, H., Lee, M., Sung, W., Park, D.: Semantic Web-Based Services for Supporting
Voluntary Collaboration among Researchers Using an Information Dissemination
Platform. Data Science Journal 6, 241249 (2007)
14. Bohm, C., Naumann, F., et al.: Proling linked open data with ProLOD. In: Pro-
ceedings of the 26th IEEE International Conference on Data Engineering ICDE
2011, Workshops, pp. 175178 (2010)
15. Pu, K., Hassanzadeh, O., Drake, R., Miller, R.: Online annotation of text streams
with structured entities. In: Proceedings of the 19th ACM International Conference
on Information and Knowledge Management, CIKM 2010, pp. 2938 (2010)
16. Toutanova, K., Kelin, D., Manning, C.: Enriching the knowledge sources used in
a maximum entropy part of speech tagger. In: Proceedings of the Joint SIGDAT
Conference on Empirical Methods in Natural Language Processing and Very Large
Corpora EMNLP/VLC 2000, 6370 (2000)
17. Wongthongtham, P., Chang, E., Dillon, T., Sommerville, I.: Development of a
Software Engineering Ontology for Multi-site Software Development. IEEE Trans-
actions on Knowledge and Data Engineering 21, 12051217 (2009)
Governance Issues on Heavy Models in an
Industrial Context
Sabri Skhiri1 , Marc Delbaere2 , Yves Bontemps2 , Gregoire de Hemptinne1 ,

and Nam-Luc Tran1
1
Euranova S.A.
2
SWIFT : Society for Worldwide Interbank Financial Telecommunication
Abstract. SWIFT is a member-owned cooperative providing secure

messaging capabilities to the nancial services industry. One critical mis-
sion of SWIFT is the standardization of the message ows between the
industry players. The model-driven approach naturally came as a solu-
tion to the management of these message denitions. However, one of the
most important challenges that SWIFT has been facing is the global gov-
ernance of the message repository and the management of each element.
Nowadays modeling tools exist but none of them enables the manage-
ment of the complete life-cycle of the message models. In this paper we
present the challenges that SWIFT had to face in the development of a
dedicated platform.
Keywords: governance, meta-modeling, operational issues.
1 Introduction
SWIFT is the leader in the banking communication and message transmission.
One of its main missions is the management of the communication standards
ISO-15022 and ISO-20022 that are used between banks in order to exchange
messages. Those standards provide the denition of message payloads (i.e. which
data elds can or must be included in which communication ow).
One of the diculties of managing a worldwide business standard is the con-
tinuous need to evolve the standard to cater for new business requirements. From
a model management point of view, this creates a lot of new denitions that then
have to be organized properly.
In 2009, SWIFT Standards undertook a major strategic study aimed at den-
ing a 5 year roadmap for standard capabilities evolutions. They identied a set
of priorities: (i) the management of the content and the reuse, (ii) the ability to
support specialized standards and market practices, and (iii) the management
of changes.
Very recently, SWIFT and their customers have reiterated the role of ISO-
20022 as a mechanism to facilitate the industry integration at the business level.
In order to realize this vision, the need of a common and machine-readable de-
nition has been established. This denition comprised the business processes, the
data dictionary, the message denitions, the market practices and the mapping

378 S. Skhiri et al.
rules. All of these denitions would be managed in a controlled manner over time
(versioning). It should be possible for industry players to customize the deni-
tions in order to t their needs (e.g. local market practices, bilateral agreements)
as well as the representations of their own formats in this environment (using
the expressive power of the ISO 20022 global dictionary).
A thorough model-based approach has been set up in order to enable the
proper governance of the whole model and the interoperability across the actors
working on the model.
2 Technical and Operational Issues
All the issues related to the management of an industry-wide repository of struc-

tured business content are related to the concept of governance. This concept
involves the control of the life-cycle of each model element, the management
of the dependencies between them, the versioning, the design of new elements
based on existing components and many other aspects related to governance.
One additional complexity in the case of the ISO 20022 models is the existence
of two layers of models: a business layer that describes the business at concep-
tual level (process denitions, business concept denitions at the semantic level)
and a message denition layer that describes all of the data objects and the
actual message denitions. In this architecture, each data element present in a
message denition must be linked back to a semantic element. This additional
layer makes it even harder to govern the repository content. In this section we
briey describe the dierent challenges met by such governance framework.
Versioning: we should be able to maintain a version for each model element

with a granularity at the atomic attribute. Most of the modeling frameworks
(such as EMF) usually use XMI (XML Metadata Interchange) for the seri-
alization of the models. We would then have to rely on the versioning at the
le level, which does not meet the requirement of our versioning granularity.
Link between message and semantic objects: when the rst messages
are created, the links between the business components and the content of
the messages are clear. This relationship must remain clear over the evolu-
tion of the repository and the messages. How can we guarantee the relational
integrity between business objects and message denitions over dierent ver-
sions?
Knowledge of the market practices: each nancial environment has its
own needs. In order to let the model evolve on the right way we need to know
the main market practices and how they are used. From a model viewpoint,
the market practices are a set of restrictions applied on a view. A view is the
projection of a subset of messages from the repository. We should be able
to maintain a coherent market practice along the dierent versions of the
messages that it constraints. Going further, we should be able to evaluate the
impact of a message change on all the market practices using this message
and also on the complete repository. This is a typical governance use case.
Governance Issues on Heavy Models in an Industrial Context 379
Content management: the documentation and the structure of the models

needs to be centralized in one place in order to promote the reusability of
message components and to control the repository content. This includes,
among others, the documentation, the search tools, the central repository,
the message model templates and the comparison tools (e.g.: nd isomorphic
components).
Auditing tools: we should be able to audit each modication in the reposi-
tory and to track back detailed information on the change such as the identity
of the requester, the version, the implementor, the impacted release, etc...
3 Solutions
The foundational element of the solution is the implementation of a meta-model
above the current standard model. This meta-model allows to manage and to
simplify the use of the standard model: instances of the meta-model are the
models of the standard, and instances of the models are the message denitions.
Both are dened in an XMI le.
Versioning and organization: based on the standards dened before, we

have developed a graphical interface built on a meta-model which allows us
to create and manage models based on the meta-model and with respect to
the standards.
Business objects: these objects are based on the semantic model. The link
between the semantic model and the message model is always maintained
thanks to the object-oriented programming methodology. Since the message
model and the semantic model are dened in the same meta-model, they can
be linked and work together. Once the link between message and semantic
is done, it is conserved.
Auditing tools: thanks to the meta-model, the objects are always linked.
All the variations of the model are based on dierences between messages.
Every denition has links to other instances of denitions. This makes pos-
sible the comparison of objects and the creation of auditing tool. It allows
to add search functionalities, impact analysis and message denitions com-
parison.
Market practices: meta-modeling is also a good choice for the creation of
market practices. These are the usages in which the message denitions are
used in practice by the users. Thus, these consist in restrictions added on
a message denition. This can be seen as elements that are added to the
base object. This is easy to accomplish thanks to the meta-modeling. The
restriction should be easy to change and to remove. We therefore keep the
initial object every time, and it becomes a restricted object.
Content management: in order to structure the documentation, the model
allows adding documentation on each object. Furthermore, using models to
organize objects and data makes things clearer for non-expert people.
The data can then be stored on a centralized way in order to promote re-usability.
Modeled architecture data storage as provided by CDO is ideal in this situation.
4 Implementation
We have developed a framework answering the governance issues, based on the

Eclipse Rich Client Platform (RCP) tools with the Eclipse Modeling Framework
(EMF). We have created a visual editor in order to manage the models very e-
ciently. Mainly based on tree and editor views, this interface is intended to draw
a graphical representation of the models. The documentation for each model
element can be added almost everywhere and can be reviewed. We developed an
authorization and authentication layer integrated with the editor. In such way,
we are able to track back any operation on models. This makes it possible to
formally separate the global standardization process from the denition of local
market practices.
5 Illustration
In this section we chose to describe two important mechanisms of the Model

editor. This description aims at giving a better understanding of the meta model
and its usage.
5.1 View Model
The View model is used for grouping elements within an high level view. Orig-
inally it was designed for resolving two important challenges of the ISO 20022
Repository: (1) nding a relevant content, as its relevance may rely on several
criteria of dierent kinds (project, business domain, publication, etc.), (2) the
need to dene ner-grained scopes, since the dictionary size will dramatically
increase in the coming years. Therefore, the view model is a mechanism for
providing a view on specic set of message components. In additionn it oers
informations to describe when this view was extracted. The root element of the
model exposed in the Figure 1 is the ViewSet, which is nothing else than a set
of views. Basically a View has a name, a description and a list of message com-
ponents. A view does not contain components, it references them. A view can
be checked out from the repository. In such a case, the editor will create a local
copy of each element. A change request can then be associated with this view.
That is why the change model is also linked with the view model. In case of
modications when the view is checked in, the user can use EMF compare and
its 3-way comparison to evaluate the changes and merge the dierent versions.
The mechanism of Publication View is based on the same concept. A publica-
tion is the mechanism by which the base standard is published, it uses the same
concepts and adds additional elements: the previous and next Publication View.
These attributes enables to link the publications between them.
Governance Issues on Heavy Models in an Industrial Context 381
Fig. 1. The view model is used for checking out content, but also for publishing new
base standard
5.2 Semantic Traces
Semantic traces aim at simplifying the understanding of the message model.

The ISO20022 repository is composed of a conceptual and a logical layer. The
rst is used for dening the normalized business model while the second layer
is used for dening message components. The message components are a view
of the business components, they make up the real message denitions used
on the network. The mapping to the business layer aims at giving semantic
meaning. In the example of the Figure 2, the PersonIdentication is the message
component while its attributes are the message elements. We have to trace the
message component to a business component, in this case the Person, but also
each message element. A message element can be traced to a business element of
the business component traced from its container (person in this case) but also
to any other business elements of any business component connected to Person
through a navigation path. For instance, a navigation path can specify that the
birthPlace message element represents the IsoCode of the birthPlace of a Person.
By linking two parts of the model that evolve at their own pace, semantic traces
can pose governance issues, namely consistency problems.
Fig. 2. The semantic trace between the business and logical layer. This trace is used
for dening the impact of an element.
Thanks to the meta-modeling approach, we could dene the concept of impact,

eg, a trace target X (a business component has an impact on a trace source y
(a message component) only if the target of y is X, and implement an impact
analyzer. Now, before any change is performed on the business model, analysts
can assess the semantic impact on message denitions.
6 Conclusion
The governance of models of signicant size is a real challenge and no frame-

work today can cover all its dierent aspects. In this case, we have developed a
simplied framework covering our prior requirements. However, there is a need
for research and industrialization in this area. It has clearly been shown that
the modeling approach brings more cohesion and clarity in the managed data.
With this problem impacting signicant models, we see how we can go back to
a more elegant solution that allows easier governance by adding abstraction and
meta-modeling.
High Quality Technical Documentation for Large
Industrial Plants Using an Enterprise Engineering and
Conceptual Modeling Based Software Solution
Steven J.H. van Kervel
Formetis BV, Hemelrijk 12 C, 5281PS Boxtel, The Netherlands

steven.van.kervel@formetis.nl
Abstract. Engineering contractors are building very large installations such as

nuclear power plants, airports, oil refineries etc. Two closely related artifacts,
the plant and the accompanying technical documentation, need to be produced.
The quality requirements, the size and the complexity of the documentation are
high and any shortcoming may lead to severe problems. State of the art IT
systems for engineering documentation fail to meet the requirements and
address only the symptoms of problems. This paper presents the underlying
scientific theories, methodology and software technology to meet the
requirements of high quality technical documentation. The conceptual modeling
methodology delivers high quality enterprise models. A software engine
executes directly these enterprise models and is the de facto IT system.
This paper is for the ER 2011 Industrial Track, describing an innovative
software artifact as a solution for a specific industrial problem.
Keywords: technical documentation, engineering contractors, enterprise

engineering, ontology, conceptual BPM modeling, DEMO methodology,
DEMO processor, IT system engineering, document information systems.
1 Introduction
Engineering contractors are designing and building very large and complex
installations such as nuclear power plants, airports, oil refineries etc. The whole plant
is described, specified in detail by technical documentation. This documentation is of
equal importance as the actual plant and should meet also high quality requirements.
This application domain is characterized by increasing size and complexity of the
plants, compliance to increasing legal and other external regulation and the increasing
need to apply and control rules for governance. This increases the overall complexity
of the documentation and the number of rules business processes- to be followed in
an exponential way. The risks, responsibilities, liabilities and the financial exposure
increase similarly. The elements of this domain are:
Plants to be designed, constructed, maintained and demolished after service life.

Technical documentation to provide an appropriate and truthful representation of
the plant during service life.
384 S.J.H. van Kervel
The production of the documentation is performed by an 'enterprise', an

engineering contractor, working according to business procedures.
The enterprise uses an IT system for the production of technical documentation.
2 The Problems and Symptoms

Technical documentation that is not appropriate, truthful, and/or also not concise,
comprehensive, consistent and coherent (the C4-ness quality criteria) causes practical
problems:
Documentation as the most important control mechanism to build the plant
(a BoM is just a part of this documentation) may cause production delays.
A technically perfect plant without proven high quality documentation may not
go into production for legal reasons.
Ambiguity and uncertainty in assignment or exclusion of responsibilities and
liabilities of stakeholders, suppliers etc, may lead to complex legal procedures.
Several symptoms of problem are mentioned in the NEMI White Paper Report,
[1]: "i) Document File type, conversion and format issues, lack of standard
formats. Paper documents; ii) Document version versus component version
issues; iii) BoM correctness issues (up to 80% error rates), often delivered by
suppliers; iv) Consistency, Completeness and Correctness problems. v) High
level of 'fire-fighting' due to waiting queues;" etc.
It is claimed that these are mostly symptoms of unrecognized underlying problems.
3 Requirements for Technical Documentation

Despite the growing complexity, documentation should meet stringent requirements:
Documentation should provide a high quality appropriate and truthful
representation of the plant during the whole life cycle of the plant and after this.
Documentation should support several active functions; validation of functional
requirements and constructional requirements by the customer; support the
construction of the plant; support the production of the plant and support
validation of the plant against the documentation. The IT system should be able
to render automatically views such as a BoM, current state of the construction,
identification of bottlenecks and support for external project management tools.
Documentation should be able to deliver automatically rendered proof of overall
verification; all business procedures must have been executed and terminated.
The overall state of the documentation can be reconstructed for any point in time.
4 State of the Art of IT Systems and Business Alignment

There is broad recognition in the literature (Standish Group 2009; Saur and
Cuthbertson 2003; Tata Consultancy 2007) that the alignment of business (design and
operation of an enterprise) and the supporting IT system versus the strategy fails. This
is explicitly the case for all intangible document-driven services (financial services,
High Quality Technical Documentation for Large Industrial Plants 385
insurance, pharmaceuticals, engineering contractors etc) that are produced

interactively with the customer. We are able to engineer high quality artifacts in many
domains such as electronics, telecommunication, cars etc. if and only if we apply the
underlying scientific foundations and modeling methodologies well. Engineering
contractors are typically not (yet) able to meet the before-mentioned requirements.
Their IT systems focus on practical solutions for symptoms of problems.
5 Root Cause of the Problems

The root cause is the lack of scientific foundations in the engineering of those
enterprises that produce document-driven services interactively with the customer.
Design science of Hevner [7] describes the engineering of artifacts (in this case
products/services, enterprises, IT systems) and claims that the engineering sciences
should also be rooted in the empirical sciences. Since enterprises are social systems
operating in "the real world" we need the behavioral sciences. For any framework,
methodology or technology that is not founded in the empirical sciences we are unable
to validate models against reality, which is mandatory in engineering, as argued by
Dietz and Hoogervorst [2]. The capability to aggregate unlimited large business process
models at runtime with formally correct execution is also mandatory for this domain.
Van Nuffel et al [4] propose enhancements for BPMN (Business Process Model
Notation, OMG) [3] for i) a lack of high quality formal languages (lack of
completeness, construct excess, construct overload, construct redundancy, ambiguity) to
represent models; ii) the inability to translate models (except small trivial models) into
reliable executable systems. The required enhancements for BPMN are not (yet)
available [4].
6 Theory, Methodology and Scientific Foundations

The proposed approach is founded on research conducted at the Delft University of
Technology and several other universities, the CIAO! Consortium [5], the Enterprise
Engineering Institute [6] and proprietary company research. The design and modeling
of the conceptual enterprise models of the documentation, the enterprise and the IT
system are all engineering artifacts and are therefor all founded on the engineering
sciences, e.g. Design Science [7] and the behavioral sciences. The applied scientific
foundation is the theory of Enterprise Ontology [8]. Enterprise ontology has by now a
well-founded ontological appropriateness and truthfulness claim based on a
reasonable set of industrial case studies. The applied methodology is DEMO (Design
and Engineering Methodology for Organizations) [8], derived from the theory of
Enterprise Ontology. DEMO delivers high quality (C4-ness; coherent, consistent,
concise and comprehensive) enterprise models in a formal language. The high quality
enterprise models enable the construction of a formally correct software engine.
7 Technical Documentation and Related IT System Engineering

A cornerstone of the DEMO conceptual modeling approach is that: i) the technical
documentation to be produced, ii) the organization or enterprise (actors, communication,
coordination of the production) that produces the documentation and iii) the supporting
IT system, are closely related engineering artifacts. Example: the engineering of a
bicycle factory is directly derived from the engineering of a bicycle. A supporting IT
system for the bicycle factory is also an engineering artifact that is directly derived from
the way a bicycle factory operates. This is common practice and successful in
manufacturing. However, for document-driven enterprises this is not (yet) applied in a
proper way due to a lack of applicable science (enterprise ontology) and methodology
(DEMO). For this domain, engineering contractors the produced technical
documentation is also controlling the production and maintenance of the engineering
contractor artifact (refinery, energy plant etc.).
For each new project these three artifacts have to be designed in advance and
represented in high quality DEMO conceptual enterprise models. Enterprises are
complex entities, recursively composed of aggregated sub-enterprises (example:
multinational-national-departmental-sub-department) Recursive modeling into finer
detail delivers finer detailed enterprise models. These aggregated conceptual models
of unlimited size and complexity specify simultaneous:
The construction and the operation of the enterprise including all communication
and coordination;
The detailed production for each actor- employee in the enterprise, and
The IT system that monitors and controls the enterprise operation.
This may seem very elaborate but these models have a high degree of reusability and
the overall modeling effort is small.
The core of the software technology is a software engine, the DEMO processor.
Edit
model
model rendering
Simulation Model
results validation
<--
DEMO
DMOL XML models
Processor Communication
model repository ==> Actor 1
& coordination
1 .. n
parsing &
Communication
model building Actor n
& coordination
DEMO
4 aspect models
Fig. 1. DEMO model simulation and validation of an (elementary) enterprise model
The DEMO processor constructs and executes DEMO models, enables model
simulation, model validation and incremental model improvement during
development (fig. 1). The development process starts with the modeling stage for an
enterprise (nested in enterprises etc.) that delivers the 4 graphical DEMO aspect
models. Then the models are translated (not programmed) on the DEMO processor in
a 1:1 process. The DEMO processor executes the enterprise model dynamically and
delivers simulation results for model validation. The execution involves all
High Quality Technical Documentation for Large Industrial Plants 387
communication and coordination in a prescriptive way between all (human) actors

(1..n) of the enterprise, similar to a workflow system.
If model validation fails the model under execution can be edited and the
simulation validation cycle is repeated. After successful validation the model is
rendered as an DMOL (DEMO Modeling Language) XML file with full state
information and stored in a model repository. At any time the original model, in its
current state, can be parsed and rebuild for further simulation. A model representation
rendered in (near) natural language enables the (re)construction of the 4 DEMO
aspect models. This process is repeated until we have a complete model repository of
all elementary enterprises, each of them producing an elementary production
component.
Communication
DMOL XML models MIS Actor 1
& coordination
model repository production
Enterprise A, actors 1 .. n
copy to instance Communication
model rendering Actor n
& coordination
<--
DMOL XML files DEMO
production instances Processor
production database ==> Communication
Actor 1
& coordination
parsing &
model building & Enterprise B, actors 1 ..
model aggregation Communication
Aggregated Actor m
& coordination
DEMO models
Fig. 2. DEMO processor in production environment
In production (fig 2) for each elementary production component a production

model instance for that elementary enterprise is created from the model repository by
a copy operation. Production instances are aggregated by the DEMO processor into a
model under execution that represent the production of all aggregated enterprises A
and B. Model building, aggregation and optional destruction is executed at runtime. In
production the DEMO processor executing the aggregated model delivers all
communication and coordination for each actor in each enterprise, as a workflow
system. For each production step descriptive data can be delivered to a MIS
(Management Information System). At any time an aggregated model can be
decomposed into its aggregating DMOL file components, stored in the production
database. When the production resumes the original production model reconstructs
itself, with full state information and continues communication and coordination.
8 State of the Art of the DEMO Processor

DEMO and enterprise ontology are a new methodology and theory, with still a small
number of industrial case studies but with convincing empirical validation [9]. The
before-mentioned application development platform has been in use since 1997 in
several large professional applications, mostly financial services. The DEMO

processor exists now as a prototype for proof of correctness. A professional
production version is under development and will be made available i) for free as a
modeling, simulation and education tool and ii) as a webservice production
environment (cloud). A major bank-insurance company made the commitment to be
the launching DEMO processor customer. Due to the nature of the application domain
of engineering contractors, the potential benefits are assumed to be there more
substantial. Interested parties are invited to discuss participation.
References
1. NEMI White Paper Report, In search of the perfect Bill of Materials (2002),
http://thor.inemi.org/webdownload/newsroom/Articles/BoMwhite
paper.pdf
2. Dietz, J.L.G., Hoogervorst, J.A.P.: Language Design and Programming Methodology.
LNCS, vol. 79. Springer, Heidelberg (1980)
3. Object Management Group Inc, 2009. Business Process Modeling Notation (BPMN)
Specifications (2009), http://www.omg.org/spec/BPMN/1.2/PDF/
4. Nuffel van, D., Mulder, H., van Kervel, S.: Enhancing the formal foundations of BPMN
using Enterprise Ontology. In: CAiSE CIAO (2009)
5. Ciao Consortium, http://www.ciaonetwork.org
6. DEMO Knowledge Centre; Enterprise Engineering institute, http://www.demo.nl
7. Hevner, A., March, S., Park, J., Ram, S.: Design science in information systems research.
MIS Quarterly 28(1) (2004)
8. Dietz, J.L.G.: Enterprise Ontology. Springer, New York (2006)
9. Mulder, J.B.F.: Rapid Enterprise Design. PhD thesis (2008); ISBN 90-810480-1-5
Publishing Open Data and Services for the Flemish
Research Information Space
Christophe Debruyne1, Pieter De Leenheer2,3, Peter Spyns4, Geert van Grootel4,

and Stijn Christiaens3
1
STARLab, Vrije Universiteit Brussel, Brussels, Belgium
2
Business Web & Media, VU University Amsterdam, Amsterdam, The Netherlands
3
Collibra nv/sa, Brussels, Belgium
4
Flemish Dept. of Economy, Science, and Innovation, Brussels, Belgium
Abstract. The Flemish public administration aims to integrate and publish all
research information on a portal. Information is currently stored according to
the CERIF standard modeled in (E)ER and aimed at extensibility. Solutions
exist to easily publish data from databases in RDF, but ontologies need to be
constructed to render those meaningful. In order to publish their data, the public
administration and other stakeholders first need to agree on a shared under-
standing of what exactly is captured and stored in that format. In this paper,
we show how the use of the Business Semantics Management method and tool
contributed in achieving that aim.
Keywords: ontology development, methodology, social process, business se-

mantics management, fact-orientation, natural language.
1 Introduction: An Innovation Information Portal for Flanders

For a country or region in the current knowledge economy, it is crucial to have a good
overview of its science and technology base to develop an appropriate policy mix of
measures to support and stimulate research and innovation. Also companies, research
institutions and individual researchers can profit from the information maintained in
such a portal. EWI1 thus decided to launch the Flanders Research Information Space
program (FRIS) to create a virtual research information space covering all Flemish
players in the field of economy, science and innovation. The current version of this
portal2 contains, for instance, mash-ups of data on key entities (such as person, organ-
ization, and project; and their relationships) on a geographical map. Another aim of
FRIS is to reduce the current administrative burden for universities as they are con-
fronted with repeatedly reporting the same information in different formats to various
institutions. Indeed, if all information would be centralized and accessible in a
uniform way, creating services for such reports would greatly facilitate the reporting
process. Before data can be centralized, this initiative faces two problems: 1)
capturing the semantics of the domain in an ontology and 2) appropriately annotate or
commit the heterogeneous data sources to that ontology.
1
The Department of Economy, Science and Innovation of the Flemish Government
http://www.ewi-vlaanderen.be/
2
http://www.researchportal.be/
390 C. Debruyne et al.
As we will explain in Section 2, integrating all information and reducing the ad-
ministrative burden faces some problems for which appropriate data governance me-
thods and tools are needed. Such method and tool is presented in Section 3 and we
end this paper with a conclusion in Section 4.
2 Problem: Heterogeneous Information Sources

Universities receiving funding from the Flemish government are asked to regularly
report the same information to different organizations (local and international). As
there is little alignment between those reports, universities are confronted with repeat-
edly sending the same information in other formats, other structures or according to
different classifications not always compatible with each other3. This creates a heavy
administrative burden on those knowledge institutions. Universities furthermore store
their information in autonomously developed information systems, adding to the com-
plexity of the problem.
As the EU also wants to track all research information in Europe, they ask all univer-
sities to report using the Common European Research Information Format (CERIF) [4],
a recommendation to EU-members for the storage and exchange of current research
information. While the CERIF model, created with Entity-Relationship (ER) diagrams,
allows for an almost unlimited flexibility on roles and classifications used with entities,
the actual approach has shown its limitations when it comes to communicating the mod-
eled domain facts to domain experts and end users. The learning curve for the domain
experts to understand the ER model and translate it back to the conceptual level is quite
steep. Fig. 1 shows some CERIF entities, their attributes and relationships.
To populate the FRIS portal with all information provided by the delivered CERIF
files and other heterogeneous sources, (i) a consensus amongst the involved parties on
a common conceptual model for CERIF and the different classifications is needed
(taking into account the non-technical expertise of most domain experts), (ii) an easy,
repeatable process for validating and integrating the data form those sources and fi-
nally (iii) using that shared understanding to publish that information as in a generic
way on the Web on which third parties can develop services (commercial or not, e.g.
to produce the different reports) as demonstrated by other Linked Data initiatives.
3 Approach: Business Semantics Management

In order to overcome the above-mentioned difficulties, all these classifications and
models need to be actualized and homogenized on a conceptual level, first within
Flanders, later with more general and international classifications. The Business Se-
mantics Management (BSM) [2] methodology was adopted to capture the domain
knowledge inside CERIF and the different classifications. BSM adopts the Semantics
of Business Vocabulary and Business Rules (SBVR) [1] to capture concepts and their
relationships in facts. SBVR is a fact-oriented modeling approach. Fact-oriented
modeling is a method for analyzing and creating conceptual schemas for information
3
Different classifications are used within Flanders: IWETO discipline codes, IWETO science
domains, VLIR scientific disciplines, IWETO application domains, SOOI (based on the IWI-
Web of Science codes), NABS (used for budgeting) and FOS (Fields of Science), etc.
Publishing Open Data and Services for the Flemish Research Information Space 391
systems starting from (usually binary) relationships expressed as part of human-to-

system communication. Using concepts and a language people are intended to readily
understand, fact-oriented modeling helps ensuring the quality of a database applica-
tion without caring about any implementation details of the database, including e.g.
the grouping itself of linguistic concepts into records, relations, In fact-oriented
approaches, every concept plays roles with other concepts, and those roles may be
constrained. It is those constraints that allow the implementer of a database (or in fact
an algorithm) to determine whether some linguistic concept becomes an entity or an
attribute, or whether a role turns out to be an attribute relationship or not. This is dif-
ferent from other approaches such as (E)ER and UML, where these decisions are
made at design time.
Fig. 1. The CERIF entity cfProject and its relationship with the entity cfProject_Classification
(linked by the two identifiers of the linked entities). A CERIF relationship is always semanti-
cally enriched by a time-stamped classification reference. The classification record is main-
tained in a separate entity (cfClassification) and allows for multilingual features. Additionally,
each classification record or instance requires an assignment to a classification scheme (cfClas-
sificationSchemeIdentifier).
Business semantics management is the set of activities (depicted in Fig. 2) to bring

business stakeholders together to collaboratively realize the reconciliation of their hete-
rogeneous metadata; and consequently the application of the derived business semantics
patterns to establish semantic alignment between the underlying data structures.
Fig. 2. Business Semantics Management overview: semantic reconciliation and application
The first cycle, semantic reconciliation, is supported by the Business Semantics

Glossary (BSG) shown in Fig. 3. This figure shows a screenshot of the term Project
(within the Project vocabulary of CERIF speech community that is part of the
FRIS semantic community). The software is currently deployed at EWI for manag-
ing business semantics of CERIF terms. A term (here Project) can be defined using
one or more attributes such as definitions, examples, fact types, rules sets, categoriza-
tion schemas (partly shown in taxonomy), and finally milestones for the lifecycle.
Project in this case is a subtype of Thing and has two subtypes: large academic
project and small industrial project. Re governance: in the top-right corner is indi-
cated which member in the community (here Pieter De Leenheer) carries the role of
steward, who is ultimately accountable for this term. The status candidate indi-
cates that the term is not yet fully articulated: in this case Project only 37.5%. This
percentage is automatically calculated based on the articulation tasks that have to be
performed according to the business semantics management methodology. Tasks are
related to defining attributes and are distributed among stakeholders and orchestrated
using workflows.
Fig. 3. Screenshot of Collibras BSG supporting the semantic reconciliation process of the
BSM methodology by providing domain experts means to enter simple key facts in natural
language, natural language definitions on facts and terms in those facts as well as constraints.
Applying BSM results in a community driven (e.g. representing the different clas-
sifications and models mentioned earlier), iteratively developed shared and agreed
upon conceptual model in SVBR. This model then is automatically converted in a
CERIF-based ER model and RDFS/OWL for Web publishing. Fig. 4 shows a part of
the generated OWL from the concept depicted in the previous figure. In this figure,
Publishing Open Data and Services for the Flemish Research Information Space 393
we see that Project is a Class and all instances of that class are also instances of
entities with at least one value for the property ProjectHasTitle, one of the rules
expressed in SBVR in Fig. 3 (see general rule sets).
Fig. 4. Screenshot of the OWL around Project generated by BSG. In this picture, we see that
Project is a Class and all instances of that class are also instances of entities with at least
one value for the property ProjectHasTitle.
The contents of the databases to be annotated can be published with off-the-shelve

solutions such as D2R Server4. D2R Server generates an RDF a mapping for trans-
forming the content of a database into RDF triples. This mapping also described in
RDF contains a skeleton RDFS of classes and properties that are based on the
database schema. Fig. 5 below depicts a part of the generated mapping file around the
table containing information around projects.
@prefix map: <file:///.../OSCB/d2r-server-0.7/map.n3#> .

@prefix vocab: <http://192.168.0.136:5432/vocab/resource/> .
@prefix d2rq: <http://www.wiwiss.fu-berlin.de/suhl/bizer/D2RQ/0.1#> .
...
map:CFPROJ a d2rq:ClassMap;
d2rq:dataStorage map:database;
d2rq:uriPattern "CFPROJ/@@CFPROJ.CFPROJID|urlencode@@";
d2rq:class vocab:CFPROJ;
d2rq:classDefinitionLabel "EWI.CFPROJ";
...
Fig. 5. Part of the generated mapping file by D2R server, it maps the table CFProj to the
generated CFPROJ RDFS class. It uses the primary key to generate a unique ID and the class
definition label is taken from the tables name.
Even though classes and properties are generated and populated with instances,
these RDF triples are not semantic as they stem from one particular information sys-
tem(s database schema). That RDFS is then aligned with the generated RDFS/OWL
classes and properties generated from the BSM ontology. The commitments described
in the previous section are used as a guideline to create this alignment. Fig. 6 below
shows the changes (highlighted) made on the generated mapping file with the ontolo-
gy. The ontology can then be used to access the data.
4
http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/
@prefix ont: <file:///.../Project.rdf#> .

...
map:CFPROJ a d2rq:ClassMap;
d2rq:dataStorage map:database;
d2rq:uriPattern "CFPROJ/@@CFPROJ.CFPROJID|urlencode@@";
d2rq:class ont:Project;
d2rq:classDefinitionLabel "Project";
...
Fig. 6. Modified mapping file with the ontology exported from BSG. An extra namespace (for
the exported ontology) is added and the generated classes and properties are appropriately
annotated with that ontology.
4 Conclusion: Inclusion of the Method and Tool in the Portals

Architecture
This paper presented a case of applying Business Semantics Management (BSM) in a
Flemish public administration for the creation of an innovation information portal.
The purpose of this portal is to integrate and provide a uniform access mechanism to
all research information in Flanders as RDF, allowing third parties to create services
around that data (e.g. reporting) and removing some of the administrative burden of
universities. Business Semantics Management method and tools helped in construct-
ing an ontology and was well received by the users.
Publication of data in relational databases became fairly easy with solutions such
as D2R server. The triples generated by such tools are rendered meaningful by
exporting the ontology into an implementation in RDFS/OWL and use these to anno-
tate the instances, since the ontology is the result of collaboration and meaning
agreements between stakeholders representing autonomously developed information
systems. Future work in that area consists of developing a flexible layer between the
generated RDF triples from existing tools and the generated ontology from the Busi-
ness Semantics Glossary.
References
[1] OMG SBVR, version 1.0, http://www.omg.org/spec/SBVR/1.0/
[2] De Leenheer, P., Christiaens, S., Meersman, R.: Business semantics management: A case
study for competency-centric HRM. Computers in Industry 61(8), 760775 (2010)
[3] Halpin, T.: Information Modeling and Relational Databases. Morgan Kaufmann, San
Francisco (2008)
[4] Jrg, B.: CERIF: The common European research information format model. Data Science
Journal (9), 2431 (2010)
[5] Jrg, B., van Grootel, G., Jeffery, K.: Cerif2008xml - 1.1 data exchange format specifica-
tion. Technical report, euroCRIS (2010)
[6] Spyns, P., Tang, Y., Meersman, R.: An ontology engineering methodology for DOGMA.
Applied Ontology 3(1-2), 1339 (2008)
[7] Spyns, P., van Grootel, G., Jrg, B., Christiaens, S.: Realising a Flemish government in-
novation information portal with business semantics management. In: Stempfhuber, M.,
Thidemann, N. (eds.) Connecting Science with Society. The Role of Research Information
in a Knowledge-Based Society: University of Aalborg, Aalborg University Press (2010)
Author Index
Abell
o, Alberto 108 Gailly, Frederik 163
Aguilar, Jose Alfonso 14 Garca-Ranea, Raul 323
Aguilera, David 323 Garrigos, Irene 14, 336
Ait-Ameur, Yamine 98 Geerts, Guido L. 291
Glorio, Octavio 336
Bach Pedersen, Torben 364 Golfarelli, Matteo 358
Bakhtouchi, Abdelghani 98 G
omez, Cristina 323
Bartie, Phil 231 Guerra, Francesco 328
Battaglia, Antonino 358 Guizzardi, Giancarlo 161
Bellatreche, Ladjel 98
Bergamaschi, Sonia 328 Hallot, Pierre 230, 322
Bhatt, Ankur 343 Hernandez, Inma 345
Bianchini, Devis 34 Hernandez, Paul 336
Billen, Roland 230, 322 Houben, Geert-Jan 1
Bontemps, Yves 377
Boukhebouze, Mohamed 24 Jansen, Slinger 151
Brdjanin, Drazen 292 Jouault, Frederic 332
Briand, Lionel 338 Jureta, Ivan J. 44
Brisaboa, Nieves R. 241 Kabbedijk, Jaap 151
Cabot, Jordi 332 K
ak
ol
a, Timo K. 119
Caniupan, Monica 75 K
astner, Christian 130
Chen, Tao 251 Khan, Ateeq 130
Christiaens, Stijn 389 Kingham, Simon 231
Clasen, Caue 332 K
oppen, Veit 130
Clementini, Eliseo 231 Lechtenborger, Jens 65
Corchuelo, Rafael 345
Lefons, Ezio 86
Dau, Frithjof 45 Levin, Ana M. 203
De Antonellis, Valeria 34 Liddle, Stephen W. 183
Debruyne, Christophe 389 Lieto, Antonio 210
de Hemptinne, Gregoire 377 Linner, Konrad 55
Delbaere, Marc 377 Loebe, Frank 193
De Leenheer, Pieter 389 Lonsdale, Deryle W. 183
de Oliveira, Jose Palazzo Moreira 2 Lopes, Giseli Rabello 2
De Troyer, Olga 120 Lozano, Angela 141
Di Tria, Francesco 86 Luaces, Miguel R. 241
Lukyanenko, Roman 220
Egenhofer, Max J. 261
El Dammagh, Mohammed 120 Maric, Slavko 292
Embley, David W. 183 Marth, Kevin 312
Erbin, Lim 24 Masolo, Claudio 173
Mazon, Jose-Norberto 14, 65, 336
Faulkner, Stephane 44 McGinnes, Simon 4
Frasincar, Flavius 1 Melchiori, Michele 34
Frixione, Marcello 210 Mens, Kim 118
396 Author Index
Middelfart, Morten 364 Schneider, Markus 251

Mitsch, Stefan 271 Schre, Michael 55
Moreau, Guillaume 281 Schwinger, Wieland 271
Moro, Mirella Moura 2 Sertkaya, Baris 45
Servières, Myriam 281
Neto, Waldemar Pires Ferreira 24 Simitsis, Alkis 357
Neumayr, Bernd 55 Skhiri, Sabri 377
Skyberg Knutsen, Torbjrn 338
Olive, Antoni 323, 349, 353 Spyns, Peter 389
Sturm, Arnon 118
Panesar-Walawege, Rajwinder Kaur
338 Tangorra, Filippo 86
Parsons, Jerey 220 Thiran, Philippe 1
Pastor, Oscar 161 Tort, Albert 349
Poels, Geert 163 Tourwe, Tom 371
Tran, Nam-Luc 377
Reinhartz-Berger, Iris 118, 302 Trujillo, Juan 65
Reitsma, Femke 231 Tsiporkova, Elena 371
Ren, Shangping 312 Tsoury, Arava 302
Retschitzegger, Werner 271
Ritter, Daniel 343 Vaisman, Alejandro 75
Rivero, Carlos R. 345 van der Kroon, Matthijs 203
Rizzi, Stefano 358 van Grootel, Geert 389
Rodrguez, M. Andrea 241 van Kervel, Steven J.H. 383
Romero, Oscar 108 Van Mingroot, Hans 357
Rossi, Matti 291 Velegrakis, Yannis 328
Rota, Silvia 328 Villegas, Antonio 353
Ruiz, David 345
Wand, Yair 161
Saake, Gunter 130
Sabetzadeh, Mehrdad 338 Zaki, Chamseddine 281
Sancho, Maria-Ribera 349, 353 Zim
anyi, Esteban 44, 230

Bok:978 3 642 24574 9 PDF

Uploaded by

Copyright:

Available Formats

Bok:978 3 642 24574 9 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bok:978 3 642 24574 9 PDF

Uploaded by

Copyright:

Available Formats

Lecture Notes in Computer Science 6999

Commenced Publication in 1973

ER 2011 Workshops FP-UML, MoRE-BI,

Claudia Bauzer Medeiros

Hans Van Mingroot

ISSN 0302-9743 e-ISSN 1611-3349

Library of Congress Control Number: 2011937539

CR Subject Classication (1998): H.4, H.3, I.2, D.2, C.2, H.5

LNCS Sublibrary: SL 3 Information Systems and Application, incl. Internet/Web

Springer-Verlag Berlin Heidelberg 2011

WISM: Web Information Systems Modeling

In all, 31 workshop papers were accepted from a total of 88 submitted, making

July 2011 Olga De Troyer

Oscar Pastor Polytechnic University of Valencia, Spain

Sandro Bimonte Cemagref, France

Anthony Cleve University of Namur FUNDP, Belgium

Nicola Guarino Laboratory for Applied Ontology (ISTC-CNR),

Ricardo Rodrigues Ciferri UFSCar, Brazil

Je Parsons Memorial University of Newfoundland, Canada

Posters and Demonstrations

WISM 2011 - The Eighth International Workshop

Social Networks and Data Interoperability in Web

Conceptual Modelling for Web Information Systems: What Semantics

Requirements Analysis, User Interaction, and

Yet Another BPEL Extension for User Interactions . . . . . . . . . . . . . . . . . . . 24

Semantics-Enabled Web API Organization and Recommendation . . . . . . . 34

MORE-BI 2011 - The First International Workshop

Formal Concept Analysis for Qualitative Data Analysis over Triple

Semantic Cockpit: An Ontology-Driven, Interactive Business

A Model-Driven Approach for Enforcing Summarizability in

Repairing Dimension Hierarchies under Inconsistent Reclassication . . . . 75

GrHyMM: A Graph-Oriented Hybrid Multidimensional Model . . . . . . . . . 86

Ontologies and Functional Dependencies for Data Integration and

A Comprehensive Framework on Multidimensional Modeling . . . . . . . . . . 108

Variability@ER11 - Workshop on Software

ISO Initiatives on Software Product Line Engineering: Vision and

Feature Modeling Tools: Evaluation and Lessons Learned . . . . . . . . . . . . . 120

Service Variability Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

An Overview of Techniques for Detecting Software Variability Concepts

Variability in Multi-tenant Environments: Architectural Design

Onto.Com 2011 - International Workshop on

Experimental Evaluation of an Ontology-Driven Enterprise Modeling

Levels for Conceptual Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Principled Pragmatism: A Guide to the Adaptation of Ideas from

Ontological Usage Schemes: A Working Proposal for the Ontological

Gene Ontology Based Automated Annotation: Why It Isnt Working . . . 203

Formal Ontologies, Exemplars, Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Unintended Consequences of Class-Based Ontological Commitment . . . . . 220

SeCoGIS 2011 - The Fifth International Workshop

Referring Expressions in Location Based Services: The Case of the

Cognitive Adequacy of Topological Consistency Measures . . . . . . . . . . . . . 241

The Neighborhood Conguration Model: A Framework to Distinguish

Reasoning with Complements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Towards Modeling Dynamic Behavior with Integrated Qualitative

Transforming Conceptual Spatiotemporal Model into Object Model

FP-UML - The Seventh International Workshop on

Preface to FP-UML 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

On Automated Generation of Associations in Conceptual Database

Specication and Utilization of Core Assets: Feature-Oriented vs.